Any Examples of Nvidia meshlet tests polygon count?

Newgamemodder said:
Has anybody tested mesh shaders and can say how much they managed to render (without counting culled triangles)

It depends on what the mesh shaders (or compute shaders) actually do to minimize overdraw. Ther are many solutions to the occlusion culling problem, with differing strengths and weaknesses. So there is no single answer to your question.

But personally i have implemented a method which i think is pretty standard now, at least for cluster based methods which mesh shaders is about.
I think it was introduced by Karis with Nanite, and is often called ‘two-pass occlusion culling’. But it's so simple, maybe it existed before that already.

Let's see if i remember how it works:
First we render the set of clusters which was marked visible in the previous frame.
Then we build a ‘hierarchical Z-buffer’ or ‘Z-Pyramid’ from hat.
Then we consider to render the rest of the clusters, but only if they are potentially visible after testing the HZB for their bounding rectangle.

Assuming the camera movement since the last frame was small, the method is very precise.
Which means, it renders only (or almost only) clusters which you actually can see in the final image.
Accuracy is better if clusters are small and compact, which is the case for high poly geometry.
If geometry is low poly, clusters become big and you get more overdraw, but a solid wall still manages to occlude most stuff behind it.

So it's pretty good and likely the method you would choose.

That said, notice that the answer actually depends on your models. Some examples:

