Ramblings in 3D (and other stuff)

2008-02-22T09:44:00.002+01:00

Tip of the day

Nope, no engine updates today. Instead I'll give you a website recommendation.

If you're a bit weird like me, that is, you rather read graphics papers than fiction before you go to sleep, you probably already have this one in your bookmarks.

Ke-Sen Huang keeps an index of all papers available online from every academic graphics conference worth it's name.

I'm yet to find a good rescource that lists all papers and presentations from more commercially oriented conferences like GDC. Feel free to share your own bookmarks :)

2008-02-20T08:59:00.005+01:00

Soft shadows

I've added soft shadows to the engine. I use Percentage-Closer Soft Shadows (PCSS), described in this paper. It differs from regular PCF in that a "blocker-serach" step is used to approximate a shadow penumbra size. The estimated penumbra size is then used to control the filter size. It's not real penumbra shadows but it looks quite convincing.

Believe it or not, but until now my engine had no support for normal mapping. Now it does. The dynamic indirect lighting is also affected by the normal maps.
Time for the screenshots:

Note the green light that is reflected from the wall (not visible) onto the scene.

Soft shadows.

The scene is also lit by an enviroment map.

2008-02-08T12:47:00.000+01:00

Dynamic indirect lighting

I got the indirect lighting to work correctly. There were some stupid bugs in my SH code. In the screenshots I use a 3x3x3 grid of sampling points (see last post) and one bonce of indirect light. There is also a (very) small constant ambient term so that no surfaces are completely black. Combined with SSAO it looks quite nice.

The scene is simple and HDR is deactivated so that the lighting effects is more apparent.

2008-02-01T14:14:00.000+01:00

I've been quite busy with the engine lately. The new stuff is:

Dynamic reflections
Each reflective object has it's own cube enviroment map. I support multiple bounces by spreading out the cube map updates over a number of frames. This means there can be some subtle "popping" in the reflections. Acceptable for my application.

