Since life is short and eternity is not, executing a piece of code an infinite number of times is severely constraint by quite a few circumstances. The first one is probably that you like to see the image you are rendering in the very near future, most often measured in minutes and even if your imagination is great enough that this is not of matter to you, imagine that the universe will cease to exist in few zillion years, while your computer would be guaranteed to still be busy with calculating the gazillionst subdivision step and not even be close to the limit surface.
But there is hope. Since an image has a limited resolution, clever people came to the conclusion that one may take advantage of this and subdivide only so often that the resulting shape has a geometric resolution — read: number of polygons in a REYES-renderer — that can be captured by the number of pixels present in the image anyway. Since those people writing REYES renderers rival those aforementioned in cleverness, they use exactly that approach. The number of subdivision steps applied to the input geometry is determined by the size of the object on the screen (and another attribute which is not discussed here and called ‘Shading Rate’ in RMan; but let’s completely ignore this now).
To understand what this means, we get back to our spaceship example. Let’s say we build a spaceship in our modeling application, consisting of approximately 10,000 polygons. Rendering this one out as a SubdivisionMesh primitive will quite probably mean that the renderer will generate a few million polygons from it while it is close to the camera. As it moves away and fills a smaller portion of the image, less and less polygons will be created from it — only enough to get a nice curved look under all circumstances imposed by the image the renderer was asked to generate from it.
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