Just curious about what this all important "object class" that is so important for a good 3d engine. Thanks

I assume you know what classes are, and how they are used to represent a objects...

so... here is a very simple example.

the idea, in simple terms, is you have a really basic object, that can be enhanced to represent anything you want.

say, you had a really simple space game, you might only give this object members dictating the objects position, rotation (through use of a matrix maybe), speed, and, say, strength and mass...

now... then what you might do, is create a group of functions for the base object...
say, something like

ApplyDamage()

Destroy()

virtual Render()

virtual OnCollide()

Push()

etc...

then, put in the code to destroy the object, making sure memory is all cleaned up... or code to apply damage, and destroy the object once it''s hit 0... etc..

the render function is virtual because there is nothing to render, this is a base object. Render will be replaced.

Now, create, say, a ship object...

class CShip : public CBaseObject
{
...
}

all this could have is a Render function, which would do everything needed to render a ship. otherwise, it would be exactly the same as the base object in every other respect, except it draws a ship.
This way you don''t have to reprogram the same things for every object.

a laser object might override OnCollide to inflict damage on what it hits, for example.


The real power of this, though, comes in when you have an object manager.
This can be in many different forms.. but basically, what it will do, is it will keep a list of all objects created, and each frame, will loop through and render them, tell them to destroy if the app is closing, handle memory management when they are destroyed, etc...
And also do more complex things, like handling collision detection, if an object wants it.
(ie, you write collision detection code once, for everything)

Using one of these, you can then create functions, or macros, or whatnot, to create a new object in the object manager..
so, as I''ve mentioned before, you could create a Particle object from within the render function of the Laser object..
thus your lasers will have particle trails...

Had the objects not been based off of the basic object, object managers, having render() called automatically, memory management, etc , would ALL be done on a PER OBJECT basis. thus, if you wanted to add another object, you would have to add managers, etc, for that object. and you''d likly have a set limit to that object..
This is not the case here. As unlimited number of objects should be possible (though a linked list).

it also means your code is a lot simpler.
Imagine having 10 different loops running through your 10 different object types just to render them... then another 100 to do collision detection between each object type...
and as the program gets bigger, things get more complex...

now imagine having 1 line telling the object manager to render all your objects.

This is a VERY simple example though.


my current project has a (in my opinion at least) very powerful base object, containing no less than 3 matricies, 9 vectors, a linked list, and a host of other members. This complexitiy is scalable by the derived objects, so particles only use the objects position, where as a wheel only needs to override 1 function (ApplyForce) to act exactly like a normal wheel.

this means if there is a bug in my wheel, I only have to look through 15 lines of code to find it. as I know its there, because it''s not occuring in any other objects.

This is the power of OOP.

I guess thats why it is so critical! THANKS! If i can ever get my god damned mouse to work ... as you all probably have noticed that big long thread of mine...

It''s all about looking at things in a different way. Sometimes when u look at things in a different way it''s more easily understood or nicer to work with. In relation to programming, different ways of looking at what you''re doing may make it easier (or harder) to find (nice) solutions to different problems.

yes. good point. exactly.

don''t look at the surface of an object and try to emulate it, look at what makes the object what it is, and try to simulate it.

eg, (I''ll bring it up again )
the car from my current app is made of 15 objects... 4 wheels, 4 suspension nodes, a main object, 4 collision controling objects, 2 steering nodes, and there will be many more in time. There is no ''car''.