Saturday, July 30, 2011


Time for a little vacation in Berlin with my fellow beer-buddies. Wurst, Bier, Heidi und Schlager. What does a men need more? But before we can become “Berliners”, first a little-big story about portal-culling.
*1. What is portal-culling?
*2. Recursive function to get visible sectors
*3. Checking if portals are in your view with a 2D overlap check
*4. View-frustum narrowing
*5. Optimizing with Scissoring
*6. Portals that are partially in front, partially behind the camera
*7. Preventing infinite loops

1. I see what you don't see
The best part about programming is doing the stuff you like, with quick results. Adding the last straws on the other hand... Don't know about you, but in my case it often leads to 90% finished parts. The other 10% is... well, for another day.

Of course, with limited time you can't fine-tune everything till perfection. At the time it's perfect, it's probably also outdated, in this insane fast evolving software world. But sometimes you forget about important missing parts. Now that all Radar Station maps are imported, I noticed a relative low framerate on my laptop (~20 to 24 FPS). Now my laptop isn't the fastest anymore, but suddenly I remembered I didn't finish the portal-culling engine... This particular map has quite a lot of rooms and walls between them, resulting in a lot of overdraw.

For those unfamiliar with (portal)culling, or rendering performance in general, this technique helps preventing stuff from getting rendered for nothing. Unless you are spying or wearing X-Ray goggles, "rendering" the interior of your neighbor’s house is useless, cause you can't see it anyway. Walls and stuff. If we don't cull, invisible parts of the map will be called for nothing, and pixels will be drawn on the screen, and then get overdrawn by something else in front = a waste of time. In an ideal 3D world, each pixel will be drawn only once (asides overlapping pixels with alpha blending enabled).

A deferred-rendering engine already helps reducing the lighting complexity, but when rendering the contents for your deferred pipeline (data textures), shadow/depth Maps or other passes, you still want to exclude rooms you can't see. Or how about rooms you can only see partially? Behind a door or window, there could be st.Paul’s Cathedral. Yet you only see the bits behind the opened doors/windows ("portals").

With portal-culling, you divide your world into rooms, hallways, terrain chunks, or as I would like to call them: “Sectors”. The openings between them (open space, doors, windows, holes, ...) are called "Portals". In a perfect definition of a sector, for each corner(vertex) of a “room”, you can see all other corners of the same room without obstacles between them. But you can cheat a bit of course. Since rendering works best with bigger batches of data, try to prevent ending up with hundreds of tiny sectors. Because you will render sector by sector.

2. Portal Culling recursive function
Before you render your scene, you first have to determine what sectors are visible for the camera. Making such a list isn't that difficult, but it has some tricky (math) catches. Don't worry, my math doesn't go much further than counting potatoes, yet it succeeded. Here a pic, and some pseudo code:

// Make a list of visible sectors
1- Start in the sector your camera(player) is standing. Add to the list
2- FOR EACH portal IN currentSector.portalList
......3- Check if the portal(quad?) is inside/intersecting the camera view-frustum
............4- Add the sector behind the portal to the list, IF not done before.
............ Be aware that the same sector can be visible through multiple portals.
............5- For each sector, manage a list of portals that made it visible. Add ............ this portal to the sectors list.
............6- repeat step 2 for the sector behind the portal

Now when you go rendering your world, just loop through that sector-list. Eventually do it backwards to help with the depth-sorting for alpha-blended/transparent surfaces. The furthest sectors will be rendered first, your current sector last. Oh, and did I mention this "visible sector list" is also handy for other stuff like updating lamps, A.I., and vegetarian cooking? Having a list of visible sectors helps you to exclude unnecessary checks.

