Shaders’ Outpost

[JensAyton]

1) that’s a convex surface.
2) on flat surfaces, you don’t get small highlights like that (unless the light source is up close); the entire surface lights up if the angle is right.

I suspect, though, that Griff’s revised fuel leak would look less strange on a moving object. Still, I’d reduce the exponent slightly.

[Griff]

come to think of it, the fuel leak does look like a hole in the object! might be a cool idea to tie that effect to a variable of some sort and get it to spread out across the surface of the ship until it becames totally dark and glossy like some sort of cloaking device effect or something, maybe tie it into the engine_level so as it accelerates it transforms?

[Arexack_Heretic]

@Ahr.
You are right. I always mix those two up. :duh:
And I know about 'flat' surfaces reflecting. :p

The 'invisible' effect is mainly from the similarity to the background colour, I think.
So be sure to have some way of sampling the ambient colours.

I'm sure ray-tracing (or whatever it is called) is not what we are using here to give reflections and such.

[Arexack_Heretic]

Say, with spawnTime(floatingpoint) now available (v1.69), the glowy_alloys can decay over time can they not?

[JensAyton]

Yes. I’m working on that demo, alongside some other stuff. :-) (It uses timeElapsedSinceSpawn, though.)

[JensAyton]

As promised, an updated version of Griff’s glowing alloy (the original version with only one model, for simplicity), demonstrating new 1.69 features. Noteworthy stuff:

• Uses a uniform binding to “cool down” over time (specifically, 45 seconds).
• No texture duplication. The material key/non-shader diffuse map may now be used as a texture provided to the shader.
• Files now have somewhat sensible names. The next person to release something called “alloy1.dat” gets it up the posterior.
• shipdata.plist is in OpenStep format rather than XML. This should mostly work, although it’s possible that there are some keys that won’t work this way.

I also changed the MetalGlow function. It’s similar to the temperature glow function from the Shady Cobra, but redder. The function fades from white through yellow and red to black, rather than maintaining the same hue; this provides a much better approximation of the behaviour of cooling metal. (For realism, the temperature should really have exponential falloff rather than linearly fading.)

Artistically, I think it would look better if the burned areas were charred into the metal (blackened in the diffuse map, low specularity).

Edit: edited for clarity.
Edit: edited for spelling.

[Griff]

not being able to see the changes in colour your shader code would generate from different values of the 'heat' variable was always a big dissapointment in that release of the glowingalloys.oxp.
That's a great idea about scorching the hottest areas of the surface too, i'll rework the textures to add this in i think.

edited to remove far too many occurances of the word "great!"

[Uncle Reno]

As promised, an updated version of Griff’s glowing alloy (the original version with only one model, for simplicity).

I get a message at the Oolite start screen that this OXP isn't compatible with 1.68, is this a problem.

[United Blobs]

According to the wiki page on uniform bindings (as linked in Ahruman's post):

The information presented on this page applies to Oolite test release 1.69 and later.

So unless you're using the unreleased v1.69 then you can't use it.

[Uncle Reno]

Whoops, sorry , obviously not paying attention.

Thanks for the answer United Blobs.

[Griff]

sorry, i added to the confusion there. i was looking at the Ahruman shader in a program called rendermonkey, it allows you to add 'slider' type controls to variables, i'd linked one of these to the 'time' variable and was able to see the cooling effect by interactively moving the slider.

[Uncle Reno]

No worrys Griff, I was obviously too eager. It sounded cool, I knew I wouldn't understand all the detail so didn't read too closely, downloaded the OXP and dumped it into my AddOns folder. I obviously looked after I leapt!

[JensAyton]

I’ve decided to deprecate the old fixed set of uniforms: engine_level, entity_personality, entity_personality_int, hull_heat_level, laser_heat_level and time. These will be supported transitionally in 1.69, and removed in future releases. The same functionality can be achieved using property bindings in 1.69 and later. For instance, if you use time, you will need to add the following code to your shader dictionary in shipinfo.plist (no shader change required):

Code: Select all

uniforms =
{ 
    time = universalTime;
}

or in XML:

Code: Select all

<key>uniforms</key>
<dict>
    <key>time</key>
    <dict>
        <key>time</key> <string>universalTime</string>
    </dict>
</dict>

At the same time, the relevant uniform availability macros will be removed: OO_ENGINE_LEVEL, OO_ENTITY_PERSONALITY, OO_ENTITY_PERSONALITY_INT, OO_ENTITY_LASER_HEAT_LEVEL, OO_HULL_HEAT_LEVEL, OO_TIME.

Edit: The examples above use a simplified binding declaration syntax, and the wiki page has been updated to reflect this. To support this change, it is no longer possible to declare constant numerical uniforms with similar abbreviated syntax. I believe this was only done in Freaky Thargoids, which will be updated once 1.69 is out.

[JensAyton]

Freaky Thargoids has been updated for 1.69. In addition to using an explicit binding for the time, it also does away with the redundant copies of textures.

[JensAyton]

Do shader bindings work in 1.69 under Windows? For instance, does the new version of Freaky Thargoids work, and the fading-over-time version of glowing alloy? (In the latter case, reducing the decay time in the shader might be helpful for testing.)