LarryKing

100 bytes per mesh is nothing really (considering you'll probably have between 1 and 10 meshes per model), but if all your meshes use the same layout, or some use the same and some don't, you could add a "layout array" and have each mesh reference their layout by layout index, in the case that there is only one layout, you're only wasting 1,2, 4 or 8 bytes (depending on your index type) per mesh + 1 sizeof(your offset type) for your layout array start pointer.

 

Also, I don't think I read it, or you didn't mentioned it, I think everyone assumes this is for characters/props and not for architectural/level models or is it for both? not that important, but I guess if you are modeling a cathedral you might end up with more than 10 meshes in a single model.

 

So you're saying store the vertex layouts in the model, and have the meshes index to the matching layout. That might work.

After a quick thought thought, 100 bytes per mesh * a mean of 8 meshes per model * about 1000 models per level = ~781 KB. (averages not from any real statistics)

Not nearly as bad as I had imagined.

 

The other thing I could do is store the vertex layouts in separate files. That way meshes using the same layout would just use the same file, which I could cache.

If I did it this way I would only have to have one copy of each unique vertex layout in memory and on disk.

 

Regarding what a model would contain: the idea was that a Model would just be a generic class to store related Meshes. A mesh would have an index buffer, N vertex buffers, and N resources / textures. This way a model could contain, for example, all of the meshes that composed an automobile.

These models would then be used by objects that would also have a material. Now of course some checking would have to be done to make sure that the model would be compatible with the material. Luckily each mesh has a MeshMask, 16 bits specifying what attributes the mesh contains; the mesh header also keeps track of the number of TexCoord and vertex color streams as well as the number of texture resources. To check if a model and a material were compatible, I would just loop over each mesh and check if its mask and header were compatible with the materials requirements.

A level would then contain many objects that could be culled, sorted, and drawn.

 

My intent was for the model to be able to store pretty much any type of graphic meshes;, whether it contains a weighted charter,  a tree, a sword, or a spaceship shouldn't matter as the model is just a container for meshes. A model should also be able to store thousands of meshes(up to 65, 536) assuming the file doesn't become over 4GB in size. I don't think I'm missing anything that would prevent this, but I could very well have skipped right over something.

 

Again, thank you for your ideas.

I keep textures, meshes, animations and skeletons in different files, my model file is sort of an index of what files constitute a model, so I load and process a model file that in turn loads (or gets references to already loaded) meshes, animations, etc. This way I can mix and match different parts and avoid data redundancy (IE: packing the same texture in two different files).
 
I removed multiple vertex buffers from my format and instead use a single interleaved buffer, this made sense for my purposes since it simplifies the code and apparently its the recommended way of doing it for mobile platforms (OpenGL ES), that's probably also true for the PC, though a with a quick Google search you'll find out there isn't much difference. Don't get me wrong, Multiple vertex buffer support is good, supporting interleaved as well is better.
 
Other things I noticed have already been covered.

Yep, the model is really just a container of meshes. The textures are stored in other files - the model just contains the names of the textures so they can be loaded.

Similarly, all other types/objects, ie bones and animations, will be - I haven't gotten to this stage yet - stored in separate files.

 

The way I have my vertex buffers set up is that a mesh can have multiple vertex buffers, but doesn't necessarily need to. Each vertex buffer can also contain interleaved attributes.

When the files are opened in my exporter tool, you can create new, split up, and delete vertex buffers; however, it defaults to two vertex buffers per mesh.

 

So the default could look like this:

• Buffer 1 - Position
• Buffer 2 - TexCoord, Color, Normal, Tangent, Binormal...

 

The buffers could be split to look like anything really. ie:

• Buffer 1 - Position, Color1
• Buffer 2 - TexCoord1, TexCoord2, Color2
• Buffer 3 - Normal, Tangent, Binormal

The big reason, I opted for split vertex buffers, is fast shadowing. I just have to bind the buffer that contains the position data (which I force to always be the first buffer).

 

I am worried, though, about how I should deal with getting the VertexLayout to the renderer. I'm not sure if I should store it per mesh, load it similarly to how I'm loading textures, or just have each material specify.

The vertex layout itself could end up being 100 bytes per mesh, so storing it per-mesh doesn't really seem ideal.

 

Any ideas?

Thank you for your input.

Personally I'd be extremely careful at considering those "pointers". They can change size, have odd values. As said, they are really offsets and should be treated as such.

I'd rather not put texture blobs in the model format directly. This functionality could be emulated using archives (I have to admit texture loading is still in the works for me).

Do not put API-dependant values in your blobs (such as DXGI_FORMAT). Well, you can, but it's going to look wrong in the long run.

 

Yeah, I'm adjusting the loader so that they are treated more as offsets.

I'm not storing the textures in the file, the blob just contains the character data for the texture's name. The model loader has no idea how to load the textures, it just request the texture from the texture cache. The cache  can then load the texture from where ever.

You're right about not putting the DXGI_FORMAT in there, I'll adjust that.

 

A small point.....

 

Stop exporting all of your structs! Consider this:

 

 

struct DLL_EXPORT Foo
{
};

 

 

This will cause all implicitly created methods (eg constructor, copy constructor, destruction, assignment) to be DLL exported, which for a constructor that does exactly nothing, is completely pointless. You only need to export a class when it actually has member functions that need to be accessible from other dlls/exes.

 

All right. It looks like I'll have to adjust quite a few things in the library as I've just been tacking the dllexports on to make visual studio be quiet.

 

Thanks for all of the feedback!

All right! It's good to know that you can offset a pointer with an int.

I also like the idea of offsets relative to the position of the offset, although I wonder what would happen if you had a negative offset;

Theoretically it wouldn't matter and would still work.

 

Now, regarding the custom deleter, the deleter would call a "delete" function of the model, correct?

Would it then cast the Model* to a char* before finally calling delete[] foochar?

 

I assume the deleter would look something like this:

 

void DeleteModel( *Model)
{
     Model->Shutdown();
     delete[] (char*)Model;
}

 

Thankyou.

 

EDIT:

Your offset template is a really good idea!

It took me a moment to understand what it was doing - still new to C++

Well, I feel like a complete idiot!
I found the error... I wasn't sending the normal-buffer to the graphics card!

I have no idea how I missed that

Oh, well. Live and learn!

-Thank you to everyone who looked this over