Many renderers use polygons as primitives. This has a lot of disadvantages, the probably most obvious one being that geometry arrives in the renderer at an resolution determined by an external [modeling] application. Depending on the size of the rendered geometry in the image and the resolution of the image itself, the resolution of the geometry may well be completely inadequate for the image the renderer was asked to generated from it.
Just think of a spaceship made of 100,000 polygons that is flying away from the camera. While still filling the view, more or less, 100,000 polygons may sound pretty reasonable. But once it is so far a away that it only has about a size of 10 pixels in the image, a lot of the detail will probably be invisible. Nevertheless, the renderer still must transform and shade 100,000 polygons per frame. Vice versa, if the camera is very close to the spaceship, 100,000 polygons may not be enough detail at all and parts of this spaceship that ought to look curved will show nasty polygonal silhouette edges. If you think that all this doesn’t sound very clever, you’re on the right track and have made the first step in becoming a REYES addict.
After talking about the disadvantages of what other renderers do, lets look at REYES again. Instead of relying on the modeling application and polygons, REYES uses high-level primtives. RMan renderers particularly know typically about 20 of these. The ones we are going to look at here are the RMan Subdivsion Mesh and the RMan Polygon Mesh and their treatment in a REYES implementation. Using the Polygon Mesh actually would — in many ways — be as inefficient as in a non-REYES renderer, as touched in the previous paragraph. Hence one should avoid using it whenever possible.
Moritz– nice little article.
You may remember me from such productions as ‘Animalia’ (I’m one of the joonya’s that sat next to you).
Question after reading the article– If Subdivision is recalculated frame by frame in order to optimize micropolygon numbers, is it ever likely to encounter artifacts caused by a timestep and resulting mesh change. That is to say if the topology of the surface is changing to incorporate more or less polygons will the change every lead to problems. I wondering both about possible silhouette issues and texture problems. I suppose what I’m really asking is if I was to crank the shading rate to 50 or 100 (assuming it lets me and the control surface is suitably low poly) would the mesh pop in a random fashion either side of the ‘limit surface’ or would the subdivision remain, by some miracle, relatively uniform .
Obviously I would assume such variations would be next to impossible to detect on a moving object with a suitable shading rate but all the same I wonder.
Myles
Yes, it is indeed so that in REYES, the dicing of a mesh will change every frame, if that mesh is deforming/transforming and/or the camera is transforming or changing parameters, relative to the gprim in question.
This can lead to crawling artifacts on very slowly deforming geometry (slowly, as in: little change over many frames and possibly motion blur not being used to worsen things). Particulalrly displacement/bump mapping is prone to expose the problem.
Note, however, that this is all happening in alignement with the primtives’s UV parameterization which (supposedly) is the same, direction wise, over a sequence of frames. This and the fact that motion blur is almost always used in images coming out of REYES renderers, helps hiding the issue, if there is any visible one.
Consider the alternative in a ray tracer: every pixel is sampled (many times). Were a ray hits the primitive (aka: the ray-tracer’s “shading rate”) has nothing to do with the UV parameterization of the surface at all. Even with correct filtering, you can get similar popping of features but it will likely be much more pronounced than in a REYES renderer.
la idea muy buena
RSS feed for comments on this post. / TrackBack URI