I used to believe that creation of complex and highly detail scenes can be pretty difficult, given the amount of time and work that is spent in shifting vertexes and cutting more resolution edges into edges.

However, little did I know that creating low polygon scenes for real-time environment that uses different formats from what I had most often used (standard large terrain simulations databases), can pack its own punch of challenges as well.

Some points that I had gathered, as I spent my time over the past two weeks planning and creating a terrain scene for a real time simulation application…

First of all, any scenes created for real time purposes, are to be as simple as possible, namely the polygon counts. But yet, the aesthetics of the scene has to be pleasant to the eye, with details burned into the simple polygon objects through all sorts of tricks one can come out with.

Secondly, the manner and direction that the textures is mapped and wrapped is very important. A ton of textures for every single 3D objects in the scene, can be extremely heavy on the load of the real time engine and thus, as much as we can help it, the same piece of texture is recommended to be reused over again. For repetitive surfaces such as sides of buildings, a single piece of small texture, like that of a window, or a section of windows, is used and repeatedly titled all over the surface. How each of the 4 edges of the texture ends are then, of the most importance, as the titled texture must appear seamless and faultless when titled side by side or top and bottom of one another.

Thirdly, we can save scene loading sizes, and hence the loading an caching time, by saving the amount of textures used in the scene. What do I mean by that? For simple and small face objects, we can always use a single piece of jpeg picture with multiple pictures in it. With different areas representing the surfaces of different object faces… all of them fitted into a single jpeg piece. Hence the the texture mapping to surfaces shall require some additional planning, say the texture for the surface of table A starts from point 0,0 of file myTexture.jpg, while the surface of table B starts from point 250,250 of the same file, myTexture.jpg. In this case, we are able to use a single piece of jpeg for 2 separate object faces.

Fourthly, we have to “help” the real time engine to “light up” the world through lighted textures. Floor areas, wall sections that are hit with directional street lights or other directional lights are either baked with the light sources in the scene, or simply, lighted in the correct directions using photoshop. A scene with baked lights textured into the texture, will save much on the number of light sources used and hence, the light computation, when the camera or viewpoint is shifting through the 3D landscape.

Next, the scene creator has to take into account objects, or part of the objects that requires animation or movement. Here, the modeler, texture and lighting creator must be able to predict the direction of movement and the changes of resulting lighting that is cast on the moving object’s surface. Things will look really strange if we have a plane that is hidden in shadow whilst in the hangar, coming out on to the runway in bright sunlight, with the textures on the plane still showing the darkness of the shadow from the hangar rooftop.

And of course, lastly, objects that cannot be seen by the cameras within the scene, should NOT be there. Don’t bother drawing them. Don’t even plan for them to be in the scene. Forget it. For framerate sake, don’t stress the engine unnecessary. Every single piece of tree, bush, that is hidden from view behind that cliff, that is omitted, will save the virtual scene from overloading and having a framerate like that of a lazy, fat mole.