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

11–20 of 41 posts

Re: Porting a Ray Tracer to Rust, Part 1

#11

Post by rejschaap »

programmer_dude wrote: post #2

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

"Physically Based" has somewhat turned into the CG/gamedev version of "Big Data". I remember reading a paper about physically based facial animation or modelling. Which uses the concepts of facial tissue and muscles to realistically render faces. It went all downhill after that though. We'll probably soon see a re-release of asteroids called "Physically Based Asteroids" because there is a multiplication in there somewhere that reminded the author of Newtons second law.

Re: Porting a Ray Tracer to Rust, Part 1

#12

Post by CyberDildonics »

programmer_dude wrote: post #2

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

In addition to other answers, physically based rendering pragmatically means that renders have the potential to be a correct simulation of photography up to a certain point. For many many years rendering for film didn't even use ray tracing at all. Lights were a single point in space with no area and shadows were done with shadow maps. Now most film rendering has shifted to using area lights, ray traced visibility to different points on the light, and shaders that (mostly) preserve energy (they can't reflect more light than what is incoming). Even game engines like Unreal 4 take these into consideration and make very crafty and pragmatic tradeoffs to maintain speed and the principles that give an increase in realism.

Re: Porting a Ray Tracer to Rust, Part 1

#13

Post by CyberDildonics »

rejschaap wrote: post #11
programmer_dude wrote: post #2

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

"Physically Based" has somewhat turned into the CG/gamedev version of "Big Data". I remember reading a paper about physically based facial animation or modelling. Which uses the concepts of facial tissue and muscles to realistically render faces. It went all downhill after that though. We'll probably soon see a re-release of asteroids called "Physically Based Asteroids" because there is a multiplication in there some…

In rendering specifically it isn't nearly as much of an ambiguous buzzword.

Re: Porting a Ray Tracer to Rust, Part 1

#14

Post by CyberDildonics »

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.

Re: Porting a Ray Tracer to Rust, Part 1

#15

Post by berkut »

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.

Re: Porting a Ray Tracer to Rust, Part 1

#16

Post by tunnuz »

CyberDildonics wrote: post #12
programmer_dude wrote: post #2

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

In addition to other answers, physically based rendering pragmatically means that renders have the potential to be a correct simulation of photography up to a certain point. For many many years rendering for film didn't even use ray tracing at all. Lights were a single point in space with no area and shadows were done with shadow maps. Now most film rendering has shifted to using area lights, ray traced visibility to…

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 advanced ray tracers follow this second model, but they are much much harder to build, and, in general, require higher computational power.

If you are looking for a good (you can build your own ray tracer) but not too hostile intro to physics based rendering I recommend "Advanced Global Illumination" by Dutre and others (http://www.amazon.com/Advanced-Global-Illumination-Second-Ed...). It is actually quite a fascinating computer science application, and you can produce beautiful images with it.

Re: Porting a Ray Tracer to Rust, Part 1

#17

Post by yuriks »

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.

Re: Porting a Ray Tracer to Rust, Part 1

#18

Post by yuriks »

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.

Re: Porting a Ray Tracer to Rust, Part 1

#19

Post by berkut »

tunnuz wrote: post #16
CyberDildonics wrote: post #12

Earlier quoted context omitted.

In addition to other answers, physically based rendering pragmatically means that renders have the potential to be a correct simulation of photography up to a certain point. For many many years rendering for film didn't even use ray tracing at all. Lights were a single point in space with no area and shadows were done with shadow maps. Now most film rendering has shifted to using area lights, ray traced visibility to…

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 tracing and photon mapping.

Re: Porting a Ray Tracer to Rust, Part 1

#20

Post by berkut »

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.

Post reply on HN