Shaders’ Outpost

[Eric Walch]

there's 3 plumes on this ship and even though i tried differing length values for each of them they always seem to be drawn exactly the same length as each other when in game? anybody else see this or is it just me?

I noticed something similar with the Dredgers. Although I doubled the value the plumes didn't became longer. I thought is was because the ship always flew at very low speed.

[Griff]

It might be my eyesight, but I'm convinced that if there's more than one exhaust plume on the ship, they are all being set to the same length, and i think it's the longest one that's listed in the array.
eg

Code: Select all

exhaust = (
	 "-0.0234 19.1309 -36.2109  2.5  2.5   10.0",
	 " 7.6025  8.1322 -31.6873   4.0  4.0     7.0",
	"-7.5495   8.1322 -31.6873   4.0  4.0     2.0"

all three of these exhaust plumes are going to be 10.0 units long. I think i'll fill in a bug report.

[Griff]

Whilst clearing out my bookshelves i found my old C64 Elite Game Manual & Ship ID Chart! No Dark Wheel Novella though
To celebrate i thought i'd try and recreate the shading style used on the Ship ID chart ingame, I've come up with something similar, it's not quite right, but it looks fairly cool in game.
The C64 Ship ID Chart: (appologies for the rather large scans)


A cobra3 ingame, using the shipID chart shading style:


I've only got the cobra done at the moment, but i think i'll do them all!
download: http://www.box.net/shared/htxeczmvmh

[pagroove]

Cool that should also be offered besides wireframe play. A sort of retrostyle 2

[Griff]

Arcelite style flat colour shader.




edit: updated link to newer version
download: http://www.box.net/shared/gej970qtqj (about 135KB)

This style of shading only applies to the ships in this oxp, it's not a new rendering option built into the game.
I've tried to include all the arcelite ships listed over on that amazing website in the paper models thread in the discussion forum, there are some odd ones like bushmaster, caiman etc that i've not yet put into the oxp as i'm unsure of their stats.
I've got a lot of tweaking still to do - checking laser firing positions/view positions for the player versions etc are correct and if anybody who knows the archimedies version of elite can provide some stats for the arcelite specific ships i'd be really greatful. the ships might all need rescaling down too
edit: small update - a bit of a cheat, but rather than scaling down all the ships so they looked like they might fit into the bay when launching & docking i just scaled up the stations a bit! fixed the tiny thargoid problem too.

[JensAyton]

This style of shading only applies to the ships in this oxp

You should be able to override oolite-default-shader.fragment, but it’d have some limitations:

• It would only work properly in full shader mode, and affect only some ships in simple shader mode.
• Ships with their own shaders would not be affected.
• All ships not known to the OXP would be the same colour.

[Arexack_Heretic]

That exhaust length is surely a bug.
I used to do variable lengths all the time. (the ATT1 for one).

[Griff]

Hi A_H, nice to see you back on the boards!

Ahruman, on page 11 of this thread, you mention having added in support for vec3's as uniform bindings, i don't suppose you could post an example of how this would be written in a shipdata.plist, i'm having problems working out the syntax.
I'm working on 'paint' shader, basically recolouring the alpha channel in a texture and adding it back in as a colour, I'd like to use uniform bindings to specify what colour the alpha should be.

also, i was wondering about using the 'entityPersonality' uniform as a float value for a colour channel to randomise ship colours, if possible, could we also get 2 more random floats the same as entityPersonality so we can have random values for all three RGB channels - or will this just end up creating a lot of murky, bizzarely coloured ships?
edit: i just had a bit of a play around with this idea in rendermonkey, typing different values into the shader to emulate random values as if they'd been supplied by oolite and most of the results were really horrible, it might be best to just drive one channel using entityPersonality and give the other 2 colour channels fixed values in the shader.

[JensAyton]

Ahruman, on page 11 of this thread, you mention having added in support for vec3's as uniform bindings, i don't suppose you could post an example of how this would be written in a shipdata.plist, i'm having problems working out the syntax.

Any of the following should work:

Code: Select all

uniforms =
{
    u1 = { type = vector; value = "0.5 0.7 1.0"; }
    u2 = { type = vector; value = ( 0.5,  0.7, 1.0 ); };
    u3 = { type = vector; value = { x = 0.5; y = 0.7; z = 1.0; }; };
}

The following will work in 1.72:

Code: Select all

    u4 = (0.5, 0.7, 1.0);

also, i was wondering about using the 'entityPersonality' uniform as a float value for a colour channel to randomise ship colours, if possible, could we also get 2 more random floats the same as entityPersonality so we can have random values for all three RGB channels - or will this just end up creating a lot of murky, bizzarely coloured ships?

But what if you need four random values? ;-)

I think I’ll just add some uniform types for random values.

Edit: fixed syntax

[Griff]

Thanks for that Ahruman, i couldn't get it working though, is that because it's only available in the build-it-yourself oolite version? i kept getting this error:

Code: Select all

oolite.exe[3336] [shader.uniform.set]: Set up uniform <OOShaderUniform 0x12b73e8>{0: (nil) PaintRGB = INVALID;}