HDR pipeline
I now support 64 or 128 bit HDR rendering. Pretty standard stuff where I do tone mapping based on image luminance. Of course there is also a bloom filter (as if we're not tired of that one by now;))

Antialiasing
One of the biggest drawbacks with deferred shading is the lack of support for multisample antialias (at least with DX9). The usual thing to do is to hack antialias by performing an edge detection filter and blurring the image only on the edges. It's a dirty hack but it works quite well.

Dynamic indirect illumination
This is a variant of this paper. In short, I partition the world into a uniform grid, and at each grid point I capture the incident radiance field. This is done by rendering a cube map and then projecting it to spherical harmonics coefficients. The coefficients are stored in a number of volume textures. When rendering the frame, SH cofficients representing the incident radiance at each pixel are fetched from the volume texture and used to approximate the incident diffuse lighting at each pixel.

Right now there are some problems with my implementation but I'll solve that soon ;)

At last, the mandotary screenshot:

2008-01-10T16:21:00.000+01:00

I've finally started working on the engine after the holidays.

I've done quite a lot of non graphic stuff. I've improved the engine code here and there and I've added picking for example.

On the graphic side, I've added support for cube maps and thus omidirectional shadows. All lights now also supports gobos, i.e. color textures that are projected from the lights. There is also support for reflections, but I'm still working on dynamic ones.

Scenes with a lot of lights also means a lot of shadow maps. For this reason, I've implemented a shadow map queue. When a shadow map needs an update it's added to the queue and every frame a number of entries in the queue are removed and processed. So only a small number of shadow maps are updated each frame. This of course means that there can be some noticable shadow lag when objects are moved around. For the type of application I have in mind for this engine, that is acceptable.

Omnidirectional shadow mapping

Point- and spotlights with gobos

Lots of lights! All cast shadows and some use gobos.

The power of vectorization

2007-12-03T15:23:00.001+01:00

Since I have no new cool visuals to show, I'd thought I should blog about some random tech-topic. So lets talk about vectorization in shaders. Doing this in your HLSL code can improve the compiled code significantly. For example, a naive implementation of my bilateral boxfilter looks something like this:

half d[9];
half3 n[9];
half2 uv[9];

for (int i=0; i<9; ++i)
{
    uv[i] = texCoord + offsets[i];
    d[i] = GB_GetDepth(uv[i]);
    n[i] = GB_GetNormal(uv[i]);
}

// calculate wieghts
half w[9];
half wSum = 0;

for (int i=0; i<9; i++)
{
    half wn = pow(dot(n[0], n[i]),32);
    half wz = (EPSILON + abs(d[0] - d[i]));

    w[i] = wn / wz;
    wSum += w[i];
}

// normalize weights
wSum = 1.0f/wSum;

// sample and apply weights
half3 color = 0;
for (int i=0; i<9; i++)
    color += GB_GetDiffuse(uv[i]) * w[i] * wSum;

return float4(color,1);

With the ps2_b profile, this compiles to:

ps_2_x
 def c9, 2, -1, 32, 100
 def c10, 0.00999999978, 0, 0, 0
 dcl t0.xy
 dcl_2d s0
 dcl_2d s1
 dcl_2d s2
 add r0.xy, t0, c1
 add r1.xy, t0, c0
 add r2.xy, t0, c2
 add r3.xy, t0, c3
 add r4.xy, t0, c4
 add r5.xy, t0, c5
 add r6.xy, t0, c6
 add r7.xy, t0, c7
 add r8.xy, t0, c8
 texld r9, r0, s2
 texld r10, r1, s2
 texld r11, r0, s1
 texld r0, r0, s0
 texld r12, r1, s1
 texld r1, r1, s0
 texld r13, r2, s2
 texld r14, r2, s1
 texld r2, r2, s0
 texld r15, r3, s2
 texld r16, r3, s1
 texld r3, r3, s0
 texld r17, r4, s2
 texld r18, r4, s1
 texld r4, r4, s0
 texld r19, r5, s2
 texld r20, r5, s1
 texld r5, r5, s0
 texld r21, r6, s2
 texld r22, r6, s1
 texld r6, r6, s0
 texld r23, r7, s2
 texld r24, r7, s1
 texld r7, r7, s0
 texld r25, r8, s2
 texld r26, r8, s1
 texld r8, r8, s0
 add_pp r0.w, -r9.x, r10.x
 abs_pp r0.w, r0.w
 add_pp r0.w, r0.w, c10.x
 rcp r0.w, r0.w
 mad r9.xyz, r11, c9.x, c9.y
 mad r11.xyz, r12, c9.x, c9.y
 dp3_pp r1.w, r11, r9
 pow_pp r2.w, r1.w, c9.z
 mul r0.w, r0.w, r2.w
 dp3_pp r1.w, r11, r11
 pow_pp r2.w, r1.w, c9.z
 mad_pp r1.w, r2.w, c9.w, r0.w
 mul r0.xyz, r0, r0.w
 mul r0.w, r2.w, c9.w
 add_pp r2.w, r10.x, -r13.x
 abs_pp r2.w, r2.w
 add_pp r2.w, r2.w, c10.x
 rcp r2.w, r2.w
 mad r9.xyz, r14, c9.x, c9.y
 dp3_pp r3.w, r11, r9
 pow_pp r4.w, r3.w, c9.z
 mad_pp r1.w, r4.w, r2.w, r1.w
 mul r2.w, r2.w, r4.w
 add_pp r3.w, r10.x, -r15.x
 abs_pp r3.w, r3.w
 add_pp r3.w, r3.w, c10.x
 rcp r3.w, r3.w
 mad r9.xyz, r16, c9.x, c9.y
 dp3_pp r4.w, r11, r9
 pow_pp r5.w, r4.w, c9.z
 mad_pp r1.w, r5.w, r3.w, r1.w
 mul r3.w, r3.w, r5.w
 add_pp r4.w, r10.x, -r17.x
 abs_pp r4.w, r4.w
 add_pp r4.w, r4.w, c10.x
 rcp r4.w, r4.w
 mad r9.xyz, r18, c9.x, c9.y
 dp3_pp r5.w, r11, r9
 pow_pp r6.w, r5.w, c9.z
 mad_pp r1.w, r6.w, r4.w, r1.w
 mul r4.w, r4.w, r6.w
 add_pp r5.w, r10.x, -r19.x
 abs_pp r5.w, r5.w
 add_pp r5.w, r5.w, c10.x
 rcp r5.w, r5.w
 mad r9.xyz, r20, c9.x, c9.y
 dp3_pp r6.w, r11, r9
 pow_pp r7.w, r6.w, c9.z
 mad_pp r1.w, r7.w, r5.w, r1.w
 mul r5.w, r5.w, r7.w
 add_pp r6.w, r10.x, -r21.x
 abs_pp r6.w, r6.w
 add_pp r6.w, r6.w, c10.x
 rcp r6.w, r6.w
 mad r9.xyz, r22, c9.x, c9.y
 dp3_pp r7.w, r11, r9
 pow_pp r8.w, r7.w, c9.z
 mad_pp r1.w, r8.w, r6.w, r1.w
 mul r6.w, r6.w, r8.w
 add_pp r7.w, r10.x, -r23.x
 abs_pp r7.w, r7.w
 add_pp r7.w, r7.w, c10.x
 rcp r7.w, r7.w
 mad r9.xyz, r24, c9.x, c9.y
 dp3_pp r8.w, r11, r9
 pow_pp r11.w, r8.w, c9.z
 mad_pp r1.w, r11.w, r7.w, r1.w
 mul r7.w, r7.w, r11.w
 add_pp r8.w, r10.x, -r25.x
 abs_pp r8.w, r8.w
 add_pp r8.w, r8.w, c10.x
 rcp r8.w, r8.w
 mad r9.xyz, r26, c9.x, c9.y
 dp3_pp r9.x, r11, r9
 pow_pp r10.x, r9.x, c9.z
 mad_pp r1.w, r10.x, r8.w, r1.w
 mul r8.w, r8.w, r10.x
 rcp_pp r1.w, r1.w
 mul r0.xyz, r0, r1.w
 mul r1.xyz, r1, r0.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r2, r2.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r3, r3.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r4, r4.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r5, r5.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r6, r6.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r7, r7.w
 mad_pp r0.xyz, r1, r1.w, r0
 mul r1.xyz, r8, r8.w
 mad_pp r0.xyz, r1, r1.w, r0
 mov_pp r0.w, -c9.y
 mov_pp oC0, r0

This is an example of bad vectorization. The shader compiles to 151 instructions of witch 124 is arithmetic. The problem is that many instructions (like pow and abs) are not used with full power. Many instructions are SIMD instructions and can work on multiple data in parallel.

We can rewrite this shader to perform some of the arithmetic's in parallel like this:

half3 n[9];
half3 c[9];

for (int i=0; i<9; ++i)
{
    half2 uv = texCoord + offsets[i];
    n[i] = GB_GetNormal(uv);
    c[i] = GB_GetDiffuse(uv);
}

// calculate normal wieghts 
half4 wn1;
wn1.x = dot(n[0], n[1]);
wn1.y = dot(n[0], n[2]);
wn1.z = dot(n[0], n[3]);
wn1.w = dot(n[0], n[4]);
wn1 = pow(wn1, 32);

half4 wn2;
wn2.x = dot(n[0], n[5]);
wn2.y = dot(n[0], n[6]);
wn2.z = dot(n[0], n[7]);
wn2.w = dot(n[0], n[8]);
wn2 = pow(wn2, 32);

// calculate depth wieghts 
half d = GB_GetDepth(texCoord + offsets[0]);

half4 d1;
d1.x = GB_GetDepth(texCoord + offsets[1]);
d1.y = GB_GetDepth(texCoord + offsets[2]);
d1.z = GB_GetDepth(texCoord + offsets[3]);
d1.w = GB_GetDepth(texCoord + offsets[4]);

half4 d2;
d2.x = GB_GetDepth(texCoord + offsets[5]);
d2.y = GB_GetDepth(texCoord + offsets[6]);
d2.z = GB_GetDepth(texCoord + offsets[7]);
d2.w = GB_GetDepth(texCoord + offsets[8]);

half4 wd1 = EPSILON + abs(d - d1);
half4 wd2 = EPSILON + abs(d - d2);

// divide normal weights with depth ones
half4 w1 = wn1 / wd1;
half4 w2 = wn2 / wd2;

// calc weight 0
half w0 = pow(dot(n[0], n[0]),32) / EPSILON;

// calc sum
half4 wSumTmp = w1 + w2; // perform sumation of weights 1+4,2+5,3+6,4+8
half wSum = w0 + dot(wSumTmp, float4(1,1,1,1)); // sum all weights
wSum = 1.0f/wSum;

// normalize weights
w0 *= wSum;
w1 *= wSum;
w2 *= wSum;

//apply weights
half3 color = c[0] * w0;
color += c[1] * w1.x;
color += c[2] * w1.y;
color += c[3] * w1.z;
color += c[4] * w1.w;
color += c[5] * w2.x;
color += c[6] * w2.y;
color += c[7] * w2.z;
color += c[8] * w2.w;

This compiles to:

ps_2_x
def c9, 2, -1, 0.00999999978, 32
def c10, 100, 0, 0, 0
dcl t0.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
add_pp r0.xy, t0, c5
add_pp r1.xy, t0, c0
add_pp r2.xy, t0, c6
add_pp r3.xy, t0, c7
add_pp r4.xy, t0, c8
add_pp r5.xy, t0, c1
add_pp r6.xy, t0, c2
add_pp r7.xy, t0, c3
add_pp r8.xy, t0, c4
texld r9, r0, s1
texld r10, r1, s1
texld r11, r2, s1
texld r12, r3, s1
texld r13, r4, s1
texld_pp r14, r0, s2
texld r0, r0, s0
texld_pp r15, r2, s2
texld r2, r2, s0
texld_pp r16, r3, s2
texld r3, r3, s0
texld_pp r17, r4, s2
texld r4, r4, s0
texld_pp r18, r1, s2
texld r1, r1, s0
texld r19, r5, s1
texld r20, r6, s1
texld r21, r7, s1
texld r22, r8, s1
texld_pp r23, r5, s2
texld r5, r5, s0
texld_pp r24, r6, s2
texld r6, r6, s0
texld_pp r25, r7, s2
texld r7, r7, s0
texld_pp r26, r8, s2
texld r8, r8, s0
mad r9.xyz, r9, c9.x, c9.y
mad r10.xyz, r10, c9.x, c9.y
dp3_pp r9.x, r10, r9
mad r11.xyz, r11, c9.x, c9.y
dp3_pp r9.y, r10, r11
mad r11.xyz, r12, c9.x, c9.y
dp3_pp r9.z, r10, r11
mad r11.xyz, r13, c9.x, c9.y
dp3_pp r9.w, r10, r11
mul_pp r9, r9, r9
mul_pp r9, r9, r9
mul_pp r9, r9, r9
mul_pp r9, r9, r9
mul_pp r9, r9, r9
mov_pp r14.y, r15.x
mov_pp r14.z, r16.x
mov_pp r14.w, r17.x
add_pp r11, r18.x, -r14
abs_pp r11, r11
add_pp r11, r11, c9.z
rcp r12.x, r11.x
rcp r12.y, r11.y
rcp r12.z, r11.z
rcp r12.w, r11.w
mul_pp r9, r9, r12
mad r11.xyz, r19, c9.x, c9.y
dp3_pp r11.x, r10, r11
mad r12.xyz, r20, c9.x, c9.y
dp3_pp r11.y, r10, r12
mad r12.xyz, r21, c9.x, c9.y
dp3_pp r11.z, r10, r12
mad r12.xyz, r22, c9.x, c9.y
dp3_pp r11.w, r10, r12
dp3_pp r0.w, r10, r10
mul_pp r10, r11, r11
mul_pp r10, r10, r10
mul_pp r10, r10, r10
mul_pp r10, r10, r10
mul_pp r10, r10, r10
mov_pp r23.y, r24.x
mov_pp r23.z, r25.x
mov_pp r23.w, r26.x
add_pp r11, r18.x, -r23
abs_pp r11, r11
add_pp r11, r11, c9.z
rcp r12.x, r11.x
rcp r12.y, r11.y
rcp r12.z, r11.z
rcp r12.w, r11.w
mad_pp r11, r10, r12, r9
mul_pp r10, r10, r12
dp4 r1.w, r11, -c9.y
pow_pp r2.w, r0.w, c9.w
mad_pp r0.w, r2.w, c10.x, r1.w
mul_pp r1.w, r2.w, c10.x
rcp_pp r0.w, r0.w
mul_pp r10, r10, r0.w
mul_pp r5.xyz, r5, r10.x
mul_pp r1.w, r1.w, r0.w
mul_pp r9, r9, r0.w
mad_pp r1.xyz, r1, r1.w, r5
mad_pp r1.xyz, r6, r10.y, r1
mad_pp r1.xyz, r7, r10.z, r1
mad_pp r1.xyz, r8, r10.w, r1
mad_pp r0.xyz, r0, r9.x, r1
mad_pp r0.xyz, r2, r9.y, r0
mad_pp r0.xyz, r3, r9.z, r0
mad_pp r0.xyz, r4, r9.w, r0
mov_pp r0.w, -c9.y
mov_pp oC0, r0

This time there is 108 instructions of witch 81 arithmetic.

In this shader, when calculating the weights, more work is done per instruction. For example, the pow instruction is used only three times instead of eight. The summation of weights are done with two add and one dp4 instead of nine add.

Note that we could have vectorized the texture coordinate calculations as well, but then we would need SM 3.0 (arbitrary swizzles) and change how the offset constant is set up.

With a small effort we got rid of 43 ALU instructions! It should be noted that this necessarily won't lead to a speed-up since instruction count is just part of the story. ALU/Texture instruction ratio, texture cache etc. comes in to play as well. On my Radeon X1600 this shader is limitied by texture lookups so the win is not that big.

At last I would like to point out that I'm by no means a shader optimization guru, just a guy trying to fill his blog ;)

2007-11-29T17:06:00.000+01:00

Light volumes and more

I've not been able to work much on the engine the last week since I've been busy with school projects.

Some things have been done though. I've updated the deferred rendering system to work with light volumes instead of full-screen quads. This alone provides a huge speedup as long as the lights are reasonably small. This also made me think about light attenuation. Funny enough, this thread at gamdev popped up today. As discussed in the thread, I also wanted to find a way to set a maximum radius for a light, without affecting its atenuation too much. After some playing around with Maple, I found that max(0, 1-1/maxRadius*x)/(1+k*x^2) does the job quite good (this function is suggested in the thread) . I implemented it in my lighting shaders and the result is fine. I also took the opportunity to shave of a few instructions.

Here are some screens:

In the second shot there is 100+ lights. As you can see, the point lights does not cast shadows yet. I will also need to implement a 64 bit HDR pipeline as I get oversaturation and banding artifacts.

I've also ordered a AMD HD3870. While slightly slower than the Nvidia 8800GT, it's slightly cheaper and most importantly: it's available ;)

2007-11-20T12:51:00.000+01:00

Eliminating noise

The last couple of days I have tried to reduse the noise in the SSAO output. It proved to be a hard problem. My initial attempt was to simply apply a separable gaussian blur. It produced a nice, smooth image. But as I expected it resulted in ugly halos around object edges when combined with the albedo term. Next I tried to combine the gaussian with some edge detection trickery. Looked kind of cool, but unfortunally it just reduced the halos and did not eliminate them.

Then I turned to bilateral upsampling (see Jeremy Shopf's blog). Eliminated halos, but the SSAO input was way to noisy for simple bilinear filtering. My last atempt was a combination of a box blur and a variant of bilateral filtering. The result is acceptable. I'm not satisfied, but it will do for now.

Next up is some speed optimizations and then I'm on to indirect lighting.

SSAO + "bilateral filtering"-hack

2007-11-13T15:14:00.000+01:00

I've been playing around with screen-space ambient occlusion (SSAO) today, one of the AO-techniques used in Crysis. It's not trivial to get it to look good. I use the randomized normal trick described in the Crytek paper but I only sample on a hemisphere around the pixel normal to avoid self occlusion. I need to optimize the shader quite a bit, but so far this is just an evaluation of the technique and I'm quite pleased with the initial results.

Mandatory screenshots:

SSAO Only:

SSAO + direct lighting

2007-11-09T16:30:00.000+01:00

Wheee! Shadows!

2007-10-24T21:32:00.000+02:00

First screenshots of NebulaX

I have been working on my new engine for some months now and I thought it was time to start blogging again.

Here are some random facts about the new engine:

* Complete rewrite of my old engine.
* Despite its name and contrary to my previous posts: it's 100% API-independent.
* Only XNA 1.1 renderer at the moment
* Pluggable rendering pipeline, but only deferred shading pipeline atm.
* DXEffect-like effect system based on XML
* Shader language independent, only HLSL impl. atm.
* "Super-shader"-style effects for generating shader permutations
* Post-processing framework
* Pluggable scene management system
* Pluggable mesh import pipeline, only COLLADA support atm.
* Optimized math library
* Everything is witten in C# execpt the math lib witch is written in C++/CLI.
* Zero GC collections during runtime!

Sounds like marketing bull, and it is:) There's quite a few places in the code that needs to get cleaned up but this is work in progress.

Below is some screenies showing some deferred shading tests.
One point light and 5 colored spot lights.

2007-03-01T19:06:00.000+01:00

Update at last

I realize I'm one lazy blogger. I'm not even sure I'm allowed to call this a blog with these infrequent updates:)

Anyway, in my last post I mentioned that I might release some code for my GUI system. Sorry, won't happen anytime soon. The reason?
The usual. School eating up my time.

I'm taking a course in AI. And it has turned out to be one of the best courses I've taken so far.
The first assignment was to implement a Checkers program, and to be approved we had to enter a tournament. I teamed up with Jesper Ek (again) and Jacob Persson and we set out with a reasonable goal: to win the competition.

And that we did.

Our program, Black Doctor, won six games in a row but unfortunately lost the last one. That was enough to win the tournament, however.

Some info about the program:
* Written in C++, multi-platform
* Bitboard representation of game board.
* Alpha-Beta (iterative + recursive) and MTD(f) searching
* Transposition table
* Quiescense
* Dynamic time management
* Simple opening book and endgame database (3-pieces)
* ~1M nodes/sec on a 1.7MHz Pentium M

No screenie this time. Console UI's just aren't that sexy...

2006-12-14T22:09:00.000+01:00

Going sloooow.

Since I just have a few hours a week to spare for engine coding, not much is happening atm. I simply have too much in school.

That said, at least I'm doing some progress:)

I have a nice and flexible GUI system up and running. It works pretty much like the usual winforms stuff (or any other GUI:)) and I have the most common controls implemented.

