BitwiseOR

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.