TheKJ, Nanite is not meant for what you probably think it is. It actually helps, but the kind of test you did was too simple. Nanite mostly helps with overlaying meshes that need to be optimized.
If you do more research, it actually does help. Just don’t use it unless you need to. They never intended for you to go Nanite crazy.
You don’t need 1000fps, your simple tests got 131! I don’t even use Nanite and I get 25-60 on a simple world with fixed up LODs. You are very lucky. Think of that.
TheKJ, Nanite is not meant for what you probably think it is
Like I said, this is not just about me. AAA studios are botching optimization even more thanks to the lies and issues I explained.
your simple tests got 131
That’s to be expected since nothing else should have stacked ms wise since other features can be oddly inconsistent performance wise. No shadows costing 2.5ms, post processing cost .60 no Lumen system costing 5.3ms(should be 4 but worst case scenario). Not a bunch of other stuff and Nanite overdraw is not even representative of a standard game scene.
If I had made LODs for the scene+with baked detail, it would perform better. This is something a lot of studios are going to ignore. That is the workflow Epic should should have invested making better and faster.
Look at the title of this thread. Even Brian Karis said it should be used on low poly objects and “wherever possible” for the sake of “disk space” even tho it would cost perf. I’m not concern for my game as much as I am for the massive amounts of other titles I’m personally looking forward to migrating to this engine and it’s misleading, upscaler premoting bs.
You misquoted me, but all I can do is watch because I can’t explain it to you.
Nanite is for rare use. By this, I mean you should only use it if you don’t have any other options, basically a last resort. You are using it whenever you want to, which isn’t what they intended for you to do. Only use Nanite if you really need to TheKJ.
Nanite is for rare use. By this, I mean you should only use it if you don’t have any other options,
I’m aware of this, but that isn’t how to UE documentation treats nor how Epic treats it in Fortnite.
Atm, it is being promoted as this one all, be all solution by Epic themselves. That is my issue, always has been.
If you want to protest this to Epic, do it to them, not us. Set this thread as resolved please.
It’s not resolved. They are still lying and misleading about the topic on the documentation and titles I’m looking forward too are being destroyed by this.
This mark can be marked resolved when the documentation is fixed with context.
Exactly this, you may see a drop in FPS but your frame rate and frame time is likely going to be way more stable which will result in a smoother looking game/video. Frame time is arguably more important than frame rate. you can have 60 fps but if it stutters due to poor frame time that wont be good, but solid frame time at even 30 fps will feel fine like in red dead 2. rockstar nailed the frame time and I couldnt even tell it was 30 fps because there was no lag or stutter like most 30fps games have.
At above 60-100fps having your framerate and frametime fluctuate won’t be a huge issue but if it does it too much players will certainly notice. No pop in or detail loss like reflections on a building is also huge in a world where you can see far.
You should use nanite if you are having frame fluctuations a lot or losing too much detail with LODs and culling. The good thing about nanite is you can just enable disable it with a checkbox so you can easily test both ways and figure out which is smoother.
Moral of the story, there are no silver bullets, and Epic will say anything to sell their engine as the best thing in the market, even though most of times it is the less performant engine developers could choose.
I can almost see the “STOP DOING NANITE” meme being created …
Seems to be a lot of confusion about what nanite is. It was never meant to be faster than LODs. Its merely an easier hands off approach to auto scale your poly count to the appropriate pixels. Its a helpful solution for people who want to use assets like Megascans and get maximum quality right out of the box regardless of how close/far you are from the mesh. As of right now I wouldn’t even recommend it for games at all, unless you are actually using megascans type assets and/or targeting hardware 3+ years from now.
Its an improvement on LODs in terms of quality, but has a cost to it. Epic has been pretty open about this cost, and certainly isn’t forcing devs to eat that cost if they dont want it.
I actually disagree with a lot of people here.
Nanite can be much faster than traditional rendering, once your game reaches a certain complexity.
First, the comparisons people are doing here are not fair. Spawning 100.000 Nanite meshes vs a single DrawIndirect call with 100.000 low poly meshes will most certainly result in better performance on the low poly part. But try to spawn 100.000 different meshes with Nanite and without, and suddenly the performance looks much different!
Nanite has a base cost of 2.5ms to rasterize and 2ms for material evaluation.
This is consistent across our game scene, independent of vertex count or object count.
That means for us as the developers we can throw as many objects in the scene as we want and the performance will not degrade. It doesn’t matter if these objects are high or low poly.
We can also stop wasting development time on creating LODs. Even better, we get completely seamless LODs for free!
This enables us to do other advanced stuff. Detailed destruction for example where you have a lot of fractured independent meshes, which would usually result in a lot of draw calls.
What really kills performance is Lumen and (if handled incorrectly) Virtual Shadow Maps.
Lumen is not production ready in my opinion. We tried to optimize it for our game and it took half of our frame budget. Even if you reduce the distant field resolution and remove reflections, the budget is just too high.
For virtual shadow maps the resolution is just way to high by default. Unreal sets it to a 16k texture per light. You can decrease this indirectly by setting the VSM LOD Bias to a value larger than -1.5. for our game a value of 0 was perfect. While it removed the pixel perfect shadows and blurred them a little bit, (comparable to traditional lighting) it gave us seamless shadow LODs and a rendering time of 1.2ms.
Still high! But it scales infinitely with no additional cost.
Also if you have a lot of moving vegetation or objects in the scene, it is better for you to create a separate shading pass in the material where the geometry is static, to prevent cache invalidations.
With this our total rendering time was at 2+2.5+1.2=5.7ms.
Then we had post processing, skeletal meshes and the rest… resulting in 8ms frame time.
Now the cool thing about the Nanite pipeline is that it can run in parallel to the game thread. Our game logic was around 5ms, but because it ran in parallel we had a total frame time of around 10ms.
And that is the rendering time from now on. No matter how many objects we throw at the scene, it will not increase!
100FPS with infinite detail and objects in the scene, real time lighting, no LOD production or popping. Nanite is absolutely production ready.
And now comes the surprise: before we activated Nanite we had a frame time of around 50ms, with a rendering time of 45ms. (GPU bound)
So 20FPS. Yes we didn’t have custom tailored LODs (only the pregenerated in unreal), as our production time and budget was limited at that point. We also had a lot of fractured geometry in the scene, as our game heavily relied on destruction.
And now we can put as much destruction in the scene as the CPU can handle. The GPU is not a limiting factor anymore, which is exactly what Nanite promised.
Which is just another word for unoptimized considering the hardware affordable for today.
All your math was kinda pointless considering we don’t even know about the hardware you have or resolution you are targeting. A 3060 is miles ahead of PS4 and the PS4 has plenty of photorealistic gems yet modern games and Unreal as a whole abuses the abundant hardware we have for technology that adds very little visual improvement(vs alternative methods not in unreal ) for a much bigger cost.
Yes, I’m aware that is makes development faster like you said, and we should aim for solutions that provide this, but Nanite is a terrible route towards this as it’s kinda slapping customers with clearly sufficient hardware in the face.
Lumen is not production ready in my opinion. We tried to optimize it for our game and it took half of our frame budget. Even if you reduce the distant field resolution and remove reflections, the budget is just too high.
It runs worse with Nanite and will also provide a bigger visual difference. But I mixed feelings about Lumen anyways.
That means for us as the developers we can throw as many objects in the scene as we want and the performance will not degrade. It doesn’t matter if these objects are high or low poly.
The base cost is too much vs just optimizing your scene for what is necessary. This includes photorealistic environments.
, no LOD production or popping
Shadows, skeletal meshes and open world partitions still pop. So this isn’t cleaning up the presentation in any significant way. Also modern LOD pop is terrible most of the time due to auto-LOD algorithms being so wide spread. Using shader transitional effects and well made LODs are going to beat nanite.
I’m talking about reasonable best case scenario for LODs vs Nanite, LODs is going to win in performance for a number of reasons and that was the original advice for people who care about optimizing and basic game clarity.
The math that I was doing is similar on any hardware that supports directX 11.
We had no difference in Nanite calculation time on a 1080 vs a 3080.
So while you do have a base cost it runs similar on any hardware and scales incredible.
What you don’t seem to understand is that freeing the artists from work by manually creating LOD is a game changer for any serious business.
This has nothing to do with being lazy. As a smaller studio you don’t have the same budget, team size and development time as a tripple a production.
Yet now we have the same OPPORTUNITY to create these kind of games BECAUSE the technology is there!
Also what Nanite allows us is to go into much more detail with the environment.
You keep talking about „photorealistic PS4 titles“. But I don’t get that at all.
take any TrippleA PS4 title out there.
The last of us 1 for example. Beautiful game right? But before the remaster it had really low poly meshes and blurry textures. It was not even close to photorealistic.
Uncharted 4, the Witcher 3, all beautiful games! But absolutely lacking in detail compared to todays hardware.
With Nanite we can do these photorealistic games in much more detail in a fraction of time.
The problem here is „limitations“. These PS4 games had very strict limitations and they worked with what they had. Maxed out their possibilities. They threw in every tech they had. But they just couldn’t place any more objects into the scene to make the level more detailed and beautiful.
And that is the difference with Nanite. No matter how many meshes you throw at it, no matter how much detail: there is the base cost and that’s it. It will not increase.
No matter how hard you optimize, your performance does not scale as well as Nanite.
For you draw calls and poly count are a thing. Now try to have more than a few thousands of different meshes in the scene . Try to make a big production like an open world game, with high view distances.
Nanite frees you from these limitations for a base cost.
Which, once your game reaches a certain complexity, is absolutely worth it!
And like I said, 100FPS limitation for fast development time and great visuals is a fantastic tradeoff!
Our development target has always been 60FPS on a 1080 and that is easily achievable with Nanite.
The last of us 1 for example. Beautiful game right?
Weird, I was just talking about how bad this game looks (all versions) with another person on reddit.
It looks like a game not real-life. SWBF2, Detroit Human, Death Stranding, HFW, NFS2015, spiderman PS4 are far ahead and some of those run on PS4.
We could do a lot more now, but resources are being used stupidly.
: there is the base cost and that’s it. It will not increase.
That is out context, it increases as complexity increases. Go look at plenty of Epic example projects.
Our development target has always been 60FPS on a 1080 and that is easily achievable with Nanite.
At what internal resoltion? And do the visuals justify the performance compared to past games?
Sorry I am tired of this discussion.
Wanted to give my input but because you clearly have not worked in a real life production where time, cost and efficiency in the development cycle mattered, there is no point in discussing this further.
You are just theorizing.
Yes, in theory you are right. You could optimize any game down to the assembler code.
But at this point we could just argue why use a game engine at all. Isn’t that being lazy? Using unreal will introduce a lot of boilerplate code, which isn’t necessary. By writing your own engine you could achieve 10x the performance if you tailor it to your need.
But it will quadruple your production time which is not financially manageable for small studios.
Also if you look at the base Nanite cost (on any epic project) it is 2.5ms rasterising and 2ms collecting materials. It does not increase. The shadow maps do, but again you can optimize there.
I didn’t expect you continue this conversation.
Because my point is clear and there is no evidence to defend your argument.
Photorealistic games from 5 years ago are performing better than stylized games today. It’s not just limited to Unreal, but the documentation needs to be fixed regarding Nanite, that’s all this post is about.
If you want to talk about performance, there is a thread here.
I know this firsthand. I attempted to enable displacement via nanite and tanked my fps by half. turned it off, doubled my fps instantly. I am on a 1.5km map with world streaming. I just said screw it and switched all my foliage (couple hundred thousand trees and grass objecs), (hundreds of )rocks, and building objects to proper LOD form and I am getting 70+fps at times @1440p native even with a complex landscape material. Maybe 5.4 they resolve these performance issues. I don’t think nanite likes large landscapes just yet. lol.
It looks pretty yes to have that displacement, but runs like trash.
It is always possible to optimize more, at a cost in human time. If human time is not a limitation for you, then workflows that let you spend less human time to achieve the goal look with goal performance on target hardware, is not valuable to you.
However, in practice, there is never enough time. Anything that saves artists time, yet allows us to ship games that hit the performance goal on our target hardware, is a bonus. And target performance might be 60 Hz, but it might also be 24 Hz, for what that’s worth – that “filmic look” and all. (But, please, make it 60 Hz 
) Might even be 120 Hz for VR. (And in that case, Nanite might actually not yet be ready.)
But, saying “things can be optimized” is not a useful statement, because of course things can be optimized, if human time is zero cost.
And you may think you can make optimized art just as fast as standard art. Meanwhile, real games have to be produced by real artists who can actually be found and onboarded to the team.