#define Bassser

Technique:

Draw every object with unique color ID

Get the pixel @mouse position

Object = objectList[id]

Pros:

Very fast

Pixel Perfect

Cons:

Only for single select, with a multi-select, objects behind other objects won’t be selected

OpenGL Implementation

We need to define a new FBO with a color texture and a depth renderbuffer

When there is a mouse click (or whenever you want to pick), draw all your objects with a flat color shader. The color will be defined as follows:

Get a unique ID for all of your objects (for example the vector index)

We represent the id, an unsigned int, as four separate bytes (r, g, b, a)

//mask byte in uint id, shift byte to front color.r = ((gl_InstanceID & (0xff << 0)) >> 0) / 255.0f; color.g = ((gl_InstanceID & (0xff << 8)) >> 8) / 255.0f; color.b = ((gl_InstanceID & (0xff << 16)) >> 16) / 255.0f; color.a = ((gl_InstanceID & (0xff << 24)) >> 24) / 255.0f;

After everything is drawn…

The real picking: pick a pixel

byte packedID[4]; glReadPixels(mousePos.x, mousePos.y 1, 1, GL_BGRA, GL_UNSIGNED_BYTE, &packedID);

Unpacking goes like this

uint id(0); id |= ((uint)packedID[0]) << 0; id |= ((uint)packedID[1]) << 8; id |= ((uint)packedID[2]) << 16; id |= ((uint)packedID[3]) << 24;

And voila: picked object == m_DrawList[id]

Problems:

Instancing

Solution:

Use gl_InstanceID! Color converting has to happen in the vertex shader:

uniform uint inID; vec4 color ; uint id = id + gl_InstanceID; color.r = ((id & (0xff << 0)) >> 0) / 255.0f; color.g = ((id & (0xff << 8)) >> 8) / 255.0f; color.b = ((id & (0xff << 16)) >> 16) / 255.0f; color.a = ((id & (0xff << 24)) >> 24) / 255.0f;

In code you’ll have to catch this and add id+=numInstances

When you try to get the object from id, you’ll need to do a lookup.

A not so efficient implementation of the lookup, but more than enough because the picking is rarely executed:

Why

We have a big presision problem for shadows with directional lights. Directional lights have no range. Then how do you define the shadowmap?

There is no problem for spotlights or pointlights they have a range!

Thus to make sure we have shadows where we want them, we take the range so that our whole camera frustum is inside it.

As you can see, we need to define a very big region for a directional light! Even a 2048*2048 can't give good results.

Solution: Cascaded Shadows = multiple shadowmaps for one light One 2048*2048 == 4 * 1024*1024!

Here we have 4 shadowmaps. Each defining a part of the viewfrusum. The farther we look the more unpresise it gets, but that's less of a problem because it is far away.

Here is a false color picture of how it looks ingame Pink = first shadowmap Green = second Blue = third Lightblue = fourth

  How

Calculate shadow view matrix form a direction

Divide camera frustum in n-parts (4 is a good number)

Calculate shadow projection matrix for each part

Calculate new frustum

Transform new frustum in shadow view space

Find min and max

Create orthographic projection matrix

Render all objects in cascade view for every cascade to a shadowmap

Render the final image using the n-shadowmaps

Implementation

1. Shadow View Matrix

This matrix is the same for every cascade

Get the shadow look vector, make sure it is normalized and points away from the lightsource

vec3 shadowLook(-normalize(pDirectionalLight->getDirection()));

Calculate the up vector for the light:

Take a random up vector

The up has to be perpendicular to the look vector => dot product must be 0, if the dot product == 1 then the vectors are parallel to each other

Now to get the up vector perpendicular to the look vector we first have to calculate the right vector, we do this with a cross product. If you crossproduct two vectors, you get a vector which is perpendicular to the other two. Bad things happen when you supply two vectors which are parellel to each other.

By now crossproducting the look and the right vector we get the up vector!

vec3 up(vec3::up); if (dot(up, shadowLook) > 0.99f) up = vec3::forward; vec3 right(normalize(cross(shadowLook, up))); up = normalize(cross(shadowLook, right));

Now we create the view matrix like this (position, lookat, up)

mat44 mtxShadowView(mat44::createLookAtLH(pCamera->getPosition() - shadowLook, pCamera->getPosition(), up));

2. Divide camera frustum

We take four parts between the near and far plane of the view frustum. You have to tweak this! It got decent results by taking  fixed points, but you could also make everything relative to the camera.

Cascade near far 1. camera near 25 2. 25 50 3. 50 100 4. 100 camera far

3. Shadow Projection matrix

What do we need:

