thanks for putting all this together, my editor kept on crashing whenever there was too many nanite meshes in the world (non-instanced, something about nanite node buffer running out of room)
now onto RVT for landscapes…
Has anyone realized that nanite is technically lods calculated at runtime?
look at the fallback triangles part on the top left-hand corner. They just change tris and vertices just like an LOD. So why does it still take up ms of frametime? To me, nanite is just a lazy way of adding “lods” to your games. Additionaly, FN with nanite takes up more than 60% of my fps!!! (1440p no upscale)100fps-120fps using dx12 rasterization but not hitting 30fps with 1080p(dlss perf)! Honestly this is just outrageous.
I feel like this is a misunderstanding of what Nanite is supposed to be.
Epic has as far as I know never implied Nanite is a system that performs better than traditional LOD’s, and I don’t think they ever intend for it to be that either. LOD’s are great, they perform well, that’s the whole point about them.
The point of Nanite is to have large amounts of high-detail models rendered at real-time. That’s it. If you want to maximize performance, Nanite is not the answer, and likely never will be. If you want to reduce asset creation workload while increasing visual fidelity and still have the game run at an acceptable FPS on consoles and high-end PC’s, that’s when you turn to Nanite.
Nanite is not about having good performance, Nanite is about having acceptable performance with a poly count orders of magnitude higher than what was previously possible to render real-time. The minimum hardware requirement for using Nanite with good fps is really high, but the trade-off is that the performance hit of Nanite isn’t going to grow that much regardless of how many polygons your scene has.
The other benefit is that as hardware gets more powerful over the coming years, Nanite isn’t going to get more expensive, and so essentially it will be cheaper and cheaper instead. I’m sure there’s ways they can optimize Nanite to require even less power than it currently does, but the the primary driver of reduction in Nanite’s performance draw is going to be improved hardware.
That said, I do agree they should update the documentation. While they don’t claim Nanite performs better than LOD’s, they should make it clear that it doesn’t. The part of the documentation you’ve quoted seems to me to clearly be answering the question of what meshes Nanite should be used for if you’re already using Nanite anyway, not the question of whether you should be using Nanite or not. But they way they’ve written the documentation, it’s a perfectly valid interpretation to read it as them claiming everyone should always use Nanite for every mesh. Which just isn’t true, and I know Epic knows that isn’t true.
6 Likes
I’ll play devils advocate for a bit
Here’s the same shot from the city sample on 5.1, first one uses Nanite, second one has Nanite disabled on the project. Same resolution, on a 2080
It’s first really important to note, this comparison is super dis-ingenuous to the non-nanite shot. It is not nearly optimized in any way. Realistically you would setting better draw distances, HLODs, fine tuned standard LODs, etc. This is also just profiling off the editor and not a packaged build so all these numbers are basically worthless.
You can look at the average frame in unreal insights
But it’s not really the specific fps that I’m trying to highlight. Obviously GPU times are better on Nanite cause the non-nanite content isn’t optimized. But polycounts aren’t the only feature of Nanite. It’s doing per-cluster occlusion culling, eliminating mesh draw calls by finalizing them in the Nanite pass, etc. You can see the render thread is way less utilized in the Nanite scene.
When you enable Nanite, you are taking a significant up-front cost on the GPU for it. Buuuut… it scales a lot better with polycounts on objects, instances in scene, and mesh memory with not a lot of extra developer work. When you enable Nanite and populate a scene with the same mesh thousands of time you are taking the cost of Nanite but missing out on a most of the benefits (essentially no culling, draw calls were not an issue since they are probably instanced anyways).
This is probably true in simple games like Lyra as well (I dunno, I haven’t opened it so take it with a grain of salt). The benefits of Nanite start paying off when you have more complicated static environments, where you have a lot of instances and a lot of models that you want looking good from any distance. Think like big open world games. The cost of nanite is more tied to the screen resolution rather than scene complexity. So when you are testing performance of nanite in a simple scene, it looks really bad lol.
The idea of “everything that can be nanite should be nanite” I think is more regarding if you are already using Nanite, you should try to enable it for everything possible. The more that is rendered into the Nanite VizBuffer, the more it use it from occlusion and strip away traditional draw calls. Again, if only half of your scene is using Nanite, you are still basically taking the same cost but only utilizing half of the benefits (in a simplified way of thinking about it).
The performance of Nanite is a different beast than traditional LODs, and I find polycounts are one of the most irrelevant metrics to guage whether or not Nanite works for you (despite it being one of the biggest selling points of the feature, I don’t think people should be using Zsculpts in a game production anyways lmao). I’ve had scenes that actually perform better when models are higher density in triangles since the nanite clusters become smaller and the occlusion culling can be more precise to reduce Nanite overdraw.
Anyways, in all, I actually do agree with your main sentiment in the post. I feel like there has been a miscommunication in UE5 suggesting all projects should use Nanite. Obviously not true since it doesn’t even officially support PS4 / Xbone. But whether or not Nanite makes sense for a project is a harder question. I’m not even really advocating to use Nanite or anything, I believe a lot of projects don’t need it, but I do think it warrants a more thorough investigation.
4 Likes
I have never noticed that tris change, is that new?
So why does it still take up ms of frametime
Nanite uses a visibility buffer to render faster(Epic didn’t invent visibility buffers).
Nanite on the other case does a bunch of LOD work, compression and weird material stuff I personally don’t understand, culling in real-time.
Also, Nanite can sometimes make unoptimized meshes render faster, but the cost of Lumen and other features go way up making the GPU raster benefits worthless.
Then you have people say “But it gets rid of draw calls!”. Optimize your draw calls then, merge meshes and materials. City Sample could afford to be released at 30fps because it wasn’t innovative as a game, only in graphics, it marketing. There is a reason Sony’s spider man well runs well above 60fps on affordable $300 hardware(well above 60 means headroom for more important visuals like GI and reflections).
People with sufficient hardware should not have to buy a whole other $700 GPU just to play games at basic standards like clarity and 60fps.
1 Like
You said it better than I did, thanks for the write-up! 
As has been mentioned a few times now, Nanite is not aiming to be more performant than a game that’s been well optimized.
It’s not trying to perform better than LODs or manual optimization. It’s trying to make a new system of rendering in which engineers and artists workflows are not bogged down by hours and hours of optimization work. If you have 15 artists who make one mesh each per day, and then spend the next day optimizing them for performance, then Nanite will save you 150+ artist working days every single month.
It doesn’t need to run better than LOD’s and a well optimized game to reach that goal, it just needs to be able to render thousands of instances of different unmerged, LODless meshes and materials at a playable framerate.
This thread is the equivalent of being upset because transferring liquids by pumps and pipes cause more spillage than transferring it manually with a bucket. You’re free to do it with a bucket if that’s feasible and what best suits your needs, but sometimes the task is so big that it’s worth the spillage to do it the automated way.
6 Likes
I’m upset because Epic has provided something extremely destructive to games and studios.
And I’ve applauded the performance of games not using Nanite: Released UE5 games-The 60fps performance monitoring of games using UE5..
Nanites causes to many problems and hurts regular consumers. Nobody is going to care unless somebody states the “obvious”.
I don’t care about being obvious, not enough people are. Lots of games have used Nanite and this thread might help a studio decideding.
Personally, I want to make the argument between the too, I made this thread to convince LODs and optimizations are worth the investment vs slapping Nanite.
Using Nanite Pros:
- No draw calls,
- No LODs investments for static meshes,
- No pop ONLY on nanite meshes(I have stated why this is pointless here)
- Fast kitbashing,
- Faster than rendering billions of triangles, (but not millions)
- VSMs don’t break on Nanite meshes,
Not using Nanite (Cons, many can be turned into pros):
-
You need to time and money on optimized meshes with starting polycount and LOD count, merge meshes and materials, optimize meshes per scene, this might be more memory usage.
-
After you optimize you should get 20% or more free GPU power for computing for more features like #2 below.
-
You can use Lumen GI and reflections and maintain 60fps on appropriate consumer hardware(30 series and competitor brands) at crisp native resolution. If you use Nanite, it will look blurry because you need to use blurry upscalers to fix the games performance.
-
By using LODs and optimized meshes, this also makes the game look better without insanely aggressive frame smearing methods like TAA and upscalers. LODs prevent moires pattern and geo density aliasing.
-
By investing in LODs and optimized scenes, you can make more sales because games that are not blurry are praised by word of mouth, the most powerful advertising you can get. Your studio will be more respected by the majority of consumers which makes your next titles more anticipated.
2 Likes
Second time I’ve seen this in this forum. Would really like to see proof.
Would really like to see proof.
I’m not a 3d modeler but basically a pixel can only represent one triangle of a mesh, and one pixel of a texture. So when you have tons of detail on a mesh far away from the digital camera, it can only sample 2 things and misses tons on triangles and pixels in-between.
Let’s say real life was made triangles and texture, a real life camera would chroma sample light from a far and pack hundreds of triangles into one pixel representing that far away mountain etc.
On the texture side, shader can by bass the pixel limitation because you can feed in the original data from the texture the render sampled for the shader.
We can’t so that with meshes. City Sample’s buildings are insanely high poly, without TAA to fake chroma sampling or SSAA, you can find insane amounts of moirés pattern on objects from a trivial distance because of how much information and geo representation the render misses per frame.
Here is a small example of a high poly mesh as it displays moirés pattern as too little pixels can represent the data.
They need to make LODs that have the geo dense parts flattened for Mipmaps or for shader based chroma sampling to take effect.
At around 0:36, he shows a close up, the moirés is gone because enough pixels can sample the geometry.
Optimized models would have those inscribings done via fake parallax occlusion with those parts of the mesh being flat or just have LODs that focus on flattening the model and decreasing the detail as the camera distances itself.
This is why nanite marketplace assets are worthless to games.
Most game models start off with high poly and have to be optimized for both performance and visuals.
The creator of that video said he was having the issue with both LODs and Nanite and in that very same thread you said it was a mipmap issue…
Didn’t you change your name? Used to be Snake something, right?
The creator of that video said he was having the issue with both LODs and Nanite
Yeah? And both are meshes. LODs and Nanite can both have these issues, but LODs can have high geometric detail and lower geometric levels to combat this affect unlike Nanite
in that very same thread you said it was a mipmap issue…
Yes, I was not aware of geometric aliasing until I met a veteran developer in r/F*ckTAA a couple months ago.
But after it was explained it made a lot of sense.
And its still is a MipMap issue, that part of the mesh need to be flattened for MipMips to combat it automatically.
UE’s LOD system is terrible, has no logic to detect this kind of stuff. This is why I’m a firm believer AI should take over in the LOD department
Didn’t you change your name?
Yes, it was linked to VERY old Epic Account made for Fortnite(I wanted the in-game name) when I wanted to test it on a switch. Made no sense on here and found out how to change it.
1 Like
I would argue that the culprit was the aa method and settings.
1 Like
TAA and TSR, DLSS etc fix this because they fake SSAA but only in stationary and slow movement.
Basic motion from basic gameplay is going to look like Vaseline, or have ghosting, or blurring, and cause a tremendous loss in detail.
TAA and upscalers controversial for a reason, and we lack developers that give a ■■■■.
Unlike the majority of developers, I don’t believe TAA and Upscalers are the future, it’s terrible hole we need to get out of as fast as possible.
Epic Games and UE keep making this hole deeper.
Developers shouldn’t use blurry, smeary Temporal crap “fix” those. Games that do not have TAA and it’s various upscaler forms look a thousand times better.
TAA has caused such massive amounts of laziness in this industry.
Thats one of main points about Nanite, it promotes Temporal AA/Upscaler dependency which a lot of people hate, including me.
2 Likes
NEW TEST, AND PREVIOUS DATA INVALIDATION
I’m going to just entirely restart the data I provided as some of my post have become revealed misleading results. I would say some of it was my fault but there is still a lack of documentation on a particular issue I will be addressing.
First, let’s measure how many triangles are too much triangles for modern, affordable GPU playing at 1080p.
Around 2-12 million triangles keep the GPU at consistent 38-39% GPU usage
(6ms out of a 16.67ms budget).
UE5 pure poly count test RTX Desktop 3060 - Imgsli (GPU usage-triangle ratio comparisons)
Capped at 60fps to measure GPU usage.
Tested in standalone and received the same results later for anyone wondering.
I do my test in Editor first simply because it’s easier. Anyone can do the basic math and subtract the editor primitives etc and do similar test to prove me wrong anyways
Let’s take the 16 million budget and apply Nanite.
Needed to record for this one. This was not in editor. During these fluctuations, GPU usage quickly bounced around from 22%-32%-45%-72% GPU usage within 15 second intervals.
Sadly the recorder did not pick up the GPU usage measurer.
Interestingly, Nanite could prove faster on a optimized poly budget if it could retain the 22% percent but it doesn’t, at least for this test.
The test provided here, were done via r.nanite 0
Doing that command doesn’t disable Nanite, it renders fallback on an extremely different pipeline that I still don’t know is faster or slower? That Lyra test is NOT accurate as it was done via that command. Not all my test used this command, the proper way to test I believe is to go to the mesh and right click “disable”(which were done on the first amounts of test).
Now, let’s see if we can achieve a higher poly budget than 16 million, and stay at around 39-40% GPU usage. (Remember last time, it kept bouncing around at 22%-72%)
Stays at 39%-40% GPU as if it’s rendering 16 million raw triangles without Nanite…
Still, plenty of reasons not to(and as others stated reasons why should use) use nanite, but performance is so bad in recent games using nanite.
I’m not measuring anything else besides raw triangle count, which goes up when you have shadows etc.
Again, I have stated nanite can be faster, but Lumen and other features tend to spike in performance.
Wanted to clarify any issues.
Maybe this was an update, but not sure. If City Sample still runs the way it does with no AI then we need to stick with LODs for regulars customers with hardware well past next gen/current consoles.
So, found this.
Again, FIX THE DOCUMENTATION EPIC.
Straight from the creator of Nanite.
The primary reason to use lower resolution Nanite meshes is to save on disk space. The performance of lower poly meshes may not be intuitive or like you are used to. Commonly that won’t improve perf. Sometimes it can even be slower. YMMV.
From Brian Karis himself, from this comment.
In MGSV, a HIGHLY performant and GREAT looking game, most assets in the environment are under 1000k tris because the focused on baking tons, in fact millions of polys into normal maps and used good lighting. That is PS4 generation game from 8 years ago, we should only be doubling and keeping under 2k tris. What we lack and big studios like Modern Konami and Bandi Namco lack are workflows that bake detail intelligently. The LOD system is terrible in UE and even Brian Karis said the biggest difference between polies and normal maps is self shadowing.
We should have textures and systems within the engine that fake that.
Nanite should only be used in virtual production NOT GAMES.
We should also be offered stand alone Visibility buffers since that clearly enhances opaque performance, which in turn allows for better budgeting for more important thing like semi-dynamic GI and AO.
Personally, I don’t Epic is going to fix this. Their is goal is make money by making an engine just barely acceptable so enough large studios with praised IP’s don’t have to spend money on up-keeping their own engines.
And the fact that most ppl don’t know about how horrible TAA and upscalers make games looks only accelerates Epic/Studios who use UE success.
Disk space…like that matters when the game performs like trash on good hardware.
2 Likes
Well, the general development (and life) principle here is that investing time in optimizing stuff by hand would generally yield better results than being lazy and not doing so while relying on a tech that claims to provide some “free” performance automatically while obviously introducing and requiring substantial implementation complexity.
1 Like
What you need to know about Nanite is it may take cost, but optimizes your scene down to the pixel, and with a stable global cost.
If you make a big complicated scene that uses only LODs, you have got a big suite of issues there.
1 Like
How is it Epics or their technologies fault if you don’t optimize your games (which you also can and should do with Nanite, as Epic states)? Right, it isn’t.
Apart from you obviously not understanding what Nanite was built for, I also have to say that this state of mind is the reason why, up to this day, many assets in games look they have been imported straight from the PS2.
Tons of rendertime and tech effort is spent on RT and other shader effects to light and shadow assets that have more edges than M$ has shipped browsers to this world.
So please, just please, take a moment and hail Epic for this enormous leap forward to realistic geometry in games and thus graphical fidelity and if not, just do it quietly. Thanks!
2 Likes
I agree, you can’t blame it on Epic, but I make my statements based on what I was educated on and what Epic says publicly. Please do not insult my knowledge.
Here is my advice: use nanite for large meshes that may be constantly occluded. My experience with this is a little limited because I stay away from it since I don’t need it in my games, or not yet.
Edit: Epic did do some things others have not, but they haven’t been implemented at a visually noticable level. The only way to see it is to look at two examples side to side.