BitwiseOR

OBJ files are amazingly easy to parse, who knew. Not like those nasty 3DS files.

Not much to look at, but it is very promising. My first test being a bunch of colored lines in a cube with interactive camera is both boring and quick to ignore, but for me it means that everything is running smoothly. The entire setup consists of creating 3 materials (red, green and blue), creating three translates (translateX, translateY and translateZ), and creating three grids of lines to be drawn (linesXY, linesXZ, linesYZ). once that is done, it’s tied together and displayed nicely. The new scene graph is working out beautifully by the way.

SceneNode* root = new SceneNode();

wm->toggleFullscreen();
wm->mainLoop();

In the notes that I’m creating here, I state that I’m creating a rendering engine. This is just a side project while things are slow at school. It only handles rendering and simple operations for animation. Gamasutra has a letter from 2001 asking what the differnce between a game engine and a rendering engine is. What I’m doing now is definitly a rendering engine. It could be used as the final layer of a game engine. But I’m only creating it rendering experiments. I was sick of using GLUT callbacks or copying and pasting and editing old code each time I wanted to draw something onscreen. Plus, seperation of code is a good thing

Gamedev.net has a good article on how to create a very simple scene graph with example code.

Now, I think that a proper scene graph should have drawables (triangles, lines, …) as leaf nodes. But the basic way to use a scene graph will be to create a certain type of node then add children. So, we create a transform node and add a bunch of children nodes (drawables, materials, other transforms, …). Who’s to say that we can’t create a drawable node and try to add a bunch of children. Using the above example code, this is perfectly legitimate. In fact, the examples on the first page say this is what should happen. But I still see a problem as each node should affect it’s children, and drawable nodes do not affect anything.

Is there anything wrong with drawables having children? Most likely not, but I think that it ruins the semantics of it all. What if, instead of a seperate node for drawables, each node will have a list of drawables that it is responsible for. This way, the drawable nodes are not part of the structure of the tree, but are actually an addition to each node. It should work, I think.

If we modify GameDev’s sample code, then each node has the following properties

• Create
• Destroy
• Update
• AddChild
• AddDrawable
• protected children list
• protected drawable list

Now, each drawable is considered to be “under” the node it is attached to. There are no more drawable nodes. My plan for an engine is different from the article in that nodes only contain data. They know nothing about how to draw themselves. The root node of the scene graph is given to a renderer which interprets the node and applies what needs to be applied. In this context, the renderer will update a node, apply the transform, material, whatever, draw the drawable list, then do the same on the children. (In this sense, Update() is used to create animations, color changes, and so on. Not to actually apply the node as in the article.)

My first attempt at this was to create a single node type that held a void pointer and type info. Each type of node was added through it’s appropriate add<type> method (addDrawable, addTransform, addMaterial, …). Then, depending on the type, the tree structure was rearranged. If you tried to add a transform to a drawable, then a new Unknown type node was created with both the drawable and transform as its children. This is not a good way to do things.

The basis of the engine will depend on the types that we use. Any 3D program needs 3 and 4 component vectors and matrices. I choose to mimic the GLSL types: vec2, vec3, vec4, bvec2, bvec3, bvec4, mat2, mat3, mat4. We could also add ivec2, ivec3, and ivec4, but they don’t come up very often. So the above will be a good start.

vec2, vec3, vec4

vec2, vec3, and vec4 and 2, 3, and 4 component floating point vectors. Because they will be used as points / vectors, colors and texture coordinates, we will adopt the same convention as GLSL and have the components x, y, z, w, r, g, b, a, s, t, p, and q. Where x = r = s, y = g = t, z = b = p, and w = a = q. This can be taken care of using the following for members of the classes.

union
{
struct { float x; float y; float z; float w; };
struct { float r; float g; float b; float a; };
struct { float s; float t; float p; float q; };
};

Where vec2 has the first two components and so on.

Be sure to add all the nice operators (+, -, *, /, []) to vecs and mats. Plus dot products and cross products. bvecs have methods all() and any() to do logical ||s and &&s.

The main classes for a modularized rendering engine would be, from the bottom up

Primitive

Base objects to be drawn. Triangles, QuadStrip, Point, etc.

Transform

Pretty much resolving to a 4×4 matrix. Translate, Rotate, Scale, etc.

Scene

A graph representing the entire scene (eg. a scene graph). Ignoring material states and other more complicated state problems, the graph, or tree, will be Transforms as interior elements and Primitives as leaves.

Camera

Describes how we view the scene. Sets up the View and Projection matrices. MonoCamera, StereoCamera, PerspectiveCamera, OrthographicCamera, etc.

CameraManipulator

The Camera tells us how to view the scene, but the CameraManilpulator tells us how the can must most with respect to keyboard and mouse events. Has a Camera as a member.

Renderer

Takes a CameraManipulator and Scene and tells us how to combine the two using a drawing library like OpenGL or DirectX. This sets up the View and Projection matrices based on the Camera, then sets up the Model matrix while drawing Primitives using the scene. It also sends messages about keyboard and mouse events from the WindowManager to the CameraManipulator and possibly the Scene.

WindowManager

Displays the window and creates the necessary buffers for the renderer. Comminucates with the operating system to recieve keyboard and mouse events, then sends them to the renderer. Lets the renderer know when things like a screen resize or key press happens. This would be made from GLUT, MFC, Win32, etc.

Hypothetically, we can set this up to be very flexible in terms of what it can do. We can have an OpenGL Renderer or DirectX renderer, but not change the camera, scene or window manager. Different parts should be able to swap out with no problems as long as each class does it’s job properly.

I have no clue about the proper way to create a flexible rendering engine. But, here’s my attempt, with notes to follow along with. Wish me luck.

More soon…