• Advertisement
Sign in to follow this  

What's wrong with this engine's class diagram?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Please note: This is a minimal and partial class diagram of how my engine relates model/texture/shader data, how it is organized, and passed to the renderer. As this is my first engine, I am curious to hear knowledgable feedback. Also note that IndexBuffer is not pictured, but works the same as VertexBuffer. Also note that all unmarked relationships default to 1..1 multiplicity. Thanks in advance to anyone who takes the time to provide constructive criticism. Edit: See blow for an updated diagram [Edited by - Chris81 on August 2, 2005 8:16:30 AM]

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I don't see anything about shadows, particle systems, or animated characters. They are not trivially implemented from what you have. Also, you don't seem to have thought out spatial partitioning very thoroughly... you seem to want to treat both static and dynamic geometry in the same structure. And it looks like maybe all props are static? that doesn't make any sense.

But of course I only point out the things I don't like, there are good things too :)

But I think the most important thing is this. You have enough, even completely ignoring what I said above. So go and write something, and maybe a lot goes right, but later you say "Oh crap, particles are hard to do with this system!" You just make a note to yourself for your next try. The only way to learn is by making decisions and seeing the outcome, which means programming.

Getting too caught up in writing these class diagrams has only made people stupider for 2 reasons: 1) they generally pick a detail level too coarse for their objective because it blurs the inherent complexity that will foul up the system in practice (i.e. get used to the idea of 'irreducible complexity' and strategerize at that level). 2) it is a procrastination mechanism... some people will actually never accomplish anything because they feel like their code, once written, will be impossible to change. Or laziness.

So go and write it, everyone here loves to see each others' demos.

--ajas

Share this post


Link to post
Share on other sites
I agree with the AP.

I like everything on the right side, the factories and everything that derives from resource, but the left side is messy.

From the looks of it, you have a method of dividing the scene spatially, which is good, but you're missing the logical connections that a scenegraph implies.

Which class contains props and entities?

What is the purpose of node if it doesn't contain anything but other nodes?

Get a scenegraph setup.

Share this post


Link to post
Share on other sites
As software engineer ina game dev company I may give you an advice. Do not trhust too much in class diagrams alone. They usually pass only a small piece of the information needed.

When you want to show an engine diagram, include a message diagram or fow diagram alogn with the class diagram. In this case that would possibly reveal more problems than a simple class diagram may do.

My only observation would be: I don like the idea of making texture coupled to a vertex group. These are differetn concerns. Would be better (in my opinion) to attach it to mesh. The result will be almost same but would be conceptually cleaner. Same can be said about effect.

Share this post


Link to post
Share on other sites
Wow, I'm so glad I posted this because I got a lot of good information, thank you.

Quote:
I don't see anything about shadows, particle systems, or animated characters. They are not trivially implemented from what you have.


Yeah, I haven't actually started to plan out shadows, particles, or animation. I have read up on them some, and given some thought as to how they might fit in to this design, but didn't actually graph them. If you would be so kind as to take the time to post the specifics of why it wouldn't be trivial to implement these features with this class diagram and how maybe a slightly different class diagram would be less trivial, I would be forever grateful.

Quote:
Also, you don't seem to have thought out spatial partitioning very thoroughly... you seem to want to treat both static and dynamic geometry in the same structure. And it looks like maybe all props are static? that doesn't make any sense.


Well, my goal was to separate rigid geometry from animated geometery. All props are rigid, and thus can share a static vertex/index buffer. They're both of type spatial so that I don't have two seperate scene graphs, one for static geometery, and one for animated. I'm using RTTI to know which is which to call the correct pre-render functions. Prop would be litle to none, and entity would be quite a bit because that will not only represent animated geometry but every game object that you interact with. With this additional information, does it make sense now? Or is there a better way to do this?

Quote:
But I think the most important thing is this. You have enough, even completely ignoring what I said above. So go and write something, and maybe a lot goes right, but later you say "Oh crap, particles are hard to do with this system!" You just make a note to yourself for your next try. The only way to learn is by making decisions and seeing the outcome, which means programming.

Getting too caught up in writing these class diagrams has only made people stupider for 2 reasons: 1) they generally pick a detail level too coarse for their objective because it blurs the inherent complexity that will foul up the system in practice (i.e. get used to the idea of 'irreducible complexity' and strategerize at that level). 2) it is a procrastination mechanism... some people will actually never accomplish anything because they feel like their code, once written, will be impossible to change. Or laziness.

