...

A common way to approach a subdivision surface is to imagine a polygon mesh (the control mesh) which  that undergoes a local averaging (or smoothing) at every vertex, creating a new set of vertices which that have a smoother appearance than the original mesh. One application of this averaging operator everywhere on a mesh is a single subdivision step. If we could take an infinite number of subdivision steps, eventually we will converge to a limit surface, which has a set of guaranteed smoothness properties depending on the type of subdivision being used. 

...

Like most other types of geometry, a subdivision mesh is described by its control mesh. 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. 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 many other renderers, RenderMan's implementation of subdivision surfaces does not apply a fixed number of subdivision steps to a polygonal mesh. Instead, it adaptively tessellates into micropolygons whose size is by default computed in term terms of pixels on the screen. 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.

...

A 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. simple geometry with hard silhouettes), then polygons are probably all that are is needed. If the asset is meant to be a smooth surface, then the tradeoffs become more complicated:

• 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. In such cases, it is obvious that the subdivision mesh is the better representation.
• However, polygons are usually considerably cheaper if the renderer doesn't need to perform any subdivision. The renderer needs to retain extra memory on a subdivision surface in order to be able to perform subdivision. 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. In that case, the polygonal representation may suffice (i.e. it may be considered "smooth enough"). 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 up front upfront in a "pre-tessellation" step, saving memory by discarding the subdivision data.
• Subdivision meshes have the ability to perform watertight dicing in order to close potential holes or cracks caused by displacement. In RenderMan, polygons cannot do this because they don't retain enough data.
• Subdivision meshes have some topological constraints; in particular, faces cannot have holes, and they cannot represent non-manifold surfaces (surfaces where an edge may be incident to more than two faces - imagine two cubes sharing a single edge). In practice, this is usually not a significant problem.

...

RenderMan's implementation of subdivision meshes include includes two subdivision schemes:

• Catmull-Clark subdivision surfaces are the industry standard. It is a quadrilateral-based subdivision scheme, and work works best with control meshes that is are comprised mostly of quads - any non-quad geometry is immediately converted to quadrilaterals on the very first subdivision step. They generally good for most situations and have no special concerns when it comes to texture filtering.
• Loop subdivision surfaces (Not Supported in XPU) is a triangle-based scheme, which is optimized for control meshes that are entirely triangles: they tend to require less memory than Catmull-Clark scheme. However, due to the nature of triangles, derivatives can be discontinuous from face to face, which may lead to texturing artifacts that require extra effort to solve.
  
  

...

In order to provide the smoothest possible limit surface, the averaging behavior of a subdivision surface is such that the limit surface "pulls away" from the boundaries of the control mesh by default. This can be undesirable when dealing with non-closed meshes, especially those that need to connect seamlessly with other adjoining meshes. As a convenience, RenderMan provides boundary interpolation rules that allow this behavior to be overridden, allowing the surface to continue all the way to the boundary of the control mesh. Different rules allow for smooth or sharp corners (vertices which that have exactly two incident edges). The example below shows the boundary interpolation rules applied to a simple 9 face control mesh.

...

This idea of boundary interpolation can also be extended to the interpolation rules applied when dealing with data over the surface, most notably texture coordinates (in this context, RenderMan uses the term facevarying boundary interpolation). When dealing with the seams between disjoint UV regions, the renderer can use several different rules, trading off the smoothness of the subdivided result away from the seams against the desire to interpolate the seams exactly. Note that no matter what rule is chosen, the UV texture map editor must also abide by the same rules, otherwise undesirable texturing artifacts will result. The following image demonstrates the different rules applied to a 4x4 grid of quads segmented into three UV regions.

...