I'd mentioned earlier that I had implemented cameras unsing a factory method, and that it mostly required copying and pasting the object factory code and doing a search and replace, and that I would have to do a similar thing for the lights when I implemented them, and so it would be best if I could find a generic method (using templates) of implementing a factory for any kind of object. Well, on Wednesday I finally did this, and now the code is quite elegant. The Model3D class (which as its name suggests is used to take care of an entire model) has the following members:

public:

	...

	static MFactoryDatabase	objectDatabase;
	static MFactoryDatabase	cameraDatabase;
		
private:
	
	MFactory<Object3D>	objectFactory;
	MFactory<Camera3D>	cameraFactory;

The factory object uses a database (which is passed to it as a constructor parameter) and when asked for an object (through a four letter code) it finds the instatiator in the database, runs it, and inserts the new object into the (double) linked list inside it. To take care of object IDs and and previous/next pointers, an additional MFactoryObject class is required. It is assumed that all objects which the factory is designed to produce are derived from this one.

The separation of the factory from the database is quite logical. Each instance of the factory class must maintain its own linked list, while the object database should be shared across all objects (hence the static keyword). Making the database a static member of the MFactory class would not have worked since then the camera and object factory would have the same database, and then you couldn't tell in which one an object belonged.

Other than this, I've also added bounding boxes. This is a first step towards selections (when selected an object will display its bounding box and resize handles). It involved adding GetBoundingBox method to the base class which returns 2 3D points (for opposing corners of the parallelipiped), and then implementing it for each of the derived classes (the torus took a while, since it turns out that the z coordinate for it is constant, no matter what the inner and outer radii is, and for the teapot I didn't have the actual dimensions (the glutSolidTeapot function takes only a generic scale as a parameter) so I had to guess them, run the programs and tweak them). Then the Display method uses the returned values to draw the box. The picture is what the whole thing looks like right now.