The Effectiveness of a Mesh manager?

Started by
8 comments, last by lucky6969b 7 years ago

Sometimes I just wonder.

My mesh manager allows the user to specify if he needs to make a copy of the mesh in the mesh manager...

When the user doesn't do this, and I apply a physics mover, the program will crash.

Basically means the physics mover is applying transforms on the only copy of mesh which is shared between instances.

However, all of my game objects basically will apply physics to it, most likely to be 98%....

So when the first time I create a mesh, I put it in the manager, ever since, I make copies of it.

And It doesn't seem to be a great save at all.

What's your opinion here, do you think?

Thanks

Jack

Advertisement

Why does physics modify the mesh and why can't the changes be applied in the vertex shader?


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

One solution is doing like L. Spiro said, applying the changes in the vertex shader. The other (old school) is to export the frames of the mesh animation into separated files (.obj files, for example), then each object select the frame it will use without the need to modify it, because it already represents that `moment` of the animation.

The first (modify in the vertex shader) allows smoother animations and better transitions between one animation and another, but require implementation of an "animation system" and better GPU. The second is easy and can run on low spec computers, but the animations are less smooth and requires more space in the memory/disk.

Basically means the physics mover is applying transforms on the only copy of mesh which is shared between instances.

Why are transforms and meshes part of the same class in the first place?

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

It's common to have two separate classes:
* a mesh-asset stores vertex data, node structure, etc.
* a mesh-instance stores transforms, physics state, etc, and references a shared mesh-asset.

When talking about transforms are not part of the mesh class?

Here is how my stuff works:

pseudocode:

struct MeshContainer
{
    // vertex info
   
    MeshContainer* m_pNextMeshContainer;
}
 
struct Frame
{
     Matrix4  m_world;
     Matrix4  m_local;
     MeshContainer m_meshcontainer;
     Frame* m_pNextSibling;
     Frame* m_pNextChild;
}
 
class Mesh
{
 
   Frame m_root;
   StaticMesh m_StaticMesh;
}
 
void PhysicsMover::init(Mesh* pMesh)
{
      // add to physics mover via pMesh->m_StaticMesh
}

You can see that when physics is doing its job,

it will mess with my mesh or root frame anyways

How do I avoid that? I am using fixed pipeline for the moment.

I will make use of the programmable pipeline later...

The solution said by Hodgman is the cleanest, when he said transform he speaks about the world space transform.
You can combine all the meshes without any nodes or keep yout frame structure which is a node structure, I prefer the term "Node" than "Frame".
The good point of a Node structured mesh is you can animate bone an geometry at the end (to me it's more clear "Geometry" than "MeshContainer").

This topic is closed to new replies.

Advertisement