3 ms·

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

by norswap 14y ago

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, ...

jpxxx 14y ago
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. :)
- Arelius 14y ago
  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.
- zxcdw 14y ago
  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).
  - jpxxx 14y ago
    Very interesting. Thank you for the additional detail!
Arelius 14y ago
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.
- norswap 14y ago
  > 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.
  - Arelius 14y ago
    similar sort of thing can be done in a rasterised system, just distribute the rasterised triangles over time, tada.
paulhodge 14y ago
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!

by norswap 14y ago

jpxxx 14y ago

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

Arelius 14y ago
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.
zxcdw 14y ago
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).
- jpxxx 14y ago
  Very interesting. Thank you for the additional detail!

Arelius 14y ago

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.

norswap 14y ago
> 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.
- Arelius 14y ago
  similar sort of thing can be done in a rasterised system, just distribute the rasterised triangles over time, tada.

paulhodge 14y ago

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!