(At Ronimo Games, the Dutch game developer where I am lead programmer, we are currently looking for a coder with experience on the 360 and/or PS3. Interested? Have a look here for more information!)
Last weak I talked a bit about the technical side of lighting in Proun. This week, let's have a look at the more artistic side: the strange light colours I chose for each level.
A very common lighting setup among 3D artists is to let the sky emit a soft blue light, and the sun a bright yellow. This of course makes sense, since these are the colours that the sun and the sky have in the real world.
The fun of having these different colours for the skylight and the sun, is that the sun's shadows become a subtle blue. Brightly lit spots, on the other hand, may become slightly yellow. This fits what my highschool art teacher used to tell me: never paint a shadow with black, always add colour. (Of course, I didn't really understand her at the time...) Since I like this setup, I used it for Proun's first track.
For the second track, I wanted to use a totally different colour palette. Now I am not very knowledgeable in colour theory, but I did notice that yellow and blue are exactly opposite colours. So again I chose opposite colours and after a lot of experimenting with the colour scheme that I had in mind, I came up with a cyan/blue sun and an orange skylight. That is one really weird lighting setup, but I do think it looks good:
The third track is probably the weirdest. A greenish/blueish sun is combined with a pinkish skylight. I think this mainly proves that as long as two colours are chosen that work well together, the colours can be as crazy as you like. So no need to go for the standard lighting setups any more!
So, as these images show, the bright colours of Proun's objects are combined with much more subtle colour effects from the lights. Having just the bright colours worked perfectly well for many works by Kandinsky and Mondriaan, but I think in Proun's case, the subtle colours and shades that the lights add are what really make the graphics shine.
Saturday, 27 November 2010
Saturday, 20 November 2010
Lighting in Proun
Proun is getting a lot of very positive responses to how it looks. Most people seem to think that the depth of field blur is the core reason for this, but the game still looks pretty good when that is turned off. What really makes the biggest difference, is the careful lighting.
Since most of Proun's environments are static, the lighting is calculated beforehand and stored in lightmaps. Calculating lighting beforehand is called baking. Baking should not be confused with cooking, which stands for saving memory directly to disc (this is used to speed-up loading times, because you don't have to parse cooked data). Interestingly, I have heard rumours that the terms baking and cooking are also sometimes used for certain algorithms that are used in kitchens, but I don't know anything about that.
Lightmaps take up a lot of space (one third of Proun's total size), but they have some big benefits. Because lighting is calculated beforehand on the developer's computer, it doesn't matter if it takes a lot of time. This means that much more complex lighting can be used than when it is calculated in real-time. In Proun, I use this a lot. I think calculating all the lightmaps for just the second track cost my laptop about 30 hours!
The further a shadow is from the object that casts it, the blurrier is gets, especially if the light source is large. Lights that cast shadows that get blurrier with distance are usually called area lights. In practice, it is hardly ever possible to calculate this in real-time, so most games have either fully sharp shadows (as if the light source is infinitely small), or a fixed blur that ignores distance.
(On a sidenote: as soon as Proun is finished, I am going to implement a technique that I have come up with that makes it possible to render real-time area light shadows in games with a Diablo-like perspective.)
In the real world, a lot of light does not come directly from the sun: part of the light is scattered by the atmosphere and comes from all directions. Such light from all directions is called skylight. Skylight makes shadows less deep and add a lot of subtle shadow effects to the world.
Objects reflect light. So if light falls on a red object, then this object will reflect a little bit of red light onto the objects around it. This is called global illumination. This is a very subtle effect, but because of Proun's bright colours it is clearly visible in a couple of places.
All of these things are only possible because in Proun, lights don't move and almost all objects are static. I could not have used lightmaps otherwise. The levels are also small enough to store high quality lightmaps of all objects.
The things I discussed here today are pretty technical. In a future blogpost I will talk a bit about the artistic side of Proun's lighting: crazy light colours.
Since most of Proun's environments are static, the lighting is calculated beforehand and stored in lightmaps. Calculating lighting beforehand is called baking. Baking should not be confused with cooking, which stands for saving memory directly to disc (this is used to speed-up loading times, because you don't have to parse cooked data). Interestingly, I have heard rumours that the terms baking and cooking are also sometimes used for certain algorithms that are used in kitchens, but I don't know anything about that.
Lightmaps take up a lot of space (one third of Proun's total size), but they have some big benefits. Because lighting is calculated beforehand on the developer's computer, it doesn't matter if it takes a lot of time. This means that much more complex lighting can be used than when it is calculated in real-time. In Proun, I use this a lot. I think calculating all the lightmaps for just the second track cost my laptop about 30 hours!
The further a shadow is from the object that casts it, the blurrier is gets, especially if the light source is large. Lights that cast shadows that get blurrier with distance are usually called area lights. In practice, it is hardly ever possible to calculate this in real-time, so most games have either fully sharp shadows (as if the light source is infinitely small), or a fixed blur that ignores distance.
(On a sidenote: as soon as Proun is finished, I am going to implement a technique that I have come up with that makes it possible to render real-time area light shadows in games with a Diablo-like perspective.)
In the real world, a lot of light does not come directly from the sun: part of the light is scattered by the atmosphere and comes from all directions. Such light from all directions is called skylight. Skylight makes shadows less deep and add a lot of subtle shadow effects to the world.
Objects reflect light. So if light falls on a red object, then this object will reflect a little bit of red light onto the objects around it. This is called global illumination. This is a very subtle effect, but because of Proun's bright colours it is clearly visible in a couple of places.
All of these things are only possible because in Proun, lights don't move and almost all objects are static. I could not have used lightmaps otherwise. The levels are also small enough to store high quality lightmaps of all objects.
The things I discussed here today are pretty technical. In a future blogpost I will talk a bit about the artistic side of Proun's lighting: crazy light colours.
Saturday, 13 November 2010
Sun rays
Writing shaders is one of the things that I enjoy most in making games. Kind of surprising, really, because generally I dislike doing low-level coding and optimisation. Shaders are among the worst in terms of dirty hacks and hardware specific code. So why do I enjoy writing them, then? I think shaders attract me because of this: they are so limited, that science and optics become totally useless. The way real light works is so much more complex than what you can do in a shader, that you need to just make something up that kind of looks similar, although it is often totally unrealistic. Physically, most shaders are utter nonsense. So instead of being all about knowledge and math, shaders centre on creativity and experimenting. Now that's fun! (At least, to a special kind of people, also known as Joosts.)
One of the nicest examples of creativity in shaders is how light shafts are rendered in games. Light shafts are also known as god rays, volume light, sun rays or Jacob's ladders. They are what you see when a light shines through misty air. The microscopic particles in the air are lit and become visible.
Rendering volume light realistically takes a lot of computation time. You need to trace rays through air, take into account the density of the mist, and for a large number of points in the air you need to calculate whether the particles there are illuminated by your light. This includes doing shadow calculations for each of these points in the air. This is way too complex to do well in real-time.
So, some clever programmer somewhere (not me) came up with a trick that looks great and is a whole lot simpler to do. The idea is really simple: you just walk over the image from the pixel towards the sun, and look how much light there is in the image.
Click here for the original article about this technique, which is also the source of these images.
Things like volume, fog density and shadow are completely ignored. There is hardly any relation between this technique and how real volume light works, but somehow it looks very similar and really convincing. Games like Far Cry 2 and Crysis use it to create beautiful lighting effects through the leaves.
There are some limitations to this technique, though. Most importantly, it only works if the light source itself is actually in view. For example, using this technique, it is impossible to render the effect of a flashlight that is pointing away from the viewer.
Rendering light shafts this way not only looks awesome; it is also one of the most beautiful, simple and ingenious shader techniques I know of. Since I like this effect so much, I couldn't help myself but add it to Proun's third track. The track's graphics are far from final, but the light shafts are there. The little video at the beginning of this post shows how dynamic the effect looks in motion.
Saturday, 6 November 2010
Stereoscopic 3D
Stereoscopic 3D has been all the hype of late. You know, with those black shutter glasses and expensive televisions, or on the new Nintendo 3DS. Although I usually totally ignore these kinds of hypes (I don't have an iPhone, for example), I somehow already ended up making two games for 3D: Swords & Soldiers for the Playstation 3 and Proun for the PC. The latter will be playable in 3D in a few weeks at the STRP festival in Eindhoven.
I won't bother you with the technical aspects and the weird camera math of stereoscopic 3D, since I think the implications of stereoscopic 3D for graphics are a lot more interesting and not as straightforward as one might think.
The first thing to realize is that you should really consider the monitor to be a window into another world. Things may come out from this world, through the monitor towards the player, but if this happens, then these objects should not be cut-off by the edges of the screen. If an object is behind the screen in the 3D space, then the viewer's brain easily accepts that it is partially behind the monitor's edge. However, if the object is in front of the screen, yet is cut-off by the edge of the screen, then that is really weird to watch: how can an object be hidden behind something that is further away? This is called a window violation. A design implication of this is that in a first person shooter, the gun cannot be in front of the monitor and thus cannot be really close to the player.
However, it is a lot of fun to have objects fly towards you. This looks so real, that as a player, you will want to duck to evade that coconut that is being thrown at you. So it is a good idea to put some of these effects in the game. Unfortunately, both Proun and Swords & Soldiers lack such effects, because I didn't have the time to add additional special effects just for 3D.
For pure realism, one could argue that the distance between the left and right eye in the game world should be the same as on a real person. However, as a programmer, you have control over this. Moving the virtual eyes further away from each other essentially makes the depth effect stronger. The stronger, the more spectacular, but making it too strong causes headaches.
A difficulty of 3D is that your eyes always focus on the screen, even though your brain thinks you are seeing objects that are behind the screen or in front of it. Because of this difference between your brain and your eyes, switching from where you are looking takes longer for stereo 3D than it does in the real world. Even worse: doing it a lot causes headaches, especially with certain people who are sensitive to this (like myself).
This is especially important to think about for the GUI. For example, in Swords & Soldiers, the healthbars are deliberately placed at the same distance as the soldiers. I would have liked to also position the map and the player's gold at this same distance, but because we also have foreground graphics, I had to place the interface in front of the foreground graphics.
A very cool effect in Swords & Soldiers is that because all the objects are themselves 2D, making the entire scene 3D means that all objects look like cardboard cut-outs. In a normal game that wouldn't be cool, but it works really well with the cartoony art style of Swords & Soldiers and looks awesome!
Finally, stereoscopic 3D means that certain cheap tricks cannot be used any more. Many games create rain by simple placing a rain texture on the screen, instead of having actual rain in the 3D world. With stereoscopic 3D, this trick becomes very obvious, so you need to somehow do better rain.
So, even though it is pretty easy to get 3D to work at all, it definitely takes some extra design work to make a game that works really well with stereoscopic 3D!
I won't bother you with the technical aspects and the weird camera math of stereoscopic 3D, since I think the implications of stereoscopic 3D for graphics are a lot more interesting and not as straightforward as one might think.
The first thing to realize is that you should really consider the monitor to be a window into another world. Things may come out from this world, through the monitor towards the player, but if this happens, then these objects should not be cut-off by the edges of the screen. If an object is behind the screen in the 3D space, then the viewer's brain easily accepts that it is partially behind the monitor's edge. However, if the object is in front of the screen, yet is cut-off by the edge of the screen, then that is really weird to watch: how can an object be hidden behind something that is further away? This is called a window violation. A design implication of this is that in a first person shooter, the gun cannot be in front of the monitor and thus cannot be really close to the player.
However, it is a lot of fun to have objects fly towards you. This looks so real, that as a player, you will want to duck to evade that coconut that is being thrown at you. So it is a good idea to put some of these effects in the game. Unfortunately, both Proun and Swords & Soldiers lack such effects, because I didn't have the time to add additional special effects just for 3D.
For pure realism, one could argue that the distance between the left and right eye in the game world should be the same as on a real person. However, as a programmer, you have control over this. Moving the virtual eyes further away from each other essentially makes the depth effect stronger. The stronger, the more spectacular, but making it too strong causes headaches.
A difficulty of 3D is that your eyes always focus on the screen, even though your brain thinks you are seeing objects that are behind the screen or in front of it. Because of this difference between your brain and your eyes, switching from where you are looking takes longer for stereo 3D than it does in the real world. Even worse: doing it a lot causes headaches, especially with certain people who are sensitive to this (like myself).
This is especially important to think about for the GUI. For example, in Swords & Soldiers, the healthbars are deliberately placed at the same distance as the soldiers. I would have liked to also position the map and the player's gold at this same distance, but because we also have foreground graphics, I had to place the interface in front of the foreground graphics.
A very cool effect in Swords & Soldiers is that because all the objects are themselves 2D, making the entire scene 3D means that all objects look like cardboard cut-outs. In a normal game that wouldn't be cool, but it works really well with the cartoony art style of Swords & Soldiers and looks awesome!
Finally, stereoscopic 3D means that certain cheap tricks cannot be used any more. Many games create rain by simple placing a rain texture on the screen, instead of having actual rain in the 3D world. With stereoscopic 3D, this trick becomes very obvious, so you need to somehow do better rain.
So, even though it is pretty easy to get 3D to work at all, it definitely takes some extra design work to make a game that works really well with stereoscopic 3D!