Geometry
Tessellation is a computer graphics technique that can make a coarse, low-polygon mesh render smooth. This is achieved through polygonal subdivision, which happens at render-time. Working with low-polygon meshes and letting Redshift do the subdivision during rendering has certain advantages:
- Low-polygon meshes can be simpler to manage for animation reasons
- The 3D program itself doesn't have to maintain large numbers of polygons which can be expensive in terms of system memory
It can be more memory-efficient (which is important for GPUs) when combined with view-dependent and/or adaptive subdivision. Small or distant objects, for example, can render smooth with fewer subdivisions.
Redshift subdivides quad polygons using the Catmull-Clark algorithm. For triangles, it uses the Loop algorithm. Redshift supports both screen-space and world-space adaptive tessellation for improved memory usage.
Displacement is a technique typically combined with tessellation. It allows the user to add extra detail on their meshes through shader networks, i.e. textures, noise shader nodes, etc.
The benefits of displacement include:
- Manipulating textures and shader networks for certain displacement effects (such as a brick wall) is much easier than manipulating lots of vertices in a 3D program
- Sculpting apps like ZBrush and Mudbox are easier to use compared to polygon modeling when creating organic geometry. A displacement (or vector displacement) map allows this sculpted detail to be applied on a fairly low-resolution mesh.
Because displacement can happen on adaptively tessellated meshes, it can be more memory efficient than using a full-detail, full-tessellation mesh in memory at all times and irrespective of its size or viewpoint.
Redshift supports both heightfield (displacing along the vertex normal) and vector displacement maps. The vector displacement maps can be in object or tangent space. Importantly, any displacement detail that couldn't be represented given the existing tessellation settings is represented, instead, using bump mapping – therefore a good level of surface detail can be present even in fairly low-quality tessellation settings.
You have to activate this option to be able to use Tesselation or Displacement with this object.
The Tessellation and Displacement settings are effective on the object that hosts the Redshift Object tag as well as any child objects.
Activate this option to increase the amount of polygons for this object during render-time.
Redshift supports two different algorithms for polygon subdivision: "Catmull-Clark + Loop", which is used for triangles and "Catmull-Clark Only", which is used for quads. These algorithms are also called "Subdivision Rules".
The "Catmull-Clark+Loop" subdivision rule uses Catmull-Clark for quads and Loop for triangles. On the other hand, the "Catmull-Clark Only" option uses Catmull-Clark for triangles too, by first splitting each triangle into three quads. The "Catmull-Clark Only" mode should be used when Redshift is combined with other software that doesn't support Loop subdivision.
Enabling screen-space adaptive tessellation means that objects that are further away from the camera will be subdivided less and will, therefore, use fewer polygons and less GPU memory. If this option is disabled, then subdivision becomes "world space adaptive". This option affects the unit used for the "minimum edge length" setting, as explained below.
This controls whether Redshift should subdivide quads and triangles using the Catmull-Clark and Loop algorithms respectively or whether it should do a simple linear subdivision instead. If you are adding displacement on simple angular meshes (such as walls or a box) and don't want them turned into smooth, curvy objects, disabling smooth subdivision might be the right option for you.
|
|
Smooth subdivision enabled |
Smooth subdivision disabled |
When Smooth Subdivision is enabled, Redshift will smooth not only the vertex positions but also the UV coordinates and tangent space vectors. Smoothing UV coordinates means that the UVs will be shifted to remove any 'zig-zagging' and 'UV breaks' during tessellation and maintain smooth UV-space curves. In the majority of cases, this is the desirable way to treat UVs. However, there are cases where strict UV layouts (such as with when UV tiles are aligned to quads) need to be preserved and not smoothed.
For this reason, Redshift supports enabling/disabling UV smoothing.
Adaptive subdivision keeps dividing quads/triangles while their edges are longer than this setting. If you are using screen-space adaptive subdivision, this length is measured in screen pixels. If you are not using screen-space adaptive subdivision, this means "world space adaptive subdivision" so the length is measured in world-space units. The smaller this value, the more tessellation will be applied to the mesh. If you set the value to zero, tessellation will continue until "maximum subdivisions" (see below) has been reached.
The following pictures show a tessellated cube which becomes this spherical-like shape with smooth tessellation. Notice how there is more tessellation when the min edge length becomes smaller. This is showing screen-space adaptive subdivision so 8 means "8 pixels" while 2 means "2 pixels".
|
|
Screenspace adaptive with min edge length of 8.0 |
Screenspace adaptive with min edge length of 2.0 |
Subdivision happens in 'passes'. Each pass can turn single quad/triangle into 4 quads/triangles respectively. This means that the number of polygons can grow extremely quickly with this option. It is a "power of four".
- A setting of 1 can turn 1 quad into 4 quads
- A setting of 2 can turn 1 quad into 16 quads
- A setting of 3 can turn 1 quad into 64 quads
- A setting of 4 can turn 1 quad into 256 quads
- A setting of 5 can turn 1 quad into 1024 quads
- A setting of 6 can turn 1 quad into 4096 quads
- A setting of 7 can turn 1 quad into 16384 quads
- A setting of 8 can turn 1 quad into 65536 quads
So a mesh containing only 1000 quads, using a "minimum edge length" of 0.0 and a "maximum subdivisions" 8, could become a 65 million quad mesh which could take a long time to generate and would consume lots of memory! For this reason, great care has to be applied when adjusting both "maximum subdivisions" and "minimum edge length".
|
|
|
|
Subdivision disabled | One Level | Two Levels | Three Levels |
Out of Frustum Tess. Factor[0.00..+∞]
This option allows objects that are outside the camera frustum (i.e. objects that are not directly visible to the camera) to be tessellated to a lesser degree. The larger the factor, the lesser this out-of-frustum tessellation will be. This setting can help save memory by tessellating "unimportant" objects less. However, sometimes an object might be outside the camera frustum but still very visible through reflections. Or it might be casting a well-defined shadow within the camera frustum. For such objects, smaller factors should be used. A factor of 0.0 disables this optimization. For a more detailed discussion on this, please see the relevant section below.
Limit Out Of Frustum Tessellation
Max Out Of Frustum Tess. Subdivs[0..16]
When Limit Out-Of-Frustum Tessellation is enabled, you can specify the maximum number of subdivisions that should happen outside the camera frustum with the Max Out-Of-Frustum Tess. Subdivs option. This setting is useful when the Out Of Frustum Tess. Factor setting can still yield excessive tessellation. This condition can happen when the mesh is using large displacements. For a more detailed discussion on this, please see the relevant section below.
Out Of Frustum Tessellation
The following images show what "out of frustum tessellation factor" does for polygons that are outside the camera frustum.
The test scene is simple: it's just a quad with a mild fractal displacement. The camera is looking at the quad (slightly tilted down) from a close position.
Scene setup
We use a wireframe shading node so we can visualize tessellation.
In the images below, we rendered once from the camera, then we froze tessellation in the RenderView and then we "pulled the camera back" so we could see the effect of polygon tessellation outside the camera frustum. As you can see, the polygons that are inside the camera frustum are tessellated the most. Polygons that are away from the camera frustum are tesselated less and depending on the "out-of-frustum tessellation factor". The farther away a polygon is from the camera frustum, the less it gets tessellated.
|
|
|
Out-of-frustum tessellation factor: 8 |
16 |
32 |
This setting should be used carefully! Even though a polygon is outside the camera frustum, it might be visible through a mirror or it might be casting a defined shadow inside the camera frustum! So, in these cases, making it tessellate less might make it look blocky/angular and generally too-low-poly in reflections or shadows!
While Out of Frustum Tess. Factor allows us to get tessellation under control and save on Redshift's memory usage and rendering speed, there does exist one case where it might prove ineffective: scenes with large displacements and the camera being close to the displaced geometry.
To explain: When you set up displacement in Redshift, you have to declare a Maximum Displacement setting. This setting tells Redshift that displacement can go up to a certain distance. This setting is also used by Redshift when it tries to determine if a polygon is inside the frustum or outside it. The reasoning behind that is that, if a polygon is going to be displaced ("moved") by a lot, it might actually be moved inside the camera frustum, even though it was originally outside the camera frustum. In other words, Redshift applies "conservative" tessellation when it comes to displaced polygons that might end up being inside the camera frustum.
When this happens, Redshift might incorrectly "think" that too many polygons are inside the camera frustum and it might, therefore, tessellate these polygons a lot!
To show this, we'll edit our scene and make Maximum Displacement several times larger. Notice how there is much more tessellation because Redshift now thinks that all the polygons outside the frustum could possibly end up inside the frustum!
Increasing "max displacement" produces much more tessellation
For these cases, the Limit Out Of Frustum Tessellation control should be used. In the picture below, we enabled it and set the "max out-of-frustum sudivs" to 5 (the mesh uses max subdivs 8). This means "If a polygon is outside the frustum, ensure it doesn't get subdivided more than 5 times".
Setting "max out-of-frustum subdivs" to 5 limits the tessellation
You can think of this setting as a "subdivision clamp".
Activate this option to allow this object to shop displacement. The displacement is defined by the corresponding property of the Redshift materials.
Maximum Displacement[0.00..+∞]
This parameter tells Redshift what is the maximum length the displacement shaders/textures will be displacing the vertices by. For example, if you're adding two displacement textures in the shader graph and each displacement texture can push the vertices by 1 unit, then both of them can push the vertices by a maximum of 2 units, so a setting of 2.0 should be used for this setting. Unfortunately, due to flexible nature of shaders, it's not currently possible to compute this value automatically.
If the value for this setting is set too low, you will see a 'ceiling' on your displacements, i.e. the maximum displacement will be clamped. If, on the other hand, this value is set too high, there won't be any visual artifacts but the performance could suffer. It is, therefore, advisable to use a value that is as low as possible before seeing any artifacts.
This scales the displacement results, which has the effect of accentuating or toning down the displacement. While it is possible to scale the displacement in the node material itself, this setting was added for the case where the same displacement shader is used on different meshes but different levels of displacement 'strength' are required among these meshes.
Below is a sphere displaced with a fractal shader.
|
|
|
Scale 0.05 |
Scale 0.1 |
Scale 0.3 |
Very high-detail surface detail can require very high tessellation levels to be captured sufficiently, otherwise the result might look too soft. However, this can mean longer rendering times and higher memory usage!
The Enable Auto Bump Mapping option effectively emulates what would happen if you were to tessellate your geometry to a sub-pixel level and modifies the surface normals accordingly, as if they were bump-mapped.
The following two spheres were rendered with exactly the same tessellation setitngs but the sphere on the right uses auto bumpmapping. Notice how it's able to capture more surface detail.
|
|
Without auto bump mapping |
With auto bump mapping |
These settings affect the fixation of some 3D shaders, such as Noise, on deformed objects. These shaders are often calculated based on the position of the object's axis system, which would lead to a change in the generated structures on the surface if the object were deformed. These options can establish a fixed relationship, e.g. between the point coordinates of the object and the 3D structure of the shader, and prevent the shader structure from slipping during deformation.
You have three options available to reference the shader projection to the deformed surface:
- Auto: This setting will in many cases already have the desired effect of 3D shaders organically following a deformed surface. This results in an automatic alignment between the undeformed and the deformed shape. This can work well whenever deformation objects are used.
- Object: In this mode, another object can be assigned that usually reflects the undeformed form of the object with the Redshift Object Tag. It should have the same point order and point/polygon count to allow back calculation of the deformation matrix for the shader assignment.
- Snapshot: In this mode, the point and polygon structure of the object can be saved directly by clicking the Capture button. This mode also works well when using deformation objects, as well as PLA (Point Level Animation) animations, where the number of points and polygons, as well as their order, remains static.
Here, a separate object can be assigned whose point and polygon structure is compared with that of the deformed object to calculate a deformation matrix for the assigned 3D shaders.
In Snapshot mode, you can use these buttons to save or remove the point and polygon information of the current (undeformed) object from memory to be able to calculate a deformation matrix by comparing the undeformed with the deformed point positions.