Having implemented those new post-processing filters & added more proper solar system physics, I decided to pick a fight with FRAPS & some random video editing software.

Aaaand in case you don’t see any improvements, here’s a historical perspective:

After an indulging xmas & a discussion with some random & professional close realtive, I decided to implement post-prodiction filters. Here are the results from

Waking up rather perturbed this early semi-xmas morning, I decided to implement planetary rings. Not very hard, really, just a plane going through the origin of the planet. However, it is the fragment shader that really does the job, imposing cutoff for length + generating noise patterns. In the end, turned out pretty decent for 2 hours work I’d say!

Ring shadow is ray-traced through the planet sphere, so shadows are genuine

The shadow ray-tracing works as such: if a ray with origin at the ring and direction towards the light-source intersects the planet sphere, there is shadow. This basically means solving a standard second order-equation, so if B^2-4AC<0, the ray does not intersect the planet and thus there is no shadow.

Planetary rings seen from other planet

Planetary rings are nothing but 1-dimensional Perlin noise P(l), where l = |x|. Then impose cutoff: if (l ≤ min or l ≥ max) discard the pixel. Yay!

Planetary rings seen from self planet

With bump mapping!

Here’s the whole fragment shader, in case you were wondering. Remember, the input is just *one* GL QUAD with 4 vertices, blending included:

float getRings(in float l) {
	float c = (0.6 + snoise2(vec2(l*0.7,0)));
	c+=0.4*snoise2(vec2(l*5.0,0));
	return c;
}

float rayIntersectSphere(in vec3 d, in vec3 o, in float r) {
	float A  = dot(d,d);
	float B = 2.0*dot(d,o);
	float C = dot(o,o) - r*r;
	float D = B*B-4.0*A*C;
	if (D ≤ 0.0) return 0.0;

	float t0 = (-B - sqrt(B*B - 4.0*A*C))/(2.0*A);
	if (t0≤0.0)
		return 0.0;

	return 1.0;
}

void main(void)
{
	float l = length(myPos)/fInnerRadius;

	if (l≤ringMin || l≥ringMax)
		discard;

	float c = getRings(l*10.0);
	if (rayIntersectSphere(v3LightPos, myPos, fInnerRadius)==1.0 )
		c*=0.3;
	gl_FragColor = ringColor*c;
	gl_FragColor.w = 0.7*c;
}

Some comments : snoise2d is a 2d perlin noise function and fInnerRadius is a uniform containing the radius of the planet while myPos is a varying vec3 containing the interpolated fragment pixel position, our origin of the ray (just myPos = gl_Vertex.xyz in the vertex shader)

So. I Rewrote the water shader, improving performance + fixing some bugs + making the color correspond to the planet atmosphere. Here are sunset results, with sun radiance reflection :


But here’s the cool part: the 2D heightfield class can now generate perlin type noise textures with normals as such:

in terrain space:

When this texture is applied in the terrain tangent space in the fragment shaders as additional terrain normals, something wonderful happens: bump mapping occurs. And suddenly, the terrain becomes way more vivid and alive, because the amount of (apparent) details is increased about a tenfold. Cheating? Yeah sure, but cheating never looked so good =)

Scene without bump mapping

Scene with bump mapping

Random scenes with bump mapping & new water shader

After battling with the vertex and fragment shader a couple of days, I finally managed to implement Eric Brunetons fantastic method. Parameters still needs to be tweaked to make the scene look good, reflections needs to be added and the refractions are not quite right yet.

… but it beats the crap out of not having water!

So. It was never a secret that the planet-renderer code was *slow*, and that the quadtree still had those *particularly* annoying quadtree gaps.

But wait! All that changed when I a) implemented multi-processor support using MPJ Express and b) spent a rainy day filling those quadtree gaps with armored concrete.

The really amazing new thing is that *all* geometry generation is now done by the slave processors, and the main processor is free to only render the scene. In other words: the code runs with max fps, and the dynamical creation of geometry never “jerks” the scene.

So what does this mean? Well I could finally make a video =)

Ok. So heavy coding and reading for the exams usually don’t combine that well, but this year things are turning out quite wonderfully! My exam in old babylonian is next monday, and after that I’ll have a smoking hot new computer =)

So. First things first. I am trying to document my progress by writing a silly tutorial of the project here. So, what am I currently working on?

Rivers

Basically tweaking the multiridged perlin noise and doing some stuff.. however, was thinking about checking out this interesting paper when I have more time!

GPU colors & textures

New stuff : texture coordinates, colors & normals are generated on the GPU!

Clouds

Clouds are now generated on GPU. However, I still need to tweak parameters to generate weather-like patterns on planetary scales.. and lighting is not correct yet. But, better than nothing I guess. Will post some videos of weather patterns before xmas!

GPU Terrain

I have implemented shaders that calculate vertex positions / fragment shader normals from the multiridged 3D perlin noise. However, my crummy macbook from 2008 is complaining badly – so I am currently awaiting my new computer, GeForce GTX 560 included! Then the buns will be different. Yeah. Norwegian idioms rule.

ka-*swing* : GUI

Swing saved my life! Not many parameters to play around with yet.. but at least it is starting to look like a real program. In real-time, that is.

Some profound changes have taken place recently. As mentioned, I quit my post-doc position at the university in order to work for SINTEF IKT. The department is an official NVIDIA CUDA research group, and I will finally be learning some new and interesting stuff:

• Proper C++, templates and OOP patterns / methods
• CUDA and GLSL done right
• Project design and management

I mean, seriously, I think I really need to become better at this stuff. I never seem to finish any of my code projects, and they are usually riddled with design problems and inconsistent code. So it’s time to do something new!

The only “proper” project I have been working on recently has been a cosmological N-body simulator for use at the University of Oslo. Alas, the project (duh) has currently been put on hold for obvious reasons.

Cosmological N-body particle system

check out MyBodys homepage

Now, at SINTEF my first project is co-developing a SPH particle code. MS Visual C++. Heavy templates & design patterns. So I’ll grab as much experience from this and continue working on the CiRIOBase-library as much as possible!

But first, a quick holiday to Rome =)