Oolite Bulletins

@another_commander thank you so much!

gsagostinho wrote: ↑Tue Jul 18, 2017 12:26 pm

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?

Hi, I'm new here, and I am reviving a topic that's more than a year old, but perhaps it will be interesting anyway. I have spent some time working on rings in my own open source space game, and I can describe what I did for that. Perhaps some of it will be useful in Oolite as well. I was largely inspired by this amazing video: https://www.youtube.com/watch?v=UgxWkOXcdZU which is supposedly made from photographs of Saturn taken by the Cassini probe, which is to say, it's not CGI.

There are a couple interesting things I noticed about this video.

1) The rings tend to be either fully opaque, or have fully transparent gaps (opacity tends to be either 1.0 or 0.0, with little in the way of translucent sections.)

2) The two sides of the rings are not the same. One side is in shadow, and is darker (but not fully dark) and one side is in sun, and is brighter.

As for the opacity, I was a little reluctant to discard translucency entirely, since while it may be the case that Saturn has little in the way of translucent rings, other imaginary planets might be different. Nevertheless, I did make the rings tend a bit towards opacity. What I really did was link the opacity to the brightness, more or less, of the underlying texture, so that lighter areas of the rings were more opaque, and darker areas more transparent (this alpha manipulation is baked into the texture).

As for the two sides, in my ring shader (I have a shader specifically for rings), I determine the plane of the ring, and determine which side of this plane the camera is on, and which side of this plane the light source resides. If the camera and the light source are on the same side, then we are looking at the bright side of the ring. If the camera and the light source are on opposite sides of the plane, then we are looking at the dark side, and the brightness is attenuated.

As for the moire effect, what I did is use essentially a 1 dimensional texture, which defines a cross section of the ring. Actually, I used a 2 dimensional texture, but each ring uses only a single texel wide slice of this texture. That way I can cram 512 different ring textures into a single 512x512 image, and it's high enough resolution that I don't seem to have too much problems with moire, or rather, the way the texture is sampled, the moire doesn't seem to happen. In the fragment shader, I compute the distance from the center of the ring, and use this to index into one axis of the texture (the other axis is held constant -- but a different constant for each planet's ring.) And also in the ring fragment shader, I shoot a ray back towards the light source to see if it intersects the planet, and thus get the planet's shadow onto the ring. And in the planet fragment shader, I find the intersection of a ray from the planet surface to the light source with the ring, and sample the ring texture to allow casting the shadow of the ring onto the planet in a way that matches the rings. I also put a little bit of specular reflection on the ring.

Results look like the links below. The first two show the same planet from different angles, showing the light and dark side of the ring, the 3rd shows some specular reflection.

https://i.imgur.com/eSqKcy0.png

https://i.imgur.com/VoeLWYu.png

https://i.imgur.com/fgM36Kq.png

Ring shader: https://github.com/smcameron/space-nerd ... xel.shader
Planet shader: https://github.com/smcameron/space-nerd ... xel.shader

Perhaps some of these ideas will find their way into Oolite in some form or another.

Hi smcameron, thank you so much for your post! Your works looks really good. The problem I ran when I was working on that shader was that it was not possible to use transparencies, only full 1.0 or 0.0. The result I manage to get looks like this: https://bb.oolite.space/viewtopic.php?f= ... 75#p258675 I am super busy with RL at the moment but please feel free to try to improve what I created in the rings OXP. Cheers!

Those rings look very cool. Thanks for the pointers to the shaders. I will definitely have a closer look at what they do as soon as I get a chance.

In today's nightly we have a small experiment: filmic tonemapping. This is something really neat and it mostly works with HDR assets. However, it seems that it does really well with Oolite, so here it goes. If you want to know more about filmic tonemapping, there is a really good presentation by one of Naughty Dog's developers here; jump to around minute 26 for the relevant parts.

Essentially, instead of simply applying normal gamma correction at the end of our shader, we apply this totally magical formula: This has the gamma correction already baked in and generates very vivid colors and great dark tones. Have a go with the latest nightly and let us know what you think. Here are screenies comparing our current system (above) against filmic tonemapping (below).

that looks really nice, it really helps brings out the colour in that lovely planet texture. fab metallic sheen on the cobra3 as well - Oolite is looking really awesome - stunning work A_C

I'm trying to add a small section on definitions onto the OXP howto texture wiki page.

I don't understand any of this.

What I have so far is this:

