Something that has been bugging me for a while is object-management in D3D. By that I mean the manor in which you handle objects and camera views in an actual application/game. I have thought of a few ways, but being as new as I am to this, I am wanting others'' opinions on the subject. The way I started to approach it was to create an "Object Interface" which would allocate memory for new objects and store their pointers in an object registry and render every registered object in a single call through the interface (basicly a COM type structure) For the individual objects I created a "CBaseObject" class which simply contained the position/rotation and mesh information that any object would require. From that I derived some more objects like CPlayerObject and CStaticObject, each adding only a few more properties to the base object. For the camera, I created a method to "attach" the camera to an object, which would basicly set its principle position/rotation to that object whatever it may be. So in order to create a free-floating camera I had to create an object first (which I name FloatCamera, hehe) and attach the camera to it and make the object (which was invisible) fly around. I know that the method that one would use would be more determined by the scope of the application, but I was thinking more for something like a MMORPG style game. It would be very interesting and helpful to hear other peoples comments/ideas on this subject. How do you keep track of things lke monster, player objects and everything, and what kind of order might you draw them in if any? Ideas ideas! Thanks

Since you are thinking MMORPG, lets go with that.

The client does not store the entire list of monsters. Probably the best way to go about it is to split the world into "Zones", EQ sytle (without the load times, we hope =). Then, on the server, the player belongs to a certain zone. Now, on a network update, the server looks through it''s list of monsters in that zone. For each monster in range of the player, the server says, "Draw this model at x, y, z". Probably the animation is taken care of using a standard timing system (perhaps also downloaded from the server at log on). The client, to save memory, will probably only load the models and textures that can be in that zone, including every player model and texture.

This is how I would do it. I would allow the camera to have a fixed position in space, and NULL for the object it should follow, and also be able to attach it to an object, at an offset (if you attach it to a model, and 0,0,0 in model space is at the feet, you should be able to offset the camera attachment to 0,1,0, etc)

Z.