This article was originally published for UDN
Frequently we receive questions about UE’s support of (cross platform) hardware tessellation and our future plans for supporting it.
Historically, UE has supported hardware tessellation for certain RHIs, however there are platforms, particularly consoles, that never received UE support for hardware tessellation. The reasoning behind this decision is that tessellation for any RHI requires regular maintenance, especially when optimizing for performance. In particular, on consoles, we found that the performance limitations of the hardware did not justify the engineering requirement of maintaining hardware tessellation and all of the rendering features that rely on it.
In parallel to these considerations, Epic was developing Nanite (A first look at Unreal Engine 5 - Unreal Engine). We foresee Nanite’s geometry system as a superior alternative to tessellation support, particularly for it’s fine grain control of mesh LODs, improved performance, and our ability to customise the system by comparison to hardware tessellation, which is typically restricted by per-platform/RHI graphics drivers.
Moving forward, we will discontinue support for hardware tessellation and focus on cross-platform support for Nanite instead. We currently support Static Mesh, Hierarchical + Instanced Static Mesh and Geometry Collection components. Wherever sensible, Nanite support for other components will be added in a future UE5 update. We are also currently in early R&D phases for skinning support, and subsequently Skeletal Mesh support. Tessellation/displacement support is also in the early stages of R&D.
For heightmap/terrain, we support high instance counts, so it’s possible to author terrain this way, but we still need to develop this into a more efficient system (e.g. hierarchical scene culling/processing for the GPU Scene instances are going into Nanite). So whilst we won’t support Landscape as is, we are aiming to make new developments support the same kind of workflows that are intuitive to artists (e.g. virtual heightfield meshes can be used as an alternative). For landscape displacement (e.g. snow, footprints etc), we currently do not have an ideal solution, but we can support development of a custom solution such as a compute shader based replacement, so please reach out to us via UDN for suggestions.
Regarding hardware tessellation, if you wish to develop it yourself, please reach out to us on UDN and we will do our best to provide initial guidance on how to implement it, but our support will be limited to these initial pointers as it will require a significant custom engine modification by your engineers.