PDA

View Full Version : 3D Engine Class Design/Structure



technomage
19-03-2006, 02:36 PM
Hi People

I'm just starting to put together a design for my new engine and I would like some feedback. I posted a image of my current design thinking.


http://alertfighter.mirthmedia.co.uk/images/design/isreclassdesign.png

A couple of explanations. the TBaseObject is my base class for all items in the engine, this class has overridden memory management routines to ensure the object creation and deletion is a fast as possible, and so that the system can use the memory manager that I use. All classes in the engine are derived the this one base class.

Everything else should be self explanatory. The TAsset class (for example ) is the base class for all the assets being used, the TAssetManager will handle those assets and will know how to load them from disk/web/archive and will manage releasing the asset when it is not being used, specialised managers are derived from this class.

The TSceneManager will handle the TSceneNode's (which can be derived from by other specialized objects) and will be responsible for building up a list of all the visible objects and their materials and mesh data to be passed onto the TRenderingSystem. The rendering system will be responsible for Ensuring the data is passed to the graphics system as efficiently as possible using the available THardwareBuffers. The TShaderMaterial will contain all the base data from the TMaterial and TTextureMaterial as well as a TGraphicsProgram object.

If anyone has any comments on this current design (good or bad) let me know, this will be my first large scale engine (i.e I want to be able to push a heck of allot of poly's with this engine) so I want to get as much feedback as possible.

Cheers :D

Robert Kosek
19-03-2006, 02:52 PM
Hmm, it looks pretty good to me. What memory manager are you using, btw?

I wonder at how to pass the data about, myself, since if descendents need other data, how would you get that data to the object? Aside from hardcoding stuff, of course, but I'm just wondering. ;) It looks like a cool system though.

technomage
19-03-2006, 04:56 PM
I have a custom made memory managememtn dll which replaces the default manager under delphi and FPC. Within that DLL I can plug in any memory manager I choose, under windows I think I use QMemory.

What kind of data are you refereing to when you talk about passing data about? vertex data, materials?

cronodragon
22-03-2006, 02:39 AM
Hi! After reading your thread I found interesting the topic of memory managers, but then I found this test:

http://www.wasanderes.de/mmtest/ :shock:

Is it really a good idea to replace Delphi's memory manager?

technomage
22-03-2006, 07:58 AM
Depends on what you need.

Even borland ended up replacing there default memory manager with once of the ones in the list on the site you posted. I can't remember which one though.

Borlands memory manager is good, but I think it does fragment memory if you are doing allot of create and free's within you application. Some of the other memory managers perform better as they block allocatei.e grad a whole chunk of memory in one go rather that lots of small chucks, this is quicker.

the memory manager for this engine has already been tested on one of the other projects and it works really well. I'm not too bothered about the memory system at the moment, I'm more interested in getting the engine design right :D

Eric
22-03-2006, 09:14 AM
They replaced it with FastMM, which is a highly optimized iteration of RecyclerMM-like allocation strategy.

http://sourceforge.net/projects/fastmm/

The main issue with Borland's MM is that if in "best case" situations it can do well, in worst case situations it can become several orders of magnitude slower than other MMs, and can fragment to the point of running out of memory on a 2 GB machine with no more than a few dozen of MB allocated.

technomage
22-03-2006, 10:03 AM
Back to the matter in hand :wink:, I will upload a new version of the engine design later today. If people could have a look that would be great. :-D

I'll put a post up when I've upload the new version.

jdarling
22-03-2006, 02:05 PM
The only change that I see would be placing MobilObject under StaticObject. This only makes sense as they both require a world position, a state, and most likely a modle or texture. The difference (in my eyes) would be the movement and changing of modle (or mesh) states and applying physics (witch still may exist in a static object, for example a spinning crystal is pretty static).

Just my two cents :)

technomage
22-03-2006, 04:54 PM
You are of course correct, I missed out a Class, :oops:

TPlacableEntity or T3DEntity

This would sit above TMobileObject and TStaticObject.

I will update the diagram with these changes and a few extra's that I have added.

technomage
22-03-2006, 07:33 PM
I've updated the design with a few more bits and pieces. Including one of the missing classes above TStaticObject and TMobileObject. :D