Terminology
A normal texture specifies a single property of the model’s material at each point – specifically, its diffuse colour, or albedo. Specular maps, glow maps (eg for the engine exhaust glows) and other effect maps are auxiliary textures specifying additional material properties. Extra detail can be added into the alpha layer/channel (eg for the city night lights for planets in Oolite v.1.90: the illumination map should get embedded in the alpha channel of the planet's diffuse map).

See Shaders in Oolite for explanations of vertex shaders, fragment shaders and uniforms.

It's based on a quote from Ahruman back in 2006/7, with bits added.

Can somebody please look it over and correct it?

It says nothing useful about gloss maps. Or diffuse maps. Or if specular, gloss and glow maps are examples of normal maps (are they?).

I presume that different terms (eg alpha layer & alpha channel) are often used to refer to the same thing, but again, no idea!

Please help.

I'd like to end up with something which even a dumb pilot like myself can get something out of!

I get myself tangled into knots when talking about this stuff,

Terminology
A normal texture specifies a single property of the model’s material at each point – specifically, its diffuse colour, or albedo.

the 'normal texture' mentioned in the quote is just a 'normal texture' in the sense that back in the day 'normally' oolite would just read in the one texture map (an image file in png format) which it wrapped around the polygon geometry of the game model to give it some surface colour and detail, eg the texture looked like metal plates for the ship hull or dusty rocks for the asteroid model
When we got materials and shaders, oolite was able to read in more than just this one surface colour map and it could use the pixels in these maps for other graphical effects like making it look as if the surface was very dull or very shiny depending on the colours in the texture map it was using to controll this effect, or perhaps it used the pixels in a texture image to wrap onto the model surface to look as if it was emitting light in certain areas or not (the texture artist could control the final effect by how they had painted the texture map)

Don't think of "a normal texture... " in the quote as referring to a Normal map that we talk about in the oxp folder or the screenshot threads, normal maps in this sense are again just a standard png image wrapped around the game model, but the colours in the map combined with some maths in a shader (even oolite's materials use shaders) modify a surface property called a 'surface normal' which is one of the values needed by the game engine to light the models it is displaying on screen (along with the light position eg the system sun, and the players eye position - our camera view into oolites world), by modifying the surface normal with a texture we can make an otherwise perfectly flat surface look like it's got some raised and lowered areas - it's a trick of the light though, the surface isn't really anything other than completely planar.
Post here with some youtube links where the presenter shows some of these map types and gives a brief talk about their purpose
viewtopic.php?p=277278#p277278

Hope this helps a bit and just doesn't make it even more confusing

Griff wrote: ↑Mon Jan 02, 2023 4:57 pm

I get myself tangled into knots when talking about this stuff

<grins> You get tangled into knots? How do you think us dumb pilots fare?

Griff wrote: ↑Mon Jan 02, 2023 4:57 pm

[...]

Terminology
A normal texture specifies a single property of the model’s material at each point – specifically, its diffuse colour, or albedo.

the 'normal texture' mentioned in the quote is just a normal texture in the sense that back in the day 'normally' oolite would just read in the one texture map (an image file in png format) which it wrapped around the polygon geometry of the game model to give it some surface colour and detail, eg the texture looked like metal plates for the ship hull or dusty rocks for the asteroid model
[...]

Agreed, the main confusion for the "normal texture" definition above comes from the existence of a "normal map" texture (which is a very specific type of texture, which is used in Oolite as well). I'd guess the best short description for the above definition would be either "normal (i.e. regular) texture" or "normal/regular texture" (in order to keep the previous wording as is).

Rather new to shaders but...

Is there any reason why this effect (wireframe glow)



couldn't be implemented in an effects map as suggested here?

Namely, in a similar manner to that in which engine glow can adjust in response to ship speed, the above effect would adjust in relation to distance from the player ship. Disappearing at close range but vibrant at long range.

That's a really interesting idea, looking at the bindable shader uniforms page

https://wiki.alioth.net/index.php/Shade ... :_uniforms

There does seem to be this..

relativePosition vector The location of the entity, relative to the player.

..that might work as a way to control the intensity of a glow map? I'm not sure though I don't think i'd know how to do the maths but it might be fun to poke around with it

Griff wrote: ↑Sat May 13, 2023 7:05 pm

There does seem to be this..

relativePosition vector The location of the entity, relative to the player.

Ooh, yeah, that's the sort of thing I'm after...

Griff wrote: ↑Sat May 13, 2023 7:05 pm

I'm not sure though I don't think i'd know how to do the maths but it might be fun to poke around with it

I was thinking (quite possibly naively) of distance as a percentage of scanner range = percentage opacity of effect, where there is a cap of 100%.

In any case, thanks Griff. I'm still nowhere near achieving it but I at least now I might be looking at a relevant map

EDIT...

Come to think of it, the maths could be really easy as it only needs to be approximate (i.e. invisible when very close, apparent at medium range and fully opaque at long).

So simply picking the largest of x, y or z would be a serviceable method of determining (roughly) how close a ship is rather than where it is in relation to the player. The closer the largest one is (x/y/z), the less innacurate it would be (short range being the one at which discrepancy is likely to be more noticeable).

Accurate maths needn't be difficult either but the fact the above method increases in accuracy as range decreases likely means that it's not even needed.

Redspear wrote: ↑Sat May 13, 2023 6:38 pm

Rather new to shaders but...

Perhaps the constrictors briefing shader contains something to your lik(e)ing...

cbr wrote: ↑Mon May 15, 2023 6:43 pm

Perhaps the constrictors briefing shader contains something to your lik(e)ing...

I've never actually done it but thanks

As we've both done before, a simple glowmap (no shaders) will do the trick but it's getting it to be dynamic that's the tricky part.