4 ms·

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better res

by yk 14y ago

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better results with rasterization, the two exceptions I can think of is scenes where the geometry of light rays is not flat, so for example involving lenses or black holes, or where there is a lot more optical complexity than you can reasonably use. ( A forest where each of the leafs is an object, you will never be able to notice that the advantage of this over an forest where the trees in the background are just textures.)

Osmium 14y ago
e.g. mirrors?
- yk 14y ago
  Yes, but it perhaps more instructive to think of a curved mirror. In case of a raster engine, you need to calculate a texture for every triangle of the mirror. ( Which is essentially the same as rendering the scene in the first place.) On the other hand for a ray tracing engine you just need to reflect one ray on the mirror surface for every pixel the mirror occupies in the final rendering. So compared to the same scene with a window instead of the mirror, you just need to calculate one additional reflection instead of running the entire rendering pipeline again.
  - willvarfar 14y ago
    I think John says not just one ray per pixel?
    - yk 14y ago
      Yes, I was essentially using one ray per pixel as shorthand for constant amount of rays per pixel. (As in 'I did not think about that point.') One needs more than one to avoid creating artifacts like aliasing ( see [1] for a very nice example), or depending on how 'naive' or complex the algorithm is for stuff like shadows or caustics. But for nice scenes (which do not create artifacts) with mirrors and lenses, one ray per pixel would work fine. [1] https://en.wikipedia.org/wiki/Aliasing https://en.wikipedia.org/wiki/Aliasing
Tuna-Fish 14y ago
> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene. There exists a threshold of computing power/scene complexity above which raytracing beats rasterization in speed. However, like Carmack pointed out, the constant factors are massive, so this won't be reached in the near future, if ever. The reason the constant factors are so huge is that complexity of raytracing rises linearly with the count of pixels to be drawn, while in rasterization a lot of the work can be shared by neighbouring pixels. Intriguingly, this means that if you can reduce the pixel counts, you can vastly improve the value of raytracing. Notably, if you can do eye tracking and rendering in less than 15ms, you can reach the same visual quality as a full-screen, high-resolution render by rendering only the areas you are actually looking at in high resolution, and rendering the rest of the scene at a progressively lower resolution farther from the focus point. The cone of high-precision vision is surprisingly small, something like tens of pixels when looking at a screen from a normal viewing distance. If you did this, you should be able to cut the amount of rays you need to send by at least two orders of magnitude, which would bring raytracing to real-time quality on modern hardware.
- yk 14y ago
  Yes, as I pointed out in the last sentence, perhaps I should have put a big-O somewhere into it. Do you have a link on the eye tracking/rendering combo? That technique sounds rather fascinating.
  - mynameismiek 14y ago
    Its called Foveated Rendering (http://research.microsoft.com/apps/pubs/default.aspx?id=176610 http://research.microsoft.com/apps/pubs/default.aspx?id=1766...) and is based on foveated imaging (http://en.wikipedia.org/wiki/Foveated_imaging http://en.wikipedia.org/wiki/Foveated_imaging).
- bcoates 14y ago
snarfy 14y ago
When CPUs have millions of cores and cost next to nothing to produce, the superior algorithm may be the one which scales linearly with parallel hardware. He mentions the problem of the log2 vs linear with rasterization, but that's just moving the log2 problem to hardware. Ray casting may still win out due to it's simplicity of throwing more hardware at it.

by yk 14y ago

Osmium 14y ago

e.g. mirrors?

yk 14y ago
Yes, but it perhaps more instructive to think of a curved mirror. In case of a raster engine, you need to calculate a texture for every triangle of the mirror. ( Which is essentially the same as rendering the scene in the first place.) On the other hand for a ray tracing engine you just need to reflect one ray on the mirror surface for every pixel the mirror occupies in the final rendering. So compared to the same scene with a window instead of the mirror, you just need to calculate one additional reflection instead of running the entire rendering pipeline again.
- willvarfar 14y ago
  I think John says not just one ray per pixel?
  - yk 14y ago
    Yes, I was essentially using one ray per pixel as shorthand for constant amount of rays per pixel. (As in 'I did not think about that point.') One needs more than one to avoid creating artifacts like aliasing ( see [1] for a very nice example), or depending on how 'naive' or complex the algorithm is for stuff like shadows or caustics. But for nice scenes (which do not create artifacts) with mirrors and lenses, one ray per pixel would work fine. [1] https://en.wikipedia.org/wiki/Aliasing https://en.wikipedia.org/wiki/Aliasing

Tuna-Fish 14y ago

> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene. There exists a threshold of computing power/scene complexity above which raytracing beats rasterization in speed. However, like Carmack pointed out, the constant factors are massive, so this won't be reached in the near future, if ever. The reason the constant factors are so huge is that complexity of raytracing rises linearly with the count of pixels to be drawn, while in rasterization a lot of the work can be shared by neighbouring pixels. Intriguingly, this means that if you can reduce the pixel counts, you can vastly improve the value of raytracing. Notably, if you can do eye tracking and rendering in less than 15ms, you can reach the same visual quality as a full-screen, high-resolution render by rendering only the areas you are actually looking at in high resolution, and rendering the rest of the scene at a progressively lower resolution farther from the focus point. The cone of high-precision vision is surprisingly small, something like tens of pixels when looking at a screen from a normal viewing distance. If you did this, you should be able to cut the amount of rays you need to send by at least two orders of magnitude, which would bring raytracing to real-time quality on modern hardware.

yk 14y ago
Yes, as I pointed out in the last sentence, perhaps I should have put a big-O somewhere into it. Do you have a link on the eye tracking/rendering combo? That technique sounds rather fascinating.
- mynameismiek 14y ago
  Its called Foveated Rendering (http://research.microsoft.com/apps/pubs/default.aspx?id=176610 http://research.microsoft.com/apps/pubs/default.aspx?id=1766...) and is based on foveated imaging (http://en.wikipedia.org/wiki/Foveated_imaging http://en.wikipedia.org/wiki/Foveated_imaging).
bcoates 14y ago

snarfy 14y ago

When CPUs have millions of cores and cost next to nothing to produce, the superior algorithm may be the one which scales linearly with parallel hardware. He mentions the problem of the log2 vs linear with rasterization, but that's just moving the log2 problem to hardware. Ray casting may still win out due to it's simplicity of throwing more hardware at it.