Comment by jpxxx | Hacker News Reader

Comment by jpxxx | Hacker News Reader

Oh ray tracing, the nuclear fusion of computer graphics. It's coming! It's amazing! Meanwhile the industry still keeps burning coal.

For applications that deal in perfect lighting, yes it's probably a useful technique that would benefit from hardware support. But where is the real-world benefit for the rest of us? For most consumers, lighting provides about 2% of a game's value and 0% of everything else.

So I sympathize with this point of view, but the difference can be pretty stunning. Although between getting ray tracing or getting something like NURBs as the fundamental unit of geometry composition I'd probably lean toward the latter as a bigger 'win.'

One of the things about ray tracing that was unexpected for me was that you could use a lower pixel resolution and get a higher fidelity 'feel' for the render.

Ugh, not NURBS again, they are so much harder to control for high-detail surfaces you see for modern organics, and provide little to no advantages to hard and most environmental surfaces.

Leave NURBS to vehicle and product CAD, where it's actually very useful

Ok, not NURBS but its annoying that I can describe a sphere with 6 NURBS perfectly and can't with 10,000 triangles.

If you're ray tracing, you might as well use a vec4 for that sphere. :)

Good point, it does make somethings easier.

I for one, believe it would considerably simplify the implementation of graphics engines. To make rasterization look good you have to do a lot of optimizations and go trough a very long pipeline. You don't have this problem with ray-tracing. Plus the same base technique (ray-tracing) can be used for a lot of problems in graphics: visibility checking, lighting, reflections, diffraction, motion blur, ...

I've heard as much too. It'd be interesting to see today's best raster effort put against the same game assets in a ray-traced engine with a real-world game going on.

Anything can look good when you've got 10 minutes and 500 processors. I want to see what happens in 16ms. :)

I mean, as a good point, ray tracing still isn't fast enough for the vast majority of pre-computed rendering for motion pictures. See PRMan and the majority of other modern renderers that all use still use the REYES algorithm. Sure, a unbiased renderer is great when you just need a single still without a huge amount of tweaking, but when you need motion ray tracing -everything- will remain impractically slow for a very long time.

Since you're concerned with frametimes, let's also add in the asset production pipeline and effort. As it's been mentioned, cutting edge rasterizing consists of lengthy pipeline for every single effect imaginable(also sometimes to the graphics assets, mind you) while raytracing does all that almost by default(soft shadows and global illumination are problematic for example, path tracing fixes this but is some two orders of magnitude slower).

The real problem with raytracing is that it's asymptotic computational complexity is far worse when you count scene objects. To compensate this you either lower the resolution or lower the lifetime of a ray(how many bounces it's allowed to make).

Very interesting. Thank you for the additional detail!

Sure, it's awfully simplifies everything, but at a huge cost.

> lighting, reflections, diffraction, motion blur

Just about every one of those becomes easy, but incurs a huge performance penalty.

Also, thinking about it, I'm not sure that motion blur actually becomes significantly easier.

Lighting isn't a huge win, direct lighting is improved slightly, but GI is still impractically slow.

Reflection and diffraction are a pretty good win, but are also things that are solvable with a "ray-trace sometimes" approach, which is a much more likely solution for the near to mid-term.

And generally speaking visibility is done with some sort of ray checking anyways, sure it simplifies things that now we don't have two different solutions, but the complexity is a huge optimization.

So sure, it'd simplify things a ton, but I don't imagine it to be the primary rendering technology in real-time game for a long time.

> Also, thinking about it, I'm not sure that motion blur actually becomes significantly easier.

For motion blur, you take frames at different points in time and distribute the tracing ray over time. So it's actually pretty easy. Don't know if it's practical or efficient tough.

similar sort of thing can be done in a rasterised system, just distribute the rasterised triangles over time, tada.

It would definitely make the engine implementation more simple and elegant, but why exactly would that be worth it? Why would that be worth all the downsides?

I think a good analogy, say that I'm implementing a database. In my database, every single time it handles a query, it always does O(n) search across every record to find matches. The implementation would be so simple and elegant!

Reply on news.ycombinator.com