A Better Sky

As those who follow this blog may be aware, I've been following a series of tutorials on developing a simple game engine using OpenGL.  I'm already familiar with basic OpenGL programming, WPF 3D, and know a little bit about the Unity game engine.  Unfortunately, a full-blown game engine like Unity is so high level that it gets in the way of some of the things I want to experiment with.  Total overkill. WPF 3D doesn't support a number of rendering techniques (no support for normal or bump maps.  Again, too high level; no shader-level work.  OpenGL in and of itself is fine, but I wanted to see a way to fits bits and pieces together better.  There are also a few techniques I've never tried before.

The point of this exercise, therefore, is to learn enough to assemble a very simple OpenGL game engine that will let me wander around, fly over, etc. terrains generated via the techniques I'm experimenting with.  I figure another day or two will bring me to the point where I know enough to do that, and that I've learned the additional techniques I need.  Today has brought me closer to that point.

A woman standing on a hillside, with a cloudy sky behind.

The terrain is no longer flat.  The basic skybox is in place with clouds anyway you look.  The blocky man from yesterday has been replaced by a woman who doesn't quite render properly (texture mapping problem) but is still less freaky than the box man.  The woman and one of the tree models were free models I downloaded online.

Alas, that brings me to one of the major limitations of the game engine as it stands.  It only supports OBJ models that are textured by one and only one texture file.  Untextured OBJ models, or those with multiple textures, are not properly supported.  There's a lot of good free models, at least for a demo/experiment like this, but I can't load most of them, even after converting them to OBJ via Blender, because of the poor support.

At first glance that sounds like a simple thing to resolve.  It actually is with respect to reading the file format.  But efficient data structures for rendering, on the other hand, I am still considering.  At this point, I think the likely solution in my eventual engine (as opposed to what is emerging from the tutorial) is that a model may actually become a list of paired geometries and materials.  When rendering multiple instances of a model (as with the trees, ferns, flowers, etc.) I'd iterate over the list of instances once per paired geometry/material.  So if a model had geometry/material A, B and we had instances 1, 2, 3, 4 of the model, we'd render 1A, 2A, 3A, 4A, 1B, 2B, 3B, 4B so there would only be one state change, between 4A and 1B.

I'm also considering how to deal with non-textured models.  Models with simple color can still be very useful.  Perhaps auto-generating a texture map with all the used colors on it, and assigning texture coordinates to vertices such that they map to the correct color block of the texture map, may be the answer.  That would let the same shader handle both types of models.

Anyhow, I'm going to finish out at least three more of the tutorials (day/night cycle, normal mapping, and mouse picking) before I start creating my own, limited engine.  I'm not trying to create a major game, nor sell an engine, but some of this experimental stuff is just more easily implemented using lower level graphics programming - but alas at a slightly higher level than OpenGL itself provides.  I don't think running out and using a full blown scene graph or game engine is the solution, so I shall continue.