Shadow mapping

In the last tutorial of this series, I will try to explain how to create your own shadow mapping shaders. We’ve already seen the shadows of truevision3d, now it’s time to create our own system. This is by no means the best type of shadowing, it is just good to get an understanding of what is actually happening. The system we’ll make is for a point light. The basic idea behind it is to place 6 camera’s on the place of the light, each facing outwards, so you’ve got a complete view from the camera. This is a cubemap. We’ll render the depth of the object the camera sees to the cubemaps’ faces. This then allows us to do a lookup in the direction of the pixel we’re rendering, to see if the distance of the cubemap is lower than the real distance. If it is, we have a shadow.

What do we need?

- First of all we’ll need a cubemap rendersurface.

- We will also need 2 shaders to render with. 1 shader will just output the depth, the other will sample the depth and return the colors.

How do we set things up?

- The cubemap rendersurface is created like this:

The first parameter is the size of the render surface (per face, so in this case we have 6 256×256 pixel textures).
The second parameter enables the depth buffer, so an object behind another object can never be rendered on top.
Then there’s the format and the string identifier, which you’ve already seen before.

- Another thing to set up is the cube map properties:

In this case, we set the cube map to automatically generate the camera’s for us, so we don’t have to do all that math any more (first line, 1st parameter). The position of the camera’s will be (0,15,0).
The last line tells the render surface to use a camera with a field of view of 90 degrees, which means we’ll get full coverage.

How do we render this?

- First of all, lets render the scene to the depth cube map.

In this 6 iteration loop, the StartCubeRender function will setup the right cameras. Then the room is rendered and the cuberender for that face will stop. Keep in mind that before we do this, we have to make sure we have the room render its depth by calling:

- To render the room with the shadows on it, we set the shader to the lighting shader and render it:

- Now for some explanation of the shaders. The vertex shader of the depth shader:

You should be able to figure out what it does, but just to make sure; we calculate the vertex positions in world space, calculate the distance between the vertex and the light position, transform the vertex into the view projection space and forward the UV coordinates.

- The vertex shader of the depth shader just outputs the depth:

- The vertex shader of the lighting shader isn’t too fancy, it does about the same as the ones from this and the previous tutorial combined, so it will calculate depth as well. This depth is going to compare to the one of the cube map. This might look odd, it’s the same as before right? No, we’re in another camera now, so we see different vertices now, so there can be a difference.

- The pixel shader of the shadow shader is really complicated at first glance, but I’ll extract the important parts for this tutorial from it.

This is all there’s happening that’s important. The depth variable will contain a lookup from the cubemap. You can sample from a cubemap by supplying a direction vector that points from within the middle of the cube to the outside. It has to be normalized to have a correct result.
Now that we have this depth, we can compare it to the depth we calculated for the vertex. If there’s a difference, we need to subtract some light from the pixel. That’s done by the second line.
We can’t have negative light, so the final result will be saturated (clamped to 0 if below zero).
There is a lot more going on, but this is the most important part.

Things you can add/change yourself

- There’s not much to add here, Geoff Wilson did a great job writing these shaders, so they are pretty much complete. You can however add more objects and play around with the biases in the shader to get a feeling for them.

Heat haze

Everyone knows this phenomena, you can see it about the tarmac or even something as simple as a candle. A heat haze. What is happening in nature? The air above something that is hot is rising. There are pressure differences and that means the breaking index of the air is difference, in other words; the light rays bend a little. This effect is really cool to have in our scene as well, so we’ll do that. We will take the post-effect approach. What will we do? We will render the scene without the heat haze to a texture, then we’ll render the heat haze (being particles) on to another texture. Then we’ll combine it in a shader to draw it to the screen.

What do we need?

- As said, we need 2 render surfaces, one for the scene, one for the heat haze particles.

- We need a texture for the heat haze particles that will be used as a lookup UV offset for the sampling of the scene.

- The shader will once again be explained in the render section

How do we set things up?

- There is nothing you haven’t seen yet, so there’s nothing more to explain.

How do we render this?

- As described above, we render the scene to the first render surface and the heat haze to the second surface. You should be able to decipher that easily by now.

- The vertex shader is the same as in any other fullscreen shader, so I won’t explain that.
- The pixel shader is interesting, but not too hard to understand i think.

You can see there’s a distortion being loaded from the heat haze texture (DistortSampler). Then it’s subtracted from 1, to invert its colors.
Next our real sampling is being done. We can see we’re sampling from the scene texture (ScreenSampler), with UV coordinates that came in, plus the distortion. This will give the distorted heat haze look.
Now we just output the color and set the alpha to 1.
It’s as easy as that, no magic or trickery involved, just plain maths and computer science. It is of course not a physically correct effect, but it gives a decent impression. Of course it can be tweaked a lot, but that’s up to you.

