Screenshots

[Griff]

if the rings just suddenly pop out of existance at long distance, would it help to start 'fading' them out by mixing in more and more black into their display colour the further the player is from them, sort of like how the stations now fade out when viewed from really close to the planet surface

[gsagostinho]

@Tichy Thanks a lot! I spoke with cim and he told me I can go ahead and release a new version, so soon this will be available here

@Commander_X It could be that, but I also read somewhere that you need to enable blending (whatever that means) in GLSL in order to be able to work with transparencies. I am an utter complete GLSL noob, I just know a couple of other programming languages which is how I managed to find my way around these shaders. cim told me that in order to change the opacity of the rings we would need some core changes, so if that's the case then this is as far as I can get. I just wonder why the fragment shader of the atmosphere is able to use transparency while this fragment shader for the rings cannot.

[gsagostinho]

if the rings just suddenly pop out of existance at long distance, would it help to start 'fading' them out by mixing in more and more black into their display colour the further the player is from them, sort of like how the stations now fade out when viewed from really close to the planet surface

The rings just simply pop out at around 2.7 OU. Would you be able to point me to the code which controls the fading of the stations you describe? I would be happy to attempt to adapt that.

[Commander_X]

[...] Would you be able to point me to the code which controls the fading of the stations you describe?

I cannot tell about the fading stations code, but if you're running nightly/trunk, you will find a similar approach at the end of oolite-default-atmosphere.fragment (hint -- the quant calculation). The code actually fades the shader when the ship is too far as well as when it is too close to the planet.

[gsagostinho]

if you're running nightly/trunk, you will find a similar approach at the end of oolite-default-atmosphere.fragment (hint -- the quant calculation)

I am running the most current nightly. But this is exactly the issue I am having: the opacity does work with atmosphere fragment shader but does not work with the rings shader for some reason. All those calculations in the end of oolite-default-atmosphere.fragment are just producing a float value assigned to the variable newOpacity which is then passed as the last argument of gl_FragColor. In the rings shader, no mater the value of the last argument of gl_FragColor, the opacity is always displayed in-game as 1.0.

[another_commander]

We interrupt this program for some screenies. Please use a separate topic if we are to get technical with the rings shaders.

[gsagostinho]

We interrupt this program for some screenies. Please use a separate topic if we are to get technical with the rings shaders.

My apologies, I will start a new thread for that, and a moderator can feel free to move the messages over there. As for your shots, they look great!

[Commander_X]

We interrupt this program for some screenies. [...]

Exactly my thoughts when I replied last time - actually I was thinking along the "can there be a screenshots page without screenshots" line

And to properly submit this post, this is a quick hack[*] to get rid of the Moire patterns:



[*]don't ask is not there yet

[gsagostinho]

@Commander_X Very nice! Do you want that I send you what I have so far, so you can test it what you are doing together with the ambient light?

[gsagostinho]

I've been working on some Python liveries

[Tichy]

That orange-darkgray <3

I need a python, now! A lovely, slow, cleap but gorgeous black-orange python.

[gsagostinho]

I need a python, now! A lovely, slow, cleap but gorgeous black-orange python.

That's exactly the intended reaction!

[gsagostinho]

I have just released System Features: Rings version 2.0:

[gsagostinho]

Refuelling

[phkb]

Heading out into the black...