I haven’t written in a while because I’ve been bogged down in an overhaul of the Toolset GUI. I suppose bogged down sounds like I’m upset about this (which I’m not, it’s progressing wonderfully) however, list boxes and modal dialogs just aren’t as sexy as the 3D rendering topics, so I’ve been sparing you, my dear readers, the nitty gritty.

The new GUI is written using a library called wxWidgets. The great thing about wxWidgets is that it draws the GUI using the native GUI of whatever OS I build the executables for. How this works is a bit more involved, but the benefits are clear. The toolset will look and feel like a program that is made for whatever OS it is running on. In windows when you open a file the file dialog looks like the windows file dialog with all your locations on the left (my documents, my computer) and on a mac, the menus will be shuffled appropriately so that the quit, preferences and about options are under the application menu. That might sound uninteresting, but there are a lot of conventions that users expect when they run a program on their computer, even if they’re not consciously aware of expecting them. Another upside is wxWidgets seems to run faster than the old GUI, which was drawn as a 2D overlay by the 3D rendering library.

The new GUI is still a work in progress, but it’s coming along and much more quickly now that I’ve gotten a handle on wxWidgets.

Sometimes the little things make a huge difference. A little atmospheric haze gives the world a real sense of depth and a softness that makes the terrain in the previous screenshots look stark and bare. I improved the clouds a little bit, but the main change you’re seeing between the screenshots in this post and the one I made this afternoon is the atmospheric haze. It almost makes it look like a fantasy illustration with the mounting cliffs and stylized clouds (stylized sounds nicer than “unfinished.”)

Generating realistic looking clouds and lighting them properly is an exceptionally complex task. The appearance of a cloud in the real world is a result of the interaction of an incomprehensibly large number of photons with an incomprehensibly large (not as large as the number of photons, but still incomprehensible) number of water/dust globules. No computer in existence could accurately simulate a weather system with that level of detail and even approach real time rendering speeds (you think 2 frames per second is bad, try 2 frames an hour.)

And so, the task of the real time computer graphics programmer becomes: find a way to simulate a system that looks like that hugely complex system but only requires the simulation of a bare minimum of the variables present in the original system.

(more…)

I’ve significantly improved the normal mapping code. Mostly I fixed some bugs, but there are a few speed enhancements and more to come. Here’s a shot from the toolset with lighting from the moon (not pictured) and a nearby point light.

If you’re wondering what that big ball with the glowing light coming out of it is, I’ll tell you. It’s a placeholder for a lamp post model which I don’t have yet. I have a (very) part time modeller right now, but I’ll use this space to say, Cutthroat Studios is still in need of artists! If you are a 3d artist, shoot me an email. If you’re an amateur modeller who wants to work on a very cool project (and get a game art credit for your resume) I’m interested in talking with you. If you know a 3d artist, send them a link to this blog.

Since my article on Day/Night Lighting, most of my work has been on parts of the engine that, while critically important, are not very pretty looking. This week I managed to break away from working on the ugly guts of the engine and worked on some pretty things. So, avid readers, what I am telling you, is that this is going to be a screenshot heavy article (hooray!) I even prepared some pretty visual aides to help illustrate a few of my points (also hooray!

Some Background on Sky Simulations in 3D Games

Most 3D games in recent years use skyboxes to simulate realistic skies. A skybox is exactly what it sounds like – a large cube that encloses the game world with six images on the inside faces, cleverly edited so that they appear seamless. This is an easy way to have very good looking, highly detailed skies with clouds, stars, or whatever else you expect to see in the sky. However, image based skyboxes like this are static, since the clouds and other objects in sky are essentially still photos, they cannot move across the sky, or change their colours at different times of day. To give some dynamism to the sky, some skybox systems use several sets of images and blend between them as the time of day or weather changes. This approach can look very good, but it still is not truly dynamic, even if a huge number of sets of images were used, it would be like playing a movie of a sky on a large screen that wraps around the game world. And just like a movie, it would be the same every time. Also, this technique requires a huge amount of art. While the task of displaying and blending between images on the skybox is simple, it pushes the burden onto the artist to generate a large number of image sets that smoothly transition from day to night, for example, or from clear to cloudy and back. As more variables are added (day/night/sunset/sunrise/clear/overcast) the number of smoothly transitioning image sets required by the technique multiplies. Skyboxes are a good, simple solution to the problem of creating good looking skies if a game does not require a wide range of sky situations in the same area. For example, if the player does not spend much game time in each area, you can choose a skybox that fits the time of day that the player is in the area. If they leave quickly and aren’t allowed to freely come back after time has passed, there is no need for a sky that reflects more than that one point in time when the player was there.

(more…)

To paraphrase a description I rather liked, a game engine is a system of systems (from Jeff Plumber’s master’s thesis, which has been passed around and discussed quite a bit on software development forums like gamedev.net and ogre3d.org). Now, the word system has serveral meanings, but the interpretation I use is the mathematical one where a system is essentially a “collection of things.” By that interpretation, a game engine is a collection of collections of things. A game engine is a collection of software components that collaborate to produce the experience of a game.

(more…)

Well, I figured I’d open with this topic for two reasons:

• I just finished it up and it’s still at the forefront of my mind
• I have some neat pictures of it so I can show you what I’m talking about

There are two components to a basic day/night cycle system. The position of the sun and the moon in the sky, and the colour of the light they cast (or, for the nitpickers, the colour of the light that reaches you.) The position of the sun and the moon determines the angle of the light relative to the viewer.

Some relatively simple trigonometry generates a circular path around the scene by calculating an angle from the horizontal plane using the time of day; the angle for the sun is zero at dawn and increases toward dusk where the angle is 180 degrees. So far, the sun moves across the sky and the angle of light is calculated based on the sun’s position. The lighting looks right in the middle of the day, but around dawn and dusk, it appears unnatural. This is because, in real life, we’re using to seeing a change in the colour of light whenever we observe light from the sun coming at a shallow angle. There’s some important explanation for this, involving the atmosphere and light scattering but that’s beyond the scope of this article. So, we introduce a “sunset colour.”

The sunset colour is blended with the “day sun colour” with the ratio between the two gradually increasing and decreasing as we get closer to and further from dawn and dusk. To accomplish this, I first used cosine to simulate these curves as pictured in fig. 1 where the yellow line represents how much of the sunset colour is getting blended in to the final light colour and the red line represents how much of the day sun colour is blended in to the final light colour. In fig. 1 I’ve labeled dawn and dusk, but you can deduce that the peak of the red line is noon (the midpoint between dawn and dusk.) A canny observer will soon realize that the sunset colour becomes more prominent than the day light colour exactly in the middle of the afternoon and the dawn doesn’t end until the middle of the morning. Clearly, this isn’t how the real world works, a new curve must be found.

The new curves (pictured in fig. 2) are much more satisfying. You can see the drawn out plateaus in the middle of the day, leading into the exchange of dominant colour more tightly around dawn and dusk.

The Result:

Next related task: Generating and lighting clouds and other celestial phenomenon (like stars.)