A scene rendered by ZeroRay illustrating reflection and refraction. The glass orbs both reflect and transmit light through them.

ZeroRay began its life as a ray tracer. Building a ray tracer from scratch was one of the large projects for a graduate level computer science course I took called Image Computation. I ended up using ZeroRay in a lot of other projects and it has evolved into a ray tracer/computer vision (CV) toolkit with a suite of deep applications that are both interesting, and illustrate how to use ZeroRay.

I have released ZeroRay as open source software, under the BSD license. The BSD License is pretty much the most liberal open source license. The basic jist is that you can use the code for anything you want, be it open or closed source, commercial or non-commercial. All you have to do is give the author credit for using their library. You can visit the ZeroRay project page at sourceforge. At the time of this writing, I haven’t prepared any convenient downloadable packages so you will have to check the code out of the svn repository. To do so click Develop on the project page and follow the instructions there.

If you’re wondering, “What’s a Ray Tracer?” check out my previous article What is Ray Tracing?

Back to what exactly ZeroRay is. ZeroRay is a software library (or more precisely a set of software libraries). That means it is a set of tools that are used by programmers to create applications. A simple application could be one that, when executed, draws a pre-set picture and saves it to an image file. A more complex application could be a program that allows you to set up a 3D scene by dragging objects into it a low quality rendering of the scene and then invokes the ZeroRay ray tracer to generate a high quality version of the image. As a bit of an aside: ray tracing is a way to generate very high quality computer graphics, however it is significantly more computationally intensive than the techniques used in real-time renderers, like the sort that are used in video games. To make the ZeroRay ray tracer widely useful to computer artists (who generally are not programmers), it would need an application similar to the second example. But ZeroRay is more than a ray tracer. (more…)

The PolyViz Viewer displaying three polyhedra.

“PolyViz is a tool for visualizing n-dimensional polyhedra. Motivated by the difficulty of reasoning about the iteration spaces of nested loops with many levels, PolyViz allows users to visualize polyhedral representations of those iteration spaces.”

- PolyViz Sourceforge project description

I started writing PolyViz for an advanced high performance computing (HPC) course last spring (early 2010). The course focused on the polyhedral model, a way of thinking about tightly nested loops in computer programs as geometric shapes. In the polyhedral model, each loop has an index variable, like in a standard for loop, such as i, j or k. Each index variable iterates over a range of values, this set of values is called its domain. Each index variable is interpreted as a dimension of the polyhedron. Values that are included in the domain are within the polyhedron, all other values are not.

PolyViz on Sourceforge – See the files section to download source packages or the manual, which is very good and covers background materials and the mathematics involved, along with instructions on how to use the software. (more…)

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

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

The cloud system has come a long way since I first posted about it. I suppose technically, it has come a long way since yesterday when I started working on it again, but that didn’t sound as dramatic. After a long while working on other aspects of the game, the Toolset GUI for one, but many other bits that I haven’t mentioned, I came back to the cloud system with a fresh eye and took it in a different direction than I had been imagining.

(more…)

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

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