Things you can add/change yourself

- Tweak the texture and parameters, offsets etc to get a better result, it is possible, just have a good look at some pictures of heat hazes. (google is your friend).

Per pixel object shader

We’ve seen an object shader already, but now we’re going to do something more interesting. In tutorial 4 (per pixel lighting), we’ve seen some per pixel lighting already. It would be good to try and replicate or even improve this effect. We are going to do this in this tutorial. Before you continue, make sure you at least have an idea of what tangent space and parallax mapping might be .

What do we need?

- Since we’re going to do parallax mapping as well as normal mapping, we’re going to have a special texture that will contain the tangentspace normal map in the rgb channels and the parallax map in the alpha channel. This way we can save some texture memory as well as bandwidth.

- We’ll need a fairly advanced shader. It will be explained a bit more in the render section of this tutorial.

- We’re going to have the depth of the bumping variable, so we need the input engine to allow input to happen.

How do we set things up?

- Let’s initialize the variables of the shader first, so it knows where the light is and how much it should bump.

The first line sends a Vector3 variable to the shader. It sets the values of the vector3 (which is a float array with a size of 3) to the “LPos” variable in the shader.
The second line sets the “BumpAmount” variable of the shader to fBumpAmount. fBumpAmount will be adjustable by pressing the ’1′ and ’2′ keys.

- We also set the lighting mode to tangent space to be able to use the tangent space coordinates in the shader:

We set the lightsamount to 0, so the engine won’t worry about lighting the cube.

How do we render this?

- Now for the shader. Let’s see what’s in the vertex shader:

First of all, the vertices are transformed to the right place. Then the UV coordinates are passed through.
The next 2 lines will transform the tangent, binormal (which is the perpendicular vector to the tangent and normal vector) and normal vectors to world space.
Then the position of the vertex is multiplied with the world matrix, to know where the vertex is in world space.
Then the light vector is calculated from its position minus the vertex position, multiplied by the (tangent, binormal, normal) matrix. This is to get the light direction in the right space.
Last of all the view vector is calculated, in the same way as the light vector.

- Now the pixel shader:

The first line normalizes the view vector to make sure it has a length of 1.
Then the UV offset is calculated from the parallax map (normal map alpha channel), of course multiplied with the bump amount. We will add the UV coordinates as well, so we have the right UV coordinates to sample from now.
Then the color is fetched from the texture.
Then the normal is fetched from its textures’ rgb channel. It also needs to be multiplied by 2 and decreased by 1 to allow negative normals as well.
Now we normalize the light vector to make sure it has a length of 1.
We now calculate the diffuse term, by calculating the dot product of the light and the normal vector. If you don’t know what this is about, have a look at this.
The last line multiplies the light intensity with the color, to make sure the model is correctly lit.

Things you can add/change yourself

- Try writing a phong shader, parallax shader, or whatever you want to try. Try to get things moving, you should follow some tutorials on HLSL or try to replicate some samples from developer.nvidia.com’s shader library.

HLSL Basic Post effects

Everyone will have seen black and white films/pictures, sepia pictures, pictures or movies with film grain etc. To get such an effect in the 3D world, we normally use a technique called post-effects. This means we apply some kind of filter after (post) rendering. This means we don’t have to do the effect on every object that’s hidden, we only apply the filter on the pixels that are actually visible. This can be really usefull and good, especially when adding some more calculation heavy stuff.

What do we need?

- Of course we will need a shader, just as in the previous tutorial.

- We also need to grab a picture of everything that just has been rendered. There are multiple ways of doing this, but right now we’ll use the easiest way of doing it: A render surface aka rendertarget. This is basically a texture that you can render to, when you tell it to be the texture to render to of course.

How do we set things up?

- We will create the render surface first. This is pretty much the same as creating a mesh, but there are some more parameters this time.

First of all there are the width and height of the texture. You can set those to the screen size, but a lot of older graphics cards can only do power of 2 textures. That’s why we chose to round up to that any way, so it’s 1024×1024.
The second thing is the format of the render surface. You can choose to not have an alpha channel or just a red channel, or anything else, based on what the enum contains. In this case we choose an A8R8G8B8 format, which means every channel (alpha, red, green blue) has 8 bits to store its information in. That means 256 possibilities per channel. This is pretty much the default format, except for HDR scenarios, which we will not cover now.
The last parameter is a string to name it, which is once again not recommended, you should just keep track of such things yourself.