in the shipdata i've got the uniform declared like this:

Code: Select all

PaintRGB = { type = vector; value = "0.5 0.7 1.0"; }

I tried all 3 examples you posted above, but they all gave an error, infact the third one gave a parse error in shipdata.pist.
in the fragment shader i've got:

Code: Select all

uniform vec3   PaintRGB;

Anyway, here's a working version of the idea that instead of using 1 vec3 uniform binding for the paint colour, it uses 3 seperate float bindings for the R, G & B values.
Edit: fixed using Ahrumans advice below, the oxp now uses 1 vec4 binding for the paint colour
paintjob cobra
http://www.box.net/shared/s3su7s3qt2

[JensAyton]

Thanks for that Ahruman, i couldn't get it working though, is that because it's only available in the build-it-yourself oolite version? i kept getting this error:

Code: Select all

oolite.exe[3336] [shader.uniform.set]: Set up uniform <OOShaderUniform 0x12b73e8>{0: (nil) PaintRGB = INVALID;}

That’s actually a bug in the debug code for displaying binding objects. Vector bindings do work. However – and I only just noticed this – you have to use vec4, not vec3. (The a component is always set to 1.0. I’ll probably allow an optional a component to be specified at some point.)

infact the third one gave a parse error in shipdata.pist.

Typo, fixed.

[Griff]

Here's my attempt at a wavy flag shader

http://www.box.net/shared/hy4dlqauzd
It sort of works ok, i haven't worked out how to get more than 1 'ripple' at a time, plus the flag has to be modeled in a certain way as the Z co-oords are used to weight the wavy effect, which is a bit of a pain.

[Frame]

@Griff: one ripple at a time

I presume you made this code based on the shader code i posted in another thread..

Inside the hard code of the c++ there is the following loop

Code: Select all

// Start Drawing Our Mesh
	for (int x = 0; x < SIZE - 1; x++)
	{
		// Draw A Triangle Strip For Each Column Of Our Mesh
		glBegin(GL_TRIANGLE_STRIP);
		for (int z = 0; z < SIZE - 1; z++)
		{
			// Set The Wave Parameter Of Our Shader To The Incremented Wave Value From Our Main Program
			cgGLSetParameter3f(wave, wave_movement, 1.0f, 1.0f);
			glVertex3f(mesh[x][z][0], mesh[x][z][1], mesh[x][z][2]);		// Draw Vertex
			glVertex3f(mesh[x+1][z][0], mesh[x+1][z][1], mesh[x+1][z][2]);	// Draw Vertex
			wave_movement += 0.00001f;									// Increment Our Wave Movement
			if (wave_movement > TWO_PI)									// Prevent Crashing
				wave_movement = 0.0f;
		}
		glEnd();
	}

As you can see it runs the entire length of the mesh, instead of just parts of it..

however i´m unsure wheter or not you can run for if loops inside a vertex fragment file.. but if memory serves me correct, you can..

[JensAyton]

Code: Select all

// Start Drawing Our Mesh
	for (int x = 0; x < SIZE - 1; x++)
	{
		// Draw A Triangle Strip For Each Column Of Our Mesh
		glBegin(GL_TRIANGLE_STRIP);
		for (int z = 0; z < SIZE - 1; z++)
		{
			// Set The Wave Parameter Of Our Shader To The Incremented Wave Value From Our Main Program
			cgGLSetParameter3f(wave, wave_movement, 1.0f, 1.0f);
			glVertex3f(mesh[x][z][0], mesh[x][z][1], mesh[x][z][2]);		// Draw Vertex
			glVertex3f(mesh[x+1][z][0], mesh[x+1][z][1], mesh[x+1][z][2]);	// Draw Vertex
			wave_movement += 0.00001f;									// Increment Our Wave Movement
			if (wave_movement > TWO_PI)									// Prevent Crashing
				wave_movement = 0.0f;
		}
		glEnd();
	}

This is of no use in a shader. It’s just drawing a mesh, which Oolite has already done for you. Vertex shaders always work on a single vertex at a time.

In order to have more than one ripple, you need to change the frequency of the waving. To do this, simply multiply the parameter of sin() by some factor. But for it to look any good, you’ll need more vertices – I can’t be bothered to do the maths properly, but I think you’re already getting aliasing (that is, the frequency of your sine wave is higher than the distance between each column of the flag, and the result is a wave of a lower frequency).

For your next trick, modify the surface normals so the flag is illuminated correctly. :-)

[Griff]

Hi Frame
I did study the code example for a bit, but i ended up trying to invent my own solution using 'griffmaths' - a little known school of mathematics in which problems are solved using a process of cutting and pasting bits of other peoples sums around in rendermonkey.

right, i *think* i've done the surface normal modifying thing to get the flag lit more realistically, basically i just bunged the v_normal though the wave_deform effect like this:

Code: Select all

v_normal = normalize(gl_NormalMatrix * gl_Normal + wave_deform_effect.x * 0.15);

not sure if this is right? it sort of looks ok, but then again i don't really know what i'm doing. I've updated the oxp and uploaded it to the same link as above.