Jump to content

  • Log In with Google      Sign In   
  • Create Account

Phyletic gradualism

New Project - Star Blaster (working title)

Posted by , 20 August 2011 - - - - - - · 803 views
unity

Yet Another New Project


Time for yet another new project: a 3D space shooter using the Unity engine, tentatively titled Star Blaster. (A quick google indicates at least 2 other games with the same title exist, so I'll probably change the name when I've thought of a different one).

Since Gamedev are awesome enough to allow hosting working Unity apps with the GDNet webspace (big thumbs up for that), I shall try to upload the latest build as frequently as possible, and keep a log of changes made here. It's not going to be anywhere near a decent game for quite some time (and the graphics will likely suck for just as long), but feel free to provide any feedback here.

The latest build can be found here.


Current Features


What's implemented so far is very basic: You can fly the ship around, and it's followed by the camera. \o/

The camera is attached via a configured 6DOF PhysX joint, with springs to return it to the defined anchor rotation behind the ship. I'm pretty happy with how this has turned out, though it might need a bit of adjustment when there's more than one ship type in game.

The ship control scheme is WASD for forwards, backwards and strafing, and mouse for pitch / roll. The space bar provides an additional booster, and left shift cuts the engine and turns off drag (à la Freelancer's tab / z keys). I'm not really sure I like the pitch / roll model, and will probably implement a rotate towards type thing for comparison (the real test probably will come when turrets / shooting exist).


What's Next?


First up is fiddling with the Unity WebPlayer Template to show a keyboard layout below the WebPlayer. Then I probably need to think up some sort of hardpoint system, for simple creation of different engine types / effects and weapons turrets etc.

See the next page for ongoing progress this week.








Tri-planar textures and bump mapping

Posted by , 10 April 2011 - - - - - - · 3,873 views
bump mapping, tri-planar, opengl
Last summer I started on a project that stalled largely due to my apparent compulsion to write engines, not games, excessively ambitious scope, lack of a realistic project plan and a masochistic hardware target (OpenGL 4.x). However, since ATI seem to have fixed a couple of driver bugs that were plaguing development (for loops with uniform conditionals, and a hideous driver crash), I spent the weekend fiddling with lighting and bump mapping. Even with just two rather amateur test textures I don't think it looks too bad:

Attached Image

The bump mapping was a bit painful, due to using tri-planar texturing for the terrain. While the relevant GPU Gems article touches on the subject of bump mapping, it doesn't really go into detail. Still, I seem to have ended up using a hacky method similar to the code in the article.

The scribbles below show my thinking out the tri-planar texturing method, and the coordinates needed. I'm using the same texture on multiple "sides" of the projection for the moment, and seem to have a slightly different mapping from the article (notice that on all the sides of the cube UP is upwards, not on its side). Splitting out the 6 cases I wanted, the correct texture coordinates can be figured out from the world (/object) space position (they can be combined into 3 by using the sign of the relevant normal).

Attached Image

So far I've not managed to properly generate tangents to perturb the normal, so I'm just swapping the x / y displacement to the relevant world-space axis each for the tri-planar projection, adding it to the normal and normalizing. This is what the bump vector is on the right of the scribbles.

And here's a test image of the terrain using the tri-planar projection:

Attached Image

The snippet of glsl below shows the end result of the scribbles in code. I'm currently using a default texture, and an array of alpha maps / other textures - I might simplify this to include the default in the array at some point. I'm using noise to sharpen and randomise the transition between different textures - this could also be improved, perhaps taking into account the bump map.


	// get terrain normal (already normalized)
	vec3 normal = texture(NormalsTexture, TexCoords).rgb;

	// calculate triplanar texture weights
	vec3 tpweights = abs(normal);
	tpweights = (tpweights - 0.2) * 7.0;
	tpweights = max(tpweights, vec3(0.0));
	tpweights /= tpweights.x + tpweights.y + tpweights.z;

	vec3 signs = sign(normal);
	
	vec2 tpcoord1 = vec2(vec2(-signs.x * Position.z, Position.y) * DetailTexCoordScale);
	vec2 tpcoord2 = vec2(vec2(signs.y * Position.x, -Position.z) * DetailTexCoordScale);
	vec2 tpcoord3 = vec2(vec2(signs.z * Position.x, Position.y) * DetailTexCoordScale);
	
	// noise value for blending
	float noise = 0.0;
	noise += tpweights.x * texture(NoiseTexture, tpcoord1 * NoiseCoordScale).r;
	noise += tpweights.y * texture(NoiseTexture, tpcoord2 * NoiseCoordScale).r;
	noise += tpweights.z * texture(NoiseTexture, tpcoord3 * NoiseCoordScale).r;
	
	// collect detail texture data based on alpha maps
	float alpha_accum = 0.0;
	vec3 detail_color = vec3(0.0);
	vec3 detail_normal = vec3(0.0);
	
	for (int i = 0; i != NumDetailTextures; ++i) {
		float alpha = texture(AlphaTextureArray, vec3(TexCoords, i)).r;
		
		// modulate alpha value with noise, to get sharper, but noisy transitions
		alpha = smoothstep(0.48, 0.52, alpha + noise - 0.5);
		
		// calclate triplanar detail colour
		vec3 dc = vec3(0.0);
		dc += tpweights.x * texture(AlbedoTextureArray, vec3(tpcoord1, i)).rgb;
		dc += tpweights.y * texture(AlbedoTextureArray, vec3(tpcoord2, i)).rgb;
		dc += tpweights.z * texture(AlbedoTextureArray, vec3(tpcoord3, i)).rgb;
		
		detail_color += min(alpha, 1.0 - alpha_accum) * dc;
		
		vec3 bump1 = tpweights.x * normalize(texture(NormalTextureArray, vec3(tpcoord1, i)).rgb * 2.0 - 1.0);
		vec3 bump2 = tpweights.y * normalize(texture(NormalTextureArray, vec3(tpcoord2, i)).rgb * 2.0 - 1.0);
		vec3 bump3 = tpweights.z * normalize(texture(NormalTextureArray, vec3(tpcoord3, i)).rgb * 2.0 - 1.0);
		
		vec3 dn = vec3(0.0);
		dn += vec3(0.0, bump1.y, -signs.x * bump1.x);
		dn += vec3(signs.y * bump2.x, 0.0, -bump2.y);
		dn += vec3(signs.z * bump3.x, bump3.y, 0.0);
		
		detail_normal += min(alpha, 1.0 - alpha_accum) * dn;
		
		alpha_accum = min(1.0, alpha_accum + alpha);
	}
	
	// fill remaining alpha "space" with default detail colour
	vec3 ddc = vec3(0.0);
	ddc += tpweights.x * texture(DefaultAlbedoTexture, tpcoord1).rgb;
	ddc += tpweights.y * texture(DefaultAlbedoTexture, tpcoord2).rgb;
	ddc += tpweights.z * texture(DefaultAlbedoTexture, tpcoord3).rgb;
	
	detail_color += (1.0 - alpha_accum) * ddc;
	
	vec3 bump1 = tpweights.x * normalize(texture(DefaultNormalTexture, tpcoord1).rgb * 2.0 - 1.0);
	vec3 bump2 = tpweights.y * normalize(texture(DefaultNormalTexture, tpcoord2).rgb * 2.0 - 1.0);
	vec3 bump3 = tpweights.z * normalize(texture(DefaultNormalTexture, tpcoord3).rgb * 2.0 - 1.0);
	
	vec3 ddn = vec3(0.0);
	ddn += vec3(0.0, bump1.y, -signs.x * bump1.x);
	ddn += vec3(signs.y * bump2.x, 0.0, -bump2.y);
	ddn += vec3(signs.z * bump3.x, bump3.y, 0.0);
	
	detail_normal += (1.0 - alpha_accum) * ddn;
	
	// hacky normal mapping
	normal = normalize(normal + detail_normal * BumpScale);
	
I'm still not 100% satisfied with this, and will probably try out the method of generating a tangent basis touched upon in the GPU Gems article and see if it looks better. In the mean time I'd love to hear if anyone else has done any bump mapping with tri-planar texturing, and how you got it to work.

Cheers,

__sprite


A Picture

Posted by , 08 April 2011 - - - - - - · 544 views
deferred lighting, pic-spam
Deferred lighting:

Attached Image

Because it's pretty.