The Intel article describes the scene model as a collection of polygons. While that's typical for rasterization, isn't one of the main benefits of ray tracing that you can use other types of geometry?
With bicubic patches, that teapot's profile is nice and smooth at any distance. And it takes far less memory to describe, improving load times and offsetting thrashing due to non-coherence of shading rays.
I'm always disappointed when I see ray tracers that handicap themselves with tesselated geometry.
Unfortunately, the second article appears to be offline right now.
i wrote a sort of mini-review about the beyond3d article, cross-posted here on ompf (as b3d's forum is down): http://ompf.org/forum/viewtopic.php?p=5305#5305
@Adrian Although it's correct to say a ray tracer can be built using a variety of geometry types, I was surprised by the number of real-time ray tracers that only handle triangles. I am told that part of this is the uniformity of one geometry makes designing acceleration structures and intersections more efficient. It's true that you don't get nice level-of-detail you'd get with an implicit surface like a bicubic patch. With the number of interactive ray tracers that don't implement other primitives and the simplicity of their intersection algorithms, it shows they're a reason why they "handicap" themselves. Performance. For one thing, anything like bicubics have to deal with concavity, which is relatively slow compared to a ray tracer.
I think Howard received a lot of flack for that comparison image on Intel's blog. Rasterization has come a long way since the 1970s, when he rendered that image.
4 comments:
The Intel article describes the scene model as a collection of polygons. While that's typical for rasterization, isn't one of the main benefits of ray tracing that you can use other types of geometry?
With bicubic patches, that teapot's profile is nice and smooth at any distance. And it takes far less memory to describe, improving load times and offsetting thrashing due to non-coherence of shading rays.
I'm always disappointed when I see ray tracers that handicap themselves with tesselated geometry.
Unfortunately, the second article appears to be offline right now.
i wrote a sort of mini-review about the beyond3d article, cross-posted here on ompf (as b3d's forum is down): http://ompf.org/forum/viewtopic.php?p=5305#5305
@Adrian Although it's correct to say a ray tracer can be built using a variety of geometry types, I was surprised by the number of real-time ray tracers that only handle triangles. I am told that part of this is the uniformity of one geometry makes designing acceleration structures and intersections more efficient. It's true that you don't get nice level-of-detail you'd get with an implicit surface like a bicubic patch. With the number of interactive ray tracers that don't implement other primitives and the simplicity of their intersection algorithms, it shows they're a reason why they "handicap" themselves. Performance. For one thing, anything like bicubics have to deal with concavity, which is relatively slow compared to a ray tracer.
I think Howard received a lot of flack for that comparison image on Intel's blog. Rasterization has come a long way since the 1970s, when he rendered that image.
Darn typos. I meant, "compared to a triangle" and "there's a reason".
Post a Comment