Sign in to follow this  

Check My Graphic Engine Arch

This topic is 4479 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

Here is what I got 1. Vextex Class with postion data 2. Polygon Class with Vertex* array (Derived Strip, Quadrangle, and Triangle Classes) 3. Mesh Class with Polygon* array, 4. Object Class with Mesh* array 5. Scene Class (Singleton) with Object* array 6. Base Class context and window control I do have a Light Class and a Camera class encapsulated in Object and Scene respectively This seems logical to me but this is my first graphic engine. I have experince with large scale OO projects but to design a OO scheme you need to have some clue on what the design goal is. All I know is I want a cross platform graphic engine. Been playing around with OGL for a couple of months now and this is the best i can come up with. Does any one see any major problems with this design in terms of high poly, semi good performance 3D graphics engine? Sorry I am not a big UMLer.

Share this post


Link to post
Share on other sites
Personally, I'd get rid of the polygon class, and just have the Mesh class hold pointers to the vertices and indices. I also wouldn't make it manditory for your objects to have mesh's... Depending on how you're handling entities within your engine that is. You just need to think about how you're going to handle the rendering system now [smile].

Looks pretty standard though really.

Share this post


Link to post
Share on other sites
Hi,

1. Vextex Class with postion data
I think this one is not required.

2. Polygon Class with Vertex* array (Derived Strip, Quadrangle, and Triangle Classes)
This is not required either.

In case of 1 and 2 I'd suggest a class that represents a Vertex Buffer and Index Buffer. This is common architecture in both GL and DX so encapsulating would be better than trying to go into smaller detail.

3. Mesh Class with Polygon* array,
I'd suggest Mesh class with an VB/IB representation. Plus bones for skinning in a derived 'Skinned Mesh' class.

At this point I also may suggest a manager for your meshes. That is a central repository that can handle loading/unloading functions. Maybe you can use a list or a simple array of pointers to meshes so you only have to say 'Hey, manager... give me the mesh number 5'... or... 'Drop all meshes except this one' or 'Unload the meshes that I haven't used in the last 5 mins... but keep the internal references for quick reload'... that is... all you would like from a central manager for objets.

Also, you are missing two other basic objects which are critical for modern day engines. Textures (1d, 2d, 3d, cube) and its purposes (Texture or RenderTarget). A manager would also be useful.

Of course shders are integral part of any engine. Consider shaders as any other resource like meshes or textures. Then you would like to load the shader, detect its parameters, etc. In this case, if you are planning for multiplatform, I'd suggest nVidia's Cg or CgFX. A manager would also be good.

Thar covers your resource management. Now onto the object management.


4. Object Class with Mesh* array
You are going too fast. A mesh is not everything in an engine. I may suggest a central repository of renderaable objects. A renderable object is a combination of meshes+textures+effects representing an object. That way you can use the same mesh combined with other texture. You may have a Red Car or a Blue car... just change the texture and you have a new paintjob. Also, you may change the shader from a brand new car to a rusty car. Same mesh, just mix resources.

Then, your Object class may have a reference to one of this renderables. That way, instead of a mesh, you have all the additional info required.

After this, derive other useful objects from this BaseObject class. Light, Camera, Particle systems, And the most useful... the ObjectContainer. That is, an object that may hold other objects. As a container is also an object, you can create a useful structure that you may use for point 5.
A list o objects may be useful.

5. Scene Class (Singleton) with Object* array
Base this on your object container, Add an array of lights, a list of particle systems, and if you wish an array of cameras (in fact almost any object may become a camera.

6. Base Class context and window control
That may be your Rendering Device. Allow it acces to your resource managers and your scene classes (yes, you may want to have MANY scenes).

Thats all, maybe this helps you.

Luck!
Guimo

Share this post


Link to post
Share on other sites
Wow thanks. I guess i need to do some more reading and more time spent looking at examples. I will post a redesign here. I have had trouble finding a good "standard" OO design, as I am sure there are many variants. But a good noob OO structure might be helpful for some.

Share this post


Link to post
Share on other sites
What do you think of this one.

1. Mesh Class class with VB/IB representation.
2. Mesh Manager <Singleton>

3. Surface Class
4. Texture Class derived from Surface class
5. RenderTarget derived from Surface Class
4. Surface Manager <Singleton>

7. Shader Manager <Singleton> Hanging lose because I dont know what to do with it.

8. Resource Manager <Singleton> with Surface Manager, Mesh Manager and Shader Manager.

9. BaseObject Class
10. Light Class derived from BaseObject
11. Camera Class derived from BaseObject
12. Object Class derived from BaseObject with indecies to meshes/surfaces/etc
13. Scene Class derived from BaseObject with Light* array and encapsulted Camera Class
14. ObjectContainer. STL container for right now.

15. Root Class <Singleton> context and window control, encapsulted ObjectContainer.

Share this post


Link to post
Share on other sites

This topic is 4479 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this