Comment by alkonaut | Hacker News Reader

Comment by alkonaut | Hacker News Reader

Parent Full thread

Writing one is fun because it’s trivial to start, but you can be sure that there are features that are simply beyond your capability almost no matter how good you are. And it gets hard fast. It’s also very cross disciplinary if you like math, physics and system level programming. Those of use who wrote ray tracers are probably the same that code toy synthesizers. We like numbers. Once you made one it’s also an excellent way of learning a new language to make a new one.

Nice challenges include:

add parallellism. Traversing a tree hierarchy efficiently with SIMD or GPU code isn’t trivial. (I tend to dodge this part of the problem by using intels simd lib Embree)

Or make it spectral (trace with wavelengths instead of simple colored light, to get effects such as rainbows in refractions). This is actually reasonably simple - but then you realize it ruins your hope of parallelizing efficiently as the rays diverge when they refract!

Or implement realistic subsurface scattering. Doing it physically right means your render will never finish, so it’s back to inventing the most clever hacks - just like rasterizing!

> your render will never finish with physically correct subsurface scattering

did you mean "will take a very long time", or "won't actually terminate"? if the latter, why? that sounds really interesting!

Path tracing in general do not technically terminate since it's trying to approach an integral (the rendering equation) with sums. It's up to the user to determine the sample per pixel threshold with which he is satisfied. The goal is often to not have too much noise for the time spent. It's not easy because noise reduction over time tends to be logarithmic.

This. Doing “physical” SSS means shooting rays stochastically into the medium (skin, milk, marble) and having them bounce around inside, emerging at a random location, but more likely close to where it entered.

That type of tracing will simply not produce a reasonable result in a reasonable time. You have to cheat.

That's not completely true - at least in the VFX industry we've been doing brute-force SSS (with multiple scattering) for more than two years now in some cases. Yeah, it can be slow depending on the MFP, but it's usable...

Cheats like Dipole/Dwivedi are still used when they can be, but they often have artefacts and aren't completely correct, so they're starting to be avoided now.

Dwivedi is brute force. It’s just a sampling strategy.

True, but it's biased, which still causes trouble with some edge cases, depending on how/where you bias towards - biasing towards point-of-entry isn't always better than not biasing depending on where the lights are, and it's cumbersome to set up for artists (depending on where you bias towards).

Interesting, any particular renderers that do this?

To add some challenges to your list:

- implement a bidirectional path tracer to increase convergence speed

- implement multiple importance sampling. It's a simple concept that I found astonishingly hard to implement in practice.

- implement an acceleration structure (like a BVH) that builds and caches efficiently. Can you make it fast enough to have animation?

- implement shader based unit tests to ensure correctness. Thus is also surprisingly hard.

Reply on news.ycombinator.com