We would like to request support for evaluating Procedural Vegetation Editor (PVE) skeletal wind animation driven by the Instanced Skinned Mesh Component (ISKM) in the Path Tracer.
Currently, PVE-generated skeletal foliage animates correctly in the real-time viewport but renders in a frozen static pose when Path Tracing is enabled. This prevents us from using the new PVE skeletal wind workflow for final-quality Path Traced renders.
Our production pipeline is built around final-pixel rendering in Unreal Engine with Cryptomatte outputs for compositing. The traditional Vertex Animation Texture (VAT) + World Position Offset (WPO) workflow is not a suitable alternative because WPO deformation is not accurately reflected in Cryptomatte, resulting in matte misalignment on animated foliage.
The new bone-driven PVE system is the preferred workflow because true skeletal animation is expected to produce matching beauty and Cryptomatte outputs. However, without Path Tracer support, we are forced to choose between accurate wind animation and correct compositing data.
Adding support for ISKM/PVE skeletal animation in the Path Tracer would benefit studios using Unreal Engine for film, episodic, virtual production, and high-end visualization, where Path Tracing is used for final renders and Cryptomatte is an essential part of the compositing pipeline.
We would appreciate clarification on whether this functionality is planned for a future release or if there is a recommended production workflow that provides equivalent results.
[Attachment Removed]
Steps to Reproduce
Trees created with the new Procedural Vegetation Editor (PVE), using the bone-driven skeletal wind system (Instanced Skinned Mesh Component + Wind Transform Provider), animate correctly in the real-time viewport but lose all animation when Path Tracing is enabled the mesh renders as a frozen static pose. We have isolated this to the interaction between Nanite, the Instanced Skinned Mesh Component (ISKM), and the Path Tracer’s structure build, and we are unable to find a supported way to get wind-animated instanced foliage working in Path Traced output.
[Attachment Removed]
The combination of Nanite and ISKM is currently not supported, but we believe the non-nanite case should be supported. Can you share a small project that shows the issue from the video so we can advise the best path forward?
Also, can you provide a small scene that shows the VAT + WPO setup that is not working with Cryptomatte? This sounds like a different issue which may also have a solution.
[Attachment Removed]
Just to follow up, the PVE tool is designed for the nanite foliage case which isn’t currently supported in ray tracing. This is something the team is working on (along with other improvements to nanite ray tracing). ISKM on its own doesn’t support skin cache which means it cannot (yet) work with raytracing either. The team is also working on this extension.
In the meantime, for the path tracer specifically it would be better to focus on WPO methods for wind (with non-nanite meshes). This is supported but can be relatively expensive as each tree will require its own acceleration structure which increases memory usage. Ideally you can limit the number of instances which need to be simulated. You can take a look at the cvars starting with “r.raytracing.geometry.instancedstaticmeshes” to see the options to control culling and WPO in raytracing.
Let me know if you have any other questions!
[Attachment Removed]
Thanks for the clarification regarding the current limitations with Nanite + ISKM and the ongoing work to extend ray tracing support.
Even when Nanite is completely disabled, the Instanced Skinned Mesh (ISKM) generated by the Procedural Vegetation Editor still remains static in the Path Tracer, with no wind animation being evaluated. The same asset animates correctly in Lit mode (including Hardware Ray Tracing), but both the Path Tracer viewport and MRQ Path Tracer render the tree in its bind pose.
We’re attaching a small sample project that demonstrates this behavior.
Additionally, we’ve included the rendered EXRs for the VAT + WPO test case to illustrate the Cryptomatte inconsistencies we’re observing when rendering with the Path Tracer.
Project drive link - https://drive.google.com/file/d/1adeaoAxCXE82RnYtedgqRnKYsPiY4IVN/view?usp=sharing
[Attachment Removed]
Thank you for the scene. It looks like the first three trees are running with nanite enabled which is the unsupported case (both for (instanced) skeletal animation and WPO).
When disabling nanite from the ISM and ISKM asset, the trees render without the leaves because those rely on nanite assemblies (which don’t have a nanite=off equivalent).
The static mesh + WPO case appears to be working correctly. You can technically use StaticMesh + WPO + Nanite, its just that the runtime falls back on the raytracing fallback mesh. If you bump up that ray tracing fallback triangle count to 100% you can match the nanite off result (at the expense of memory). Its probably simpler to just leave nanite off in this case.
As far as cryptomattes, one limitation to be aware of is that the cryptomatte output goes through the deferred renderer pipeline. Therefore edge anti-aliasing will no match in the general case. I noticed the exrs you provided looked like they had a bigger mismatch in terms of leaf positions, but I couldn’t reproduce it when rendering the beauty image and object ids together. I used the GRAPH configuration for Movie Render Graph, connecting the ports that were unplugged.
If they were rendered separately, its possible the frame time in the shader was not matching. When working through the sequencer, its a good idea to keyframe a shader parameter to represent time precisely instead of relying on the global “Time” node. This way repeated renders should match up better (leaving only the AA and motion blur differences). Be careful that the nested material functions driving WPO have many copies of the Time node, so it might take a bit of work to track them all down. Ideally you should be able to see the trees move only when scrubbing the sequencer timeline.
Better support for path-traced cryptomattes has been on the wish list for a while although is tricky to implement since the current ObjectIDs are driven through the stencil buffer which isn’t used in the path tracer (and cannot hold anti-aliased values). One possible alternative is to create RGB shader masks to isolate parts of the trees and do quick renders with the same path tracer settings to get masks that at least have the same anti-aliasing edge quality.
Hope this helps!
[Attachment Removed]