So go and write it, everyone here loves to see each others' demos.


Actually, I have already written about 70% of everything in that class diagram. Along with another large class diagram for the main kernel flow, a real-time profiler, a base application system to accept game logic/input, debugging features, and math.

I wanted to make some changes to support shaders better, including a level-of-shader system, and so reorganized a few things in the diagram. Even though everything I've coded so far seems to be going smoothly and working great, I just fear that this design will all fall apart for some reason, and a large part of it will need to be rewritten. I know that due to my inexperience, there is a very good chance of this anyway, but I thought this post might lower the percentage of that chance.

Quote:
Which class contains props and entities?

What is the purpose of node if it doesn't contain anything but other nodes?


A prop and entity both derive from Spatial. The node relationship is actualy a mistake that I didn't notice on the diagram. It actually has 0..* Spatial children. So a node can contain any number of spatial children (node/prop/entity), but prop/entity's have no children and are leaf nodes. I have coded this layout already, with a function DrawScene that traverses the tree, calling DrawPrim for each prop/entity. However, a big change to this in the diagram is the RenderList class. I will instead, traverse the tree doing object culling using the usual popular methods, populate the RenderList, sort it, then render that. I am still implementing the bounding classes now. I hope this seems like a good system?

Quote:
As software engineer ina game dev company I may give you an advice. Do not trhust too much in class diagrams alone. They usually pass only a small piece of the information needed.

When you want to show an engine diagram, include a message diagram or fow diagram alogn with the class diagram. In this case that would possibly reveal more problems than a simple class diagram may do.


Very good point, and I was hoping to do a detailed one. The only problem is that ArgoUML doesn't support sequence diagrams and I can't afford Rational Rose/XDE. I will do as you suggested though and maybe use OpenOffice's draw program to create flow charts. Unless you know of a better tool to use? Thanks.

Quote:
My only observation would be: I don like the idea of making texture coupled to a vertex group. These are differetn concerns. Would be better (in my opinion) to attach it to mesh. The result will be almost same but would be conceptually cleaner. Same can be said about effect.


Yeah, this is one thing that I've been thinking a lot about. Right now I have coded so that it is one texture per mesh, and this is actually a change in the latest class diagram. However, the problem is that all non-terrain geometry will be created in 3DSMax/Maya and imported into my level editor. Say they have built a house in 3DS Max. If I used one texture per mesh, I would have to break up the house into lots of little meshes, sort of defeating the purpose of vertex groups. If I didn't break it up, that would be one huge texture for a whole house.

So, I was trying to reason on what cons there are to texture-per-vertex group and couldn't think of any significant ones. All prop meshes would be sorted by texture, so all vertices sharing a texture would be drawn together anyway, so no extra SetTextures. When there are VertexGroups with unique textures, it doesn't really add any extra SetTexture/DrawPrim's because you would have to do that anyway. Where it gets funny is with entities, particularly characters. They would rarely have more than one vertex group anyway, but if they did it would require extra work for the artist to split up the textures like that.

I very well could be overlooking something obvious and huge though, or not know about a better alternative. If I didn't use a texture-per-vertex group, how do you handle large models with lots of different textures being imported from a 3rd party modelling program?

Thanks again everybody, I really appreciate the constructive criticism, and thanks for the positive comments as well. :)

P.S. I typed this up pretty quick because there are people waiting on me to goto breakfast, so I apologize for spelling/grammar.

[Edited by - Chris81 on July 30, 2005 10:16:11 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Chris81
Very good point, and I was hoping to do a detailed one. The only problem is that ArgoUML doesn't support sequence diagrams and I can't afford Rational Rose/XDE.

Violet
Visual Paradigm

I would make the resource factory into a template, and make the differenct factories use it( TextureFactory: Factory<Texture> ), otherwise A mesh-factory could as easily store a Texture.

Everything else looks fine to me(not knowing that much about graphics - designing my first engine myself too ;) ),

Share this post


Link to post
Share on other sites
Quote:

A prop and entity both derive from Spatial. The node relationship is actualy a mistake that I didn't notice on the diagram. It actually has 0..* Spatial children. So a node can contain any number of spatial children (node/prop/entity), but prop/entity's have no children and are leaf nodes. ... I will instead, traverse the tree doing object culling using the usual popular methods, populate the RenderList, sort it, then render that. I am still implementing the bounding classes now. I hope this seems like a good system?


