Hey people, One thing I''ve noticed during the last couple of months is that when people are creating their 3d engines,is that they are deriving everything from a CObject class.They derive their terrain,actors,models,water,sky,etc etc from this CObject.Why is that? Did I miss something? Does it make everything easier to code or is there some efficiency thing going on? Just curious.

Well, the main reason people do this is to encapsulate some common (usually low level) code that almost all of their objects will use (memory management, scene graph stuff, etc).

This used to be real common before templates came along, and you will see it in a lot of older libraries (like MFC).

Think of CObject like this:

class CObject {
public:
CObject(){}
~CObject(){}
int x;
int y;
};

This is you''re "base class".

Now, say you want to have an object such as a character. A character is going to need a position on the screen as would any object. If every object is going to have a position, why not just code it once and derive all the new objects from the base class? Consider this:

class CCharacter : public CObject {
public:
CCharacter(){}
~CCharacter(){}
int HP;
};

This new object will have a HP value for the character but because it is derived from CObject, you can also access it''s variables and member functions. Therefore:

CCharacter Zane;

Zane.x = 100;
Zane.HP = 100;

This is now possible. Let me know if you need more explanation of this topic.

I derive everything in my scene graph from CObject for two reasons, first I can add functions to all derviced types like save\load. Second I can store\pass around pointer to CObject without knowing what it is. (Really basic flawed exmaple):

For example I store pointers to CTank and CBuilding in CNode.

CNode then draws all it''s objects in the tree. It then calls .Draw() on the Tank and Building object. Both derive from CObject with has a virtual draw method. By doing this CNode doesn''t need to know what is in it''s geometry list.

I use this exact method for renderstates like applying lighting or textures to all objects at that or deeper nodes.

gimp

My most common use of CObject-type base classes is to provide a generic messaging structure. To this end, my CObject-type base object must be aware (by enumeration for my current purposes) of its type.

Consider an MFC application that has many kinds of objects that must be manipulated across several views and several controls. If you were to modify the interpretation of one object, in a view, you would want to be able to tell views to update that object''s interpretation (for say, a list view, and a graphical view, and a tree view) without having to reload all of the objects. You could write a modify message handler for each type of object and hope you don''t run out of message ID''s before you run out of object types... or you could do what I do... pass the base class of the object if the base class knows the type so you can safely cast back up to the proper type on the other end of the message. This means that I have a single message for my major functionality (one for add, one for modify, one for delete) while using a generic conveyance mechanism (the CObject-type base class) while retaining the ability to properly interpret the object (due to the base class''s knowledge of what the object is "supposed to be", when casting back up). This also has the added advantage of allowing me, in MFC, to be sure that my item data pointers in my tree controls, list controls, etc, are all the same type despite obviously representing different things (and believe me, trying to decide according to layer what type you should cast the pointer returned by GetItemData to when you pull it off a tree control is "really flipping ugly".)

There''s also the fact that deriving from generic objects can make certain types of data structures easier to use, when done properly.

-fel