Shaders’ Outpost

[gsagostinho]

As some of you know, I have been working on an update for the System Features Rings OXP and there were some discussion about it in the Screenshots thread starting with this post. Because the discussion was out of topic over there (sorry again!), I thought of continuing it here. I currently have three issues that I would like to solve/improve and I would greatly appreciate some advice:

- drawing distance seems to be set at 2.7 OU, at which points the rings pop out of existance. Apparently this would have to be modified in the core code of the game.

- applying opacity < 1.0 to rings: no matter what value I use as the last argument of gl_FragColor. Some people told me that I can't have transparency in Oolite. Others told me to look at the atmosphere fragment shader, but I can't understand why the transparency works there and not with the rings shader. I have also read online that one must enable blending in order to work with opacity, but I am an utter complete GLSL noob and I don't know what that means nor how to accomplish it.

- a minor thing, but would someone here perhaps know how to improve the Moire patterns that the rings display?

Here is what I have so far:

[Svengali]

- applying opacity < 1.0 to rings: no matter what value I use as the last argument of gl_FragColor. Some people told me that I can't have transparency in Oolite. Others told me to look at the atmosphere fragment shader, but I can't understand why the transparency works there and not with the rings shader. I have also read online that one must enable blending in order to work with opacity, but I am an utter complete GLSL noob and I don't know what that means nor how to accomplish it.

You can't enable it through GLSL. Only Oolite can enable blending and as far as I know it does it only for the planets/flashers. So no OXP ship or extra features - like the rings - can use it. There was some thinking about giving shaders are readout for the backbuffer or a render target, but I think it has not been implemented yet.

[Commander_X]

To confirm what Svengali said, the material the shader applies to must have transparency "beforehand" the shader comes into action.

The system rings OXP (and the other OXPs too) seem to apply the shader effects using the effectdata.plist file in the Config folder. That file (and the stuff it uses) seems to be defined in OOShipRegistry.m source file. "Injecting" transparency in the material assumed at that point could help here, but also "break" things in other places -- textually -- showing holes where they're not supposed to be

The reason I've pointed you to the atmosphere shader "quant" calculation, was to follow Griff's advice on the Screenshots discussion: fading the rings to black when the distance comes close the disappearance limit.

I just checked though, and the size of the rings is too big at that limit -- so fading it to black might be a good thing if the planet is not seen on the background of a nebula, but make it worse if that's the case.

[gsagostinho]

I see, thanks to you two for the clarifications. I will probably let this opacity issue aside and just think of the others.

The reason I've pointed you to the atmosphere shader "quant" calculation, was to follow Griff's advice on the Screenshots discussion: fading the rings to black when the distance comes close the disappearance limit.

I just checked though, and the size of the rings is too big at that limit -- so fading it to black might be a good thing if the planet is not seen on the background of a nebula, but make it worse if that's the case.

Hmm, this might make it look even stranger: a planet against a nebula would have a black ring popping up then slowly getting colour. I wonder how difficult it would be to make a core change to allow certain objects to have larger drawing distances, I will ask another_commander if this is possible and if he would consider implementing this. That would really solve this issue, as this fading might improve a bit, but sounds too much like a hack to me and has this potential drawback that Commander_X pointed out.

And once again, thank you all for all the feedback and patient answers, I really appreciate it all

[Commander_X]

I wonder how difficult it would be to make a core change to allow certain objects to have larger drawing distances, I will ask another_commander if this is possible and if he would consider implementing this. That would really solve this issue, as this fading might improve a bit, but sounds too much like a hack to me and has this potential drawback that Commander_X pointed out.

Well, don't be afraid of hacks. It is how the atmosphere shader started actually, by hacking the planet shader. Then, as suggested by a_c I've done a bit of core hacking on the atmosphere part.
In what you're trying, maybe it would worth investigating the approach to allow for transparency for the effectsdata.plist approach (which would also "free" the OXPs of the non-transparent shader codes).

To come back to your request on the Screenshots discussion, the quick hack I've made to avoid the Moire is quite simple -- I've commented out the code that draws holes in the rings. Unfortunately this lead to two other inconveniences:
1. (which should be easier to overcome) The rings are solid. Although from the distance the patterns are no more a problem, when getting closer (or through) one wouldn't be able to see "through" the rings. In order to avoid this that "quant" method I mentioned could be used to unblock the holes once the ship is close enough.
2. (which is more difficult to overcome) There are other artifacts that come from the whole texture drawing. Some are visible at close range (not very important considering 1. above) -- some seams of the texture, and some weird mapping issues. But from the distance it seems that the whole texture setup is not cooperating as expected with the atmosphere/planet shader, giving some rough edges where the planet is lit along the rings (see below in the top right part of the planet).

And once again, thank you all for all the feedback and patient answers, I really appreciate it all

You're welcome, that's what a forum is for!

[Svengali]

Just as sidenote for all the GPU folks - I rediscovered a very good in-depth explanation on how GPU works published in 2008 on c0de517e blog:

• Part 1
• Part 2
• Part 3

[Griff]

Been trying to implement an awesome fake sub surface scattering shader, thought it might work for ice asteroids
fake sss shader: http://www.gamedev.net/community/forums ... _id=481494
glsl translation by toneburst here https://machinesdontcare.wordpress.com/ ... er-shader/

test oxp here:
https://app.box.com/s/lnd728bjcqr8hz76ml35jjpqrdps3tb0

It's very basic at the moment, the oxp contains a script to spawn 4 asteroids nearby when the player launches from a station. I've just been testing at lave so i'm not sure how other system suns will work.

you need to get really close to the asteroid to see the effect, I was hoping it would just limit itself to the shadowed side of the rock, but in my crappy implementation this doesn't seem to be the case

Would like to add a sparkle effect, there is an example in the 'rendermonkey' examples file but it needs a cubemap texture, are these available for ships? I can see lines for them in the default fragment shader, would anyone know what the line to declare them as a uniform in the shipdata.plist would look like?

[another_commander]

I have uploaded the updated Griff Boa Proto 1.1. shaders here to make it compatible with the new rendering engine and to look like this:



Hopefully they can serve as an example of how to modify existing ship shaders. Just copy the files found in the Shaders folder to the Shaders folder of the OXP, and the shipdata.plist file to the OXP's config folder, start Oolite with Shift down and buy the ship.

Only the player version shaders have been modified and you need the latest Oolite trunk to see this.

[Griff]

shader test with lighting code taken from the uIOR version of the oolite shaders
I'm trying out storing paint colours in an array, means that the shader needs opengl version 120 minimum to work.
player and NPC versions, in oxp format https://app.box.com/s/6dcsmkwkvaq9lzd3dpeilhnt2jlktjc2

edit: no uIOR shader version: https://app.box.com/s/b8dry5zvrny7yopu6yxkq6bq0rc5oko1
weathering preview:

[another_commander]

Nice! Just a quick clarification though: uIOR is no longer used. It was put in temporarily in order to facilitate energy conservation in the new lighting model, but now that energy conservation has been properly implemented using the material specular color as base, IOR is no longer needed.

What you do need for a proper implementation of materials in the new system is a) specular color and b) gloss. I think I may have to put some time aside and write down a few notes about how to handle materials using the new lighting system soon. In the meantime, you can have a look at the llatest trunk's oolite-default-shader.fragment if you want to see how things are done without IOR.

[Griff]

yeah i'm struggling to get the awesome lighting 'sheen' as seen in the examples in the screenshots thread happening in these shaders, think i'm feeding the shader some duff glossmaps and shinyness levels. tweaking stuff in rendermonkey is a bit tougher as it seems to set the gl_ variable stuff differently to oolite and in some cases doesn't even seem to set a value at all and i end up with blue ships from the kD calculation bit, looks ok in oolite though so i just test in there

[another_commander]

One more thing I saw in your Gnat shader test, Griff: See these lines in your CalcSpecularGGX function:

Code: Select all

float g1vNL = 1.0f / (NdotL * (1.0f - k) + k);
float g1vNV = 1.0f / (NdotV * (1.0f - k) + k);

and

Code: Select all

return distribution * fresnel * visibility * NdotL;

These lines do produce a result and appeared like this in early versions of the GGX shader, but I am not sure they are physically accurate. In the new default shader, these lines have been substituted by

Code: Select all

float g1vNL = NdotL / (NdotL * (1.0f - k) + k);
float g1vNV = NdotV / (NdotV * (1.0f - k) + k);

and

Code: Select all

return distribution * fresnel * visibility * NdotL / max(4.0 * NdotL * NdotV, 0.001);

which seem to be more in agreement with information found online (ex. https://learnopengl.com/PBR/Lighting). You are not obliged to align with the physically accurate methods if you like the current result, of course. Feel free to modify the shader as you prefer, as long as a good result can be achieved at the end.

[Griff]

thanks a_c, i'll update those lines, i'm blown away with how great the default shaders look and want to try and match the lighting as closely as possible, i'll check that link out too, hope its not too maths heavy
edit: argh yes it is lol

[gsagostinho]

That looks impressive, Griff!

On a side note, would anyone be able to explain to me how the values for the variables cloud_color, land_color, polar_cloud_color, polar_land_color, polar_sea_color and sea_color for each planet were generated? I am considering writing an OXP which changes those variables to more conservative values for all planets. I find images like this and this gorgeous but planets like this look a bit too wacky for my taste. My idea would be to simply create a new planetinfo.plist with those variables substituted by new random values generated by some functions I would write but I was just wondering how these original values were generated in the first place.

Also, apologies if this doesn't fit in the Shaders' Outpost category, but I could not think of a better place to ask. The colours are controlled by a simple plist but are applied by the planetary shader, which is why I thought it belonged here. Mods, please feel free to edit or move my post.

[another_commander]

I uploaded the method which I think is responsible for the clouds etc. color calculations here: https://pastebin.com/WjvXUmZf

It can be found inside src/Core/Entities/OOPlanetEntity.m. Hope it helps.