It's fully skinnable and easy to customize and extend. Since I'm too lazy for drawing my own skin, I "borrowed" a texture from this guy:)

I plan to add some more stuff (including 360-controller support) and polish the code and make this public with source and all. Probably some time after Christmas.

Hopefully they don't add GUI support to XNA too soon. Would make all this pretty pointless ;)

2006-11-09T19:39:00.000+01:00

I have begun coding on my new engine, entitled NebulaX.
Today I threw together a simple text rendering component and started working on a complete GUI library. Most stuff is directly ported from my old engine and altered to fit the pretty cool game component and content pipeline stuff in XNA.

I've also got myself a XBox 360 gamepad for my PC. Need that to test my input code.

A few days ago I found a cool open source project: Mono.XNA, witch is going to be an implementation of XNA using Mono and Tao.

So, all you "I-use-C++-instead-of-C#-since-I-want-platform-independence" people, stop whining and start using 21th century technology:)

2006-10-23T12:22:00.000+02:00

Long time, no see.. erhm.. update.

I haven't worked on the engine for quite some time now. I've had lots of other stuff to do.
This semester I've taken a course in mobile computer graphics. A really great course that have given me a lot of useful knowledge about graphics hardware.

In course we had to do a mobile game project using the M3G (JSR-184) Java API, and once again I teamed up with Jesper Ek. We decided to do something different and we ended up doing a OpenGL accelerated J2SE implementation of M3G. There was a competition to award the greatest game. We obviously didn't win, since we didn't make a game:) We received a Technical Achievement Award, however. The jury consisted of people from the industry, including folks from Sony Ericsson, TAT and LUGG.

