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

21–30 of 41 posts

Re: Porting a Ray Tracer to Rust, Part 1

#21

Post by yuriks »

berkut wrote: post #20
yuriks wrote: post #17

I also did a similar thing with SmallVCM, another "educational" ray-tracer: https://github.com/yuriks/SmallVCM-rs There is also a written report with my experience and benchmark results, but unfortunately it's in Portuguese: https://github.com/yuriks/tg-yuriks-2014b/blob/master/final/... One thing that surprised me a lot is that Rust ended up being noticeably faster than C++ (around 20%) even when compared with clang…

Do you mean compared to C++ compiled with LLVM (as opposed to GCC)? I've found that LLVM is generally faster than GCC and in some cases significantly so.

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

Re: Porting a Ray Tracer to Rust, Part 1

#22

Post by darkpore »

yuriks wrote: post #21
berkut wrote: post #20

Earlier quoted context omitted.

Do you mean compared to C++ compiled with LLVM (as opposed to GCC)? I've found that LLVM is generally faster than GCC and in some cases significantly so.

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? :)

Re: Porting a Ray Tracer to Rust, Part 1

#23

Post by CyberDildonics »

berkut wrote: post #15
CyberDildonics wrote: post #14

So one important question about Rust that is relevant here is how it handles dynamic stack allocation. It is in the language? C++ has alloca of course but needs a couple of macros to work across compilers. Memory allocation ends up being a very big performance concern in renderers. PBRT uses both memory arenas and an ALLOCA macro.

It's quite possible to not use alloca(), but just use C++'s placement new operator to re-use memory already allocated on the stack. I'm not sure if Rust has something similar to placement new, but I'm sure custom allocators (for memory arenas) are possible in Rust.

That is a valid and useful technique, but being able to dynamically allocate stack memory in the first place is separate from using placement new on stack memory.

Re: Porting a Ray Tracer to Rust, Part 1

#24

Post by berkut »

CyberDildonics wrote: post #23
berkut wrote: post #15

Earlier quoted context omitted.

It's quite possible to not use alloca(), but just use C++'s placement new operator to re-use memory already allocated on the stack. I'm not sure if Rust has something similar to placement new, but I'm sure custom allocators (for memory arenas) are possible in Rust.

That is a valid and useful technique, but being able to dynamically allocate stack memory in the first place is separate from using placement new on stack memory.

Of course, I was just pointing out it's not always necessary to use alloca - I've written a production-level path-tracer without needing to allocate stack memory dynamically.

Re: Porting a Ray Tracer to Rust, Part 1

#25

Post by CyberDildonics »

berkut wrote: post #19
tunnuz wrote: post #16

Earlier quoted context omitted.

Fun fact: in most physically based ray tracers, the photons are shot by the camera, bounce on various objects, and finally hit a light (or a sky box), whose energy is then back propagated along the chain of bounces. In physics everything is reversed, the photons are generated by a light, and bounce on various objects (which change their energy by absorbing it) before ending up in a camera sensor. In fact, some advanc…

Erm... Photon mapping uses "forward" path tracing to trace photons from the lights, not the camera. In conventional (uni-directional) path tracing, rays are shot from the camera only, and bounce around the scene (other than for light visibility testing). Bi-directional path tracing uses rays originating at both the camera and light sources going in opposite directions. VCM is a combination of Bi-directional path trac…

I think he was talking about rays when he said 'photons', not photon mapping in regards to the specific technique.

Re: Porting a Ray Tracer to Rust, Part 1

#26

Post by steveklabnik »

berkut wrote: post #15
CyberDildonics wrote: post #14

So one important question about Rust that is relevant here is how it handles dynamic stack allocation. It is in the language? C++ has alloca of course but needs a couple of macros to work across compilers. Memory allocation ends up being a very big performance concern in renderers. PBRT uses both memory arenas and an ALLOCA macro.

It's quite possible to not use alloca(), but just use C++'s placement new operator to re-use memory already allocated on the stack. I'm not sure if Rust has something similar to placement new, but I'm sure custom allocators (for memory arenas) are possible in Rust.

User-defined placement new and custom allocators for existing data structures are still being worked on. `box` can do a form of placement new already, and while you can use your own allocator, you can't use it with already-existing types.

Re: Porting a Ray Tracer to Rust, Part 1

#27

Post by steveklabnik »

yuriks wrote: post #18
CyberDildonics wrote: post #14

So one important question about Rust that is relevant here is how it handles dynamic stack allocation. It is in the language? C++ has alloca of course but needs a couple of macros to work across compilers. Memory allocation ends up being a very big performance concern in renderers. PBRT uses both memory arenas and an ALLOCA macro.

I might be mistaken about this, but I believe they plan on implementing support for this at some point.

It's on the todo list.

Re: Porting a Ray Tracer to Rust, Part 1

#28

Post by kzrdude »

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.

Re: Porting a Ray Tracer to Rust, Part 1

#29

Post by losvedir »

programmer_dude wrote: post #8
tomjakubowski wrote: post #5

Earlier quoted context omitted.

You can take it up with these guys. http://www.amazon.com/Physically-Based-Rendering-Second-Edit...

Yes, I have seen that. This is why asked what those words meant. The words "physically" and "based" as they are used here do not fit my understanding of the English grammar. I am not a native English speaker. I just want to know why is this sequence of words meaningful?

I'm a native English speaker, but have no experience with rendering or this topic.

To my ears, "Physically Based Rendering" does sound a little stilted. I don't immediately have an intuitive grasp of what it means based on words alone.

It doesn't sound like it means "physics based rendering", which would mean "a rendering process that uses physics at its core."

Rather, the attachment I have to the word "physically" is more along the lines of "metaphorical vs. physical" (i.e. "concrete", "real", "observable"). So along those lines, my natural understanding of "Physically based" rendering would be a process not based on abstract mathematical principles, but one that tries to take the physical properties of objects into account. So, maybe to render a rock you'd think about what it's made of, if moss grows on it, etc.

(I don't know if that's actually what PBR means, just that's what it sounds like to me as a native speaker.)

Re: Porting a Ray Tracer to Rust, Part 1

#30

Post by damon_c »

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

Post reply on HN