One if the limitations of displacement using nanite tessellation, is that it only supports calculating the displacement in local space. Meaning everything gets scaled with the object scale.
This is often undesirable.
I can counter the visual displacement changes in the material but the buffer it allocates to handle the displacement still gets scaled.
If the camera enters inside the area allocated for a nanite meshes displacement the culling breaks down.
When objects are scaled, this area can get quite large.
It’s looking like my only option is to have a cache of meshes that I swap to as an object is scaled that require less scaling to reach the desired object size.
Just thought I would reach out here though to see if anyone has an alternate suggestion.
We have an internal task to evaluate supporting whether tessellation shouldn’t be affected by local scale (related PR https://github.com/EpicGames/UnrealEngine/pull/11735\) but haven’t prioritized the task very highly. It’s unclear how soon we’ll get to it. Have you evaluated whether Nanite tessellation is performant enough overall for your use-case if this option were available?
I’m passing along this question to my colleague who is more familiar with our plans in this area for additional thoughts.
Yes, world-space displacement is planned, but it is unclear when the team is going to be able to focus on it. Also the culling issue is interesting - I don’t think we’ve seen that in our own assets. Looks like what happens when WPO extends the geometry outside the culling bounds. If the culling issue is still a problem for you and you can produce a simple project that reproduces the issue I can take a look.
Unfortunately, the file you attached failed to upload or attach correctly and we are unable to download it. We’re trying to track down what the issue is. It would help if you could enable Dev Tools in Chrome (F12) and in the Network Tab enable “Preserve Log” at the top. Then re-upload the file, or make a reply with the file attached. Then, when finished uploading, click the “Export HAR (sanitized)” button in the same header as the “Preserve Log” checkbox, and send us that exported file. It’s a JSON file you can open in a text editor that shows the network traffic on the web page, status codes etc that may help us determine what’s going wrong with the uploads. While you have the Dev Tools open, if you see any errors in the Console it’d help to know what those are too.
Thanks so much for getting those logs for us and figuring out a workaround. I’ve passed the info onto our web gurus and created an internal issue for the Nanite culling issue for tracking which should be visible publicly soon here: UE-369126
Sounds like swapping meshes is my best bet for now.
I’m investigating a workflow where I build most of the scene out of 4 ISMs (Square Side, Triangle side, Edge and Corner).
I haven’t done any rigorous performance testing yet, but framerate hasn’t been a noticeable problem for the moment. I get 100+ fps in the editor viewport with this stuff filling the screen.
Mostly I’m looking at this from a workflow perspective that I could add a bake step to later if needed.
I’m curious though if having most of the geometry on screen handled with just a handful of ISMs will provide some performance optimization to absorb the hit from the displacement rendering.
Thanks for the follow up. I’ve attached a project that demonstrates the issue.
You should see the issue as soon as the project loads.
Let me know if you don’t.
I am able to work around it for now by swapping the meshes as I increase the scale. I’m wondering if this is the right approach for performance reasons even if the render issues are fixed?
Though, I image if fixing the issue is done through providing would space support so that the displacement doesn’t scale with the object it would be cheaper to have fewer unique meshes?