Almost all 3d engines have a scene graph of some sort at their core and the Qixis engine is no exception. The scene graph is built up from one or more so called ‘nodes’. The root of the world is also a scenegraph node and is the data member m_root on the engine object. Since the engine object is a singleton, the engine, in its current incarnation, can handle one scene graph.


The basic building block of the scene graph is the ‘node’, a simple class mainly consisting of a position and an orientation in the 3d world. Take a look at this picture:

Here we see a simple scenegraph. In the picture, for simplicity, it’s two dimensional. In the engine, of course, all coordinates are tree dimensional. This scene contains three nodes, named ‘A’, ‘B’ and ‘C’. As you can see in the picture, all nodes have a position and an orientation (called ‘rotation’ in the picture). These two attributes determine their positions in the world.


Every node has a parent. For most nodes, the world’s root node will be their parent, but it’s possible for a node to have child nodes. The position and orientation for child nodes is based on their parent nodes. In the picture, node B has node A as its parent. Its position is calculated by adding node B’s position and orientation to that of node A. Moving node A moves node B along with it. Rotating node A rotates node B too. This is very useful for 3d objects that are made up of multiple parts, like a plane consisting of a body part and a propellor. The propellor has to move and rotate with the plane while at the same time having its own rotation…

 
 

In the ‘Init’ function of the engine, we find the following code:

60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

bool Engine::Init() 
{ 
    std::cout <<"Engine::Init(): " <<this <<std::endl; 
//// Construct a test node 
// 
    Node *nd = new Node("square"); 
    iRenderable *rd = new Square(); 
    nd->position = Vector3<math_type>(0.0f, 0.0f, 0.0f); 
    nd->orientation = Quaternion<math_type>(Vector3<math_type>(0.0f, 1.0f, 0.0f), 0.0f); 
    Node::RenderableInfo ri;
    ri.renderable = rd; nd->renderables.push_back(ri); 
    m_root->AddChild(nd); 
// 
//// 
    return true; 
}

These few lines of code actually fire up a large part of the engine. Let’s take a look at the code a few lines at a time.

