Copies of meshes

[powerpop]

okay, i have been able to load .obj files! Now, in trying to wrap my head around how IRR does things i have a basic question (that doesnt seem to be answered in the tutorials or doc) - say i have a cube.obj mesh - now i want to make a hundred of them - so i call getMesh each time? does this load a brand new mesh or is it keeping one copy of my cube mesh and giving me a new node each time?

[Robomaniac]

scene::IAnimatedMesh* mesh[100];

for (int i = 0; i <= 100; i++)
{
mesh = = smgr->getMesh("cube.obj");
}

That should work

--The Robomanaic

[keless]

ug. but is that really keeping 100 extraneous copies of the vertex data? i hope not!

if so, im going to have some major beef with Niko as this is something the engine's resource management should take care of-- the difference between sharable and not shareable data. EG: a texture is shareable (multiple models can use the same texture) but a "sprite" (something that keeps track of animation and the current position/frame of a series of textures) is not. similarly, vertex data and animation matrices are shareable, but the current position/animationframe of an individual model is not.

I really hope the engine keeps this in mind, and does not waste memory using multiple copies of shareable data.

[powerpop]

keless - exactly! - i am going to have tons of copies of objects - many will have different textures but the core mesh will be the same - i imagine this is how irrlicht has to work since making copies of meshes is not workable - ogre has mesh->entity->node - IRR just has mesh->node which i think is better - raises a couple questions though

- can i make a node and not attach is to the scene? (until later? - so then i can set the position and textures but not pop it into the scene yet to be rendered)

- and on managing textures as well as meshes - what is the preferred way to decide that a texture is no longer needed - same with a mesh?

[Boogle]

I'm quite sure the 'get' methods (getMesh, getTexture, etc) do impliment resource management. ie they keep track of paths and do not reload previously loaded files.

However, powerpop are you looking to load 100 copies of the mesh, or load 100 scene nodes using that mesh? If the latter, you'll want something closer to

Code: Select all

IAnimatedMesh *mesh = smgr->getMesh("cube.obj");
for(int i=0;i<100;i++)
{
   node[i] = smgr->addMeshSceneNode(mesh->getMesh(0),...);
}

[keless]

::whew:: that sounds more like it.

thank you Boogle, i was worried.

[Boogle]

np. In fact I just went and checked the source, and loading a mesh twice does indeed result in it only being loaded once into memory. A binary search is used to search the loaded meshes, so it's all nice and effecient.

[powerpop]

and how does it tell when you are not using that mesh anymore? or is that up to us?

same with textures?

and there is my original question - when i load a static mesh (a .3ds for instance) niko told me to use getMesh(0) to get the first frame and made my SceneNode out of that - but then there is the awkward thing that there was an animated mesh created somewhere - who handles getting rid of that at the end?

[Boogle]

Using the code I mentioned you will create one copy of the mesh and all 100 nodes will use it. Meshes seem to be unloaded only when the program is exiting. Perhaps I'm missing something though.

You have to drop the animatedMesh when you are done with it I believe.

[knightoflight]

in a thread once upon a time, i suggested to use createMeshCopy, but i dont know if its better or not?:

tempmesh = smgr->getMesh("tile.3ds");
//here the loop
tileset[i][j]=smgr->getMeshManipulator()->createMeshCopy(tempmesh->getMesh(0));

[Boogle]

Well you'd really only want to copy the actual mesh if you were planning on modifying it, say with the mesh manipulator. Other than that, there is no reason to. The SceneNode handles all the attributes that will differ between objects in a scene.

[powerpop]

it seems we do need some way to drop a mesh (or better said to drop a reference to the shared copy of the mesh) when we get rid of a node that references it - and then when the count reaches zero IRR can get rid of that mesh - waiting until an exit is a bad idea - especially for an app that loads many levels

i guess its okay if niko doesnt keep a reference count as long as its obvious when a mesh is being referenced - we could keep our own reference list if need be (its awkward but we could do it) - to this end it might be nice to allow a userdata pointer on a mesh object (and texture objects) - this way we could attach our reference number to it and increment/decrement it as needed - in fact, this is probably better since i can see each game needing to do different kinds of management of resources

or you could just add a short to every resource object for this purpose!

[keless]

I already have a Managed Memory Objects system, though its obviously not built into IrrLicht's scene/mesh/etc classes. basically for a resource that you want to be managed, you inherit from B_MMObject. the constructor for B_MMObj requires a B_MMO_Provider pointer-- this is a class that keeps a list of each MMO. it has functions such as 'cleanGarbage' which will remove all objects with less than one reference to them. It is required to use SmartPointers to reference MMObjs (because smart pointers will automatically increment and decrement an MMO's reference counter).

because each MMO is linked to a specific MMO_Provider, you can have multiple providers with their own group of MMOs-- for instance, I plan on giving each state its own MMO_P-- when a state is destroyed, MMO_P is also destroyed, which makes it call 'DestroyLiveObjects' to empty its MMO list. This will delete ALL MMOs no matter if you forgot to stop referencing them in your state or not. this means each state will definately keep good track of its MMOs.

Objects which should stay intact across states will use the game_Engine's MMO_P instead of just the state's.

Not sure if you want to use this code as a part of the IrrLicht engine or not, but if individual developers want it-- just post/IM/PM/email me.

[Cleves]

Hey guys,

I want to create 25 copies of the same mesh and i want them to be position at diffreant places, but they all use same texture.
I tried to use what Boogle said but i can't get it to work. can you plz help?

[powerpop]

Cleves - do you really want 25 copies of the same mesh - or do you want 25 copies of the same 3D object - copies of the mesh means you have separate data for all the vertices and polys in the model (can be very expensive) - copies of the mesh (which means having a node for each object that points to the same mesh object) allows you to change the textures individual (or let them all have the same texture) - but you wont use the MeshCopy call at all but the following, after you load in a Mesh

node = smgr->addMeshSceneNode(mesh);

once you do this you can make calls on node to change the materials and orient the block however you wish - the node holds this data

------

in another area i ran into a mesh copy oddity - so if i want to make a copy of a mesh i have to make a meshmanipulator - kind of seems like a backwards way to get a new mesh - wouldnt it be better to have a clone method on the base Mesh type? so then each kind of mesh can duplicate itself??