Now that's easy, just a recursive function, some looping, little list... done. But wait, as said, there are some catches. Circular references may occur, and how the hell do you know whether a portal is (partially) visible or not? If you are like me, you Googled "triangle sphere collision" and the likes quite some times. But "portal(or quad) versus frustum test" didn't gave me a lot useful results. Mostly you'll need combinations of functions, as collision-test routines are often incomplete. In case your portals are quads, they can be fully inside your camera frustum, intersect it, or completely overlap it (when standing nearby a big portal).

And that's where I didn't finish the code. Just made a cheap check to make sure portals would be visible. But due the margins, invisible sectors still became visible according to the checks. Time for a revision.

3. 3D to 2D
Checking if 3D stuff collides, intersects or overlaps isn't so easy. Narrowing the view-frustum when it travels through a portal neither. Checking if 2D rectangles overlap on the other hand... So why not do the math in 2D? It still has a few flaws, but at least it's an easy way. And a solution that actually works is also worth something right?

So, instead of doing 3D math, we convert the view-frustum and portals to simple 2D rectangles first. Initially, your view covers the entire screen, which means it’s rectangle would have the following coordinates: {-1,-1,+1,+1}. Where -1 is the left or top of the screen, 0,0 the center, and +1 the right or bottom. This conversion still requires a little bit matrix-math though. There are multiple ways to convert a 3D point to 2D, but what I did is using the camera ModelViewProjection (MVP) matrix. Wha? The same matrix you use in vertex shaders to convert 3D points to projection space(ehm... am I saying that right)? You can get this matrix in OpenGL as follow:

// 1. First, make sure your camera is set. For example:
glutLookat( ... ); // Point the camera at a target somewhere
gluPerspective( ratio, fov, near, far );

// 2. Now buy your matrices for only 99 cents
glGetFloatv( GL_MODELVIEW_MATRIX , @modelViewMatrix );
glGetFloatv(GL_PROJECTION_MATRIX , @projectionMatrix );
// Construct the MVP (matrix x matrix)
MVP := matrixMultiply( modelViewMatrix, projectionMatrix );

// 3. Convert a 3D point to 2D with the MVP (matrix * vector)
p2D.xyzw = vectorTransform( MVP, worldPos3D );
p2D.x := p2D.x / p2D.z;
p2D.y := p2D.y / p2D.z;

With this MVP matrix, you can convert 3D points to 2D space, in the range[-1..+1]. If you like, you can multiply further with the screen-resolution to get real screen pixel coordinates, but we don't need that here. Oh, AND your 2D point should also carry a Z. You can use the Z to check whether a point is in front or behind the camera-view frustum.

Testing, testing

PointInsideViewFrustum := (p2D.x >= -1) and (p2D.x <= +1) and
(p2D.y >= -1) and (p2D.y <= +1) and
(p2D.z >= 0);

The -1, +1 are the screen bounds, the Z tells if a point is in front or not. That's how you can check a single point. But, Portals aren't just points right? Portals can be seen as quad (since doors and windows are rectangular). But if you really like, you could also make complex shapes such as... circles, or... kangaroos.

What I do is simplifying the calculation by making simple rectangles out of whatever shape you want to check. First of all, your own view-frustum happens to be a rect; the entire screen. But hold on, your frustum may get narrowed as it passes through portals! (See Scissor chapter below). Next is the portal. Simply loop through all its (vertex) points, convert each one to 2D, and determine the most left/right/top/bottom ones. That makes a rectangle, or 2D “bounding box”.

Sure, rectangles fill more space than, say, a circle. So your portal might become visible even when you can't really look through it yet. But who needs complex portals anyway. Quads, or sets of quads, will do in almost any situation, and keeps the amount of point conversions limited. Asides, it’s wise to have some margin anyway. On top, the usage of rectangles gives an extremely nice bonus-track... but more about that later. Let's show how to do the overlap-check first:

