Hi there.. i don't know if this is the correct subforum.. I want to redesign my 3d engine, and i've made an UML class diagramm showing the new design. I am intressted what others think about the design, and what things I have to change maybe. Note that this is my first try with UML, so i dont think i've used it correct, but i think it should be clear what I mean. thanks for any answers. design: http://www.c-worker.ch/hansipirman/uml.jpg P.S. the design is inspired by the orge design [edited by - Hansi Pirman on February 8, 2003 10:51:21 AM]

i used umlsculptor, a litte and opensource uml tool
http://umlsculptor.sourceforge.net/
it''s a little mfc proggy, just a single .exe no need to install it at all

Hey hansi,

Let me preface this with the fact that I don''t know a whole lot about UML, and haven''t used it in awhile. I''m also new to 3d game engines, so take that into account, too.

Okay, you''re saying that every Mesh object has to have at least one SubMesh object. So if you have a car model, it would be represented with a given Mesh object. The mesh object for this car has to have at least one SubMesh. That would probably be the car body. It might also have additional SubMeshes for the wheels. Maybe a SubMesh for a car door. The only problem I have with this design is how the SubMeshes relate to each other. The only relationship that each of the SubMeshes have with each other is they all belong to the same Mesh object. But there is no hierarchy between SubMeshes. That''s kind of limiting, isn''t it?

Let''s take another example. Imagine that you are modeling a human object. You have a "Model" object that represents the entire human. It would contain a root mesh that just consists of a torso. This root mesh can have textures, position and rotation, render states, etc. This root mesh has a child mesh called LeftUpperArm. The LeftUpperArm contains all of the same methods and properties that the root mesh has, because it is another instance of the SAME mesh object. It also has some sort of kinetics object that only allows it to pivot about the shoulder joint. The LeftUpperArm object also has a child mesh called LeftLowerArm. Again, this is just another instance of the mesh object. LeftLowerArm has a child mesh object called LeftHand. And so on and so on. Obviously the torso object would also have other children (RightUpperArm, LeftUpperLeg, RightUpperLeg, and Neck)

Since you now have a hiearchy, it''s much easier to animate the human model. If you want to position the human model somewhere, all you have to do is move the root mesh. All of the child objects will move with it. If you want to raise the left arm, all you have to do is pivot the LeftUpperArm. The LeftLowerArm will move with it, and the LeftHand will move with the LeftLowerArm.

If you really want to get fancy, you could also do inverse kinemetics... You could just raise the LeftHand up into the air, and the LeftLowerArm and LeftUpperArm will rotate accordingly so that they stay attached to the LeftHand and the Torso.

I don''t think these things would work too well with my understanding of your diagram. I apologize if I''m way off base here, but I hope this gives you something to think about.

hi again

thanks for the big answer Expendable!!


The Mesh is also a Movable, so all SubMesh''es are moved when the mesh is moved. The World Matrix for each SubMesh is computed like: Mesh.worldMatrix*SubMesh.worldMatrix.
I allow each SubMesh to move independent for simple animations such as a Tank with a Tower on Top, which rotates independent from the rest of the tank.
But the main Purpose of SubMesh''es is to Split up Meshes which use different Materials and Textures.
For animation i gonna add skeletal animation, which isn''t included in the current UML diagramm. and skeletal animation uses such a hiearchy you are talking about, i think.

maybe i should remove Movable as superclass for submesh, but i thought it will be nice for simple animation effects, and for complex i would use skeletal animation.

what do you think ?

kind regards
hansi pirman

Hmmm, the question I gotta ask is this: Why do you have a Mesh class and a separate SubMesh class? It doesn''t make sense to me. I don''t think there should be two separate class types. I think you only need a single type of mesh class. Why make things harder for yourself?

Any particular instance of the Mesh class can have 0...n pointers to other mesh instances, making up a nice hierarchy like I talked about before. Every single mesh has its own textures, its own surface properties, its own position, and its own rotation (and anything else that the mesh needs).

If you don''t do this, I think you will paint yourself into a corner. You''re going to find skeletal animation to be a complete nightmare (maybe even impossible) with the way you''re going now. A single, robust Mesh class will reduce the code complexity and give you far greater power.

What is the Movable Superclass all about? Not sure I understand what you intend there.

Movable is used to move and orient a mesh in the world.
Movable::getMatrix() will return a matrix which represents this movement.

i use SubMeshes because all the SubMeshes share one skeleton and one VertexArray (stored in Mesh). i dont think its a good idea to have multiple meshes with separete vertex array, sharing one skeleton.

Maybe you could still have one giant vertex array that contains all the vertices for all the meshes, regardless of whether the meshes relate to one another. I think that''s how a lot of engines work, but I''m not entirely sure.

hm.. yes this could work...
something like: each mesh has a pointer to the vertex data, so multiple meshes could share it!!

Expendable, thanks for you great input! i think i have some good alternative ideas now!

kind regards
hansi