# A question on speed

This topic is 4659 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

It's predominately a design issue, but it's only in the nitty-gritty of the code do I ask myself some questions. It is hard to describe my architecture to you without a UML diagram, but I shall try:
IModel
|
-- IModelStatic
|       |
|       -- CModel3DS
|       -- etc.
|
-- IModelKeyframe
|       |
|       -- CModelMD2
|       -- CModelMD3
|
-- IModelSkeletal
|
-- Not Yet Implemented

Okay, that's good. I like to think two levels of abstraction isn't overkill, and that's as top as it gets. The problem is that my mesh structure has the same problem:
IMesh
|
-- IModelStatic::IMesh
|
-- CModel3DS::CMesh

Now, this schema allows anyone to write support for a file format, just by writing a model class and inheriting from the correct archtype, and implementing the pure virtual functions. These functions for the model include getMeshes() and load(). IMesh defines things such as getMeshDescriptor() (not actually abstract) and getVertexBuffer() and other similar accessors. Finally, for lots of models that are all the same model, I have ISharedModel:
ISharedModel
|
-- ISharedModelStatic
-- ISharedModelKeyframe

etc. The reason for these splits is to allow for a unified way of accessing models and their meshes. The archtypes (static, keyframe, skeletal) allow for unified ways of organising similar models, and a IModelStatic::IMesh may implement things that a IModelKeyframe::IMesh may not. Likewise with the shared models - consistent access. My question is: Is this implementation going to suffer from virtual function overhead (I know most of the time it doesn't, but there's a lot going on here), and is it flexible enough to be able to handle batch rendering, or triangle culling, or other voodoo magic that I haven't even thought of implementing yet? I ask out of hope that someone has had experience with this sort of architecture before. I don't like to think I've newbed and gone overly OOP, but it's certainly possible I have.

##### Share on other sites
You might want to consider keeping internal object representation separate from data representation in files.

So, instead of having different model and mesh classes, you have 1 class for each of these, and different loaders for loading the particular file format into your internal representation of that data.

This way, you have less code to maintain, and you can extend and change your classes without having to worry about fixing up N derived ones as well.

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5

• 14
• 12
• 9
• 12
• 37
• ### Forum Statistics

• Total Topics
631428
• Total Posts
3000027
×