- We also need to tell our shader that the texture to read from should be the render surface’ texture.

It’s as easy as that. The first parameter is the name of the variable in the shader, the second parameter is the ID to the texture.

How do we render this?

- The rendering is moved from within the TV.Clear() and TV.RenderToScreen() to another spot:

First we need to tell the render surface which camera we are using.
Then we’ll tell it to start rendering, clearing both the depth as well as the color buffer (if we’d set true, it would only clear the depth buffer and keep the color of the texture that was already there).
Now we render the cube and end rendering with the render surface. This is all fairly easy.

- Now we’ll somehow need to draw the shader fullscreen with the just rendered texture. To do this, we call:

The most important thing is the Draw_FullscreenQuadWithShader method. This method will draw the shader full screen (should be named full viewport actually).
The first parameter is the shader which the fullscreeen quad (or plane) should be rendered with.
The next 4 parameters are the texture coordinates of the fullscreen plane. In this case, we’ll use the complete texture.
The last 2 parameters are 2 optional texture channels. You could pass texture id’s with it, to supply the textures, but in this case we already did this ourselves.

- Now what does the shader look like?
The vertex program is the same as the one from the object, but we don’t transform it to viewspace, because the information will be passed on correctly by the Draw_FullscreenQuadWithShader:

The fragment program (or pixel shader) is not much different either:

Note that we’ve set the colour (tutorials were written by a brit ) alpha to 1, which means it will be 100% opaque.

Things you can add/change yourself

- Try to find a way to make a sepia or black white shader, it will help you understand HLSL and fullscreen drawing a bit more.

HLSL Basic object

Now for the more advanced TV3D tutorials. The next 6 tutorials will be about shader and how to work with them. I’m not going to explain all about shaders, there are a lot of good resources for that already. Take a look at this wiki page: wiki. In this first tutorial we’re going to create a simple shader that will just output the cube with a texture. This can be the template for any object shader you’re going to write.

What do we need?

- We need a TVShader object, that will tell the engine to render with our shader.

- We need the shader that we’re going to write. We will load that shader from a text file.

How do we set things up?

- First of all we’ll set up the TVShader object. It’s pretty much the same as loading a mesh:

- Now we’ll tell the mesh to render with this shader:

This is once again not hard to understand.

- Now for the more tricky part we’ll take a quick peek at the actual shader. I’m not going in depth on all of the instructions, but i’ll try to explain what it roughly does.

This is the vertex program. It will tell your graphics card what to do with every vertex that is passed to it. It is quite simple still, what is happening, is that the vertexposition (IN.PosOfVertex) is multiplied with the ViewProjection matrix. What this basicly means, is that the vertices are correctly placed on your screen. Then the UV coordinates are passed on to the pixel program. That is being done in that last line.

This is the pixel program. The instructions described here will be executed for every pixel the triangles fill. In this case, you can see that the Col variable (which is an array of four floats) is filled by a texture lookup from the DiffuseSample texture sampler, from position IN.UV. That IN.UV contains the UV coordinates we need to sample from. Then the graphics card is told that the output color should be the Col variable. That means that we will output the texture color for every pixel. What we should see, is the cube with a plain texture of the tv3d logo.

How do we render this?

- Rendering is not different from rendering without a shader, so we don’t have to change anything here.

Things you can add/change yourself

- Try to play with the vertex and pixel program. For example try to multiply the vertex position with a sinus of some value, or try to output a single color in the pixel program. If you’re looking for more shader tutorials, you should have a look at this page, as well as (if you’re more serious about developing shader) “Shaders for game programmers and artists” by Sebastien st Laurent.

Shadow volumes

There is a light phenomena that we haven’t discussed yet. It is seen everywhere around you. Shadows. You might think we’ve already covered this, since a cube doesn’t get light when it’s not facing the light, but that’s not what we’re going to do right now. What if a light shines on that cube and there’s something below the cube? That would cast a shadow. In Truevision3D, it is not too hard to add shadows. It’s actually quite easy. It doesn’t suit all purposes and doesn’t always look like the most high end shadow solution, but it’s decent and well worth looking at.

What do we need?

- We need some thing that can actually cast a shadow. This is solved by loading room model 2, this is a floor with 4 pillars that will cast a shadow, since we’re going to place the light in the middle of the pillars.

How do we set things up?

- It really comes down to just 2 steps. The first step:

