Skip to content

Commit 4fca84f

Browse files
committed
nanite: evaluation done
1 parent 905327d commit 4fca84f

File tree

1 file changed

+17
-0
lines changed

1 file changed

+17
-0
lines changed

blog/2025-05-07-nanite-at-home/index.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -147,6 +147,23 @@ But these values are not precomputed constants, after all, moving the camera sho
147147

148148
## Evaluation
149149

150+
<iframe width="560" height="315" src="https://www.youtube.com/embed/K0du8jCp42I?si=vv40WUSLQ1IZJku5" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
151+
152+
Unfortunately, the LOD selection in my implementation is slightly broken, in that it selects a too low LOD way too early, leading to a significant decrease in image quality. So I can't exactly evaluate how much performance is saved by implementing a Nanite-like technique, or compare it to a traditional LOD technique with multiple unique meshes. And I've been trying to fix this on and off over the last few months, trying out two different lod selection algorithms, copying the lod selection from bevy, but still haven't figured out why it's misbehaving. If anything, consider that I've spent a year building all this and still it's not working properly.
153+
154+
155+
TODO image of simplified tree
156+
157+
And even then, the quality of the LODs isn't great and any 3D artist would be able to do a much better Job than my algorithm. I'd say it can handle natural objects like bolders and most human-made objects with sharp corners quite well. But if you try this algorithm on foliage, it simply looks bad. In the bistro scene itself, you can find two approaches to foliage: Most bushes are made up of many quads with alpha textures arranged seemingly randomly to create a volumetric effect, hardly a solid object, which doesn't simplify well and ends up looking very boxy on low detail levels. The trees and vines are made completely differently as interconnected mesh, which simplifies a lot to often just a few triangles, making the actual vine or leaves on the tree completely disappear. Some scenes with leaves have each individual leaf be its own instance, and would require special handling to first merge all leaves into a single mesh before processing it. Even Unreal Engine didn't support Nanite for foliage at first, likely due to needing to develop these custom algorithms for these special kind of objects. And there's likely a lot more object types that require custom handling as well. You'd likely need completely custom simplification algorithms for each one, and then some sort of algorithm to select which one to use.
158+
159+
TODO bistro image
160+
161+
What I'm getting at is that implementing Nanite is a significant time investment. If the main reason you want to implement Nanite is to gain additional performance, consider all the other options you have, most of which will gain you more performance for the effort invested. But to give somewhat of a performance estimate, I benchmarked my tech demo in 1080p on my Ryzen 9 6900HS's iGPU, which is pretty similar to a steam deck. When I finished my thesis, my demo ran at 13fps (75ms) with maximum detail and 23fps (42.8ms) with my Nanite implementation, at a significant decrease in visual quality. Since then, I implemented (kinda shitty) automated mipmap generation, which alone raised performance to 89fps (11.1ms) on maximum detail, with block-compressed images (like BC7, BC5) squeezing out a bit more at 92fps (10.2 ms). Enabling Nanite now, I'd get 195fps (5.2ms) at way worse visuals, so take this value with a significant grain of salt and expect actual results to be way lower.
162+
163+
I don't think that implementing Nanite is worth it from a pure performance standpoint, except maybe for AAA studios who have the resources to build it and get it to a good enough quality. But if you want pure performance, you should first focus on getting all the basics out of the way. Like I haven't implemented any form of frustum culling, no two-pass occlusion culling, still use a G-Buffer instead of a Visibility buffer cause it was faster to implement, could likely benefit from batching my draws and should compress my vertex attributes better. All of these will likely have better performance yields for the time invested than implementing Nanite.
164+
165+
I could see Nanite as a tool for artists though, removing their need to manually create LODs and save money in production. However, I can't reasonably give you any recommendations, I'm not an artist myself nor do I know how much time is spent on creating LODs. But there seems to be an active need in that area, since there's multiple companies selling software just for mesh preprocessing and simplification.
166+
150167
## rust-gpu-bindless
151168
* maybe a separate article, coming later?
152169

0 commit comments

Comments
 (0)