Required structure for Skeletal Mesh Nanite Assembly using USD, and the future roadmap for Nanite Foliage

Development Rendering
, ,
1

(This is a translation of a [Japanese [Content removed] by Kano Eriko.)

Thank you for your continued support.

I am currently currently exploring a USD-based import workflow for the Nanite Foliage and Nanite Assembly features introduced in UE 5.7. So I would appreciate your advice on the points below:

(If necessary, I’d like to provide relevant data.)

[Verification Environment]

- UE 5.7:

USD Importer enabled

Tested with Interchange.FeatureFlags.Import.USD = 0

- DCC Tools:

SpeedTree 9.5.2

Houdini 20.5.445 (Solaris)

[Overview]

I am testing a workflow where vegetation assets created in SpeedTree are converted to USD in Houdini (Solaris) and then imported into UE5 as Skeletal Mesh Nanite Assemblies.

Tree assets can be converted into Nanite Assemblies without problems. However, for ground vegetation assets that have no trunk mesh and are structured as Skeleton + PointInstancer (leaf parts), the Assembly mesh is not generated.

[Issue]

Ground vegetation has no mesh directly under the Skeleton root, and the structure consists of a Point Instancer that follows the Skeleton. In Unreal Engine, the Skeletal Mesh leaf parts are imported, but the Assembly mesh with parts already being placed via the Instancer is not generated.

On the USD side (in Houdini Solaris), I have configured:

API Schema (NaniteAssemblyRootAPI, NaniteAssemblySkelBindingAPI)

primvars (tokens, etc.)

This setup works correctly for tree assets, but I cannot determine whether these settings satisfy the mandatory requirements for the ground vegetation to be recognized as a Skeletal Mesh Nanite Assembly.

[Questions]

Q1. The requirements for ground vegetation Nanite Assemblies and the requirements for configurations consisting only of a Skeleton and Instancer

Even for ground vegetation assets that do not have a trunk mesh and contain no geometry directly under the Assembly root, I would like to know the mandatory requirements for the USD hierarchy, attributes, and API Schemas necessary for the asset to be recognized as a Nanite Assembly (Skeletal Mesh).

(For example, is a dummy mesh required under the Assembly root? Is specific Skeleton-related data mandatory on the prototype side?)

Q2. Future of the USD workflow

Is the USD-to-Nanite Assembly import workflow expected to remain supported going forward?

With the transition to Interchange, is there a possibility that the Nanite Assembly specification may be restructured, changed, or deprecated?

Q3. Stability for large-scale production

If I use USD as the foundation for large-scale asset production, I am concerned about the following:

Which components or areas are expected to have a low risk of change going forward?

Which components or areas are more likely to be affected by design changes in future updates?

Additionally, regarding the workflow of creating Nanite Assemblies from SpeedTree assets, I would like to know:

Are there plans for Epic Games to publish best practices?

Are there any recommendations for workflows that users can adopt at the current stage?

Q4. Destruction effects for Nanite Assemblies

Is it technically feasible to apply destruction effects using Chaos Geometry Collections or Dataflow to Skeletal Meshes that have been assembled as Nanite Assemblies?

If these are used in actual production, are there any known concerns regarding practicality or data-related overhead?

[Attachment Removed]

2

Hello,

Apologies for the delay.

Q1. What are the mandatory requirements for the USD hierarchy, attributes, and API Schemas necessary for the asset to be recognized as a Nanite Assembly (Skeletal Mesh).

The general overview of Nanite Assemblies can be found in our documentation, but the low level technical details for the USD importer are only available in the source code.

The relevant schemas for authoring assemblies are included with the USD Core plugin. These include NaniteAssemblyRootAPI, NaniteAssemblyExternalRefAPI, and NaniteAssemblySkelBindingAPI.
 
For more information on using these schemas, refer to their documentation provided with them in the source code.

The schemas are defined in:

/Engine/Plugins/Runtime/USDCore/Resources/UsdResources/Win64/X64/plugins/unreal/resources/unreal/schema.usda

There is some documentation in that file.

What’s mandatory is NaniteAssemblyRootAPI applied to a prim, which has at least one mesh or NaniteAssemblyExternalRefAPI below it.

For skeletal mesh, the assembly root must also have a “base mesh” (e.g. the trunk mesh) SkelRoot with a Skeleton (which will be used as the assembly’s skeleton).

Our typical tree USD file structure looks like this:

  • Root Xform - NaniteAssemblyRootAPI, applied, with meshType set to “skeletalMesh” and skeletonreferencing the trunk’s skeleton (see below)
    • SkelRoot of the trunk
      • Trunk mesh geometry
      • Skeleton referred to by the root
    • Point instancer (branch instances) - NaniteAssemblySkelBindingAPI applied, with bindJoints and bindJointWeights set
      • Prototypes group - Each individual prototype in this group would likely be inherited/referenced from other USD file(s)
        • Prototype Skelmesh root
          • Prototype geometry
          • Prototype skeleton

Q2. Is the USD-to-Nanite Assembly import workflow expected to remain supported going forward? With the transition to Interchange, is there a possibility that the Nanite Assembly specification may be restructured, changed, or deprecated?

At this point the USD schema structure is pretty solidified, and we have lots of data and have set up our own internal pipelines with this structure in place. To prevent issues with our own stuff, we’ll be doing proper versioning of the schemas from this point, such that old schema versions will be backwards compatible. Interchange is definitely the way moving forward though. We don’t plan on updating the legacy importer should we add features, but it should always support the original schema version shipped with 5.7.

As with most experimental features that are in active development and research, the underlying code and APIs are more likely to change than features in Beta.

Q3. Which components or areas are expected to have a low risk of change going forward? Which components or areas are more likely to be affected by design changes in future updates? Are there plans for Epic Games to publish best practices? Are there any recommendations for workflows that users can adopt at the current stage?

As said, the schemas should remain backwards compatible at this point. Also, it’s safe to expect that if you create Nanite Assembly assets with 5.7, those assets should not break in future engine releases. What might break between now and production-ready are public APIs with regard to assemblies or assembly building (NaniteAssemblyEditorUtils). We want to make sure when these interfaces come out of experimental that they are hardened and safe and can’t guarantee any code accessing these APIs will compile. That said, we still try to use proper deprecation to remove APIs over 2 engine releases where possible.

Q4. Is it technically feasible to apply destruction effects using Chaos Geometry Collections or Dataflow to Skeletal Meshes that have been assembled as Nanite Assemblies? If these are used in actual production, are there any known concerns regarding practicality or data-related overhead?

We haven’t tested this that I’m aware of but if you try to use the fracture tools on a Nanite assembly it’ll likely only fracture the fallback mesh. You’ll lose all instancing benefit if you do that.

Also as a reminder, Epic will be on holiday break starting next week (Dec 22, 2025) and ending Jan 5, 2026 and there will be no responses from Epic on public or private tickets, though you may receive replies from the community on public tickets.

We wish you happy holidays!

[Attachment Removed]

3

[mention removed]​

(This is a translation of a Japanese post by Kano Eriko.)

Thank you very much for your detailed and thoughtful reply.

It was quite helpful in understanding the USD requirements and the expected long-term stability of Nanite Assembly.

After reading your reply, it seems that aspects related to SpeedTree and actual DCC production workflows were not mentioned. Since SpeedTree plays a critical role in vegetation production pipelines, I would like to ask some additional questions about this. I apologize for the extra questions and appreciate your time in reviewing them.

■ About SpeedTree-based production workflows

SpeedTree is one of the primary DCC tools widely used by artists for high-end vegetation production. Currently, SpeedTree provides an automatic Unreal Engine import format (ST9), which creates Static Meshes with vertex-color-based wind sway. However, this does not directly support the USD structure required for Nanite Assembly, which was introduced in UE 5.7 and later.

Also, SpeedTree supports USD export, but the resulting USD structure follows SpeedTree’s proprietary conventions and does not match the requirements of Nanite Assembly. As a result, in our environment I currently perform additional processing using Houdini 20.5 (Solaris), including:

  • Separation of trunk / branches / leaves
  • Manual configuration of Nanite Assembly APIs:
    • Primitive root: NaniteAssemblyRootAPI
    • Leaf parts (placed via PointInstancer): NaniteAssemblyExternalRefAPI

With this context in mind, I would like to ask the following questions:

Q1. Other than converting SpeedTree output into USD via Houdini and reconstructing it for Nanite Foliage / Nanite Assembly, are there any recommended workflows or best practices for integrating SpeedTree assets into these pipelines?

Q2. Does Epic Games have any plans to officially support a SpeedTree-based workflow for Nanite Foliage / Nanite Assembly in the future?

Q3. SpeedTree is widely used across the industry. So, are there any best practices for gradually migrating existing SpeedTree-based production pipelines to Nanite Foliage without destroying current workflows?

■ About GroundCover vegetation (undergrowth without trunk meshes)

As mentioned in my previous question, the structure of ground vegetation assets differs significantly from that of trees. Ground assets typically have the following characteristics:

  • Consist only of a skeleton and leaf meshes.
  • Leaves are placed via PointInstancer.
  • Issue: There is no suitable trunk mesh or SkelRoot mesh to serve as the base mesh for NaniteAssemblyRootAPI.

Based on your previous reply, I tested the following configuration:

  • Applying NaniteAssemblyRootAPI for the USD root
  • Applying NaniteAssemblyExternalRefAPI for leaf prototypes placed via PointInstancer

However, this setup did not work correctly as a Nanite Assembly.

Also, after reviewing the USD Schema / API documentation, I was not able to find any additional settings that would support a structure consisting solely of Skeleton + PointInstancer, as is common for ground vegetation.

To clarify whether this is a configuration oversight or a design limitation, I would like to confirm the following:

Q4. Is it correct that ground vegetation structures that consist only of a skeleton and PointInstancer, with no trunk or base mesh under SkelRoot, are intentionally excluded from support in the current Nanite Assembly (Skeletal Mesh) design?

Q5. In Skeletal Nanite Assembly, is the presence of a “base mesh” (such as a trunk mesh) a mandatory design requirement?

If a dummy mesh is required, is there a way to exclude it after assembly, or to minimize its impact on rendering and data?

Q6. Are there any known plans or ongoing considerations for extending or improving the design to better support vegetation types that structurally lack a base mesh, such as ground vegetation?

■ About future pipelines using SpeedTree

Finally, I would like to ask about potential future pipeline.

Q7. Are there any plans for Epic Games and SpeedTree to collaborate on a workflow where the data exported from SpeedTree can automatically include the USD schemas and APIs required for Nanite Assembly, without requiring manual post-processing?

Q8. If there are no such plans currently, would it be appropriate to submit this as an official feature request, given that a lot of studios use SpeedTree for large-scale vegetation production?

Additionally, would it be feasible in the future to leverage the trunk and branch spline data provided by SpeedTree to procedurally reconstruct Nanite Foliage directly within Unreal Engine, for example by using systems such as PVE?

[Attachment Removed]

4

Hello,

We have recently published new documentation that covers Nanite Assemblies in USD in detail, which is relevant to some of your questions. You may find these of use:

Regarding your SpeedTree questions, we do understand that SpeedTree is a prevalent tool for foliage content generation. While we were developing Nanite Foliage for UnrealEngine 5.7, I spent some time evaluating SpeedTree’s file format to see if it would be possible to update our SpeedTree importer to support creating Nanite Assemblies. I found them to be unsuitable to represent Nanite Assemblies, because all of them had baked down the individual leaves, twigs, and branches to individual geometry.

I don’t have a whole lot of knowledge about SpeedTree, but from my searching it seems one could create a custom export pipeline to generate Nanite Assembly USDs from their Raw XML format, and it seems that instancing can be represented using Leaf References. If leaf references are able to instance more than just leaves and also represent branches or twigs, then it seems an XML to USD process could make the pipeline work. One could also author a custom importer for Unreal Engine that handles the raw XML to suit your specific purposes. This is what CD Projekt Red did for the Witcher 4 demo.

As for the future, I’m not aware of any current plans for collaboration with SpeedTree to make a Nanite Foliage workflow. Our main focus for mainstream authorship of foliage will likely remain to improve upon our PVE and PCG workflows. However, if any SpeedTree runtime format were to evolve to be represented by instanced geometry and a skeletal hierarchy, it should be easy for us to update our importer to create skeletal mesh Nanite Assemblies.

Now, for the ground vegetation issues. The base mesh of the skeletal mesh Nanite Assembly unfortunately must currently have geometry for the import to succeed. You could add a Mesh with a single triangle that is hidden. It may or may not work if that triangle’s corners are all the same point. It’s possible that you might encounter errors about degenerate triangles or empty meshes, but you should try it. If it does succeed, then it will effectively have no cost as the mesh builder will discard any degenerate triangles. We should theoretically be able to relax this requirement in the future. However, do note that currently Nanite Assembly parts only animate rigidly, and so making all visible geometry a part of an empty skeletal mesh assembly can work like this, but these parts will not bend. It will just behave like animated static meshes.

Regards,

-Jamie

[Attachment Removed]

5

[mention removed]​

(This is a translation of a Japanese post by Kano Eriko.)

Thank you very much for providing such a detailed response.

Due to your explanation, I can now well understand the current technical limitations of integrating Nanite Assembly with SpeedTree, as well as the future roadmap.

I also appreciate you sharing the USD workflow documentation and the example from CD Projekt Red, which was very helpful. I will make good use of the information in our ongoing development.

All of my questions have been addressed by your response. So please close this case.

Thank you again for your time and support.

[Attachment Removed]