Replies: 6 comments 15 replies
-
|
First step is to collect some hard data. I need to run a couple of different meshes through the converter and collect some statistics on their DAG levels, meshlets per level, meshlet occupancy, etc. I also need to try the new attribute-aware simplification on meshoptimizer main. |
Beta Was this translation helpful? Give feedback.
-
|
Not easily, unfortunately. The current workflow is to open a gltf in blender, merge everything down to 1 mesh, and then run it through a janky program I didn't merge upstream. More ergonomic and built-in workflows are blocked on larger design changes in Bevy - the gltf converter I had was not a good path. I will try to cleanup the program and upload it here to make testing easier. |
Beta Was this translation helpful? Give feedback.
-
|
Got it. I think it will be good long term for meshopt to have a workflow demo that approximates Nanite so I will probably look into that next week, so may not need this. |
Beta Was this translation helpful? Give feedback.
-
|
Collected some data on the stanford bunny, stanford dragon, arcane jinx from sketchfab (merged down to 1 mesh), and quixel megascan's "Huge Icelandic Lava Cliff". Meshlet occupancy is a map of |
Beta Was this translation helpful? Give feedback.
-
|
Cluster counts.... actually looks pretty good now? I guess something has changed since my initial implementation several months ago. Not able to get to a single root cluster, but <20 is fairly good. We could probably do better once I tune the heuristics to be more aggressive. Meshlet occupancy counts I haven't yet analyzed, need to build some graphs. But it looks like at least for LOD 0, we're doing pretty good. |
Beta Was this translation helpful? Give feedback.
-
|
At LOD 0, 31118/31244 ~= 99.6% of meshlets have 64 triangles At each further LOD level, the amount of full meshlets decreases. Interestingly, the amount of meshlets with 48/32/16 triangles increases per LOD level proportionately. |
Beta Was this translation helpful? Give feedback.
-
|
Worth noting in general that you will never have fully balanced workgroups with 64v/64t: on grid-like meshes a 8x4 regular quad grid (8x4 * 2 = 64 triangles) uses 9*5=45 vertices; on the flip side, if you have a lot of disjointed triangles, you will have a lot of vertices but few triangles, e.g. worst case is 21 triangles with 3 unique vertices each => 63 vertices. That's fine in the sense that it's a common property of any clustered renderer to have an imbalance somewhere, just noting that if you expect 64v/64t then that's not going to happen very often. See https://zeux.io/2023/01/16/meshlet-size-tradeoffs/ But otherwise I think it's critical to understand where the issue happens and why; I would probably recommend starting with a reasonably simple mesh that should not have a problem with getting down to very few root clusters and trying to debug the steps that get stuck early. Could also try repeating that with Nanite in UE to understand what data it generates. |
Beta Was this translation helpful? Give feedback.
-
|
I don't actually need a balanced workflow for vertices. I mainly care about triangle counts per meshlet. My rasterizer is a 64-thread compute shader where each thread loads a vertex, transforms, and stores in LDS. Then each thread loads 3 vertices from LDS and rasterizes a triangles. The triangle raster is much more expensive than the vertex transforming.
Agreed. I need to install UE and see if how good a job they do at simplifying the bunny (which seems like a simple mesh). No time today, but will hopefully be back with some hard data later this week. |
Beta Was this translation helpful? Give feedback.
-
|
Got it. One other thing you could try is see if using a 128v/64t or 196v/64t configuration helps at all. This is aggressive (normally you wouldn't want this many vertices), and it can reduce occupancy by requiring more LDS for vertex storage, but given a complete triangle soup where every triangle is not connected to any other triangle as an input, that's the configuration you would need to maintain fully loaded wavefronts; this is not necessarily something you'd want to keep long term but trying that would also help figure out the limits of the system. (to actually get "a triangle soup input" to work in your setup you would need to use simplify_with_locks which was added so that the boundary of a cluster can be explicitly specified to the simplifier, but I don't think you actually need to do this at this stage if you are testing on well formed meshes, it's just an example of an input asset that maximizes the pressure on the vertex data) |
Beta Was this translation helpful? Give feedback.
-
|
One other note: currently, I'd like to improve this in the future somehow but I'm not sure how 😅 meanwhile I'd note that Nanite uses METIS to recursively split clusters in half until reaching a size close to the max required. It should be simple to try that approach in Bevy; my long term goal is for METIS to be unnecessary in Nanite like pipelines but it's valuable to understand if that's the core part of the issue and to what extent this is better. |
Beta Was this translation helpful? Give feedback.
-
|
@zeux some questions:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah it’s certainly a little awkward. Maybe this can be fixed without switching to a different data type internally; I’ll need to check. |
Beta Was this translation helpful? Give feedback.
-
|
@JMS55 I did some more tests in a separate repo. The README has most of what I found interesting. Adding some extended info below. EDIT 06-09-2024: Added stats the other border vertex definition (vertex shared between meshlets instead of based only on geometry). The model's I've choose greatly influence results. Overall problems:
With these 2 issues, I don't think it's possible to create a good DAG. The only solution seems to be randomly removing triangles (!). At higher DAG levels all meshlets are disconnected single triangles. In the logs directory I've added console dumps with stats. These are the same models as I've originally wrote month ago - Jinx (
Ofc. it might sound stupid. You get perfect DAG if you randomly remove triangles! But what are the alternatives? PS. DO NOT LOOK INTO quadric.ts. |
Beta Was this translation helpful? Give feedback.
-
|
@zeux an issue I've ran into: I keep running into Might be nice to have an override for that. I'm going to try and patch meshopt with a higher limit to allow me to test my code. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that function is meant for use by meshlets atm; it does not account for the possibility of using a larger collection of triangles. The limit is documented. The good news is that using this function is probably incorrect anyway. I think the logic that Bevy is using atm is distance to sphere center, but even if it uses a distance to sphere boundary, the resulting error function is not monotonic unless the bounds of the merged group entirely contain the bounds of the children. To get here, you need to actually union the spheres into a larger sphere, as some spheres may be outside of a precise spherical boundary created around the vertices. I ran into this yesterday when working on #760 (absolutely no promises any of that code is correct!); I wrote a function that validates that error through DAG is monotonic and discovered it's not. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, at runtime, Bevy should be moving the group sphere to be on the closest point of the culling sphere, and then projecting the group sphere. In practice it hasn't mattered too much. Same with the group spheres not necessarily perfectly bounding their children - it hasn't been an issue in practice yet. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the culling sphere comment is right. To have conservative error, you need to make sure to match the computation of the parent LOD on the child cluster and self LOD on the parent cluster exactly; since clusters have multiple parents, these all should all agree on the same error - but you don't want multiple clusters to all have the same culling sphere. And yeah I don't think the problem is very prevalent. It happened on some meshes in some configurations I was testing but not others. What can happen as a result though I think is duplicate geometry being rendered (or maybe gaps? unsure). Either way, I've added a note to see if this limit can be completely removed; that requires a memory allocation which this function doesn't do atm. I don't want to increase this limit as the stack space requirements here become non-trivial for Wasm in particular. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm yeah, I might've misremembered the issue. It was something about projecting the group sphere though. |
Beta Was this translation helpful? Give feedback.
-
Followup to bevyengine/bevy#14660
In Bevy's Nanite-style renderer, I've run into a couple problems:
Nanite was obviously able to get to much better results, and there are 3 major parts:
For the first two, I use meshoptimizer. The latter I do myself with METIS.
I'm opening this thread to hopefully improve my mesh -> meshlet mesh building code. Maybe meshoptimizer can improve in some way, and my code almost certainly so.
Beta Was this translation helpful? Give feedback.
All reactions