Sign in to follow this  
Raeldor

Mesh Manager?

Recommended Posts

I have finished my texture manager class, and all seems to be working well. Thanks to everyone for their help answering my (sometimes silly) questions. The texture manager is a hash table with a usage count keyed off the texture filename, which seems to work pretty well. Next I was thinking I should do the same thing for meshes with a mesh manager, however this could be a little more tricky. Is it normal to also have a manager for handling meshes, so as not to load the same mesh twice if you use it more than once in your scene? At the moment, I have a node class and a sub-classed mesh class. When I load a mesh from disk, it is done by a function in the node class that creates one or more mesh objects that are children of the node class (depending on how many pieces of geometry your model has). The children have the same names as individual objects in the 3ds max scene. The problem is that if you have one model file that has a 3d model of a fence made up of 3 planks of wood called 'plank1', 'plank2' and 'plank3', and then you load another model of a difference fence but the objects in the second model have the same name as the first, then it uses the original objects. [attention]Edit: This also means that the children can have multiple parents... is this bad?[attention] Is it normal to insist on unique object names across different model files? How do other game engines decide whether a mesh, or parts of a mesh are unique? What keys do they normally use? Do they concatenate the filename with the object name hierarchy like 'c:\mymodel\fence.mod\plank1'? Any advice or pointers on how other engines accomplish this would be welcome. Thanks again!

Share this post


Link to post
Share on other sites
I don´t have experience with that kind of thing, but since I´m currently thinking about a similar thing among others, I´m gonna give my opinion nevertheless ;)
I don´t think that you have to check whether a part of a mesh is unique or not, "just" checking the whole mesh should suffice... I wouldn´t care whether a plank1 in mesh A is the same as a plank in mesh B, I would only try to be sure that mesh A isn´t the same as mesh B.

Share this post


Link to post
Share on other sites
I would do some kind of caching like you're trying to do. However, why not prepend the names of the parents to the childs? In your example you'd get:

meshA
- meshAplank1
- meshAplank2
- meshAplank3
meshB
- meshBplank1

No more name clashes!

Share this post


Link to post
Share on other sites
Quote:
Original post by rick_appleton
I would do some kind of caching like you're trying to do. However, why not prepend the names of the parents to the childs? In your example you'd get:

meshA
- meshAplank1
- meshAplank2
- meshAplank3
meshB
- meshBplank1

No more name clashes!


Cool. I think I will go this route and see how it works out. Worst case scenario, I'll learn from my mistakes! :D

Thanks!

Share this post


Link to post
Share on other sites
Not sure if it'll help you any, but... the way i have it at the moment is the mesh manager roughly resembles the texture manager in functionality: the "mesh server" is taking care of both loading the 3d files, and caching them. The scene nodes don't receive this data, but merely a set of IDs that identify chunks which together make up a particular 3d object. Using your example, it looks somewhat like this:

scene node: hey, mesh server, load me the 'mymodel\fence.mod\plank1.3ds'
mesh server: *checks if this file was already processed*
mesh server: *finds no cached instance, loads the file, breaks it into separate per-material chunks, puts the chunks into chunk library*
mesh server: hey, node, the file you wanted consists of chunks 34, 35 and 36
scene node: *takes note*
...
renderer: *determines the node will be visible*
renderer: hey, node, what pieces are you made of?
scene node: 34, 35 and 36
renderer: *takes note and goes off to bug other nodes*
...
renderer: *sorts the received data per material, chunk IDs and whatever, then walks down this list, bugging material server and the mesh server to contribute to material binding and mesh rendering, respectively*

it's overall a bit more complicated than that (the geometry chunks come with material IDs for example, and can be arranged into level-of-detail table) ... but that's how it goes more or less. This allows the mesh server to cache the requests --if another node asks to have the plank1 loaded, it'll receive the same set of IDs without the server processing the physical file again-- as well as to keep track on which meshes are actually rendered, and which aren't and might be possible candidates for purging, if memory usage gets too high at some point.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this