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)

Scene without bump mapping

Scene with bump mapping

Random scenes with bump mapping & new water shader

]]> http://irio.co.uk/sites/cirio/?feed=rss2&p=650 0 http://irio.co.uk/sites/cirio/?p=644 http://irio.co.uk/sites/cirio/?p=644#comments Mon, 19 Dec 2011 11:14:59 +0000 leuat http://irio.co.uk/sites/cirio/?p=644 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!

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 =)

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.