This will tell the light engine that this light source is casting shadows. The first parameter is of course the ID of the light.
The second parameter will tell the engine it is a managed light. It is a leftover from previous builds of the engine. You should always have this on true now.
The third parameter enables or disables the shadow casting, so in this case, we want the light to be able to cast shadows.
The last parameter enables or disables the light from the lightmapping solution. This is not what we want, we want this to be a dynamic light, not a lightmapped light. More info about lightmapping can be found here: wiki.

- We now only need to tell the mesh that it can cast and receive shadows.

How easy is that? The first parameter will tell the engine to make this mesh cast shadows. The second parameter will tell it to either make the shadows additive or not. Additive means you can have shadows overlap and have them be darker if more than 1 light has a shadow there.

How do we render this?

- There’s not much to add when rendering, just need to tell the engine we want to draw the shadows last by calling:

Things you can add/change yourself

- Play around with the position of the light to see the shadows move, or place other objects in order to see the shadows change.

Billboard particles

How cool would it be to be able to render smoke? Or fire? Everyone will need some kind of particle system eventually. In this case we will make some nice smoke. You might ask yourself what a particle system is. If you wonder about that, take a look at this wiki page. In this case, we are using a billboard particle system. A billboard is like a camera oriented plane. It will always face the camera. This makes it easier to create the textures to place on it. The particle system will spawn some billboards, apply textures on them and move them around based on some rules you can set, like gravity.

What do we need?

- First of all we need a smoke texture, which is not too hard to come by.

- Secondly, we need the particle system of TV, which is called TVParticleSystem.

How do we set things up?

- We load the texture of the smoke, you’ve seen this before.
- We create the particle system in the same way you create a mesh or actor. That is not hard to grasp, you’ve seen that before, the only thing that has changed is the function. We now call:

- The particle system will need to have an emitter to emit particles from. These are referenced by their ID, just like textures. We can create one by calling:

This creates a billboard emitter with a maximum of 1600 particles.

- Now we will set some properties to the emitter:

The first line sets the power and lifetime of the particles of the emitter. The power is 15, the lifetime is 5 in this case.
The second line will set the position of the emitter, that’s not too hard to see.
The third line will tell the engine the emitter is spherical shaped. You can’t really see it, but it determines the position of the particles when they spawn.
The last line will set what texture should be placed on the billboard and its size. In this case the size of the billboard will be 12 by 12 units.

- Now we need to set some more advanced stuff:

The SetEmitterDirection function is fairly straightforward, but worth explaining, you can get cool effects with it if you know how to use it. The first parameter is of course the emitter ID. The second is a boolean to tell if there should be a main direction. The third parameter is the main direction. It tells in which direction the particles should initially move. The last parameter is the random direction factor. If you supply 1,1,1, it will be random in all directions, if you supply the values we supplied, it will only be random a bit in the x and z axis.
The SetParticleDefaultColor function tells what kind of material color there is for the billboards. In our case just plain white.
The SetEmitterGravity function tells the engine in what direction there should be gravity. In our case it’s downward with a strength of 10.

- Just to answer one of the questions you might have, you don’t have to create any billboards or particles yourself, the particle system will do that for you.

How do we render this?

- Before rendering, we need to call

to update the particle system. This will emit new particles, remove them, move them etc.

- To render the particles, we call

Things you can add/change yourself

- Try playing with all of these functions. Try to make nice shapes, big explosions, anything you want.

- Change the billboard texture to some fiery thing or some other random texture. Try to create a fire, waterfall, or any thing you want, because particle systems are just plain fun!

Simple input

We already know a lot about the engine, we know how to load geometry, render it, create some 2D graphics. There is however a very important thing we didn’t do yet. What is a game without input? It’s not really a game right? Well, that’s why this tutorial is there. We’ll make sure we can rotate the camera around a cube, so we can view other areas of the scene we’re in.

What do we need?

- First of all we need the input engine of truevision3d. It provides us with an easy interface to the keyboard.

- We need to rotate around the cube, so we need to do some 3D math. This can be made easy by TV’s math library.

How do we set things up?

- First of all we initialize the inputengine and the math library. We do it this way:

The initialize function of the input engine has 2 boolean parameters, the first for enabling or disabling the keyboard, the second one for the mouse. We’ll not use the mouse in this tutorial, but we’ll enable it nonetheless.

- We set the angle system of truevision to degrees instead of radians. We do this because it’s just easier to grasp.

That’s just everything we need to do to initialize the inputengine and make sure you can read the keyboard state.

How do we render this?

