Main Page   Namespace List   Class Hierarchy   Alphabetical List   Compound List   File List   Namespace Members   Compound Members   File Members   Related Pages  

Teddy Reference Manual


Quick access to Teddy resources

This is early development version of Teddy.

Teddy is a 3D graphics library. It implements a simple windowing system and a simple scene graph. Multiple camera windows, cameras and scenes can be created with Teddy.

I am working alone on Teddy at the moment. If you would like to join to help me with the development, I will be happy to receive e-mail from you. Also mail me if you have comments or suggestions.

Getting started guide to Teddy


See namespaces and class hierarhy and the section below for a really brief introduction which explains how to get something drawn with Teddy.

Drawing something with Teddy

To get something drawn, you must have a model that you want to show. Currently there are two easy ways to make a model. The first way is to create an instance of one of the primitive models which are included in the Teddy/Models directory. Not all classes there are primitives, so this can be a bit confusing. Well, at least Box annd Sphere are such primitive models.

You can not display single Model alone directly. Instead you must have a Scene, which is a collection of Models. Create a scene and add the model to it. Now you can display the scene.

Between right here you need to care about position and orientation of each Model in the Scene, but I'll skip it with this notice. Maybe later something more.

The next thing is that to display the scene you need to have a camera which is somewhere in (or relative) to your scene. The camera is similar to models of scene: it too has position and orientation. Additionally it can spesify the field of vision.

At this point we know what things we want to show and from where we want to show them. Still we need to decide where we 'project' the scene. Most of the time this is the computer display in fullscreen or full window mode, but Teddy is a bit more complex. With Teddy you can show multiple scenes and cameras in the same fullscreen or window. Thus you must create a Projection. Then you can make the Projection to show some camera.

The projection must be added to a Layer in Teddy. The Layer is something useless, but you must have one created and connected to WindowManger. WindowManager is the root of all drawing and event handling in teddy.

The Scene class contains the current 'scene management', which is very little currently. I am planning to add octrees and other things later, but I am not going to make such things until integration with flatfour.

The drawing of the scene is probably the next thing you might be interested in. Like previosuly mentioned, WindowManager is root of all drawing. It loops a simple code blok like { drawFrame(); processEvents(); } The drawFrame() part calls drawing for each layer. Like I said the layer is stupid and might be removed later. Might.

Each layer again contains a set of Projections and a set of Areas. Projections are 3D stuff, Areas are 2D stuff. Strictly speaking Projection is derived from Area, so it is an Area.. Anyway, the further part goes like something like this:

Each projection hshould have a camera connected to it. Otherwise the Projection will not show anything. Projection draws itself by telling the connected Camera to 'draw yourself to me' where 'yourself' is the camera and 'me' is the projection.

At this point Camera hopes that it is connected to some scene. Each camera has a transformation (you can safely think it as transformation matrix, even though it is implemented as vector for position and quaternion for orientation) like any other model. The camera draws itself by first updating the camera matrix and then telling the connected scene to 'draw yourself to me' where 'yourself' is the scene and 'me' is the scene.

The scene is simply a collection of models (okay there are lights too, at this point I skip them) and scene draws itself simply by telling each model to draw themselves to the camera which scene received as an argument for the drawing operation.

Now we are at the point where single model is being told 'draw yourself to camera x'. When this happens, the model asks the camera what is the projection it is connected to. This is done so that the model and the projection can negotiate for the materials really used for the drawing. This works in the way that the model asks projection to apply model materials. The Projection then has the ultimate control to choose which material it actually applies. It can also save some time if it notices that the previous model used the very same material, and nothing needs to be done.

Hmm, actually, before the material apply happens the model asks the camera if the model is withing the viewing frustum. And even before that the model asks camera to apply the model transformation. The camera does this by concatenating the models' localToWorld() matrix with the cameras worldToLocal() matrix. As result the vertices from the models localc coordinates system are transformed into the local coordinate system of the camera.

After the modelview transformation matrix has been set, and the model has been tested for view frustum intersection (means visibility) and the material has been applied the model simply draws itself by drawing its Geometry. Each model has one transformation, material and geometry. Transformation and material are used as described above. Geometry is collection of Elements. Element is, for example, a trianglestrip (GL_TRIANGLE_STRIP) - TriangleStrip is derived from Element and it is nothing more than a set of vertices.

Now you finally get properly trasformed and 'materialized' vertices drawn to the display as part of some opengl primitives - triangles or quads most of the time :)

Things are sligtly more complex when you want to use the same shape in multiple model instances in the scene. In such case you should have one Model which has the shape but which is not part of the scene, and then you have two more models, which do not have geometry but which instead have the first model as 'child'. There is a more detail example about this in the documentation for the Teddy::Models namespace.