mat44 getProjection(const Camera* pCamera, const mat44& mtxShadowView, float nearClip, float farClip);

Clear enough on with the calculation

Calculate new frustum

We need all the 8 points. This picture will explain how we calculate them:

Or not.

The camera is the view camera. Our goal is finding w/2 and h/2

By adding the lookVector * Far to the camera position we get the center point of (P5, P6, P7, P8) In topview we can easily calculate w/2 with a tan!

tan(FOV/2) = W/2  /  Far <=> W/2 = tan(FOV/2) * Far

Now we need H/2 this looks hard, but it is much easier:

H/2 = W/2 / aspectRatio

We do the same for the nearplane and then we compose them to from the 8 points of the frustum

float wFar = farClip * tan(pCamera->getFov()), //half width //fov in pCamera is actually Fov/2 hFar = wFar / pCamera->getAspectRatio(); //half height float wNear = nearClip * tan(pCamera->getFov()), //half width hNear = wNear / pCamera->getAspectRatio(); //half height std::vector frustumPoints; frustumPoints.reserve(8); //Far plane frustumPoints.push_back(pCamera->getLook() * farClip + pCamera->getUp() * hFar - pCamera->getRight() * wFar); frustumPoints.push_back(pCamera->getLook() * farClip + pCamera->getUp() * hFar + pCamera->getRight() * wFar); frustumPoints.push_back(pCamera->getLook() * farClip - pCamera->getUp() * hFar - pCamera->getRight() * wFar); frustumPoints.push_back(pCamera->getLook() * farClip - pCamera->getUp() * hFar + pCamera->getRight() * wFar); //Near plane frustumPoints.push_back(pCamera->getLook() * nearClip + pCamera->getUp() * hNear - pCamera->getRight() * wNear); frustumPoints.push_back(pCamera->getLook() * nearClip + pCamera->getUp() * hNear + pCamera->getRight() * wNear); frustumPoints.push_back(pCamera->getLook() * nearClip - pCamera->getUp() * hNear - pCamera->getRight() * wNear); frustumPoints.push_back(pCamera->getLook() * nearClip - pCamera->getUp() * hNear + pCamera->getRight() * wNear);

4. Min/Max

To calculate the projection rectangle

vec3 minP(mtxShadowView * pCamera->getPosition()), maxP(mtxShadowView * pCamera->getPosition()); std::for_each(frustumPoints.cbegin(), frustumPoints.cend(), [&](const vec3& point) { vec3 p(mtxShadowView * (point + pCamera->getPosition())); minP = minPerComponent(minP, p); maxP = maxPerComponent(maxP, p); });

5. Ortho Matrix

mat44::createOrthoLH(minP.x, maxP.x, maxP.y, minP.y, min(minP.z, 10), maxP.z);

6. Shader

GLSL 150 core

Why

Storing a position in a buffer needs a lot of space! We need 32bits per channel (RGBA32F), which is a 128byte buffer, and that is too much. Low and even mid end gpu's don't even handle these formats very well and it goes horribly slow. That's why we will use the depth buffer (which is generated anyways).

Steps

Position is calculated in view space, because we actually don't need to go back to world space

Sample depth buffer

Unproject depth buffer value to find position.z

Unproject the nDc position to find position.xy

Implementation

Al code listed will be GLSL core 150 (GL3.2) and C++

Encoding

We do not need to encode anything because the depth buffer is generated automatically!

Decoding

Here is where the fun starts.

Step 1: Sampling the depth buffer

This should be easy, but for completeness: C++

//Generate texture to store depth in glGenTextures(1, m_DepthTextureID); glBindTexture(GL_TEXTURE_2D, m_DepthTextureID); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT32F, width, height, 0,GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, 0); //Attach to your framebuffer glBindFramebuffer(GL_FRAMEBUFFER, m_FboID); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, m_DepthTextureID, 0);

pass m_DepthTextureID as Sampler2D to the shader GLSL 150 core:

uniform sampler2D depthMap; uniform vec2 texCoord; void main() { float depth = texture2D(depthMap, texCoord).x }

Step 2: Unprojecting

I will give the code first and then explain what I do GLSL:

vec3 reconstructPosition(in float p_depth, in vec2 p_ndc, in vec4 p_projParams) { float depth = p_depth * 2.0f - 1.0f; float viewDepth = p_projParams.w / (depth - p_projParams.z); return vec3((p_ndc * viewDepth) / p_projParams.xy, viewDepth); }

C++

