An image of the statute of Athena rendered by ZeroRay.

There are two approaches to the computer graphics problem:

1. For each object in a scene, project it onto the screen, then color in all the pixels that it covers.
2. For each pixel on the screen figure out which object in the scene it points at, then color the pixel the color of that object.

The first approach is the one used by mainstream, real-time graphics toolkits like OpenGL and DirectX. The second approach is ray tracing. This may seem like a fine distinction, but this choice determines what sort of things end up being hard or easy later. (more…)

There are two basic shadowing techniques that are commonly used in real time rendering: stencil shadows and texture shadows. The stencil shadow technique (also called shadow volumes) works directly on the geometry to project shadow volumes through the scene. The texture shadow technique works by rendering the scene to a texture (jargon that simply means image) from the light’s point of view and using that texture to determine where shadows fall during the rendering process of the output image (what you see on the screen). Both methods have distinct advantages and disadvantages and the myriad array of sub-techniques and specialisations of these two umbrella techniques makes choosing a shadowing technique suited to ones own uses a bit of a task. Describing, or even enumerating all of the sub-techniques that have been used or proposed is outside the scope of this article (read: outside the scope of my evening). I may write some articles in the future about the sub-techniques that I think are wonderfully clever (and some of them are deliciously clever) but for now, the basics. How does anyone get any shadows on the screen in the first place?

(more…)

I remember the first time I started looking into shadows. It was back when I first started working with 3D graphics and I had this naive idea that 3D graphics were so awesome because they were simulating nature. Learning about real time shadow rendering techniques quickly killed that idea. Learning about other aspects of real time 3D rendering like geometry and lighting I suspended the realization that it is all just smoke and mirrors, by imagining that if my computer were just faster, I might be able to take into account enough detail to actually be simulating how light works, rather than just making a nice picture with a pseudo-approximation of how light works. But when it comes to shadows, that rationalisation rolls over and dies. The methods used to create the appearance of shadows in real time rendering (and as far as I’ve researched, in offline rendering as well) are far removed from the real world physics that create shadows.

(more…)

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…)

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.)