You can check out the project here, and the other game entries here (some are really cool!).

What about my engine then?

It's discontinued. Yep. Discontinued.

I have decided to not develop it any further and instead start on a completely new engine using Microsoft XNA!

My old engine was 100% graphics API independent and that's of course a good thing. However, being a single developer with very little spare time, that resulted in slowing down the project considerably. By selecting only one API, I will be able to speed up the development and focus on the cool stuff.

XNA is of course the obvious choice.
It still lacks some important functionality, but I'm very confident that that will be addressed when it's finally released. Micsosoft seems very serious about XNA and I think it has a bright future.

And yeah, I've "upgraded" to the new Blogger beta, so I changed to a new blog template. Sweet.

2006-06-17T22:06:00.000+02:00

Today I added refraction to the water. Pretty standard stuff where the reflection and refraction textures are blended together based on the fresnel term.

I've also improved the texturing a bit. If you look at the second image in my last post, you can see that the terrain at "medium" distance from the camera is blurry. I now use yet another detail texture in this region and the result is that the terrain appears to have detail at all distances.

2006-06-13T21:33:00.000+02:00

Well, It has been a while since I had time to work on the engine, but today I had some time left.
A few days ago a found a tool called L3DT. It's a very cool and capable terrain generator and it inspired me to improve the texturing of the terrain.