p_projParams = vec4((m_pCamera->getProjectionMatrix()(0, 0), m_pCamera->getProjectionMatrix()(1, 1), m_pCamera->getProjectionMatrix()(2, 2), m_pCamera->getProjectionMatrix()(2, 3));

p_projParams are the projection parameters out of the projection matrix.

Every vertex in the vertex shader gets multiplied by a World View Projection matrix:

1. Transform vertex in worldspace. 2. Transform vertex in viewspace. 3. Transform vertex in screenspace. When we go to the fragment shader the position is devided by the .w component. Now we have nDC (normalized device coordinates)

nDC ranging from -1 to 1, where .z is our depth component and .xy our 2D position on the screen. The trick: we want to go back in viewspace, thus we do the inverse of 4. and 3.! sidenote: openGL stores the depth default from 0 to 1, so we need to bring this in calculation as well We will do this inverting in one go. Finding The formula:

* Simplify projection matrix with A, B, C, D * Multiply matrix with view-position (x, y, z, 1) * Divide by .w * nDc position = ( A*x / z, B*y / z, C + D/z, 1) --(x, y, z) in viewspace * Now we calculate z in viewspace * The depth stored in the depth buffer == nDc.z * 0.5f + 1.0f * View z = D / (nDc.z - C) --nDc.z being sampeled depth * 2.0f - 1.0f * We can now calculate view xy * view x = (nDC.x * view z) / A * view y = (nDC.y * view z) / B

The Math: (whiteboard action)

Conclusion

The depth is reconstructed with this function in the shader

vec3 reconstructPosition(in float p_depth, in vec2 p_ndc, in vec4 p_projParams) { float depth = p_depth * 2.0f - 1.0f; float viewDepth = p_projParams.w / (depth - p_projParams.z); return vec3((p_ndc * viewDepth) / p_projParams.xy, viewDepth); }

p_depth = the sampled depth buffer p_ndc = the nDC position of the current pixel (texCoord.xy * 2.0f - 1.0f) p_projParams = vec4(A, B, C, D); (from c++)

p_projParams = vec4((m_pCamera->getProjectionMatrix()(0, 0), m_pCamera->getProjectionMatrix()(1, 1), m_pCamera->getProjectionMatrix()(2, 2), m_pCamera->getProjectionMatrix()(2, 3));

About

Ev0lut!0n is a game made in C# + XNA to participate in Microsoft's ImagineCup.

In this game you rule over a new civilization. Assign and manage your people's jobs and watch your city grow and Evolve!

Do research to make your workers more efficient but be aware it could have negative effects on the climate! This could introduce disasters. Possible disasters are: earthquakes, floods and diseases.

There are all kinds of jobs you can give your people, some are available from the start others only when you have certain buildings. Jobs include lumberjack, water carrier, fisher, miner, farmer and researcher

You win the game when you achieve a given goal. This could be: collect 200 wood and a population count of 300.

My Work:

I implemented the pathfinding (A*), the automatic city-building, camera movement, and all the graphics programming (shaders, skybox, ...)

Credits:

Engine Programmer: Bastian Damman Gameplay Programmer: Joke van Oijen Gameplay Programmer: Clair Bellens Art: Laurens Toering

About:

The Blueprint is a game prototype made in Unity.

It was a school assignment for DAE in December 2010

The game plays like a '2D Rubik's Cube' and you have to steal all the blueprints (yes you're a thief). Some blueprints are easy to get, other will be blocked by water, big ice cubes, ... There are also rooms you do not want to enter. Like a room with robo-dogs or security camera's.

My Work

I did most of the programming: movement of the rooms, water flow, doors opening/closing, blocking elements and dangerous elements.

Credits:

Lead Programmer: Bastian Damman Programmer: Maarten De Nef Art: Geert De Cnodder Art: Pieter De Bie Art: Laurens Toering

About:

Virtual Conflict is a side scrolling 3D shooter made in the CryEngine3. It was a school assignment in our second year at Digital Arts and Entertainment in Belgium. It was made in roughly five weeks (with concept and learning the engine included).

My Work:

I did all the programming. This includes: letting the camera follow the player sideways, restricting the walking to only two directions, picking up coins, particles, weapons, enemies + AI and win/lose conditions

Credits:

Programming: Bastian Damman Level Design: Robin Lesage Char rig/skin: Anne Mergaerts Extra Props: Tom De Vis

Why

We can do a lot of lights

Scene complexity is completely decoupled form lighting

Post processing is easier because we already have the normal, position and depth of every pixel

We can do even more lights

Problems

Alpha blending is not 'out of the box' possible

Heavy on memory

Heavy on fill rate (#pixels a graphics card can render per second)

No MSAA

How

First we render all geometry to +-three buffers. Then we use these buffers to draw the final lit image. A quick way to implement this is to draw a full-screen quad for every light, but this is not very efficient: it kills the fillrate. A better approach would be by using light volumes, or screen aligned quads (early depth-test !)

My first implementation used 3 g-buffers filled in like this:

color/Illumination buffer: GL_RGBA8

position/spec buffer: GL_RGBA32F

normal/gloss buffer: GL_RGBA16F

Which is a total buffer size of 32 + 128 + 64 = 224 bytes! And that is too big. It goes sloooooow. (high memory usage)

My current g-buffer layout:

color/Illumination buffer: GL_RGBA8

normal buffer: GL_RG16F

spec/gloss buffer: GL_RGBA8

32 + 32 + 32 = only 96 bytes! As you can see no position buffer and no z-component for the normal buffer. We even have 16bytes of unused space, but this could be useful later on. (motion vector, extra material properties, ...)

The position will be reconstructed from the depth buffer and is explained in detail here: http://bassser.tumblr.com/post/11626074256/reconstructing-position-from-depth-buffer

This started out as an assignment for school. The goal was to make something with C++, DirectX 10 and nVidia PhysX. Me and my colleague Sebastiaan Sprengers made a game engine called "Happy Engine". We kept working on the project even after the assignment was due. Now we are working on Happy Engine version 2, a completely overhauled version of the first one. We started from scratch and are now using OpenGL 3.2 and nVidia PhysX 3.

Highlights

Deferred rendering

3D & 2D

Shadow mapping

Screen space ambient occlusion (SSAO)

Component based entity system

Multithreaded physics

Cross platform (windows, mac, linux)

Open Source (http://code.google.com/p/happy-engine/)

We are still working on this game engine and it is not yet finished.

Software used: Visual Studio 2010, Codeblocks

Implemented Features

Deferred rendering (pointlights, spotlights, directional lights)

2D Renderer, draw text, rectangles, circles, textures, ...

HDR

Bloom

Cascaded shadow mapping

Console + binding of variables

PhysX objects

Car physics

Basic Networking

Feature Video

Development shots

Rayman Gold, a game I was never able to finish.

Few years ago I had totally forgotten about this game! I put the CD in, installed it - no problem - but then it all went wrong. The game didn't work anymore. I tried dosBox but it wasn't perfect.

Luckily in my first year of DAE, we got the assignment to remake an old game. I chose Rayman! We had about four months to finish it. It was my first year c++ so everything went a bit slow, especially because I had to rip all the sprites and animations myself. 

I managed to finish one level!

Rayman can jump, duck, hang, climb, charge and throw his fist, drown and die. There are also three enemies: the running anitoon, the biting anitoon and the piranha The goal is to collect all the blue 'things'.

Behind the scenes:

Collisions are done with small 8*8px AABB's These AABB are defined in a level file, which is actually ASCII art where every char stands for a specific item: 

for example: - 's' is a complete solid block - 'w' is a water block - 'B' is a thing - 't' is a running anitoon - ...

This is what it looks like in debug mode:  

Hello my name is Bastian Damman and i am currently studying Digital Arts and Entertainment at Howest, Kortrijk in Belgium. http://www.digitalartsandentertainment.be

It's a course to become a technical artist.  Technical artist? 

It means I can make a video game totally on my own. I can program and make the artwork for it.

I just started my third and final year.

My first year was a real pain if you look at the workload. Everything was new and cost a lot of time to do, but then again I liked what I was doing. We learned about perspective drawing, digital painting, 3D modeling with 3ds max and c++ (where we made our first game! A remake of an old game. This is mine: http://bassser.tumblr.com/post/10780067662/rayman-gold).

Let's be honest: I'm not that good of an artist but I'm one hell of a programmer.

Luckily for me we had to choose a major in or second year: 3D arts or game development. I chose game dev. In this year we really started focusing on making games. We worked together with the 3D arts major. We did the programming and they did the art (at least when they'd understood what lowpoly is...).

Our first project was in the cryEngine3! It was really cool, we where one of the first to use this engine. Then we noticed it wasn't documented and it crashed every 5 minutes. Anyway this is what we made http://bassser.tumblr.com/post/11608930678/virtual-conflict

Next up: Unity! Great engine, well documented and easy to script in. BUT IT DOESN'T WORK WITH SVN. We couldn't use the build in version control since we didn't had Pro. So great engine if you work alone.  (it's a 2D Rubik's Cube kind of game)

Next we participated in Microsoft' s imaginecup (c# and XNA). We didn't win tho. http://bassser.tumblr.com/post/11610414460/ev0lut-0n