# Utility of submesh class in a 3d game engine?

I've read somewhere that we use sub mesh for being able to give different materials to one mesh. But why not simply do this with scenegraph ?

I mean you have a car mesh, and instead of using submeshes for windows, wheels etc... We could have one car node which would be composed of child nodes ( wheel, window ) with differents meshes and materials.

What's the utility of submeshes while there is scenegraph ? I've noticed that in Ogre3D there is both scenegraph ( SceneNode class ) and a mesh/submesh system, why ?

• Usually I wouldn't be that quick to accept an answer just because another user may come along and give a better one, but that's just me. Hope that it made sense – Coburn Aug 26 '14 at 22:51
• I accepted it because it seems sufficient to me but you're right maybe I'll get a better one :) – user2591935 Aug 26 '14 at 23:02

Deep within the game engine your mesh is defined by your vertices, your indices (which define how to draw the triangles using the vertices), and its material (which consists of the shader as well as other parameters). Submeshes allow you to define separate lists of indices and materials (depending on the engine) over the same vertex data which is useful not only for applying multiple textures but also to cut down on moving memory around and a few other things.

If you have a car with multiple parts (let's say a few mirrors, a few windows, and the body), there would most likely be some sort of connection where you have vertices shared by the two. Let's say you had these as separate objects in the scene graph as you were saying. To render this the engine would take a path similar to the below in order to render your car

>>Render the car
>>Render the body
--Load the vertices for the body
--Load the indices for the body
--Render all of that to the screen (vertex shader, fragment shader, set pixels)
>>Render the windows
--Load the vertices for the windows
--Load the indices for the windows
--...
>>Render the mirrors
--Load the vertices for the mirrors
--Load the indices for the mirrors
--...
>>Done rendering car


In each step we have to load the vertices for each object from some file (perhaps already in memory) onto the GPU in a vertex buffer which takes time. Now look at the path it would take if we used submeshes which share the same vertex data but have different index data

>>Render the car
--Load the vertices for the car
>>Render the body
--Load the indices for the body
--Render all of that to the screen (vertex shader, fragment shader, set pixels)
>>Render the windows
--Load the indices for the windows
--...
>>Render the mirrors
--Load the indices for the mirrors
--...
>>Done rendering car


Now we only load vertices for the entire car in one go and then apply different lists of indices to get each piece.

Some other things to consider is that with a submesh you also don't generally need the functionality and overhead provided by a full blown game object. I doubt you're going to need to apply velocity separately to the windows versus the car itself or have the windows check for collision independently so why bother, less can go wrong. If you need that functionality then you'd have to end up breaking it up into two separate objects.

It just so happens that some engines will also let you apply a different material to each submesh which can be beneficial in cases here you'd like to keep one mesh sourcing from multiple materials within the same game object (although you need to switch the materials while rendering each submesh which takes time).