Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting a Ray Tracer to Rust, Part 1

willusher.io

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Porting a Ray Tracer to Rust, Part 1

#31

Post by darkpore »

damon_c wrote: post #30
programmer_dude wrote: post #2

What is physically based rendering? What do the terms physically and based mean here?

One of the main concepts in physically based rendering, more than whether it uses path tracing or ray tracing or global illumination, is the notion of correctly modeled energy conservation with respect to the rendering of surfaces. have a look at this link: https://support.solidangle.com/display/AFMUG/Standard

Rather ironically, Arnold's standard shader still has bugs meaning its Cook-Torrance microfacet model isn't completely energy conserving at glancing angles...

Re: Porting a Ray Tracer to Rust, Part 1

#32

Post by damon_c »

darkpore wrote: post #31
damon_c wrote: post #30

Earlier quoted context omitted.

One of the main concepts in physically based rendering, more than whether it uses path tracing or ray tracing or global illumination, is the notion of correctly modeled energy conservation with respect to the rendering of surfaces. have a look at this link: https://support.solidangle.com/display/AFMUG/Standard

Rather ironically, Arnold's standard shader still has bugs meaning its Cook-Torrance microfacet model isn't completely energy conserving at glancing angles...

Interesting. It's been around long enough you'd think they would have worked out those details. I just linked it because I felt it gave the clearest explanation of the concept.

Re: Porting a Ray Tracer to Rust, Part 1

#33

Post by Twinklebear »

kzrdude wrote: post #28

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…

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.

Re: Porting a Ray Tracer to Rust, Part 1

#34

Post by kibwen »

darkpore wrote: post #22
yuriks wrote: post #21

Earlier quoted context omitted.

Yes, I compared Rust and Clang using similar LLVM versions and the Rust version of the code consistently beat Clang.

Not the same version then? :)

For the moment Rust is using a custom fork of LLVM while waiting for its patches to be upstreamed.

Re: Porting a Ray Tracer to Rust, Part 1

#35

Post by darkpore »

Twinklebear wrote: post #33
kzrdude wrote: post #28

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…

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 th…

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.

Re: Porting a Ray Tracer to Rust, Part 1

#36

Post by Twinklebear »

darkpore wrote: post #35
Twinklebear wrote: post #33

Earlier quoted context omitted.

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 th…

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 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.

Re: Porting a Ray Tracer to Rust, Part 1

#37

Post by elihu »

Twinklebear wrote: post #33
kzrdude wrote: post #28

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…

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 th…

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

Re: Porting a Ray Tracer to Rust, Part 1

#39

Post by Twinklebear »

elihu wrote: post #37
Twinklebear wrote: post #33

Earlier quoted context omitted.

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 th…

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…

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.

Post reply on HN