Near the camera I use the same splatting technique as before but the textures are tiled at a much higher density so the ground look really highly detailed even if you look straight down. This ofcourse causes ugly repetition patterns further away. To hide this I blend in a large (1024x1024) color texture on terrain far from the camera.

I've also changed from vertex lighting to a normal map. This makes the lighting independent of the LOD and reduces popping artifacts. It also makes the distant terrain look more detailed.

I use L3DT to generate all texture data I need, since it does that a lot better than my own hack;)

2006-05-26T21:38:00.000+02:00

Well, Jesper and I have finished the final assignment in the ASR course. This time it was about shadows.

We implemented both shadow mapping and z-fail shadow volumes. All done on the GPU. The geometry needs to be preprocessed for shadow volume extraction to work entirely on the GPU.

The shot shows "soft" shadow mapping with 3x3 PCF.

Nothing special, but I have to fill my blog with something when I don't have time to work on the engine:)

Btw, my lecturers got their paper "High Dynamic Range Texure Compression For Graphics Hardware" accepted to SIGGRAPH 2006. Really sweet stuff!

2006-05-16T12:35:00.000+02:00

Well, I'm back from India. It was a great vacation and it feels a bit strange to be home, but I guess it's time to get back to normal life.

The image is a shot from an ocean water simulation I did for an assignment in the ASR course. It features two superpositioned Gerstner waves calculated in a vertex shader.