- The title is a little weird here, you don’t render input, but whatever, for consistence i chose this title any way, since it happens in the main loop. We will keep the rotation around the cube as a floating point number, to be able to smoothly rotate around it. If ‘a’ is pressed, we rotate to the left, if ‘d’ is pressed, we rotate to the right. This is done by the following calls:

You can see that there’s a boolean returning function called IsKeyPressed. You tell it which key you want to know is pressed. There’s an enum called CONST_TV_KEY, that contains all of the keys you can choose from.

- The last step is updating the camera to reflect the changes we made to the horizontal angle. We do it by the following call:

The first function is the MoveAroudnPoint function. It takes a couple arguments. The first one is a vector which is the point to rotate around. The last three are the radius, horizontal and vertical rotation. We rotate horizontally with fHoriz degrees and keep a distance (radius) of 20.
The second function sets the camera to the new position by the first 3 parameters. The last 3 are the lookat point. This determines where the camera is actually looking at. It’s looking at the 0,0,0 point, which is the center of the cube. What we just did, is calculate a new position for the camera and make it look back at the cube.

Things you can add yourself

- You can try to make the camera rotate around the x axis as well, to make sure you can go around it all the way.

Simple 2D

In this tutorial, we’re going to render some 2D stuff. We will draw a rectangle and a 2D image. This can be really usefull when you’re going to make a menu for your game or application.

What do we need?

- We need a 2D image, which will be the truevision3d logo, ripped of the website.

- We need some way to draw 2D textures, which is the TVScreen2DImmediate.

How do we set things up?

- We just create the TVScreen2DImmediate by its constructor.

- We load the texture by calling:

You’ve seen this before, so I won’t explain it again.

How do we render this?

- Just like with the text rendering, we will use a begin/end block.

You can see it is a little different, but it works the same as with the text.

- To draw the texture, we’ll call:

The first argument is of course the ID of the texture we want to draw.
The second and third argument are the start position on the screen (in pixels).
The fourth and fifth argument are the end position of the texture on the screen (once again in pixels).
The next 4 arguments are the colors of the vertices at the corners. If you set them, you can make cool gradients that multiply with the texture. If you supply -1, it will be no color, so white. If you supply -2 as the last 3, it will use the same color as color1.
The last 4 arguments are the texture coordinates on the texture. 0,0 is the top left corner, 1,1 is the bottom right corner, so we draw the whole texture.

- To draw the blue rectangle, we call the following method:

It will draw the box from the middle – 128 pixels to the middle + 128 pixels. That’s the first 4 parameters.
The next 4 arguments are the colors of the vertices on the corners. The last 3 are just -2 because it’s easier, you tell the engine that it needs to pick the color that has already been supplied for the first vertex, which means it will be blue.

- Of course we need to render the text after the rectangle, since it needs to go on top of the rectangle.

Things you can add/change yourself

- It would be a good idea to experiment with loading other textures and drawing them somewhere on the screen.

- Experiment with the color of the corners of the rectangle to know what’s happening if you’d change it on the texture as well. Especially changing the alpha value is usefull when you want a texture to fade out. Another possibility would of course be to put an alpha channel in the texture, but that will take a little more memory.

Simple text

In this tutorial we’ll explain how to render text to the screen. This can be usefull to display debug information, but also to make a menu or console. What we’re going to try to do is render the all famous “hello world!” to our Truevision3D screen. For this, we created an all clean project again, to get rid of everything we’ve used so far, except for the TVEngine object.

What do we need?

- We need to tell DirectX that we want to draw text. You can do so by creating a texturefont. This can be done in the TVScreen2DText object.

How do we set this up?

- We need a TVScreen2DText object. This can be created in a normal way, you just create an instance of it, like you would with the tvengine.

- To create the texturefont, we call the following function:

This is not too hard to grasp. It creates an object with the name “our_font_name_string”, of the font called Times New Roman, with a 24pt size. The next couple of booleans are for: Bold, Underline, Italic, International and Clear Type Anti-Aliasing. The clear type anti-aliasing will provide us with more readable text. That’s basicly all there is to creating the texturefont.

How do we render this?

- To optimize the DirectX states (see: link) we can use:

to define the beginning and end of the texture rendering.

- To make sure the text is in the middle of the screen, we need to know the height and width of the text. We can do that by calling:

It will put the result in W and H because they are references.
- Now we can draw the text by calling:

The parameters are: Text, x position, y position, int color and the texturefont id.

Things you can add/change yourself

- Play around a bit with the text, color, font etc. It’s not that exciting, but maybe you will find out things you didn’t know yet.