Question: What would the best way for me to store my model data, vertices, normals etc?

I'm building a assets management system for my 3D engine. I'm using DirectX9, C++, unmanaged code. I'm aiming for a flexible system where i can load a model during runtime, via means of my choice (triggered, scripted, console), retain it in memory for unknown period of time, push it to video memory when i want, export it to my selected format, edit it's data, remove it from memory without crashing everything.

I know most of it is dependant on how i design the rest of my system, but as for now, i'm only out to know if i my GeometricAsset-object should keep it's data airy, or compact.
What i mean airy is several easy to access data structures, or a compact all-in-one structure i work against.

I'm kinda new with assets management so... i want to get it as right as possible on my first implementation. (I don't want to make stupid misstakes with data management as i've done with my previous rendering techniques, it resulted in a need of massive recode, and that in turn drained my will to work on my project.)

The current loading system looks like this.

*AssetsManager
{
  * AssetsLoader(s), only handles loading of types, returns AssetsObjects of appropriate type.
  * MinorManagers(for types: model, texture shader, etc)
  {
    * AssetsObjects (Different types depending on loaded object was model, texture etc. A SubManager only keep track of its own kind.)
  }
}

It's basically how my AssetsObject for models that i need to work out as it is now. Simple to work against and i'll use it's structure or design to work out how to build my other AssetsObects.

I'm somewhat unsure that my question is correctly asked, but i'll regard any information about assets management for a 3D engine welcome.

/* ZuraK

---

Blog: http://pineinteracive.blogspot.com/

Ok, i think i now have some sort of solution to my problem:

AssetsManager only keep pure data from loaders.
But when i want to add an object in my world, i create a new node in my scenegraph and use
  the data from the assetsmanager to create that object.

So:
reference = m_hAssetsManager->loadStaticGeometricAsset( "cube.obj", "TestCube" );
would load my cube into memory, keeping track of vertices, indices etc. all that useful stuff.
A reference to that data is returned, so if needed directly just use the reference. The second
parameter is the data id.

and:
reference2 = m_hSceneGraph->createGeometry(reference);
would create a geometrynode for my scenegraph.

m_hSceneGraph->add( reference2, "TestCube" );
should load the node to the root node of my scenegraph.

another way would be, but looks somewhat messy.
m_hSceneGraph->createGeometryAt( m_hSceneGraph->find("RootNode"), m_hAssetsManager->loadStaticGeometricAsset( "cube.obj", "TestCube" ), "TestCube" );

Does it look like a stupid design?

---

Blog: http://pineinteracive.blogspot.com/

These are all questions. I think you're on the right track.

I think for starters you may want your asset manager to be be able load a self-describing package that may or may not include all of the data that it describes. For example, instead of storing the data in a custom package file, you might sometimes specify uri's that point to the data. That way you can test quicker without have to build your custom packages.

Make sure that your self-describing file format for your packages is flexible. Use generic tags in the file that can allow you to build a more robust structure on. Labeling the tags allows you to differentiate.

I guess for me the biggest thing to get right is the specification of your package file system.

---

http://thnogg.mybrute.com