When the spaceship only fills a space of 10 pixels in the image, a maximum of 10.000 polygons will be rendered at last as it will probably be small enough then to not make a visible difference between a however subdivided version. All this is done completely automagically by the renderer. Never will you, the user, have to tell it what the number of subdivision steps is needed for rendering a certain view of any primitive. Neither will you have to tell it what an appropriate number of polygons is, for the image you asked for, to look nice and smooth — the renderer will know better itself.
Still not convinced? “I can do the same and manually (or with an expression) steer the number of subdivision steps in my modeling application and hence have my renderer create equally clever and thrifty results.” You are right, but either you’d need to set up these expressions, which many users are not able to do or you will have to adjust the number of subdivision steps applied to your geometry by hand, depending on a lot of factors like speed of the spaceship, image resolution, the camera’s field-of-view etc. Another issue is the size of the polygons the renderer ultimately creates. REYES renderers create micropolygons. They don’t differ from the polygons you know but they are called ‘micro’, because their size typically is that of a pixel or even less. Most renderers get into trouble when thrown an average scene at, consisting of polygons ending up at the size of a pixel on screen.
A REYES renderer will (almost) always do the right thing. Some people would go as far and use this fact as an argument to separate renderers capable of rendering sudden surface types (including subdivision surfaces) from those who are not. Be warned thus that the following last part of this essay definitely belongs to the mere philosophic aspects of REYES.
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