Hey,
I have been posting a couple of projects on the work I did for Fading echo. I have just finished working on a new one where I discuss why we took the decision to completely remove Nanite from our project and how to optimise a game using old techniques rather than blindly trusting new features.
You will see that it is pretty standard but I thought I would share it with people for insights
If you want to see the full breakdown with videos and extra explanation head over to artstation:
https://www.artstation.com/artwork/q0A9OR 


Replies
Great work!
Glad to see devsusing UE5 while not falling for Tim Sweendley's marketing slop, and doing things the way they're meant to be done.
The art of optimization shouldn't and can't die.
Nanite was not invented so everyone could import infinite density meshes and just let the engine handle it, costing all of your RAMs.
It was invented so the Fornite dev team wouldn't have to manually create 18 further LOD instances to manually battle the eventual pop-in they would encounter in a pub-g type open map with hundreds of meters of render distance.
Seeing stuff like this makes me instantly trust a dev to make good decisions.
Well done all around. Your effort absolutely show!
Did you use perlin noise as a blend method to avoid that simple blurred lerp look?
The first title we shipped on ue5 didn't use nanite cos we needed xbone and ps4 support but if you're not forced onto legacy systems I'm not entirely sure why you'd not opt in to having effective batching/instancing given that unreal does such a piss poor job of it with static meshes
I'm genuinely curious - I've not dug into it properly as we primarily use our own engine and nanite was veto'd for the reason above
Regarding why we didn't use nanite, multiple reasons:
- The first was the performance impact compared to the benchmark target we had. I always work on small scale scenes before creating full environments to stress test everything and avoid surprises later down the line. The majority of the assets I did at the start of the project were very high poly, first of all because they were extremely large scale and second of all because the leads on the project wanted to avoid using normal maps (with the fake idea that mesh could do everything now).
Assets were still optimised to not import raw sculpts and came down to about 30-40k polys for a 15m cube shaped cliff. With a base of 20-25 assets to build a scene 20x20m I started to observe EXTREME performance issues. Culling wasn't working properly, we had a bunch of overdraw, draw calls were completely broken and the base cost was almost a third of what our target ms was and honestly the render didn't look that much better...
Keep in mind all of this was on Unreal 5.2 at the time of development (we later switched to 5.3 and then 5.6 much later into production)
- Based on all the observations above I just did some heavy testing using the majority of the features we were going to use for production (for example level instance which nanite struggled with for no apparent reason). The WPO toggle option with nanite meshes was easy to use and good addition but honestly we could easily replicate it with non nanite as well.
I compared our first pipeline to a more traditional one which an automatic custom lod batch tool and a material switch included with the LODs that would also saved up some performance (which nanite also could not do without some external implementation as far a we were aware at the time). On a benchmark scene by only removing nanite and adding simple lods we went from 35 to 19ms. When adding the material switch and later on the custom application within the levels we came down to 16-17ms. That's without any other type of optim on the game at that point. Just raw art
- Regarding other features we removed VSM as they were also tanking performances but we are using lumen. The reason being that the team was small, production was let's say eventful to say the least and having to go through a baked lighting route would not have been viable with those cards