bool Engine::Init() 
{ 
//// Construct a test node 
// 
    Node *nd = new Node("square"); 
    iRenderable *rd = new Square();

This code allocated and initializes two objects. The first is a scenegraph node (we’ll get to that later), the second an ‘iRenderable’-derived class Square. We’ll get to the renderables in the next tutorial.

    nd->position = Vector3<math_type>(0.0f, 0.0f, 0.0f); 
    nd->orientation = Quaternion<math_type>(Vector3<math_type>(0.0f, 1.0f, 0.0f), 0.0f);

Every scenegraph node has a few attributes that it must have set. The position and orientation are mandatory and are initialized here to be at the coordinates (0, 0, 0) and have a rotation around the ‘y’-axis (0, 1, 0) of 0 degrees. In short, a square is placed at the center of our virtual universe.

    Node::RenderableInfo ri; 
    ri.renderable = rd;

In order for the square to be visible, we need to attach it to the scenegraph node. This is done using a container object, ‘RenderableInfo’. RenderableInfo has two member fields: the renderable object and a material description. Because ‘Square’ is a test object and handles its own material settings, we can leave the material definition empty. Easy

    nd->renderables.push_back(ri); 
    m_root->AddChild(nd); 
// 
////

And the last step, were we attach the renderable square to the node, and add the node to our universe, the root of which is conveniently called ‘m_root’, on the engine.

Now that we have set up something to render, let’s try to make it visible on the screen. To do so, all we have to do is to tell the engine where the camera is in our universe and in which direction it is pointing. Since the square we just created is in the center of our universe, it seems only logical that the camera has to point there. Also, we need some distance from the square so we can admire it in full.
All of the work to achieve this is done in the engine’s Render function. Most of it is plumbing and not important right now. The interesting part is where we set up the camera.

129
130
131
132
133
134
135
136
137
138

//// Temporary camera code 
// 
    m_camera.Eye(Vector3<math_type>(1.0f, 1.0f, -3.0f)); 
    m_camera.Target(Vector3<math_type>(0.0f, 0.0f, 0.0f)); 
    m_camera.Up(Vector3<math_type>(0.0f, 1.0f, 0.0f)); 
    m_camera.UpdateRenderer(); m_camera.SetFoV(60.0f, 1.0f, 0.1f, 10.0f); 
    m_camera.UpdateFrustumCull(); 
    m_renderer->Clear(true, true, Qixis::Color::Color::DarkBlue()); 
// 
////

The camera is another member of the engine, just like the universe’s root node. It is controlled by three vectors: Eye – where the camera itself is located, Target – where the camera is looking at and Up – a vector pointing up in the world. After setting up the camera position, we tell the engine to update its internal state so it actually uses the new camera position. Also, we tell it to use a view angle of about 60 degrees, an angle comparable to what a human eye sees.


That’s it for now. You now know the basics of the scene graph and how nodes determine the position of objects in the 3d world. In the next part we’ll add an animator to the node to make the square spin.

Before starting work on a big task like building a 3d engine, it’s probably a good idea to decide which tools and programming language you are going to use. Of course, this being an engine for the iPhone, the choices are a bit limited.

First, we’re going to need a development environment and an SDK for the iPhone. Apple’s official iPhone SDK contains XCode, an excellent Integrated Development Environment. It comes complete with an iPhone simulator, making debugging and testing of software a lot easier. Also, it integrates with Shark and Instruments to do some basic performance profiling. And best of all, as long as you don’t mind developing in just the simulator, it’s free too. It’s Mac only, so if you’re using Windows you’re a bit out of luck here… As far as I know iPhone development can only be done on a Mac.


Second, we’re going to choose a language to use. I’m not an experienced Objective C programmer, but I know my way around C++. On Mac and iPhone development, it’s not really possible to avoid the use of Objective C altogether, but it’s easy to mix it with C++. So, I’ll write the iPhone specific bits in Objective C (ObjC from now on) and the bits that have any potential to be platform independent in C++. I think this is good practice if one possibly wants to use their code on other platforms in the future. All the maths code and a good portion of the OpenGL code in the engine is platform independent and compiles and runs fine on Linux. The engine has some preparations to separate the platform-dependent rendering from the platform-independent bits. We’ll get to that later.


If you don’t know any ObjC or C++ you are going to find these tutorials hard to follow. If you know some of it and just need an online reference, here are some good ones:

• C – http://www.physics.drexel.edu/courses/Comp_Phys/General/C_basics/
• Objective C – http://www.otierney.net/objective-c.html
• Objective C – http://cocoadevcentral.com/d/learn_objectivec/
• C++ – http://www.cplusplus.com/doc/tutorial/

C and ObjC are relatively easy to learn. C++ is a very difficult but very powerful language.


So, that’s all settled. XCode will be the development environment, ObjC and C++ the languages.

• Download XCode with iPhone SDK here.

Also, to follow this tutorial, you need a copy of Qixis::Engine (known as ‘the engine’) from now on. This is the version of the engine as it is in my subversion repository on august 20, 2009. It’s not finished, and we’ll finish it as we go…

• Download Qixis::Engine XCode project here (version 2009.08.20).

Before continuing, install the iPhone SDK if you’ve not already done so. If the installer asks any difficult questions, all the default answers are OK.


Unzip the file ‘Engine-2009.08.20.zip’ to a location that’s convenient for you. For me, it’s a folder ‘Programming/iPhone’ in my home directory. After unzipping, open ‘Engine3d.xcodeproj’. XCode fires up and presents you with a screen looking more or less like the following:

That’s it for now. You now have the development version of the engine, exactly as I have it. I recommend to just look around the code a bit to familiarize yourself with its structure. The interesting files at this moment are ‘Engine.cpp’, ‘Node.cpp’ and ‘Square.cpp’.


In the next part of this series I’ll take you through all the files and describe what they do and how they fit in the engine’s architecture.


‘Till next time!

This is the first part in a set of articles where I will describe the process of developing an iPhone game. The first few articles will focus on the creation of a somewhat generic 3d engine. Of course, I’m describing my own engine (Qixis::Engine), but most of the concepts are valid for all 3d engines. Also, keep in mind that I’m still learning a lot on this subject. I don’t know everything, but will describe what I know and make corrections along the way, as I learn more.

The plan so far is to take a look at at least the following subjects:

• Basic engine architecture
• Basic building blocks
• Building a scene graph
• Adding basic automatic animation
• Resource management
• Basic rendering
• Building scene nodes to show something on the screen
• Materials
• Optimising the renderstate
• Optimising rendering
• Frustum culling
• Optimising troublesome scene nodes
• … this is where my engine is at this moment

The articles are probably not going to be tutorials explaining basic OpenGL ES or iPhone programming; there are some excellent tutorials covering these subjects and if I can learn most of what I need to know from them, so can you. For a quick start, here are some excellent resources covering the basics:

• General math topics – http://www.gamedev.net/reference/list.asp?categoryid=28
• Matrix and quaternions – http://www.gamedev.net/reference/articles/article1691.asp
• OpenGL ES reference – http://www.khronos.org/opengles/sdk/1.1/docs/man/

If these seem overwhelming now, don’t worry. Things will become clear along the way. When I started this project, I didn’t know a Vector from a View Frustum…

Building a 3d engine isn’t a trivial task and there are some rather good off-the-shelf solutions. Why didn’t I use one of those, like SIO2 or Oolong or Irrlicht, or…?

Mainly because building a 3d engine isn’t a trivial task. It’s a fun project and I learned (and still am learning) a lot during this project. I’m writing these articles because I couldn’t really find anything good on basic 3d engine architecture and hope to make my own small contribution this way.

As I’m writing this, the engine is not finished yet. The basic plumbing is there, but a lot of the solutions I chose are naive and can use some more optimisation. I don’t believe in premature optimisation however, so optimisation will probably a topic for a future article.

Writing articles is not something I regularly do. Also, English is not my primary language. Any feedback is more than welcome, both on technical subjects and the writing itself. The preferred way is to just add a reply to an article. My e-mail address can be found on the ‘about’ page of this site.