Jump to content
  • Advertisement
Sign in to follow this  
Code-R

What's The benefit of having submeshes over one big mesh?

This topic is 4838 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!