# Subdivision Surfaces

# Writing poly as subdiv

In Multiverse you can specify which Maya poly mesh geometry should be described as a subdivision surface when writing your asset to a USD file. This process is rendering agnostic, all you need is either:

  • Hit 3 on the keyboard with a poly mesh shape selected. This will also draw it as subdivision on the viewport (and can be optionally disabled in the smooth mesh options).

  • Set the smooth mesh preview attributes on the attribute editor.

When writing your asset as a USD file, Multiverse will check whether this attribute is set and tag the mesh accordingly.

Note

You can always set a poly mesh to render as subdivisions after you have written your USD asset.

# Rendering poly as subdiv

Multiverse honors geometry tagged as subdivision surface (see the previous section) and renders it as such with the renderers capable of analytically compute subdivisions at render-time: these are 3Delight and Renderman.

For the Arnold, Redshift and VRay renderers more information is needed to render a mesh as a subdivision surface: specifically they all need the number of subdivision iterations to perform before rendering.

There are several ways to set these attributes, and there is an override order:

  • In the Attribute Editor of the Multiverse Compound (shape node) you can set your renderer "render as a subdivision" and "iteration number". These are typically under each renderer's extension attributes. All contents of the Compound will render as such (except those that were explicitly tagged not to render as subdivisions).

  • If you have previously written overrides, and they are set as a layer in your Compound, upper layers will override lower layers according to their contents.

  • In MEOW, on a item/prim you can assign an attribute override on the desired item location (remember that children will inherit if not further overridden) This will override the settings on the Compound and on the layers (once these) overrides are written they can be then loaded as a layer and the stacking order will matter. Again you can apply new overrides in MEOW, and again these overrides will override the layers in the Compound.

# Rendering subdivisions: a panorama

Each renderer handles subdivision surfaces in a a different way.

Note that subdivision surfaces are closely related to displacement: most of the time you want to displace on subdivision surfaces rather than on “raw” polygons.

Here's an overview for each renderer:

# Arnold Subdivs

Arnold pre-tessellates subdivision surfaces before rendering. This has several major drawbacks:

  • It requires a lot of Arnold shape attributes to control the look of subdivision surfaces. This increases workflow complexity.
  • Impacts directly displacement which relies on subdivision surfaces for high quality results. Arnold relies on a gimmick called “auto-bump” which tries to mitigate the need of high number of subdivision iterations by extrapolating bump from high frequency detail in a texture. This produces images with much lower image quality and increases workflow complexity.
  • Produces subdivision surfaces are not infinitely smooth (meaning that zooming into the geometry will exhibit polygonal faceting at some point). This requires pre-planning with camera zooms.
  • Requires very large amount of memory and slows down a lot when rendering high number of subdivision iterations are necessary, and when rendering HQ displacements.
  • Hides Arnold incapability to efficiently deal with displacement and introduces a bias as it requires a higher level of competence for the user to produce results that are comparable between renderers.

In addition to that, with the GPU version of Arnold memory implications become significant when subdividing to a high level and when using displacement on subdivided geometry.

# 3Delight Subdivs

3Delight analytically computes subdivision surfaces at render time in a completely automatic way and without the need to set any additional attributes for UV interpolation and dicing: everything is handled automatically.

This has several major advantages:

  • Does not require any additional attribute
  • Works perfectly with displacement
  • Produces infinitely smooth subdivision surfaces
  • It is fast and much more memory efficient

Note

When benchmarking against another renderer that pre-tessellates subdivs, make sure to set a decent number of subdivision iterations to produce a meaningful and comparable benchmark, ideally your benchmarks should perform renders at different camera distance from the subject.

# Redshift Subdivs

Redshift pre-tessellates subdivision surfaces before rendering and incurs in the same limitations as Arnold and VRay.

In addition to that, being a GPU-only renderer, memory implications are significant when subdividing to a high level and when using displacement on subdivided geometry.

# Renderman Subdivs

Similarly to 3Delight, Renderman also analytically computes subdivision surfaces at render time, but it does so in a "semi-automatic" way: the user still needs to set additional attributes for interpolation and dicing as well other attributes are needed for geometry and displacement. This adds complexity to the workflow and requires more know-how on the user side.

Note

When benchmarking against another renderer that pre-tessellates subdivs, make sure to set a decent number of subdivision iterations to produce a meaningful and comparable benchmark, ideally your benchmarks should perform renders at different camera distance from the subject.

# VRay Subdivs

VRay pre-tessellates subdivision surfaces before rendering and incurs in the same drawbacks mentioned in the Arnold section.

In addition to that, with the GPU version of VRay memory implications become significant when subdividing to a high level and when using displacement on subdivided geometry.

Last Updated: 10/29/2020, 4:40:40 PM