Oolite Bulletins

For those who may have missed the recent discussion on github, there s a new unifrm used now in Oolite and it refers to atmospheric fog.

Since approximately v1.69, when shaders were first introduced, Oolite has been carrying a "bug": atmospheric fog did not work. This, technically, is not a bug, since The OpenGL specification states that fog should be disabled when there are fragment shaders running. However, it did look kind of weird, to say the least and was something that needed fixing.

See the pic below. This is what you have been seeing up to now when shaders were enabled and you were looking up at the Lave Coriolis station from within the atmosphere:


In reality, it should look like this (which is what you can already see with shaders disabled:


The deeper you go into the atmosphere, the denser the fog becomes. This creates not only a more pleasing visual effect, but also a sense of scale increase, which is good.

Thanks to some shader wizardry by kanthoney, shader writers can now bind the method fogUniform, which holds the fog color's rgba value, to a vec4 type uniform and apply the effect on their creations. You can refer to the current nightly's Resources\Shaders\oolite-default-shader.fragment (vec4 uFogColor) for an example of how we use it (but keep in mind that Oolite binds the uniforms to methods internally for its default shaders, so you aay still need to do the fogUniform binding manually).

Edit: Example of foggified Griff's Dodo spawned inside planet's atmosphere:

another_commander wrote:

For those who may have missed the recent discussion on github...

I did miss that discussion... but I did see the foggy commit(s) on the nightly page.

another_commander wrote:

You can refer to the current nightly's Resources\Shaders\oolite-default-shader.fragment (vec4 uFogColor) for an example of how we use it (but keep in mind that Oolite binds the uniforms to methods internally for its default shaders, so you aay still need to do the fogUniform binding manually).

I've just tweaked the shader code a bit to simplify it (I'm using the built in mix function instead of doing the maths myself), so if it looked fearsomely complicated try the new one. I've also tweaked the core code so that the fogging is probably more in line with the non-shader version (there's now more fogging near the ground).

It's been a while since I did one of these. Anyway...

In tonight's build, we've got the new mobile external camera for you to play with. In external view mode, engage caps lock and the arrow / yaw keys will rotate the camera around your ship. Holding shift while using the arrow keys will pan the camera, and page up/down will zoom in and out. Alternatively, you can click and drag using the mouse and zoom using the mouse wheel.

Have fun, and the screenshots thread is here. Let us know if there's anything that could work better, or doesn't work at all.

I would just like to add that, unfortunately, due to our current lack of Mac port maintainers, the new feature is available only for Windows and Linux. The Mac port does not currently have a way to distinguish the status of Caps Lock, so the entire feature cannot be activated, even though its code is included in the Mac binaries. Apologies for any inconvenience caused and, if there is anyone with Mac programming knowledge willing to contribute so that the Mac port can catch up, now would be a very good time to do so.

In tonight's build...

A long time ago, somebody asked for a facility where they could get system information for all the systems along their planned ANA route. So we rustled one up, which worked OK except there was a slight problem - every now and then a planet would disappear, which came as quite a shock to the people living on it let me tell you. Because of that it was deemed not quite polished enough to go into trunk.

Anyway, after an intensive debugging session we managed to get the bug tracked down and sorted, so it's now in trunk. On the F7 system info screen, use the left and right arrow keys for info on the previous / next system on your current route. The home key will show info for the home system and the end key that for the target system.

On the chart, the there will be a blue circle around the system that appears on the F7 screen. That can be moved using the Alt key (or Opt key if you're a Mac user) plus the keys above.

Nice... but Terrastorage seems to be down. I'll try again later... after morning coffee, perhaps.

At least someone noticed. It's very quiet round here, isn't it?

<nods sadly> Aye... quieter than I've ever known it.

Sorry, I noticed the post but I'm on holidays with the family and likely won't get a chance to try it out until much later in the week. I'm really looking forward to this patch, as it's been a real issue with the F7 screen for a while. Great work, kanthoney!

Hello. Can confirm the bind caps lock thing on the Mac works well. You can get some very nice camera angles. Is zooming in/out implemented also? Anyway great work.

O I see that zooming out is also implemented. Very nice

Ok a litte bit confused here. Due to the down situation of the Terrastorage site I was sent to a redirect page where i could download a mac dev version.

In this version there is a folder called: Mac Os. When I run this file Oolite starts and I could get the nice views etc. But then I wanted to try my save game. As I also have a traditional Add ons folder with my own oxp's I moved this folder to the Oolite Trunk dir. But as this folder doesn't have a normal Oolite.app I think that this is not the right way to do that and I think that I have to build a Trunk version via Xcode? Is that right?

Terrastorage is back up, and the new feature works fine - muchas gracias!

A very minor thing: with the home system set, jump to the next system on the route, and F7 remains on the previous system.
The arrow keys seem stuck there - you have to use the Home key to nudge it along to the new home system.

F7 is really crying-out for more system info/background - even if it's only padding.