If the model is 100 quads placed in order behind each other to form a cube of slices, and we look at the model straight so we see only the front most quad, we will only render this single front quad and cull all 99 others.
But if we rotate the model, so we see a bit from each of the 100 quads, then we end up rendering all of them.
(This example ignores the clustering, but that's how you should think about it.)
Another example:
We are in a skyscraper in a room, and all doors are closed. We will only render this single room and the stuff within it.
But then we fly outside 20 meters, and turn back, looking at a grid of 10 * 50 windows.
Because we can see through the glass, we will end up rendering 500 rooms. But we don't render the 4000 other rooms further behind them.
(I'm describing ideal results here. In reality we will always render some occluded stuff as well, but you can ignore this, or just adding 10% maybe)

Notice both my examples here are about ‘dense’ models with ‘high depth complexity’.
So adding a final example about low depth complexity:
We have a Star Trek model of the Enterprise space ship. It has no interiors, no rooms inside. Just the stuff we could see from outer space.
Even without any occlusion culling, this model will give us a maximum overdraw of 3.
Assuming both engines at the back and the saucer at the front overlap a single pixel, and we culled all back faces already, we will draw to this pixel 3 times.
In this case the culling will not cull much, and it might be even a slow down.
For a strategy game in space, or typical top down games like Diablo, there is probably no need for occlusion culling. You need to draw almost all triangles which were not backface culled anyway. Further occlusion culling would only slow it down.

So for this example, the answer is simply: You draw 50% of your triangles which passed the frustum test. The other 50% were backface culled.

I hope this helps so you can estimate yourself.

I found sortof an example:

Now i know LOD's will play an effect plus half of the side of the ships would be occluded especially with mesh shader meshlets…

Newgamemodder said:
Now i know LOD's will play an effect plus half of the side of the ships would be occluded especially with mesh shader meshlets… Like Quote Reply

Yeah, for this a LOD solution will help the most, by far.
Occlusion culling is probably pointless. Although it's cheap, so not totally sure.

The advantage with mesh shaders i see is: You can do backface culling there already, before reaching the vertex shaders.
And you can cull triangles so small they don't cover a single pixel too, which are currently surely a lot. But not so much with a lod solution.

Heh if the ships i intend to use are high poly occlusion culling is probably helpful ;D

Newgamemodder said:
Has anybody tested mesh shaders and can say how much they managed to render (without counting culled triangles) I know a Chinese game called Justice managed to render 1.8B triangles at 4K60fps (i assume they mean rendered and not per second)

The article describes a very similar technique to what Unreal does with Nanite, and what various HLOD systems have done for just over two decades. Vertex shaders allow code on the graphics card to push the details, Advances in the last six years or so of graphics cards have enabled far more work to move to shaders like mesh shaders and amplification shaders, but the research behind the technology is two decades old now.

The main difficulty has always been keeping the video card fed with data, followed with the difficulty of the rasterization which often goes through multiple complex shaders. The last few rounds of shader technology removed a lot of those bottlenecks.

You can have multiple billion polygons in a scene, and through carefully managing level of detail you can adaptively control which polygons make it to the video card, and once on the card they can adaptively figure out detail on different segments of the mesh, and with meshlets better control which mesh sections are actually rasterized. There is culling done at every step, long before they're turned into rendered polygons.

All of it is view dependent, and even within a mesh different patches have different detail levels. A large dragon that is chomping on a player may have high density patch of triangles around its teeth and jaws, slightly less density around its jaws and nose, and no mesh details at all on the tail, yet all of the patches might take up perhaps 15-30 pixels on screen in one set of settings. The dragon may be several hundred thousand polygons in the scene, yet through managing the hierarchy the system can compute which patches need to be highest density like the teeth that are biting and taking up a lot of screen, and less in other parts of the body taking up less of the screen.

The mesh shaders coupled with amplification shaders are a step up on vertex shaders and are able to compute how much density it actually needs for a patch on screen, and generate data for the next frame that a patch needs more detail or less detail. Real-time ray tracing shaders give systems feedback about the patches. Meshlets are powerful, supported on RTX 20-series (2018) and later.

Newgamemodder said:
Since what i will make is a mod i only need it to run on my PC (so depending on how far tech has gone either an RTX 6090/6090ti or a RTX 6000 Pro from the next generation

You may be pleasantly surprised by what good tech on decent hardware can do. In the last two titles I've shipped, Unreal has been able to happily manage sprawling scenes and manage to keep it consistently running at a solid framerate even on cards that are almost a decade old. There's a huge leap on newer cards that support meshlets, but the underlying tech does quite well enough even with the earlier versions.

Meshlets have been around since the 2018 RTX20 chips, and RTX 2060 can quite happily fill about 100 gigapixels per second, 200 gigatexels per second.

It is far more about the complexity of the shaders you write and the actual rasterization behind them than it is about polygons in the scene.

Would i be a big dumb if the game has 4 LODS and i use the highest for the 2 highest lods but the 2 other lower ones follow industry standards?

Newgamemodder said:
Would i be a big dumb if the game has 4 LODS and i use the highest for the 2 highest lods but the 2 other lower ones follow industry standards?

If that means you have duplicated storage and memory, yeah it's dumb.
Otherwise it's a matter of checking performance. But remember not everybody will have a 6090. (Intels newest iGPU looks way more promising, imho)

But ideally you could just tweak distance settings of individual lods, so you can see details at greater distance than usual.
Maybe that's possible using lod settings in gfx options.

I will be the only one using the mod (it wont be for the public), I know it would be bad with “double highest lod” but with mesh shaders and a 6090 or RTX 6000 pro would that help?

Newgamemodder said:
I will be the only one using the mod (it wont be for the public)

Well, then you can do whatever you want. Once you are a proud owner of a 6090 for the price of a car, the ‘dumb’ part has already happened, and you can't top that anymore. /;D\

Newgamemodder said:
I know it would be bad with “double highest lod” but with mesh shaders and a 6090 or RTX 6000 pro would that help?

It will surely help a lot, but only time will tell how much geometry you can push at acceptable fps.

What is the game you want to mod?

Newgamemodder said:

Would i be a big dumb if the game has 4 LODS and i use the highest for the 2 highest lods but the 2 other lower ones follow industry standards?

Not necessarily “big dumb”, but you're using a 30+ year old solution rather than current industry standards. Static mesh replacement has been superseded since the mid 1990s in research, and in tools and tech since the early 2000's.

Continuous, view-dependent LOD where segments of the mesh are dynamically rendered at different levels of detail have been in use about 3 decades, with a big boom in 2001 after the GeForce 3 introduced hardware-based shaders. “CLOD” and “ROAM” were the terms back then. By 2002, Chunked LOD systems (easily confused with CLOD) were becoming more widespread. That was much of my research back in grad school, and it's hard to overstate how much shaders shook up the world of mesh rendering. I had been doing work on quadtree morphing and apative TIN techniques, which were gaining popularity until shaders arrived. Early demos did with a 100MB data file in memory what was being done with 1GB datasets on high-end SGI workstations.

The research from a decade ago shifted to better quality through even more comprehensive view-dependent systems based on mesh hierarchies. That was expanded even more with a boom in 2018 when “meshlets” gained hardware support with NVidias RTX20 series cards, followed shortly after by AMD's.

You wrote you wanted to “follow industry standards”, but it sounds like the standards you're following were dated 1994 or earlier. The current industry minimum standard is meshlets, many games set the RTX20x0 card as their minimum hardware spec for that feature specifically. If you're using Unreal Engine, you probably know the technology as “Nanite” as a checkbox for how meshes are handled. Research has more advanced, adaptive hierarchical methods, this is more of the min-spec machine, the bare minimum for ‘industry standard’ techniques.

Im confused, i thought having different “LOD Levels” was industry standard?, atleast that's what i've seen in games.

Forgot to add i'd like some MSAA as well so i assume my GPU should be “RTX 6000 Pro” of the next generation

Kind regards!

LOD systems are absolutely common, but not the method you described. The method of those levels of details is what has changed over the years.

Simply swapping out lower resolution models with higher resolution models is an old technique that hasn't been done in games for many years. Games transitioned away from that as soon as they had the processing power around 1997-1999 on PC, around 2000-2002 on game consoles. The last shipping game I worked on where I can remember that DIDN'T do view-dependent LOD was a Nintendo DS title. On both PS2 and original XBox we used view-dependent techniques.

Modern techniques use hierarchical level of details. Here's a 60 second explainer. And if you want to go deeper, here's a one hour explainer from nearly five years ago, showing how Unreal's hierarchical LOD system works across complex scenes, how it is used for the objects, lighting, and shadowing, how it works with streaming / loading on demand, and more. That was released as part of Unreal in 2022, and relies on hardware that has been available since 2018. At 3 years it was mainstream enough games considered it common, and right now in early 2026 the last two games I've shipped they were minimum spec requirements.

That's still "level of detail" system, but very far from models with 2 or 3 static meshes that are dynamically replaced one with another. The entire scene is processed with adaptive level of detail trying to get the correct level of detail based on the pixels actually rendered. The goal is to have small patches across the entire scene that match the detail they occupy, meshlets that occupy around 6-16 pixels regardless of if you're looking at the teeth and claws of a dragon up close, or a tiny dragon across the valley in the distance. It is also view dependent, looking directly, near perpendicular to a flat surface can use far less mesh density than an oblique angle to a curved or bumpy angular edge that forms the contoured profile, where the extra detail is important for clean edges. Take a few steps to the side and what was high density is now low density, what was low may now be high density.

Ah so you mean that i won't have control of the lods?

Sorry if i've asked this before but can you have “more triangles than pixels?”, am i correct in assuming that it's possible but you would need msaa to fix “jaggies”? There's no limit to the “polycount on screen” except for the GPU having to work, there's no technological “barrier”?

Kind regards

Newgamemodder said:
Ah so you mean that i won't have control of the lods?

By making a mod, you certainly have no control over the method the game uses to achieve lod.

If the game uses advanced continuous lod methods (e.g. Nanite) like frob has mentioned, this will make it a lot harder or impossible to make geometry mods at all (!) Because the data structures are complex and hard to reverse engineer, and generating new data from new models also is hard.
You would likely depend on modding tools released by the devs to help with this. (I assume with UE it's possible because all tools are public)

But as far as i can see, advanced lod methods are not common yet outside UE5. The latest Assasins Creed game is the only non UE game i know which uses such system. Most other custom engines still use discrete levels of detail, so multiple detail versions per mesh, which is easy to mod.

Thus it would be helpful to know the game you want to mod (if it already exists).

Newgamemodder said:
Sorry if i've asked this before but can you have “more triangles than pixels?”, am i correct in assuming that it's possible but you would need msaa to fix “jaggies”? There's no limit to the “polycount on screen” except for the GPU having to work, there's no technological “barrier”?

Technically it's no problem to have tiny triangles smaller than a pixel. It's just inefficient eventually, and lower detail is the primary way to avoid this inefficieny.
MSAA still works as well, but due to low sample count it would flicker a bit more than with low poly models.
(MSAA usually has 4 samples per pixel, with high end settigns of 8.
TAA usually has 64 samples, but could go ‘infinite’. Though, TAA only gives an exponential moving average of those samples. But it still gives much better subpixel accuracy than MSAA in general, beside the artifacts.
DLSS also builds on top of the TAA framework.)

there's no technological “barrier”?

No barrier. It's just about performance and image quality. (In offline rendering they often have no lods, causing a lot of flicker for distant models. They solve it with hundreds or thousands of samples per pixel, which they may need for correct lighting anyway.)

You can test in idtech5 Rage 16MS is practically flickerfree. So there's (performance)barrier.

Then there was MFAA for alternating coverage eg 8x MS alternating every other frame gives appearance of 16x MS

(over 2 frames).

Multi-Frame Anti-Aliasing (MFAA) Supported Configurations and Titles

MFAA is compatible with second generation single-GPU Maxwell GPUs including the GeForce GTX 980, GTX 970, GTX 960, GTX 980M, GTX 970M, and GTX 965M

Note despite asking for performance troubles all of these methods have the advantage of easing game development (authoring) troubles. Beause with new fangled temporal methods you have to keep track of velocities and history and that makes it fundamentally different: nonuniform “solution”.

It's a complexity dump and no wonder Valve didn't take the bait.

The game hasn't come out yet. I'm mostly trying to compare a list with requests.

I think the company would not use continuous LOD. But they might use meshlets. I assume that's possible?

JoeJ said:
But as far as i can see, advanced lod methods are not common yet outside UE5.

We had view-dependent techniques in various engines I've seen at EA and at Microsoft, and I presume in other engines as well. While terrain is the first natural fit that everyone adopted in the early 2000's, it's been used in models and proxy meshes for decades in the games I've seen. Unity's system is not as complex as Nanite, the Mesh LOD system and HDRP uses a somewhat similar system for screen-space meshlet processing, shadowing, lighting, subsurface effects, and similar.

These days apart from a few notable exceptions the industry has converged on UE5. And even those few exceptions like Halo's Slipspace engine are getting swapped to Unreal. Most companies have learned it costs far too much to maintain their own engines versus the relatively low cost of an engine as middleware.

JoeJ said:
Because the data structures are complex and hard to reverse engineer, and generating new data from new models also is hard.

Fortunately the structures are well documented, and they're not that difficult.

Tools like BepInEx for Unity, or Unreal's built-in module loading framework, make it straightforward. I know similar exist for idtech but I've never worked with them. There can be complications in Unreal when a game has modified core data structures, but even those are easily debugged by people familiar with Unreal's linker/loader system and associated data formats. Generally people can see which version of the Unity/Unreal engine the game was made with and compile assets using stock tools. For titles that have used other systems like the MonoGame framework have reflection internally that allow straightforward modification. Not necessarily easy, but understandable, and also extractable and extendable.

It's certainly easier when a game releases the tools – I worked on both Ark's modkit and Hogwarts Legacy's modkit – but it isn't required as many games have active modding communities outside the official blessings of the companies. Back when I was working on The Sims long ago we had active, open discussions with modders and a few times licensed or purchased their tools to bring in house. Both The Sims Store for every downloadable object and for every expansion pack, they were effectively a mod to the main game with the key difference that we had access to the full core game code and assets.

Many games are designed to be extensible and assets and systems are built as extensions by the core dev teams internally. Modding communities often leverage this by piggy-backing on what they know, what gets exposed through reflection systems in the game engines,

Is it possible to have meshlets and discrete levels of detail?

Newgamemodder said:
I think the company would not use continuous LOD. But they might use meshlets. I assume that's possible?

Naming things is hard.

Most of the 2000-2010 era “Continuous LOD” or “CLOD” systems were quadtree hierarchies for terrain, some were TIN or triangular irregular networks that are basic generic meshes getting selectively mapped to higher or lower detail levels, with or without morphing between them. Meshlets are continuously updated, but not typically called “Continuous LOD”.

Meshlets can map perfectly into the CLOD or TIN LOD systems, that is, they can work in patches where each layer is exactly the same squares used in quadtree versions or the same mesh area used in TIN patches, in which case they're basically the shader doing the work that was done on the CPU two decades ago. Both Unreal and Unity these days base it on the details of the mesh itself, but nothing prevents them from being the same regular or irregular patches used from yesteryear.

“Is it possible” is nearly always a “yes” with software, if you're willing to invest enough time/money into it. I think in this case the question reeks of ignorance, but sure, someone could mix and match a system with effectively a GPU-powered shader-based software renderer that also works well with mesh replacement systems. Worst case you replace the static mesh with a blank item and render the displayed system in shaders as a custom overwritten processing pass. I'd hate to be on the dev team unless it was well funded, though.