Griff's normalmapped ship remakes

[JD]

That's a fantastic effect.

falls to about 40% the effect will kick in - to be honest it looks a bit silly as when the ship builds it's energy back up all the burnt off paint comes back as good as new!

I wonder whether it would be possible (and obviously this is something only the devs could answer) to define a ship property that allows you to specify "when this ship dies, defer the explosion for x seconds". That way, your effect could kick in only when the ship is indisputably and irreversibly dead, and the hull could burn up for a few seconds before total annihilation.

Of course, there could be more than a few unintended side-effects of deferring its destruction.

[Griff]

@JD - I think what might be possible is when the ship dies, explode it as normal but spawn a copy in exactly the same place as the original was when it died and give it a burning away shader effect, like this

I played a space game awhile back called sol exodus I think, and this is what they did with exploding ships in that game - it looked cool - especially if the clone could be spawned with slightly different heading & rotation to the original ship so it looked this it was veering out of control as it burns up!

if you take out the flames and use a smoother blend effect between the paint and dust map you can get a sort of dirt build up effect:

car wash.oxp ?

[Tichy]

if you take out the flames and use a smoother blend effect between the paint and dust map you can get a sort of dirt build up effect:
car wash.oxp ?

Mmmh... Your ship needs periodical maintenance. Could it be linked to this effect?

...and the burning effect for ships adrift

[Griff]

Mmmh... Your ship needs periodical maintenance. Could it be linked to this effect?

I don't think there's a suitable timer that the shaders could use to count how long it's been since you last had maintenance done on your ship - hmm, well according to the list of available shader bindings http://wiki.alioth.net/index.php/Shader ... :_uniforms there's "trumble count" - I wonder if that could be misued somehow to add an invisible trumble to the ship every day or so and that phantom trumble total could be used as a days since maintenance timer for the shader? it would have to be a non breeding and never hungry trumble though, if such a thing exists

[Mauiby de Fug]

A similar functionality to that used in visual effects would be useful here. For those, there are half a dozen uniforms that can be bound to what ever you like (type permitting)...

shaderFloat1 : Number (read/write)
shaderFloat2 : Number (read/write)
shaderInt1 : Number (read/write)
shaderInt2 : Number (read/write)
shaderVector1 : Vector (read/write)
shaderVector2 : Vector (read/write)

These you can modify and bind via a script. I am not aware of the ability to do this for shaders for models, but if you can, then playerShip.serviceLevel would be the thing to look at.

[cim]

I don't think there's a suitable timer that the shaders could use to count how long it's been since you last had maintenance done on your ship

tradeInFactor (int 75-100) will be available as a shader uniform in 1.79 for the player ship.

A similar functionality to that used in visual effects would be useful here

Potentially. Though, that's done that way because visual effects don't have any inherent properties. It's (usually) pretty straightforward to allow an existing ship property to be used as a uniform binding, and means you don't have to tie a frame callback to the ship to keep it updated. If there are any others you'd like, just ask.

[Cody]

I don't think there's a suitable timer that the shaders could use to count how long it's been since you last had maintenance done on your ship

tradeInFactor (int 75-100) will be available as a shader uniform in 1.79 for the player ship.

Sounds good. Could the NPCs have differing (fixed) amounts of 'dirt' on them too - some would look clean, others not so.

[Griff]

oo that's exciting news cim about the extra shader binding in v1.79 I've written 'tradeInFactor' on a post-it note and stuck it to my computer screen so I don't forget about it when the time comes!

[Mauiby de Fug]

Potentially. Though, that's done that way because visual effects don't have any inherent properties. It's (usually) pretty straightforward to allow an existing ship property to be used as a uniform binding, and means you don't have to tie a frame callback to the ship to keep it updated. If there are any others you'd like, just ask.

True enough. However, if we consider the first instance, the burning damage shader, Griff pointed out that it would automatically heal the ship as the ship regained the energy. By using the arbitrary method, you can easily set a variable to store the hull damage, which will then remain for NPCs and so one can see increased damage after every battle.

The obvious drawbacks of this method are, as you say, the requirement of a script and a frame callback. But I can't think of an alternative off the top of my head, I don't belive there is a tradeInFactor equivalent for NPCs...

[Griff]

Could the NPCs have differing (fixed) amounts of 'dirt' on them too - some would look clean, others not so.

yes, oolite can generate a random number for the shader to use when a ship gets spawned, it could control the amount of dirt to apply to the ship. I don't know if there's a way of including the current system type or anything like that into it though (I assume the dirtiest ships will be in anarchies) but pirates, miners etc could be given a shader that mixes in more dirt than the shader would for a trader ship

[Mauiby de Fug]

Code: Select all

  20:13:32.789 [shader.compile.failure]: ***** ERROR: GLSL fragment shader compilation failed for griff_viper_pursuit.fragment:
>>>>> GLSL log:
0:116(83): error: syntax error, unexpected ')', expecting ',' or ';'


20:13:32.789 [shader.load.failed]: ***** ERROR: Could not build shader griff_normalmap_ships.vertex/griff_viper_pursuit.fragment.

Error is line 116, which is:

Code: Select all

      color += max(wave(uTime), 0.0) * (flasherMap.r + flasherMap.b) * FlasherColor,0.0);

This is the Simple shader mode emergency lights section. Skimming through the rest of the shader, I assume that the ",0.0)" at the end of the line is unnecessary?
This is from the Current Griff_Shipset_Resources_v1.2.25.oxp linked to from the wiki...

[Griff]

I'm not at my oolite computer at the moment to test but it looks like there aren't enough opening brackets around that last bit of the code, hmm, prehaps they're not even needed at all and the line should be

Code: Select all

color += max(wave(uTime), 0.0) * flasherMap.r + flasherMap.b * FlasherColor;

[JazHaz]

Error is line 116, which is:

Code: Select all

      color += max(wave(uTime), 0.0) * (flasherMap.r + flasherMap.b) * FlasherColor,0.0);

There's 3x "(" and 4x ")" in the above line so maybe that's the error?

[Mauiby de Fug]

Not only is there the extra bracket, but as FlasherColor is a const vec3, the numbers following make no sense at all. I've had a proper look through the shader now. It is the simplified equivalent of line 138, which is:

Code: Select all

       color += lightLevel * (flasherMap.r + flasherMap.b) * FlasherColor;

So as I suggested, simply removing the offending ",0.0)" from the end of the line ought to do the job.

[Griff]

yep you're right, the line needs to be this

Code: Select all

      color += max(wave(uTime), 0.0) * (flasherMap.r + flasherMap.b) * FlasherColor;

looks like some sort of copy paste mangling went on in that bit of the shader, I think that ,0.0 at the end seems to be a repeat of the max(wave(uTime), 0.0) statement at the start of the line