![]() ![]() Subdivision meshes have the ability to perform watertight dicing in order to close potential holes or cracks caused by displacement.Note that the renderer tries very hard to mitigate cases where subdivision meshes are over-modeled by converting their underlying representation to what is essentially a polygonal representation upfront in a "pre-tessellation" step, saving memory by discarding the subdivision data. In that case, the polygonal representation may suffice (i.e. If the asset is significantly over-modeled, to begin with, it may be the case that the limit surface may not differ significantly from the control mesh, and the extra memory needed to perform the subdivision was wasted. The renderer needs to retain extra memory on a subdivision surface in order to be able to perform subdivision. However, polygons are usually considerably cheaper if the renderer doesn't need to perform any subdivision.In such cases, it is obvious that the subdivision mesh is the better representation. The number of polygons that may be needed to represent a smooth surface may be significantly higher (and require more memory) than the equivalent subdivision mesh.If the asset is meant to be a smooth surface, then the tradeoffs become more complicated: simple geometry with hard silhouettes), then polygons are probably all that is needed. Comparison with PolygonsĪ common question to consider when modeling assets is: should a polygonal asset be rendered as-is, or should be it converted to a subdivision surface? If the asset is not smooth in nature (i.e. Moreover, even if the micropolygons are large due to the micropolygon length setting, their vertices are computed directly from the limit surface for the highest accuracy. Instead, it adaptively tessellates into micropolygons whose size is by default computed in terms of pixels on the screen. Unlike many other renderers, RenderMan's implementation of subdivision surfaces does not apply a fixed number of subdivision steps to a polygonal mesh. ![]() But where polygonal surfaces require large numbers of points to appear smooth, a subdivision mesh's limit surface is guaranteed to be smooth - meaning that polygonal artifacts or faceting are never present, no matter how the surface animates, or how closely it is viewed. Unlike NURBS, the control mesh is not confined to be rectangular, so in this respect, the control mesh is very similar to the polygonal surface. Thanks for the comments! I will add some stuff to the interface and see what you think.Like most other types of geometry, a subdivision mesh is described by its control mesh. ![]() I guess you plan on strictly using the normals of the resulting subdivision surface? Adding creases based on smoothinggroups or normal-continuity would be a nice feature Wouldn’t it be way easier for you to recieve the control-mesh in one interleaved data-array and one index-array? Any suggestions for this interface would be much appreciated. I suppose to achieve discontinuous colors/texcoords, attributes would need to be applied to corners rather than vertices. I haven’t thought yet about that… control over attribute interpolation is a must. For other schemes, things may be harder.Īlso, what happens to texturecoordinates - do you apply subdivision interpolation to them, or linear interpolation? Have you considered discontinous texcoords? I would humbly suggest using a general approach, attaching properties to vertices in an indexed face-set, and specifying an interpolation-method for each property - one being subdivision interpolation. The cracking problem could be handled as it is for adjacent b-spline patches. In the case of Catmull-Clark, conversion of regular regions to b-spline patches, and the use of Stam’s exact evaluation approach for regions around extraordinary vertices should make evaluating the error metrics possible. Since you’re very explicit about not dividing the mesh uniformly, how do you plan on filling the gaps between oddly subdivided patches? How do you evaluate the SDS_PATH_LENGTH, SDS_PARAMETRIC_ERROR and SDS_DOMAIN_DISTANCE error-metrics? ![]() I’d like to have an interface which permits an implementation to use various methods, and indicate to the user which ones are available. I don’t mean to be dogmatic about not subdividing uniformly… I’m sure in some cases that could be the best approach. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |