Shaders’ Outpost

[cbr]

Above the 'geo' version.
Below the current Griff glowmap with hexagon overlay.

both interesting options...

[Redspear]

Gave the lower of those two wiremaps (from cbr's screenshot above) a try.

First impression:

• Impressive

What worked well:

• The day/night discriminator from the planet code helped enormously and combined well with the thin lines of the wireframe so as not to overpower when the ship was part illuminated
• Changing the colour of the effect was a simple matter of RGB values
• The double lines of the 'V' on the back/belly of the sidewinder almost merged at long range, giving the illusion of a thicker line and therefore greater visibility

What didn't work so well:

• At very close range, the wireframe being off is both no longer necessary nor is it helpful... suspect it could be useful for something else however - more thinking needed on my part
• Including so many of the model's lines made the aft of the vessel look very cluttered - unlike the simple elite sidewinder model with it's clear rectangular engine

What was I on the fence about:

• Thin lines/thick lines... I WAS very much in the 'thicker' camp and the sidewinder model is interesting in that it partially achieves both. Hmm...

Will likely post screenshots when I have more time.

Well done Griff!

[Redspear]

Firstly, these screenshots don't do the effect justice (loss of resolution?) but...

It's quite a subtle effect, as can be seen from this rotating sidewinder.







Changing wireframe colour to cyan was easy but busy areas of the model can look a bit overwhelming regardless.





This is already pretty awesome as is and the previous post is just my nit-picking

[Redspear]

For a hopefully clearer illustration, wireframe colour intensity can be ramped up quite a bit if so desired.

Compare this



with this



Coming into close range (notice how the ship would otherwise be indistinct against the blackness of space)



Pretty close, yet still otherwise near invisible



Being able to ramp up the brightness seems to placate any concerns that I had about lines being possibly too thin.

Griff this is absolutely brilliant (sorry, ) and my game experience will now soon eventually be totally transformed for the better. Thanks so much

[another_commander]

I don't know how exactly you raise the brightness of the wireframe, but if it is by adjusting the emission_modulate_color of an emission map, be aware that in current trunk you can go crazy with the emissive colors and actually make them glow by getting them to bloom. Just use this format: emission_modulate_color = {red=6750.9520; green=6780.9630; blue=3280.8824;};

The numbers in the dictionary should be your desired color component * 256. The above example corresponds to RGB (26.37, 26.488, 12.816), which is high enough to get the 1.91 engine to apply bloom to it. Also note that the above dictionary format is the only way to pass this kind of high color values. Any other format will result in clamping colors to the 0..1 range.

[Redspear]

you can go crazy with the emissive colors and actually make them glow by getting them to bloom

Even I think that sounds a little crazy
Could be useful though to highlight a targetted or hostile vessel if not overdone.

Meanwhile, I've had a bit more of a play with this, especially thinking around the fadind effect (with decreasing distance)...

I think it has merit but the fading to nothing aspect is perhaps too much and reduces the utility of the wireframe.
Perhaps if it faded to half intensity or to be replaced by cbr's hex texture ('hex-tex' )?

Here it is without any such changes, with the colour ramped up very high for illustrative purposes


You can get pretty close before it fades sigbificantly but when it does, it fades very quickly.

Both vessels are stationary here but watch as the player ship turns towards the sidewinder.




A few things to note here

• • This is with a thinner wireframe setting (100 rather than 200 texture) but visibilty seems to be more about brightness than line width
  • the disappearing wireframe is not a bug in the shader (I don't think) but rather highlights how sensitive it is with regards closing range
  • In the last image there is actually a coriolis station on the left (check scanner for reference) but without a wireframe it's easily missed

I think the wireframe fading at close range is nice but perhaps it should fade either to cbr's hex-tex or simply to a much fainter wireframe. The advantafge of the former is that it would be much more apparent over much larger models such as an anaconda or even the coriolis in the example above.

Presumably the latter is a relatively simple matter (the effect is already present, it just needs tweaking) whereas the hex-tex one would require another texture to fade in as the wireframe faded out.

I'll see if I can work out the first one myself...


EDIT:

Yep, partial fade is a simple adjustment.

Same brightness in both of these pics.
It fades as before but much less sharply upon approach.





If it can be tweaked then it can be optimised, the above is just an example.

[Griff]

Very cool work with the shader Redspear, i think me shrinking all the textures down to 512x512 for these test versions may affect the way the wireframe glow looks, but there could also indeed be a mistake in the shader code fading out the effect very abruptly, it's something i noticed too but haven't been able to fix, all my efforts just end up with the effect not fading out at all if i potch out with it too much

this value in the vertext shader has an effect on the fade out range
const float gradient = 0.3;
lower numbers make for a longer fade out, but go too low and the effect doesn't fade out at all
and the 0.4 in this line near the end of the fragment shader
float rescaledvisibility = smoothstep(0.4, 0.0, visibility) * unlitside;

lower the 0.4 to a smaller number and i think the fade out effect triggers further away from the player, it still happens over the same amount of distance but i think the gradient value in the vertext shader controls that?

anyway, hope i'm not muddying the water with this, but here's another version of the OXP that uses Oolites standard lighting model in its shader, i think this is what the default shipset is using straight out the box.
i think this shader will work better with the ship texture files already in the game (where there are no normal or specgloss maps for each ship installed by default) so it could exist as a overrides oxp that just adds a shader definition and a wirefreme texturemap to each standard ship

download link:
https://drive.google.com/file/d/1vl2yzX ... sp=sharing

I've had to ammend the wireframe texture the oxp uses which makes it slightly more hassle to mod - i've moved the actual 'wireframe' texture that into the alpha channel for the png and used the rgb channels to provide some glow colours (specifically the engine glow in this test oxp), i couldn't get the glow colour working otherwise and i didn't want to ammend the diffuse texture to add it in there because that would mean having to ammend the core ship textures shipped with oolite when it comes time to make a version of this oxp to work with the core shipset

[Redspear]

this value in the vertext shader has an effect on the fade out range
const float gradient = 0.3;
lower numbers make for a longer fade out, but go too low and the effect doesn't fade out at all

That was my first thought ('gradient' sounded promising ) and could still be adjusted to make it more gradual and less last minute. However, your annotations in the shader led my to try tinkering with this:

and the 0.4 in this line near the end of the fragment shader
float rescaledvisibility = smoothstep(0.4, 0.0, visibility) * unlitside;

lower the 0.4 to a smaller number and i think the fade out effect triggers further away from the player, it still happens over the same amount of distance but i think the gradient value in the vertext shader controls that?

I changed the 0.4 to 0.6 and it seemed to do the trick. There's likely a better value but, like glow colour, it may be a matter of personal taste.


Speaking of which, I tried changing the wireframe colour to something approximating the sidewinder itself, for a slightly more 'natural' look.







I didn't get the colour quite right but that's almost subtle isn't it?
Not sure if I personally favour it but I suspect more palatable for those not liking the 'ship's computer overlay' idea.




That reminds me, I really must blow up that death star...

download link:
https://drive.google.com/file/d/1vl2yzX ... sp=sharing

Thanks Griff, I'll give this a try at some point.

[Griff]

Test version of the OXP that works with the default shipset, standard lighting model
uses a shipdata-overrides.plist to add the shaders definition to each ship, might fight with other OXP's and OXZ's you have that also do this

download:
https://drive.google.com/file/d/1tQTanp ... sp=sharing

not sure if i've got the lighting stuff right, had to guess some gl_FrontMaterial values for some things, it sort of looks fairly similar

[cbr]

OXP that works with the default shipset, standard lighting model

A great addition for the default shipset, very cool

[cbr]

In the gallery, the sidewinders have this side effect up close the elite-lines getting brighter...

[Redspear]

Totally awesome work Griff, I'm having loads of fun tweaking everything around

There seems to be an issue with the anaconda however...



Could it be that the subents wireframe texture needs inverting (to black on white)



Here it is again with a yellow wireframe when a cobre mk 1 with (very nearly) the same wireframe colours looks like this:



And a viper for good measure:



I've started thinking of the colours being closer to those on the IFF scanner as it may be less confusing than reinventing the wheel...

[Redspear]

Could it be that the subents wireframe texture needs inverting (to black on white)

Seems that way but it wasn't just that texture...

For example, here was the adder with a yellow wireframe:



And here it is again after I inverted the adder wireframe texture:



A very easy fix and you can probably spot the other textures that need inverting.

Correlate uWireframeGlowCol with scanner_display_color1 and all sorts of fun can be had

...Boa texture also needs renaming from diffuse to wireframe.

[Griff]

Arg, sorry about that Redspear, it looks like some of the textures aren't inverted properly, i used xnview's batch convert on the folder with them all in but it looks like i messed up with some stuff and xnview skipped a few - some look like they are missing as well, no python trader wireframe, i'm going though the list now checking what needs doing and fixing, there's some file name errors too so hang on a bit before you put too much work in to the shipdata-overrides.plist stuff, the new upload wilhave a few changes in

[Griff]

re-upped the oxp, hopefully fixed the textures that weren't inverted and making the affected ships glow all over!, there were some file name changes too - a few of the wireframe textures in the oxp still had "diffuse" in their filenames from when i was matching their names to the oolite versions, have fixed those in the oxp now i think and updated the shipdata-overrides.plist

Edit: forgot to mention - it's possible to change the wireframe glow colour if the ship suddenly goes hostile, the shader isn't doing that at the moment but it could be added in if you fancy the idea?