What's The benefit of having submeshes over one big mesh?
Author
I've always wondered about this, as one big mesh can be optimized with NVTriStrip and rendered in one, fast call. Any Ideas on why submeshes are used?
From what I've seen, submeshes are mostly used for parts of a model which aren't connected, and for parts which require, for instance, a different texture or material. They're also convenient for the 3D artist, as the model is split up into (potentially) more manageable chunks.
For example, in the torso model for the Quake III player Bitterman, there are two submeshes. One is for his torso, the other is for a leather weapons holster he appears to wear.
There doesn't seem to be any performance reason for using submeshes that I can think of. As you mention, one big mesh can be optimized, and it also takes less GPU function calls to draw one big mesh than several smaller submeshes. Seems like submeshes are mostly for convenience.
For example, in the torso model for the Quake III player Bitterman, there are two submeshes. One is for his torso, the other is for a leather weapons holster he appears to wear.
There doesn't seem to be any performance reason for using submeshes that I can think of. As you mention, one big mesh can be optimized, and it also takes less GPU function calls to draw one big mesh than several smaller submeshes. Seems like submeshes are mostly for convenience.
Quote:Original post by iNsAn1tY
As you mention, one big mesh can be optimized, and it also takes less GPU function calls to draw one big mesh than several smaller submeshes.
This is not true if you can cull away many of the small meshes. Only if the large mesh is completely visible all the time there is no performance gain from splitting it up. If you have a gigantic model (e.g. a terrain) that is only partially visible, lots of performance can be gained by culling away sub-meshes before sending them to the GPU.
Tom
Author
I'm definetely not talking terrain here, I'm talking like doom marine head and doom marine torso. I think the check will be insignificant most of the time that sendind the entire mesh would be faster overall.
sub parts = easily edited....
one body + one head = marine...
same body + another head = another marine etc...
peace.
one body + one head = marine...
same body + another head = another marine etc...
peace.
Author
But in this case, each head is a seperate model. I'm talking about having a marine model that's rendered as 5 submeshes, given that submeshes can't be transferred along models.
Quote:Original post by Code-R
But in this case, each head is a seperate model. I'm talking about having a marine model that's rendered as 5 submeshes, given that submeshes can't be transferred along models.
You can have separate animations for each sub-mesh which increases the overall flexibility. The upper body can have several different gun-poses while the legs can walk or jump or stand in different poses. e.g. 5 upper poses x 5 different lower-body animations will give you 25 types of action at a lower memory cost than 125 animation poses.
I'm programming an arcade airplane game and I used sub-meshes in showing damage and swapping in several damage meshes.
biggest gain is, submeshes can use different materials
and as other have pointed out submeshes will have tighter fitting boundingshapes which == less drawn on average.
and as other have pointed out submeshes will have tighter fitting boundingshapes which == less drawn on average.
The splitting of materials/shaders/textures to me is the one and only advantage of having submeshes. If the artist creates several meshes that all use a single material then, in a proper production pipeline, these meshes should be combined at export/processing time into one mesh before run-time.
The point of having sub-meshes at run-time is to seperate meshes that have different materials. To be honest though, I don't like the split. On a PC, you'd probably be better off to treat each (sub)mesh separately and sort them by material. If you use the sub-mesh concept and you have multiple instances of that model, then you'll end up switching contexts and drawing each sub-mesh multiple times. Instead, you should prefer, on a PC, drawing each batch of like-wise meshes for each instance all at once.
The only other benefit I can think of is gross rejection for culling based on bounds of the entire structure. And that can be handled with different means instead of using "sub-meshes".
-John
The point of having sub-meshes at run-time is to seperate meshes that have different materials. To be honest though, I don't like the split. On a PC, you'd probably be better off to treat each (sub)mesh separately and sort them by material. If you use the sub-mesh concept and you have multiple instances of that model, then you'll end up switching contexts and drawing each sub-mesh multiple times. Instead, you should prefer, on a PC, drawing each batch of like-wise meshes for each instance all at once.
The only other benefit I can think of is gross rejection for culling based on bounds of the entire structure. And that can be handled with different means instead of using "sub-meshes".
-John
Quote:Original post by Teknofreek
The splitting of materials/shaders/textures to me is the one and only advantage of having submeshes.
What if there are multiple transforms in the mesh, i.e. skinning? If you have more transformations than allowed bones then you'll have to submesh. And before you say that no one has, I have seen one commercial game project that had a few objects with in excess of 300 bones.
Quote:The point of having sub-meshes at run-time is to seperate meshes that have different materials. To be honest though, I don't like the split.
It depends on the game. If the textures for the different submeshes change independently, it might be much better to use separate sub-meshes since it would be trivial to change the texture binding.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
