Hacker News Reader

Comment by kzrdude | Hacker News Reader

Some thoughs about composition and inheritance.

What do you think about handling the missing `instance` member from DifferentialGeometry by splitting it into two types, PreDifferentialGeometry without this member, and DifferentialGeometry which has two members: the Pre- struct and the instance member?

This way we move the missing `instance` information from the value space to the type space.

If there are significant methods called on both the Pre- and full version of the struct, we can even impl Deref on DifferentialGeometry so that it calls methods on PreDifferentialGeometry automatically.

View on HN

Author here, I'm not quite sure I follow. Would this then have the Sphere's and Instance's intersect implementations differ, one returning PreDifferentialGeometry and one returning DifferentialGeometry? I thought about changing the instance implementations to return different types but later when we want to put both our geometry instances and geometry itself (triangles in a mesh) into bounding volume hierarchies I think we'd run into trouble.

Would GeometryInstances go directly into an acceleration structure? Surely objects which point to the geometryinstance and each have a worldspace transform are what go in the scene level acceleration structure...

Generally it's advisable to templatize acceleration structures so they can natively cope with triangles, objects and possibly other primitives (spheres and curves) separately.

Right, the instances go into a scene level acceleration structure and for each triangle mesh we build an object level acceleration structure on the triangles. I was planning to do something like a BVH<T: Geometry> so then I don't need a separate BVH type for instances and triangles, since Instance implements the Geometry trait. I'm not sure if there's a better alternative that would help get around the DifferentialGeometry issue since in this case the instance members of geometry types (Spheres, Triangles) and Instances must have the same signature.

Is it all that important to return the instance in the DifferentialGeometry? It seems more straightforward to just apply the appropriate inverse transform on hit point and normal vector on the way back out.

In my ray-tracer (Glome), I treat instances as just a container for some other object along with a transformation matrix, that itself behaves like a regular object. Every kind of object has a method to construct a bounding box, so that when building an acceleration structure that contains instances, if I remember correctly, I take the 8 corners of the bounding box of the contained object, transform them, and constructs a new bounding box around the transformed points. It's not optimal, but it works okay.

Another way of working around your problem is to just pass the current instance (or a list of instances) as an argument to your ray intersection function. (I use a similar trick for textures, and also for a tagging scheme where I can apply arbitrary tags to objects and then pass back a list of all the tags of objects that the ray hit when I return a ray intersection.)

https://github.com/jimsnow/glome

It sounds like our instance types will end up being a bit different. Right now we don't need to send the hit instance back with the differential geometry since it doesn't tell us anything extra but later we'll attach different materials and lights to instances of the same geometry and will then need access to the hit instance so we can compute the material properties.

Sending the instance to the geometry to fill it out in the struct is a good idea, if Rust had default parameter support I'd do this and have the instance's intersect just default to None and pass itself to the geometry's intersect. Then the functions would have the same signature and we could mark the case of a None instance in geometry as unreachable.

Reply on news.ycombinator.com