In the pixel shader I use three scrolling normal maps to add fine detail to the water. There's also cubemap reflection and refraction with fresnel terms. Finally there's a simple HDR hack to add some shininess to the highlights.

When I have time to work on the engine, I'll probably update the water with a similar approach.

2006-04-22T06:07:00.000+02:00

As some might have noticed, I haven't updated the blog for some time now. The reason is that I'm on vacation in India with my girlfriend. I'll be staying here for three weeks so there will be no coding for a while:)

I just wanted to thank everybody who have left comments and sent me email. It's very encouraging and makes me want to keep on going!

In a few hours we're leaving for Kerala. It's supposed to be a real paradise and I think we'll have a great time!

2006-04-10T12:41:00.000+02:00

Yesterday I did a quick test of grass rendering.
The grass waves slowly in the wind and is rendered as thousands of camera facing billboards. The nice thing is that everything is done on the GPU. The billboards are stored in one single static vertex buffer and the transformation to face the camera and the animation is done in a vertex shader.
I'm also using a neat trick to "fade" the grass out over distance without the need of alpha sorting.

It's not that good looking right now, but it's just a quick test. Putting it on real terrain with more variation of foliage and good texturing and lighting will hopefully make it look better.

2006-04-07T03:44:00.000+02:00

I got stuck when trying to redesign my engine to better support materials that depend on multiple render passes. So I started working on a cloud system instead:)

The system if fully dynamic and the clouds move and deform. The lighting is a (rather) simple trick but looks quite nice. I got the basic idea from an article by Michael Gehling in last months GDMag. I just modified it to suit my needs. The main problem I have is that it's very hard to tweak the system to look good in all situations. Settings that look good at dawn look crap at noon and vice versa. But I think I can solve that by interpolating settings over the day-night cycle.

Another problem is that things are getting rather costly as you can see on the fps counter:) So far I've done no optimizations what so ever so I think I can squeeze quite a few more fps out of this baby.

Here's a few new screenshots:

2006-04-04T21:38:00.000+02:00

I've added water to the engine. So far there's only reflections but refractions are coming up.

Now I need to render the scene multiple times per frame. The geometry that is going to show up in reflections is first rendered to a texture. This texure is then used in a second pass where the scene is rendered as normal but the reflection texture is projected onto the water plane. The same has to be done for refractions. The reflection pass is done with a lower LOD setting to increase speed, and the distortion of the water makes it very hard to notice the decreased LOD anyway.

I'm not totally happy with the way these multiple render passes are handled by the engine, so I think I have to redesign a bit. That's why I left out refractions for now.

2006-04-03T17:44:00.000+02:00

For the second assignment in the ASR course we took a dive into the beautiful world of Global Illumination.

We had to write a Monte Carlo path tracer. The math is a bit involved but it all boils down to a very simple algorithm. Take a loot at this slide for more information.

What you gain in simplicity you loose in speed. Since we approximate the rendering equation with random sampling (Monte Carlo integration) we need to sample a lot to reduce noise. The first image was redered at a resolution of 1024 x 1024 with 625 samples per pixel. It took 72 minutes to complete. The second one uses 2304 samples per pixels and took about 6 hours to render:)

I really like the second image. Note the caustics formed by light passing through the glass objects. Quite pretty! Kudos to Jesper for setting up that scene!

2006-03-30T03:01:00.000+02:00

I've completed the atmospheric scattering implementation, and now the terrain is also affected by the scattering. Here's a few screenshots:

2006-03-29T00:37:00.000+02:00

I'm working on a fully dynamic sky system. It's far from finished but I couldn't resist uploading a teaser screenshot:)

The system simulates atmospheric scattering, i.e. the effect of sun light scattering in different directions as it hits particles in the atmosphere.
This is what makes the sky blue at noon and red at dawn.
The method is described in this paper.

The sun in the picture is not a skybox or a billboard. It's a direct result of the scattering simulation!

I'll get back with more info as soon as I get this working perfeclty.

2006-03-28T11:49:00.000+02:00

Good procedural terrain texturing is not easy to achieve. That I learned yesterday.

In the old screenshots I used only one big blurry color texture and one detail texture. This wasn't very realistic since all types of surfaces used the same detail, resulting in for example that grass did not look like grass if I used a rock texture.

Now I use one argb detail texture per surface type and blend them together using a blend controller texture in a pixel shader.

The hard thing is to generate the blend texture. I've made a small tool that generates the this texture based on parameters in the heightmap like elevation and slope. However the result is not as good as I would like. But post-processing the texture in photoshop yields acceptable results;)

2006-03-27T13:21:00.000+02:00

Jesper and I have finished the first assignment in the "Advanced shading and rendering" course. We were given an unfinished raytracer and had to implement shading, shadows, reflections, refractions and super-sampling.

We had to implement at least one super-sampling scheme but we decided to make a comparision between a few schemes and ended up implementing uniform grid, stratified grid and adaptive. The latter is especially intresting since it tries to distribute the rays over the pixel area in a optimal way, resulting in good image quality and fast rendering.

The top screenshot shows the test scene rendered with 5x5 uniform grid super-sampling and the bottom shot is a close-up comparison between different sampling schemes.