rect1 := viewFrustumRect; // "screen"
rect2 := portalRect;
overlap := (rect1.left < rect2.right) and (rect.right > rect2.left) and
(rect1.bottom < and ( > rect2.bottom);

Still alive? Bon, because you're almost through the math-part. There is still one nasty bug at this point though, don't raise the flags yet.

* Always expand your portal 2D bounds a little bit to prevent leaky edges.

4. Portal Narrow
We know how to determine whether a portal is visible or not now. But usually a portal is a lot smaller than the sector behind it. Imagine you have a wall with a little Alice-in-Wonderland hole. Although you can fade-out and block the portal after a few meters (use this trick to keep distant sectors hidden), you will still have to render the entire sector behind that hole at some point. And how about the portals in that background sector? Maybe you can't even see them, yet they are in the view-

This was one of the reasons why the Radar Station maps went slower and slower. Pretty much all rooms had an opening to another sector somewhere, so at some camera angles, the entire map would be rendered. While you only saw ~35% of it. A waste of precious horsepower.

What we should do, is "narrowing" the view frustum after each portal. That sounds like awful 3D vector math, and, it is. But wait, we worked with 2D rects right? Narrowing the view-frustum is just as easy as using an AND-operator on 2 rects. Well, that still sounds difficult. Look:

narrowFrustum.left := max( previousFrustum.left, portalBounds2D.left );
narrowFrustum.right := min( previousFrustum.right, portalBounds2D.right );
narrowFrustum.bottom := max( previousFrustum.bottom, portalBounds2D.bottom ); := min(, );

Just adapt to the portal rect. That's it. In the recursive "PortalCulling" function, narrow the frustum each time it passes through a portal. And don't forget your view might enter the same sector via multiple portals, resulting in different results.

5. Scissor sisters
Narrowing the view prevents portals that are in the view, but occluded by foreground geometry to be evaluated. But it still doesn't fix the huge overdraw when rendering a gigantic sector behind a tiny portal. Call in the Scissor Sisters.

Yet another great feature of 2D rectangles, is... 2D rectangles. In OpenGL, you can tell where to draw by giving up a rectangle, and enabling "scissor testing". Pixels inside the rect will be drawn, others outside will go to the pixel hell.

glScissor( portalBounds2D.left, portalBounds2D.bottom, portalBounds2D.width, portalBounds2D.height );
glEnable( GL_SCISSOR_TEST );

glDisable( GL_SCISSOR_TEST );

This is why I added the portals to a list(per sector) as well in the Portal Culling function. So later on, when looping through that list, just BEFORE rendering the sector, you can setup a scissor. In case you found multiple portals you might activate multiple scissor rects (not sure if this is possible), or just combine the portals to make 1 bigger rect. Don't always hurt yourself with math, enjoy life. With a scissor enabled on the portal, only the visible part of a sector will be drawn, no matter how !#@$ big it was.

However, it does not prevent the render-calls. All triangles / objects inside that sector will be pushed, the scissor just discards pixels that didn't fall inside the rectangle. If you have massive amounts of objects / vertex-data, you may want to split up the sector in smaller chunks. And don't forget about LOD systems. Portal Culling can help a lot, but still doesn't make your game fly of course. Games like Crysis or GTA use lower-poly meshes or even sprite billboards for distant objects.

6. The exceptionals; portals partial behind / in front of the camera
So far, so good. I would almost throw the portal-culling code asides again, leaving it "95% done". If it wasn't there is a not-to-ignore bug still present. How to handle with portals that are (partially) behind the camera? Take this scenario:

Two or only one point of the (quad) portal are in front of the camera, and will produce normal 2D coordinates. The other points are somewhere behind the camera. Math wouldn't be math if there wasn't always an annoying exception on the rule. If all points still had a positive Z value, there is nothing to worry about. The portal rectangle will be partially outside the screen-bounds, but that doesn't give any problems. But in this case, the rear-portal points have a negative Z value. So, when doing the division with Z, the X and Y coordinates will get mirrored too.

This makes a wrong rectangle. Luckily, there is an easy fix. I’m not 100% sure if this is the best way, but I did it anyway. And so far it works:

p2D.x /= p2D.z;
p2D.y /= p2D.z;
if (p2D.z < 0) then begin
if (p2D.x > 0) then p2D.x := -1.0 - p2D.x else // Put it left from the left side of the screen
p2D.x := +1.0 - p2D.x;
if (p2D.y > 0) then p2D.y := -1.0 - p2D.y else // Put it below the bottom of the screen
p2D.y := +1.0 - p2D.y;

Now just make a rect out of all portal points and test it with the view frustum rect as usual, but be prepared for one exception:
if ALL points were negative, the test failed. At least 1 point has to be in the foreground. If you forget this, portals behind you can get visible as well.

7. Loop-back / Circular referencing
A problem with checking visible portals/sectors, especially with the 2D overlap check, is that we may get stuck in infinite loops, or lack info about which portals made a sector visible. Take this scenario:

In this particular case, first the room behind the 3 windows will be checked. This room has a door that leads to a toilet on the right. This toilet has another door that leads back into the big-room we started from. Although the toilet exit door is in front of the background room door, all their 2D rects will overlap (one shortcomings of doing 2D checks). In other words, after our toilet visit in the recursive functions, we get back to the main-room.

This isn't so bad, but we have to be careful not to add the room twice. But neither should we stop as soon as we detect an already-inserted room. Since we entered the room via a different route, it may show other portals that weren't visible before. This gives yet another problems: infinite loops.

To prevent walking circles, you can block portals. Once checked, they can't be checked again. But… this leads to wrong scissor-rects though, or even missing sectors. In complex situations, the same portal might be visible through multiple foreground portals. Each "route" can lead to different results, and will also produce a different scissor-rectangle. Crikey, how to deal with that? Not blocking means infinite loops. Blocking means incomplete data.

So instead of just blocking a sector or portal right away, I look if the sector was already made visible by a(nother) portal with equal or a bigger overlapping rectangle than the current one. Ifso, no need to check. Because it can't produce new results anyway.

Well, enough Portal Culling. The 2D approach has some flaws and still can evaluate portals that aren't really visible for the camera. Yet it's a relative simple (and fast) way to do culling. Just make sure your loop really checks all scenario's, in case parts of the scene are missing.

Sunday, July 17, 2011

Could the real Da Vinci please stand up?

Begging modus engaged. Concept artist required.

Question. Are you (or do you know) an artist, specialized in drawing realistic, but horrific environments? Do you love horror, and do you have at least 5 hours MC-Hammer drawing time a week? Then maybe you like to help us. We need an extra artists that can draw environment. Both realistic looking posters to illustrate the atmosphere, as schematic sketches to support the 3D modelers with making maps. If you are interested, see the contact info below.

- Ability to draw realistic, eerie looking environments. Reference pic:
Control Room
- Available 5 hours or more (quite a lot needs to be drawn, so I need someone with time)
- Eye for detail & architecture
- Affinity with the horror & fantasy theme. Able to make unreal, bizare, dreamish or nightmarish rooms.

What needs to be done:
- Working out the main themes of the game (athmosphere sketches, example environments)
- Building exterior (it's not just an ordinary flat of course)
- Schematic sketches / material sets to support the 3D modellers with making specific locations

What we can offer:
- Hopefully a fun & learnful time!

Before contacting me, please add a link or attachment to the mail with one(or more) drawings in this style. I can't judge the "match" if your art-work has a complete different style! Address:
nieuwlaat dot r AT gmail dot com


The Office

If one would ask how Demo2 is going, then I would say , “Steadily”… uhm, “slowly”. Pity, but not a complete surprise though. Quite a lot things have been upgraded thoroughly in the code, several more things yet have to be made. Or usually the required features are already in the Engine, but limited. So it has to be revised anyway. Another slowdown is the lack of materials, textures, sounds and 3D props. This time I don’t want to “borrow” media from other games anymore, so we have to make everything ourselves. From a simple carpet texture to a noisy wind ambient loop.

I’m planning to release a movie in the meanwhile though. Not in-game or cinematic sequence of (horror)stuff. Merely a tech-movie. Just showing some fancy shader stuff, that’s all folks.

Nevertheless, a little bit more tempo would be nice. The problem with making a game is that it’s not just big…. It’s f$cking big! And I’m not just talking about all the programming work. Even a simple room can already hold 5 or more different textures(from each requires additional images such as a normal- or specularMap), 10 different props (bench, TV, painting, lamp, …), and several decal/overlay textures (dust, dirt, moss, holes, power sockets, …). Well, just look around in the room, toilet, or stinky office you’re sitting at the moment. And that’s just one room… A game like this needs hundreds, if not thousands.

Of course, after making a couple of environments, your so called library of textures, models, sounds and other shit to put in the game will start growing so that future locations can be filled faster with already-existing assets. But making a start feels like pushing forward a big Diesel Locomotive. Derailed. And because progress is so slow at the start, it’s harder to motivate people. We all prefer quick results, like mcDonalds hamburgers. Painting, modeling, programming or sound engineering is difficult without seeing direct results. Certainly when spending your precious free-time on it.

Off topic. Added some more specular intensity, and it turned out pretty nice for this screenshot that uses only 2 different textures by the way.

Nevertheless, if you want to realize a big project, you shouldn’t be afraid to bleed. Rome wasn’t built in one day either. In my case it requires a lot of effort from the modelers, drawers and anyone else involved. No assets = no game. But it also requires my support, feedback, motivating and vision. Just like in any other company, whether it’s the local tobacco store, a cheese-pudding factory, FC Barcelona, or the Navy Seals, employees need clear goals, a planning, and need to get helped or pushed time to time. This interaction between employees, managers and direction is crucial for any company. If the sales are bad, you can’t just blame the employees because they were too lazy to bake cookies. And neither can you expect to solve all problems simply by replacing a manager. It takes two to dance the Tango.

Now this “managing” task is harder than I thought. Just giving a good idea (“gonna make a cool game, yeah!”), then waiting until the 3D models of double barreled shotguns, awesome monsters and picturesque locations stream in via the mailbox is not going to work. But as a typical worker (don’t talk, just work), I’m not used to socialize a lot with others, demand things, push them, or stipple out rock-solid strategies. I’m used to get some assignments, then just execute them. Managers… ttsk. Talking all day, but never touched a hammer or made their hands dirty. Who needs managers?

In theory, managers are nothing but overhead indeed. If all workers do what they have to do, one Boss-guy should be enough. In practice, worker aren’t always motivated, don’t always know what to do, have internal problems, or are just waiting for feedback / approval before they continue. And certainly; the bigger the company, the harder to get them all facing the same direction.

Now I don’t have to command a whole army of Borgs. The complexity here is the distance and limited, fragmented time. I don’t know my helpers personally. Don’t know their faces, or voices. They spend some hours in their free time, but on varying intervals. This makes it easier to forget things, and a whole lot harder to make robust appointments. The lack of appointments makes it near to impossible to plan anything. As a result, no clear mission. Nobody really knows what to do when, and finally that degrades the motivation. Why work hard if there are no concrete results to expect anywhere soon? It works like a chain; if one link gets stuck, the whole chain starts stuttering.

Ice, ice baby. Asides being David Brent, I spend time doing (cheap) Sub-Surface-Scattering & Fresnel for this ice effect. Not done yet though. Pretty darn difficult, certainly to get it right in relative dark indoor situations.

Enough metaphors. Let’s fix this sink boy. To get more done, I could ask for more people to help (like I just did for the Concept Art). But in the end, I believe smaller, flexible, motivated teams can do more than big chunky ones. So before buying extra horsepower, it’s worth trying to get the maximum out of your current team. You can do this by threatening (you’ll lose your job!), but since this is a charity project, I’d better try it the positive way. Not by kindly asking, but by providing. The A-Team won’t be able to get in action if no one provides ammunition and cigars.

So, it was time to look in the mirror to acknowledge my faults or shortcomings. One of the problems was the amount of info. Not that they don’t know anything about the project. No, there are so much documents, mails and posts scattered around that it’s simply too much. Admit it. Asides from nice books, do you really read tons of paperwork? No. It’s a waste of time making them, because 95% of the people will skip it anyway. I should learn to keep my descriptions short, and less suggestive. Don’t ask “should we do this or that?”. Just tell them what to do. Show them who’s the Boss! And if you need opinions or feedback, put it in simple, compact polls. You don’t have to rule the joint like Stalin, but as a chief, you are expected to chose directions.

Asset manager
As said earlier, another difficulty with games is the tremendous amount of assets to make. Assets? Yes, sounds, textures, models, maps, shaders, concept-art, story dialogs, an animated mouse-cursor… pretty much anything that is relevant for the game. If you want your helpers to do something, they’ll need to know what to make of course. And since there is usually more than just one asset to make, someone needs to prioritize things as well.

To make it more complex, game-assets are often interleaved. A map asset may require other texture assets, going to be made by another person. So to prevent endless waiting, the priorities of all helpers need to align. Person A can’t finish his map if person B has low priority on certain important sub-assets of the same map. This is what would be called “miscommunication” in a normal company. Obviously, the complexity grows when more and more assets & personel arrive on the scene.

Yet another problem with assets is the “unknown”. Do you really know already what EXACT assets to create for, let’s say, a corridor map? Often it’s up to the artist to decide what materials, music or decorations suit best. But to find that out, you’ll have to put the bastard at work first. To do so, he needs to know about this corridor in the first place. In other words, assets can be seen as a tree-structure. From top-level, abstract, global assets such as “making game Tower22”. Going down deeper and deeper till the actual game-content assets such as “ConcreteWall #34 normalMap texture”. First you’ll write out the top-level assets, then you start zooming in, further and further.

The red/green/blue bands is caused by an effect called "Dispersion". Now this code isn't exactly based on realistic wavelength calculations. But it looks cool nevertheless. Maybe overdone for ice, but glass objects can certainly make good use of this. How it's done? Just by calculating 3 different refraction vectors, and sampling 3 times from the background texture. One coordinate for Red, one for Green and another for Blue.

I think most of us hobby game developers made listings in Notepad or Excel. This and that map, blue chair, orange bench, dustbin and a Ming vase model. Go. But then you probably also recognize the quality of these listings: not up-to-date, incomplete, lacking detail, and asides you, no one really looks into them. It works for small assignments, but not for something in the magnitude of a game. So, I did two things:
A:- Ask a person (Brian) to help me managing
B:- Made a database tool to manage the assets

Since Brian is a writer, he probably knows better than me how to “RAR” my huge documents into short but powerful (proper English) texts. He can help me building the assets listing. He does not know about the deep gritty details such as which shaders need to be made to render a 3D turd. But he does now about story telling… and since we have to fine-tune the story and all of its assets (locations, themes, characters) first, before we can go deeper… The splitting process automatically will dig up the story details and paths that yet need a decision.

To manage all of this, I made a simple MS Access database. And a graphical program around it. In a folder-structure (the top-down approach), you can insert assets. An asset here is made of:

- Short name
- Type (texture, character, game info, 3D object, …)
- Description
- Design info (text, additional files, papers and weblinks that explain HOW-TO make it)
- Status (not started, work in progress, almost done, done, suspended, aborted)
- Priority (lowest to highest)
- Assigned person(s)
- Planned / released data (to make appointments)
- Estimated & spend hours (for administrative purposes)

And yet a more powerful feature is the ability to drag & drop assets into another. This allows to make abstract assets, split out in deeper, detailed assets. Example:

---------High poly body
---------High poly head
---------Low poly body
---------Low poly head
---------AlbedoMap body
---------NormalMap body
---------SpecularMap body
---------AlbedoMap head
---------NormalMap head
---------SpecularMap head
---------Background docs
------------------Weapon handling
------------------Ladder climbing

We can already insert the “Player” asset, without knowing which sub-assets we’ll exactly need. Hell, I don’t know what kind of animations or sounds we’ll need. The same asset can also be referred by multiple parent nodes. For example, Demo2 requires the “Ladder climbing code” asset.

Well, this program allows Brian and me to manage the assets of course. But it also allows others to have a look or eventually to update their own progress. Be careful not to let a whole bunch of persons mess around in your database, or it will get mess as every person as a different grouping / naming strategy. Each person can see his (priority) pending tasks (+ explanations), or the progress from others. Hopefully, this helps streamlining everything, and ultimately, helps motivating people. If two persons work slow, the third will be less motivated as well. If two persons work hard, the third has a better chance to get sucked into this “fanatic workflow”.

CEO of… uh, crap, still no name yet

Sunday, July 3, 2011

Forever young

Easy, the second part of the water tutorial will come. Got to finish some more rooms first... Last week I spend most programming-time on adding motion blur on rotating objects (see bottom), improving Cascaded ShadowMaps for long-range lights such as the sun, and a fancy loading-screen system! We programmers all know debugging means changing 2 letters, recompile, and run the program again for the 1235th time. When having long loading times (10 seconds or more), this can get quite annoying. So here a little tip to make all the waiting a little bit more bearable; show your concept art!

Concept artists do their best making teasing images or good reference work. By now, we got a whole truckload of old-flat photographs and the likes. So why not showing a few random pictures while waiting? Just to bring you in the mood, and to make sure all that hard work won't be forgotten.

See? There are still parts missing. And the brown chunks on the water should be ice...

Boy, all that talk about games. How old are you? I’m 27, and could become a grandpa within 13 years in theory already (didn’t count the 6 year old moms). Well she’d better not, but what I’m trying to say is: aren’t we a little bit too old for playing games? Or like me, spending thousands of hours trying to make one? Uhm… although I’m not playing that often anymore, and although the impact and charm isn’t the same as ten years ago, I still enjoy them. Mom cooking, little daughter drawing “things”, daddy shooting cowboys in Rockstar’s Red Dead Redemption. Which is an absolute masterpiece by the way, way deeper than the GTA series.

Yet, when someone asks about my hobbies, game-programming is often replaced with “doing creative stuff” (or sporting, yeah right). When colleagues at work ask “how did you learn all that stuff huh?”, I answer with “School and a little bit fooling around at home”. While the fact is that most of the experience comes from the endless attempt to make games. It’s just not cool to admit you’re doing kiddy things against a bunch of non-digital workers smeared in oil, even not when having a cigarette in the corner of your mouth.

Needless to say, openly telling your exciting Super Mario adventures and your boy dreams of being a muscular Doom Space Marine is not exactly what you tell the girls either. Grown men drink beer, demolish things, drive motorcycles and shit without toilet paper. Ok, the modern metro-man shaves legs, knows everything about expensive perfume and hits the club every Tuesday. But neither of them plays games. Not done. Just like you shouldn’t play with Lego, read superhero comics, draw bad monsters, or enjoy Commando with Arnold Schwarzenegger at my age.

Talking about action movies. This is the Radar-Station (work in progress), our test playground map for the object Editor I mentioned a couple of times last posts.

Of course, many people do have a secret Marklin modeltrain platform on their attic (where the wife doesn’t come). Oil platform workers play Pokémon on the pink NDS of their girlfriend. And just look how excited all the boys are when the word “Lego” falls. Tssssk, bet what happens if you throw a box of Lego between a bunch of full-grown drunk men on a party. Happy like never before. Being full-grown sucks, but we have suppress our feelings anyway. Otherwise the guys at the office will laugh, and your wife is too ashamed to walk in public with you.

Basically, “growing-up” means throwing your fantasy overboard. Because that’s what really happens. And whether you like it or not, sooner or later you start noticing Rambo III isn’t as funny as it used to be. Superheroes are kind of lame, Duke Nukem isn’t real, and instead of imagining your own action-packed stories, you lazily let the TV do all the work. Or maybe you read a book. Just as long as you don’t have to surrender yourself to your own fantasies, because that’s childish.

Some give a brave struggle, others fall quickly. But we all get old sooner or later. And for what? Give yourself a pat on the back. Because you didn’t only grow up(7 years after your girl, as she claims), you also got officially boring due the lack of fantasy an impulsive thinking. Perhaps resulting in the so called midlife-crisis, ten years later, as you finally realize you did nothing but working, watching TV and adapting yourself to age, wife, kids, environment, and the “norms”. Shit, you could have played Counterstrike for at least five more years, or maybe still even drink beer and laugh about farts every Saturday with fellow 40 year old childish friends! Now you suddenly got to compensate with parachute jumps and climbing a mountain.

Now seriously. Isn’t it a pity we hide or even discard our hobbies, loves and fantasies just to prove our maturity? When looking at my little daughter, it reminds me how special little things once were. Every year I hope to catch that nostalgic feeling when setting up the Christmas tree, but after two days I’m not even looking anymore. But as a kid, I was fascinated just by the red and green colors of those tree lamps. The whole atmosphere could become exciting, just by adding some colors, sounds, a specific smell or event. Kids are still unbiased, open for everything. Life is a big adventure, and when they play they live their fantasies, unashamed, pure. Doesn’t that make you jealous sometimes? At least they are still happy with everything they see and do.

I’m Goddamn happy with my game-programming hobby. Childish or not. As you may guess, my grownup girlfriend doesn’t really understand either why I’m wasting so much time behind the computer. Programming a game… ok… But for me, it feels like the last station between childhood and maturity. Already lost a lot of luggage when it comes to absurd humor, farts, partying and building fantasy cities on the attic. So please! Let me be young and dream away in my fantasy for a little longer! And if you think that’s childish, maybe. But at least I’m happy with it! Touché.

If fantasies about old barracks in spooky environments are already childish, then how the hell could a man think of Mushroom Kingdom, Harry Potter, Star Wars, or Family Guy? Exactly. Screw them, just use your fantasy and be proud of it, no matter what they say!

Motion blur on rotating objects?
Not a very high quality blur, but at least it’s cheap and easy. For a good description, check this link:
GPU Gems 3: Motion blur as a post effect
In turbo-short, perform this post-effect on the whole screen as follow;
- Calculate the previous (screen)position of each pixel by using the preview modelview matrix
- Calculate the 2D motion vector by subtracting the previous position from the current pixel position
- Create a blur-streak, using the motion vector to offset the texcoords.

This creates a blur while (quickly) rotating the camera. However, it does not make fast moving/rotating objects blur by itself. Got to give a helping hand. In the earlier passes, I also store the motion vector in one of those buffers. Just like you can store depth in a texture, you can also store a 2D or 3D velocity. Calculating this velocity is easy. For each object, store the previous matrix. You know, the position / rotation matrix you would set with glLoadMatrix before rendering your object. In the (vertex)shader, use the current and previous matrix to calculate 2 world positions. Subtract them to get the velocity.

Although somewhat more work, you can do the same trick for animated characters if you pass all previous bone matrices as well. This allows to blur fast moving limbs, such as E.Honda's Hundred-Hand-Slap. Now back to the final step. Just sample the motion vector and add it to the camera motion. Done. Burp.

We still have to produce more textures, and then fill the rooms with objects. But it is a start.