Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
- Thread starter mpg1
- Start date
You’re looking at how polygons are represented I think. A triangle strip would submit say 5 vertices and draw 3 triangles from it saving yourself 4 vertices for submission.
I do wonder if this also plays a part in it
Last edited:
No, there's definitely something funny going on with the triangulation as Nesh says. This shows the ground as you'd expect, two triangles per quad:
But we see repeatedly such 'quads' being subdivided into tiny triangles. I think what we're seeing is apparently simple, flat quads having more detail and this getting drawn into the geometry. eg.: Two tower blocks on the left, one with simple triangles, the other full of noise.
"Why are all these simple rectangles made of so many triangles?" we ask...
But up close detail shows they have a lot more too them than the simple rectangles they look like.
Some surfaces pop in lots of geometry, transforming from simple large triangles to lots of small ones. eg. Pavement at beginning of visualisation as the player walks. It appears to be an LOD aspect, possibly related to less efficient models, or maybe material related needing more triangles for a better result or faster rendering option using vertex instead of pixel functions.
interesting point. If they really don't use normals, then shouldn't everything be triangles then and we're just looking at LOD?
cheapchips
Veteran
I wonder if the triangle behaviour is related to clusters, and having find coherent joins between them?
They must be using textured normals as an efficiency thing because that much detail would take up too much data and storage space. I think, in cases of the fancy wall at least, that this geometry that looks flat is actually very small bumps, geometric irregularities. The windows for example have a central vertex. That could be a tiny deflection inwards to get more realistic, imperfect reflections.
Nanite doesn't add any triangles... all triangles were part of the source mesh that the artist provided. It "only" generates simplifications/LODs and clusters from that source data. If there's any unnecessary/extra triangles, they were in the source data, not something that Nanite needs.
Photogrammetry/scanned stuff tends to have relatively uniform triangle densities because of the nature of how it is generated. The Matrix demo is more of a mix of scanned stuff and hand modeled stuff and thus it has a much larger variety of triangle sizes than previous demos.
That said there can be situations in which finer grained mesh data/clusters provides better culling, but since the clusters are of relatively uniform triangle counts and the per-pixel overhead of rasterization is relatively small (since material evaluation is deferred), it doesn't matter a ton on practice. These larger triangles will just get sent down the hardware path and splatted into the vbuffer pretty efficiently.
Most pops after scene transitions or during fast movement through the scene are probably HLOD/coarse-grained streaming stuff, not Nanite. Would have to see a video to be sure, but if you look at the instances view and the color changes that is likely what is going on.
Can you spare 2 seconds to look at the video from 39 seconds and explain what's happening on the pavement/street?
Can you be a bit more specific? Do you mean the sidewalk part or the road part?
Are you just asking why there are lots of polygons there? I'm not sure offhand other than to say "because the source asset has lots of polygons". I wouldn't be surprised if there is actually very fine detail like modeling the creases between sidewalk tiles, which then tends to cause the rest of the center portion to become more tessellated to avoid T-junctions. Alternatively it might just be from a scanned asset that had more detail to start with. When they flip through the instances view you can see that each sidewalk tile is actually a separate instance (!).
I don't know if it's the sidewalk or road as they all look like triangles! But as the player moves, there's a sudden shift in the triangle mesh on various, but not all, floor pieces.
Here we have marked in red a square area that gets subdivided as one example, but that whole area as she crosses the road gets triangles appearing. Although as you've stated earlier, I guess this is model data that's been reduced rather than triangles getting subdivided. But then why are the triangles so arranged as they aren't adding vertices in useful places to add geometric detail - they look like regular mathematical triangle subdivisions.
In game art...
Nanite triangles view, where some get subdivided later.
Triangles mapped to vertices in the overall view:
These strike me as far too regularly placed to be model detailing for deliberate irregularities in the slabs because they are all midpoints on edges. Actually one isn't., so maybe the source models are just boxes subdivided regularly with a little noise applied?
Here we have marked in red a square area that gets subdivided as one example, but that whole area as she crosses the road gets triangles appearing. Although as you've stated earlier, I guess this is model data that's been reduced rather than triangles getting subdivided. But then why are the triangles so arranged as they aren't adding vertices in useful places to add geometric detail - they look like regular mathematical triangle subdivisions.
In game art...
Nanite triangles view, where some get subdivided later.
Triangles mapped to vertices in the overall view:
These strike me as far too regularly placed to be model detailing for deliberate irregularities in the slabs because they are all midpoints on edges. Actually one isn't., so maybe the source models are just boxes subdivided regularly with a little noise applied?
I've seen this behavior on some buildings. Example: If you're looking at a brick building face on (stationary), and the bricks on the building look texturally and symmetrically the same (i.e., quality, density, layout, and spacing), without any visible differences between them... however, within the Nanite view, you may see one section of bricks exhibiting what Shifty is trying to convey.
Imagine looking at one side of a Rubik's Cube, and one square for no apparent reason is subdividing - usually in alternating pattern (i.e., from a mesh made up of larger triangles to a mesh made up of smaller triangles) - while the other 8 squares triangle meshes are uniform in appearance. This oddity is what we're wondering about... what causes this particular issue or randomness?
Imagine looking at one side of a Rubik's Cube, and one square for no apparent reason is subdividing - usually in alternating pattern (i.e., from a mesh made up of larger triangles to a mesh made up of smaller triangles) - while the other 8 squares triangle meshes are uniform in appearance. This oddity is what we're wondering about... what causes this particular issue or randomness?
Can't say for sure, but if it's a fairly regular subudivision it might be a scanned asset. There's also possibly more detail if you were able to zoom super up close than is visible with the camera in the game; i.e. it may not actually be a truly flat plane.
That's kind of the advantage of Nanite. Normally you'd be under pressure to optimize such assets for the best visual/performance tradeoff. With Nanite you mostly don't have to and can leave all the detail there for the off chance that someone ever gets suuuuper close to something.
Would have to look at the source mesh asset I guess. Like I said I'm guessing it's either scanned or there's actually a lot of polygons along the crease at the edge of the slab and the inner subdivision is just a result of that + watertightness.
In terms of what cluster LODs Nanite picks, that is based on the minimum edge length in a given cluster. Since the clustering is an optimization process and the edge lengths are view dependent, you can certainly see what sometimes appears to be somewhat "random" selection of LODs, particularly if one cluster ends up including a triangle(s) with much different density. That said it doesn't really matter as long as the error is kept ~pixel-sized or smaller, as you can see in the demos.
Last edited:
Took a brief look in editor. Not 100% I have the right assets as... uhh... there's a lot of assets, but should be similar situations.
One of the assets (I think the top tiling one in the start area) looks hand-made but does indeed model the groove as geometry. It is split once along the center of the tile as noted (for whatever reason) and each set of 4 tiles is a separate instance:
Other assets (such as the sidewalk) appear to be scanned with lots of detail that can't really be perceived unless you zoom in super close:
Again this is one of the big advantages of Nanite here - you can just use scanned or otherwise "not game optimized" assets and heavy instancing and it mostly just works out fine. In the far distance the instances have to be combined (via HLOD in this case) just to cut down on the raw engine overhead but there's a much larger band of stuff that works well (millions of instances, etc).
Anyways this is all stuff you can go poke and play with yourself when they release the content!
No-one figured it out before?
It isn't really a single tech or method and has taken a lot of time to get into current form.
The idea of rendering in small clusters/meshlets is at least as old as playstation2 and it's emotion engine.
There has been huge amounts of LoD methods and some using clusters.
Idea of using software rasterization is not entirely new either, but many have tried to rasterize more complex surfaces than id/barycentric coordinates.
And so on.
Nanite is great as they have created and combined a lot of amazing tech into new pipeline which is aimed to modern hardware.
Future will be very interesting as more wild custom rasterization/ray-tracing paths are created.
Similar threads
- Locked