2006-03-25T23:43:00.000+01:00

Today I extended the engine with support for vertex and pixel shaders.

Right now I have support for shaders written in HLSL but to the engine shaders is an abstract concept so there is nothing stopping me from adding support for other shading languages like Cg and GLSL transparently in the future.
Shaders are integrated into the effect/material system and I have a clean and simple interface for setting shader parameters from the engine. I intend to add support for automatic passing of common parameters like transform matrices to the shaders. Using shaders will be almost as easy as using the fixed function pipeline.

The terrain in the screenshot is rendered with per-pixel diffuse lighting and fog, using a pixel shader. In this kind of scene there is not much visual difference between per-vertex and per-pixel lighting, but when the sun is moving it's more apparent. Also the per-pixel fog is a lot smoother.
I use a slightly reddish sun color to give the impression of late afternoon lighting.

Now, with shader support in place, I can start doing some cool stuff :)

2006-03-23T23:54:00.000+01:00

I've done some minor improvments to the engine.
I added collision detection with the terrian so that the camera alywas stays on the ground.

I have also begun coding on a light management system. Until now I have hardcoded the sun into the renderer but now I have a more flexible system that handles unlimited (sort of) number of dynamic lights. Still need to add smarter culling of the lights though.

2006-03-22T22:21:00.000+01:00

Since I have a lot less to do in school now, I've started working on the engine again.

Today I finished the terrain LOD system. I'm using the popular GeoMipMapping technique and it works very well. To the left you can see two screenshots taken from the same viewport. The top picture shows brute-force rendering of the terrain and ~2 million triangles are drawn. In the bottom picture the LOD is activated and only ~45k triangles are drawn. That's only ~2% of the original triangles!

It's pretty hard to see any difference in the pictures, but if you look at the distant mountains you are able to see that the bottom picture misses some of the detail.

When the camera is moving it's sometimes possible to notice some popping when the terrain patches changes LOD but still I think the result is quite good for such a simple technique.

2006-03-19T01:50:00.000+01:00

The last few days I've been writing a simple I/O library in x86 assembly for a course at uni.
We had to use the GNU assembler and debugger. It's not my idea of fun to use command line tools like that ;) It was a pain in the butt in the beginning but I got used to it quite quickly.

The GNU assembler is a bit different from other assemblers like MASM. It uses different directives and instruction syntax. The instruction parameters is reversed and you have to use the %-prefix for registers.

movl eax, ebx

becomes:

movl %ebx, %eax

A bit anoying at first, but the parameter order actually feels more natural to me since I used to do a lot of MC68000 coding.
It's been a long time since I did this much assembly coding and while it's fun to optimize small routines, it's mostly annoying to write longer programs ;)
It's a good thing that high level languages gives us enough speed nowadays.

2006-03-15T23:43:00.000+01:00

The exams are finally over!
I haven't got the results of all of them yet, but I think I passed them all.

Today, I had the first lecture in Advanced shading and rendering. The lecturer is Tomas Akenine-Möller, one of the authors of the legendary Real-Time Rendering. That's pretty cool. I have high expertations of this course, and I don't think I'll be disappointed.

In this course we're using C++, so no more Python for a while! That's a good thing:)

2006-02-28T15:55:00.000+01:00

We have released our Bomberman clone! One minute before deadline:) It's not fast, it's not perfect, and it's certanly not bug free. But considering that it was put together in more or less one weekend we're very happy with the result.

You can check it out and download it here.

You can take a look at the work of the other project groups here.

2006-02-27T00:33:00.000+01:00

I've been working quite hard with the bomberman clone this weekend and we're getting there. I've done collision detection, physics (ODE), lighting, sound, and a some of the game play.

The engine we are using had some support for collisions with static geometry and ODE objects. But for dynamic objects like crates, bombs, players and powerups, I had to do it myself. I went for simple boundingspheres and sphere-sphere tests. For the bombs I'm using simple line segment-sphere tests. Simple and efficient.

Now there's only characters, AI and some game play left. But thats Jespers job so now I can focus on the other projects.

2006-02-24T00:20:00.000+01:00

The bomberman clone have to be finished till next Wednesday. Way to little time. Especially since I have projects in the other courses to finish as well. And there is not even two weeks till the exams. I have no idea how I'm going to make this!

Anyway, I've done some more work on the particle system. Now it can do a lot of stuff. A lot more than we need for the game, so you could argue that I wasted some precious time there. The good news is that I can port it to my C# engine in no time.

The screens shows the system in action. Pretty nice explosions with fire and smoke.

2006-02-23T01:16:00.000+01:00

Tonight I enhanced my particle system in the Python engine we're using for the Bomberman clone we're making. In the screenshot you can see my first attempt to use it for the bomb explosions. One of the most important parts of the game:) Pretty neat!

2006-02-21T23:34:00.000+01:00

I and Jesper are making a simple Bomberman clone in 3D as the mandatory project in the Game Engine Technology course. We put up a very simple project web page here (in swedish). You'll find a list of all this year's projects here.

2006-02-16T00:01:00.000+01:00

I threw together a lame particle system in Python for the Game engine tech course. I can't even count the number of times I ended a statement with ';'! Not that Python cares but it's not supposed to be there:)
I am using far to many programming languages in parallel right now. I wish they didn't try to teach us every damn language in the world at uni ;)