Sounds excelent, thats more or less what I do myself. RenderQueues make it easier to perform material batching which can speedup your rendering.

Have you thought about creating a Material class? It would more or less be refactoring out the efect and texture code from the VertexGroup.

I'm curious, is this just a graphics engine or eventually going to be a complete game engine?

Share this post


Link to post
Share on other sites
Quote:
Original post by Chris81

Yeah, this is one thing that I've been thinking a lot about. Right now I have coded so that it is one texture per mesh, and this is actually a change in the latest class diagram. However, the problem is that all non-terrain geometry will be created in 3DSMax/Maya and imported into my level editor. Say they have built a house in 3DS Max. If I used one texture per mesh, I would have to break up the house into lots of little meshes, sort of defeating the purpose of vertex groups. If I didn't break it up, that would be one huge texture for a whole house.

So, I was trying to reason on what cons there are to texture-per-vertex group and couldn't think of any significant ones. All prop meshes would be sorted by texture, so all vertices sharing a texture would be drawn together anyway, so no extra SetTextures. When there are VertexGroups with unique textures, it doesn't really add any extra SetTexture/DrawPrim's because you would have to do that anyway. Where it gets funny is with entities, particularly characters. They would rarely have more than one vertex group anyway, but if they did it would require extra work for the artist to split up the textures like that.

I very well could be overlooking something obvious and huge though, or not know about a better alternative. If I didn't use a texture-per-vertex group, how do you handle large models with lots of different textures being imported from a 3rd party modelling program?




You can solve this without much work. Never allow implementation detail to rule your high level design. It does not matter to your vertex groups if 2 or more of them point to same texture. Just make them use the texture in a smart way. The texture storage should be made not IN the mesh on vertex group class; these should have only a reference to the texture.

You don't need to split textures just because your vertex groups are splited. As I said.. these are different concerns!! You may have mesh 1 using a piece of a texture.. mesh 2 using another piece and mesh 3 using the whole texture again.


remember... your meshes uses a texture.. not hold it.

Share this post


Link to post
Share on other sites
Thanks for the links sirGustav!

Quote:
I would make the resource factory into a template, and make the differenct factories use it( TextureFactory: Factory<Texture> ), otherwise A mesh-factory could as easily store a Texture


Yeah, it is templatized but I didn't see a way to designate that with ArgoUML. ResourceFactory has a private member array of ResourcePtr's (boost::shared_ptr). Then, as you create factories, you inherit from ResourceFactory< TexturePtr >. ResourceFactory handles all the resource management such as instancing the resource in a cache, creating an ID, usage stats, etc. All you have to implement is a LoadResource function which actually loads the data from a file, plus any extra functions you might need for that factory.

Quote:
Why are you making the vertex and index buffers singletons?


Only the static VB/IB is a singleton. The dynamic one has a 1..1 aggregation with Entity class. The static VB/IB is a singleton because I will only have one VB/IB for static geometry. I found no reason to split it up into multiple buffers.

Quote:
Have you thought about creating a Material class? It would more or less be refactoring out the efect and texture code from the VertexGroup.


That is a great idea, thanks. I will do that.

Quote:
I'm curious, is this just a graphics engine or eventually going to be a complete game engine?


It will be a complete engine. I am planning on using Novodex for physics and coding pretty much everything else myself. Except for various functionality boost provides, including serialization.

Quote:
You can solve this without much work. Never allow implementation detail to rule your high level design. It does not matter to your vertex groups if 2 or more of them point to same texture. Just make them use the texture in a smart way. The texture storage should be made not IN the mesh on vertex group class; these should have only a reference to the texture.

remember... your meshes uses a texture.. not hold it.


Yeah, I should have noted that all aggregations on the diagram are smart pointers. So there would only be one instance of the Texture, and all VertexGroup's hold a smart pointer to the single texture. The textures themselves would be loaded and stored in the ResourceFactory.

Quote:
You don't need to split textures just because your vertex groups are splited. As I said.. these are different concerns!! You may have mesh 1 using a piece of a texture.. mesh 2 using another piece and mesh 3 using the whole texture again.


This makes total sense, and I don't know why I wasn't realizing that. Thank you!

Share this post


Link to post
Share on other sites
Anyone know of any complete 3d renderer uml diagrams?!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement