Comment by jeroenhd | Hacker News Reader

Comment by jeroenhd | Hacker News Reader

That all depends on innovation with hardware manufacturers. For a computer graphics course, I've written a ray tracer in C# with some compute shades that will run with 10 to 15fps in a window on my 7700k and GTX1080. Not particularly impressive, no, but thirty years ago games would run this speed on similarly priced hardware.

Where the traditional rendering code is all based on hacks and tricks that simulate real life, raytracing is simply a set of formulas borrowed from a physics textbook. An engine casting more realistic shadows than a ten million lines of code rendering library can take less than a thousand lines of code.

The current raytracing acceleration is intended to boost some highlights and shadows in practice. The hardware isn't powerful enough or optimised for rendering real, full-screen games. Even a 3090 will have trouble rendering some Minecraft scenes, for example.

If the right hardware ever becomes available for the right price with enough consumers, proper raytracing engines will be feasible and complicated render paths will eventually be much simplified. Perhaps not to the point that they can be, no, but they'd be much simpler than the engines we're using now. We won't be getting Disney levels of quality, even at our own computers' resolution, but we don't need that. Equivalent to today's graphics but with proper lighting everywhere is an amazing graphical advancement already. Time will tell if that will ever happen.

> The current raytracing acceleration is intended to boost some highlights and shadows in practice.

A couple of days ago, while gaming with a few friends and noticing a transparency ordering issue in the game we played and explaining to them, how and why that happens I realized something:

The raytracing accelerators we now have at our disposal can also be used to implement proper primitive level transparency ordering on the GPU; even if you don't spawn secondary rays, just being able to do a sparse ray-triangle hit test through the whole scene building the render order list in situ.

Unfortunately it's still extremely expensive to do so. DXR documentation tells you to keep any hit shaders simple.

It's also possible to fix transparency ordering in rasterization using OIT and there is some hardware support for it (ROV), but it's also expensive and can be hard to do right so many games choose rough sorting

Transparency is still very expensive unfortunately. DICE spoke about it a GDC talk last year and recommended that the any hit shaders that are used for alpha testing (i.e., transparency) should be avoided if possible since they're rather expensive.

Their big problems is trees, since leaves modeled as flat squares with their the actual leaf shapes in textures (that are completely transparent around the leaves).

"Trees are our biggest problem in ray tracing. No matter what we do they're by far the slowest thing to trace, and they're much worse than on rasterizer, and if you have any ideas of how to ray trace trees efficiently, we're very happy to hear them. We've asked a lot of very smart people and no one has come up with a good answer yet. You can choose between geometry and alpha testing and both are kinda crap." - It Just Works: Ray-Traced Reflections in 'Battlefield V', GDC 2019.

Naive raytracers fall down on many edge-cases and need a ton of optimizations that might not quite qualify as hacks but still drive up complexity a lot. And then you can add proper hacks like ML-based denoising on top.

Hi, could you or someone else with the right knowledge give some examples of those optimizations/hacks for ray tracers or point me to some place that explains those in more detail? Thanks in advance.

That's an entire research/engineering field. I guess you can read/view SIGGRAPH papers and presentations to get an idea what they're doing to achieve realtime performance.

Common things that make a scene too difficult to handle for brute force sampling approaches: caustics, difficult to reach light sources (small or behind openings), many light sources, camera or motion blur, volumetric materials, etc. Algorithms approximating the behavior of real materials also is a complex topic, e.g. skin or hair are handled separately from dielectric or metallic surface models. Some optimizations can solve one problem well in isolation but fail when encountering a combination of them.

Here's one that tries to solve caustics and small light sources at the same time: https://cgg.mff.cuni.cz/~jaroslav/papers/2012-vcm/2012-vcm-p...

That was very informative and accessible, thanks again!

Reply on news.ycombinator.com