Game engine technology: Python
Web programming: Java, Perl (and the zillion markup languages that don't count)
Computer organization: MIPS and x86 assembly
...and ofcourse my engine: C#

I better improve my syntax switching skills...

2006-02-14T00:53:00.000+01:00

I have been working on the GUI system for a few days now. It's not complete, but I have what I need for now so I put it aside temporarily and started working on the terrain again.

I added simple multi texturing: one base texture stretched over the whole terrain and one tiled detail texture. The result is not as good as splatting but I think it looks suprisingly good. I guess I'll have a look at splatting when I have shaders implemented in the effect system.

I have a lot of stuff to do in school so guess I need to put the engine aside this week and get some 'real' work done ;)

2006-02-10T23:46:00.000+01:00

The GUI system is slowly emerging and today I added panel controls. All controls are skinnable. They are composed of a set of pieces that are read from a skin texture. As you can see in the screenshot I can set alpha and color individually. The nice drop shadows are slimply an alpha channel in the texture.

2006-02-08T22:54:00.000+01:00

I have begun coding a GUI system for the engine. The first thing to be completed is ofcourse text rendering. The fonts are simply textures created by this nice little tool and each character is rendered with a textured quad. Using a single font I can render texts in different color/alpha/size and use different aligning.

And yes, there are text in the old screenshots too but I cheated using D3DX fonts;)
I'm trying to keep things API independent, remember?

2006-02-06T17:17:00.000+01:00

I like Perl.

Normally I'm an OO purist. I also favor the C-family-style syntax. This is why i love C# and dig C++. But perl is fun. Just fun. And also quite brilliant.

Consider the UNIX command cat. It reads from standard input OR from files specified as arguments and outputs the content to the console.

In perl you could implement a basic cut command like this:

foreach (<>) { print; }

That's it. Try to do the same in C/C#/Java/whatever and you'll end up writing quite a few lines of code. Another example: the UNIX command sort.

foreach (sort <>) { print; }

Bloody brilliant. The cool thing about perl is that it makes easy stuff really easy. I wouldn't use it to code larger programs but for simple suff it's amazing. Also the code tends to get quite hard to read so it's not something I would use in team development:)

Again, coding in perl is fun. When you have tried the basic stuff it almost becomes a sport to write as little code as possible. And as you can see, perl is good at doing a lot of stuff in few lines of code.

2006-02-05T00:01:00.000+01:00

I just added texturing to the effects system. Nothing fancy, but at least my test scene looks a bit nicer :)

At the moment I'm taking a course called Game Engine Technology. Game physics is a part of the course and today I and Jesper (who also is coding a nice engine called Milk) played around with ODE (Open Dynamics Engine). In the course we use a simple game engine written in Python and we used a wrapper for ODE called PyODE. I'll have a rant about my thoughts on Python in another post, but the short story is that I'm not very fond of it.
However, using ODE worked like a charm and we got some nice ridig body physics up and running in no time since most of the stuff were already there in the engine. It's amazingly fun to throw boxes around and watch them collide and respond in a realistic (well, more or less) manner :)

2006-02-02T23:22:00.000+01:00

Today I started working on an effect/material system. It's inspired by the most common effect formats, CgFX and DirectX Effects. Think of an effect as a kind of high level shader. It encapsluates the whole rendering process for a specific visual apperance. An effect is devided in a set of techniques. A technique is a way to render the desired visual effect. A technique is then devided into passes. This is indeed very flexible. For example, imagine a human skin effect. Close to the camera the effect uses a technique that renders using costly vertex and fragment shaders and/or multiple passes that gives a very high visual quality. Farther away, the effect uses a cheeper teqnique with a single pass and cheep shaders at the cost of visual quality. But since the camera is now far away from the object the loss of quality will not be noticeble. All this is encpsluated in the effect.

The screenshot shows a simple test of this effect system. The sphere is rendered with a single effect that uses a two-pass technique. The first pass just sets the diffuse color to red and fillmode to solid. The second pass uses a yellow color and wireframe fillmode and depthtesting disabled.

So far it's all very simple, but now I have something to build on =)

By the way, I downloaded the new IE7.0 beta and kind of liked it.
Until I tried to edit my blog that is. It simply won't work. Luckily there is firefox=)
But it's still in beta so I guess I shouldn't be to harsh...

2006-01-31T20:59:00.000+01:00

Well, I think it's about time to write my first post on this blog!

There is much going on right now. My girldfriend is in India and doing her practice for her social work education. You can find her travel blog here (in swedish). I'm still in Lund and taking three courses at the university and I have started working on my C# 3D-engine 'Nebula' again.

The engine is written with 3D API independence in mind. Why, you might wonder. Most people tend to use Managed DirectX in the .NET world and that is ofcourse the most sane thing to do if you want to ever finnish your project :) However, I see this as a learning process and I don't want to constantly be temptated to take the easy road and use the goodies of D3DX utillity classes. By making it API independent I force myself to write everything myself! This ofcourse is not a philosophy I usually follow, but for learning stuff I think it's essential to do it all by yourself!

Up to this point, I have written a lot of boring plumming code like window management, scene graph management, resorce managment, vector and matrix math etc. The screenshot here is probably the first produced by this engine that is even a little bit intresting =). It features a heightmapped terrain with 1025 x 1025 vertices and simple Blinn-phong lightning. The terrain is divided in chunks of 65 x 65 vertices that are part of the scene grapth and culled against the view frustrum. I'm currently working on a GeoMipMapping implementation (LOD).

Well, thats about it for this time!