Future proofing your Art production pipeline for Nanite.

Development Rendering
, ,
1

We are reviewing our ART DCC and rendering pipeline for our game. Our game is a character centred mobile multiplayer game. As per advice from past conversations with representatives from Epic, as well as consulting the roadmap of Unreal, our understanding is that Nanite, as of 5.5:

  1. Does not have robust support for mobile rendering.
  2. Does not support Skeletal meshes beyond experimental support.
  3. The timelines for Nanite becoming viable with regards to the above features are still to be confirmed publicly.

Because of this it is at the time of writing not feasible for our studio to adopt Nanite for our game, as we are mobile first. However, over time we may want to offer ports to other platforms, such as consoles and high-end PC SKUs, and therefore would like to keep the door open for eventually being able to support Nanite while not investing any significant time into adjusting our DCC and asset export pipelines.

This brings us to the question, are there any guidelines or directives on how to approach our content creation such that we could easily expand our LOD based mesh workflows to support Nanite in the future.

For the time being, we are authoring the source assets(meshes) at high fidelity (large polygon counts, without any budgeting restrictions), and then generate LOD levels from those source meshes. The assumption here is that by using this flow, we are able use the traditional Static/Skeletal mesh LOD system in Unreal. Should we run into an instance where we would need to support Nanite, then we could just convert the Static/Skeletal meshes in engine to be Nanite meshes with the source asset(high-fidelity) as the Nanite mesh, and then have the old LOD hierarchy as the fallback mesh for non-Nanite platforms.

While this approach seems sensible based on what we know, it would be great to know if there are any other considerations we should keep in account with regards to our asset pipeline to ensure that we don’t close the door on potential future Nanite support, without committing to supporting it now. Let me know your thoughts!

Many thanks,

Daniel

2

Steps to Reproduce

3

Hey there! Your understanding of the state of Nanite is correct.

You’re in an interesting spot, since most folks ask about having to go the other direction (Nanite down to non-Nanite). But I think the answer is the same either way and it sounds like you’ve already got it. What you could do to save yourself the step of batch-converting assets to Nanite later down the line is to enable Nanite on the assets from the beginning but disable Nanite rendering (r.Nanite 0) as part of your DefaultEngine.ini. The big thing to watch out for in your case is that LOD0 will be generated based off the mesh’s Fallback settings, which may not be desirable in your situation since I’m guess you’ll probably want more control over the look of LOD0. For that, you’ll want to set the Source Import Filename in Nanite Settings to be your super-high-res Nanite mesh, then the engine will treat the asset’s normal source file name as LOD0.

Hope that helps, let me know if you’ve got any other questions!