Split: Re-scaling experiment

[another_commander]

Pardon my ignorance but where is the atmosphere fragment shader please?
Quick search for cosThreshold in each of the files that I found with 'shader' in the title came up blank.

The atmosphere fragment shader is at oolite.app/Resources/Shaders/oolite-default-atmosphere.fragment. You can make changes on that file and see the results next time you run the program, no need to hold down Shift for that. And just to be clear, this shader controls the haze you see when viewing from space, not the color of the sky when you are inside the atmosphere.

If you have specific questions about what is going on in there, feel free to ask.

[Redspear]

The atmosphere fragment shader is at oolite.app/Resources/Shaders/oolite-default-atmosphere.fragment.

So easy to find that I didn't look there
Thanks.

just to be clear, this shader controls the haze you see when viewing from space, not the color of the sky when you are inside the atmosphere

That's what I originally thought but it's good to have it spelled out.

Reduced Lave to it's normal size in order to learn how to break the shader at that size. Hopefully that will give me some insight for how to fix it at x 6.6.

EDIT: Fixed it already (or at least no problems so far...)

At first I thought it must be too small and then I though it might be too dispersed.
Making it bigger on a regular sized Lave meesed things up so instead I reduced it for the increased Lave. Result.

Thanks a_c

[zevans]

Hello guys. Almost cosmic-scale long time no speak...

Like everybody else I now have three hours a day I used to spend stuck on trains, that I can use to do interesting things instead! So I am volunteering my services to this thread... two of my favourite vintage games are Frontier and Dark Angel on the Arch, so I'm all about the space science.

I had two thoughts that might help.
1. I'm happy to track this discussion and decisions made on a fork or a branch, so we can see what issues have been opened and how they were closed; might make this a heck of a lot easier to manage when we have to split things into PRs.
2. If @Redspear can let me know which fork and branch they are working on, and they would like to collaborate, I'm happy to help with code and config.

Just to confuse you, I am coffeeandspaceships over on github.

[Redspear]

So I am volunteering my services to this thread...

Hi zevans and thanks!

I've used github before but only briefly, so it's stil like a foreign language to me, so you could certainly help with that.
However clunky it might appear, I'm happier tinkering on my on pc at the moment. I find it easy to track changes and adjust quickly.

I should post my code changes here soon but still a little tweakery to do first. I should also post pics but not right now...

Remaining known issues:

• Masslock for planets and stars
• Station traffic
• Ambient light and sun distance settings

Masslock:
I currently have it so that sunskimming at Isinor with a mk 3 (no heat shielding, not using injectors) is just about possible. Need to compare with the default game to see if that is about right. Zevans (or anyone else for that matter) please feel free to try it out for yourself!

Planetary masslock is the easier of the two (and so I've been neglecting it). Might want it fairly low to make station approach easier but not so low as to be burn up whilst torus-driving into the atmosphere...

Station traffic:
Long queues seem to be a result of the longer space lane (more testing required to confirm) and cause problems only when players don't travel WP to planet. I can halve the lane length without it being a big problem (cosmetic feature) and so if it scales well then i might not even need to reduce by that much. Again, need to test further. And to think that the problem used to be no traffic

Ambient light:
This is just trial and error. Before I had shaders, I tried Griff's ships only to reject them (sorry Griff! ), as without shaders, they were so dark. Even with shaders they are hardly technicolour (a few exceptions..) Anywho, the default ones are brighter than the oxp versions (sans shaders) but things can get very dark in certain situations and having a small, dark blob fire at you on a dark background is both harder to target and less visually appealing (as the small, dark blob becomes a medium dark, shape). Ambient light can only do so much but it helps, in at least some situations.

Good news is only one of these three is one that I'm unsure how to go about fixing, rather than just which values I should use.
Anyway, my last docking queue position after code tweaks was 9, a lot better the previous 22!

[another_commander]

Ambient light:
[...]

You can try introducing exposure in the default ships' fragment shader in order to make things a bit more visible. It works more or less the same as it would with a photo camera. The higher the value, the more detail you can discern in darker tones and the brighter the light tones become. It is not the same as ambient lighting. To use it, just add this line in oolite-default-shader.fragment, and just before the filmic tonemapping step at the end:

Code: Select all

if (uGammaCorrect)
{
	totalColor.rgb = vec3(1.0) - exp(-totalColor.rgb * 1.0); // <<<<<<<<< Add this line
	vec3 x = max(vec3(0.0), totalColor.rgb - 0.004);
	totalColor.rgb = (x * (6.2 * x + 0.5)) / (x * (6.2 * x + 1.7) + 0.06);
}

The key here is the value multiplied with -totalColor.rgb. As it is above (equal to 1.0), you will see no changes compared to what you get now. If you increase it though, you will definitely note the difference. I am finding that a value of 2.0 is about right for me, but nothing is stopping you from going higher if you want to increase visibility more. Below you can see what it looks like with the Lave Coriolis at 1.0, 2.0, 3.0 and 5.0 settings,



For visual balance, if you change the ship's exposure, you may also want to do the same for the planets. Adding the same line towards the end of oolite-default-planet.fragment will brigthen up the planets too. You don't have to use the same value as for the ships, you may even want to not change the planets at all. It is a decision based on personal taste. FWIW, I have my setup at 2.0 for ships and 1.5 for planets and I am quite happy with it. Hope this helps.

Edit: Latest trunk had a small change in the filming tonemapping part of the default shader, change is reflected in the code box.

[Redspear]

Hope this helps.

Oh yeah, they look nice

Shaders only though, so I should probably make the default a similar brightness to the core game, without any sun distance multiplier (unless we're going shaders as standard...)
Maybe I can go half-way with the ambient light, for a dark but less extreme look than is normally achieved with a distant star.

Had another idea to adjust the station traffic and should be able to report back on that soon, hopefully with some pics

EDIT: Well, the new idea seems to have worked and so if no other problems emerge... I now have planets, ships, spacelanes and even a scanner that I can scale independantly of each other without breaking something. Marvelous

[smcameron]

Speaking of this magic formula:

totalColor.rgb = (x * (6.2 * x + 0.5)) / (x * (6.2 * x + 1.7) + 0.06);

If you graph it... https://www.desmos.com/calculator/bgnp6yu96l

You can see that it starts off quite steep, boosting levels of dark areas quite a bit, and also that y asymptotically approaches 1.0 as x goes to positive infinity, however, at x = 1.0, y is:

(6.2 + 0.5) / (6.2 + 1.7 + 0.06) = 0.8417085427 about 0.84.

That means the brightest white that you're going to get out of this formula is only about 84% the brightest white, which is quite gray, really. It's really squashing the highlights down quite a bit in both dynamic range (good) and absolute value (maybe not so good). If your lighting calculations involve values significantly above 1.0, then this is probably what you want, as this will act as a limiter to control the dynamic range. If not, then you're leaving a lot of highlights on the table, and you can multiply this formula by up to 1/0.84 or 1.19 and get back some of those highlights without changing the shape of the curve much. In my game, I added a uniform gain factor to the shader which I can adjust to my liking, set by default to 1.18. (Perhaps that's more or less what this exposure correction is doing, except before the magic formula rather than after? If they are about the same thing, the multiplication by a constant should be more efficient than the exp(), but maybe they aren't quite the same, it's not really clear to me.)

Incidentally, out of curiosity I also tried this magic formula out as an audio dynamic range compressor. It is not subtle at all, and I would say not really suitable even for applications that can benefit from heavy handed dynamic range compression, like VOIP (to account for people with poor microphones or speaking off-mic).

[zevans]

Shaders only though, so I should probably make the default a similar brightness to the core game, without any sun distance multiplier (unless we're going shaders as standard...)
Maybe I can go half-way with the ambient light, for a dark but less extreme look than is normally achieved with a distant star.

I've been pondering this part. I guess there are two sources of illumination (even thought Reality(TM) only has one) - the system's sun, and the ambient light.

I can't see (ha) why the ambient light would change if you're further out...

...I can see why changing EXPOSURE rather than anything else is the right answer. If you're 6.6 times further out, then everything will be 44 times dimmer! If you were dealing with that with a real camera feeding the cockpit, you'd have to turn the exposure time, the aperture, and the ISO up in the right proportions to still give you the usable picture even though it's now 44 times dimmer in reality. (Like when you are watching sport on TV and it's overcast - the picture doesn't get dimmer, even thought daylight has gone, because the film crew whack the settings up to compensate.)

Now I've said that it seems a bit odd that setting "exposure" to 2.0 is actually helping (even if that does make it perhaps four times brighter)

What have you got planet-sun distance set to at the moment?

(EDIT: I'm working by comparison here and assuming that all the clipping, tonemapping, gamma, and whatever else remains unchanged so that the brightest part of the histogram is at 1.0 either way and it's just that 1.0 represents 44 times less light physically in the bigger Ooniverse. Guess at the moment we have a weird thing where oolite adds ambient light with no real-world equivalent and then "crushes the blacks" with the filmic map so half that light gets thrown away again anyway...)

EDIT: Well, the new idea seems to have worked and so if no other problems emerge... I now have planets, ships, spacelanes and even a scanner that I can scale independantly of each other without breaking something. Marvelous

[another_commander]

@smcameron: The Jim Hejl formula is used for tonemapping plus gamma correction. So, resulting in a value of 0.84 for white is a standard part of the package (the remaining space till 1.0 must be used for representation of high dynamic range values). Since we don't have proper high dynamic range in Oolite*, the only reason it has been used is because it does gamma correction and generates more vibrant and pleasant (at least to my eye) colors, all in one step.

Because it is so carefully crafted to include the gamma correction step, I would prefer not to apply any mutlipliers to its output. I did try your idea from Space Nerds in Space and it didn't look bad at all - quite the contrary, actually, but I would prefer to not manipulate the JH computation for Oolite.

The exposure formula I propsed to Redspear is also a tone mapping function (taken from https://learnopengl.com/Advanced-Lighting/HDR) It takes HDR values and normalizes everything to Low Dynamic Range, just in a different way. If it is used as proposed above, the end result will be two tonemapping functions in sequence. How good or bad this is I am not sure, but I guess rule of cool prevails also here. I am not convinced it should make its way into trunk though. I'd rather have proper HDR before any more fancy tonemappers. If one simply needs exposure without tonemapping, then yes, multiplying the final color by a factor higher than 1.0 before the gamma correction step would suffice and no costly exp() will be needed.

But I will stop here, it looks like we are seiously derailing Redspear's thread. The discussion is indeed very interesting, but it would be best if it were to continue on another thread.


* By trial and error, I have found that light calculations in Oolite can easily go up to (10.0, 10.0, 10.0) for white or maybe even a bit higher. Although technically this is higher than normal dynamic range, all this happens inside the shaders and values higher than 1.0 are truncated to 1.0 when displayed on screen. There is no rendering to floating point framebuffer, which is essential for a proper HDR implementation. So, certainly something can be gained by applying tonemapping but I am not sure if what we are actually leaving on the table can be considered too much or too little. This is why the decision for this particular tone mapper was based more on good looking results and less on technical reasons.

[zevans]

Created a fork as a place to dump info and assemble PRs.

I broke the changes down into 5 issues (on the fork, not the parent!) which I think can work more or less independently of each other, so you can have five PRs for better clarity on the sets of changes. (Or fewer, if we decide things work together so closely that there's no point...) I would expect each PR to then have a whole bunch of atomic commits within them. I'm happy to do the legwork in figuring out how to do that cleanly, as I appreciate Redspear has had to do this all in one piece in the codebase.

I based as much of it as possible on comments already made somewhere in this thread.

Also switched on the Wiki in my fork, as another place to dump info.

I've invited Redspear as an administrator - AnotherCommander, do you want an invite too? Or do you want to do some of this in the parent?

EDIT: It would help if I included the link!
https://github.com/coffeeandspaceships/oolite-scaling

[zevans]

But I will stop here, it looks like we are seiously derailing Redspear's thread. The discussion is indeed very interesting, but it would be best if it were to continue on another thread.

I've edited another_commander's amazing summary of the lighting model and used it to raise Issue 345 as a feature request for HDR... ! If someone does start another thread please comment on the issue and point to the new thread.

[Redspear]

Ok, so where am I up to with testing?

Pics!

L-R: sidewinder, anaconda, asp.




Isinor: Can't remember a planet looking so big from the star when the star looks so small from the planet.
Is OOPlanetEntity no longer scaling suns along with planets? I note the radius is recorded differently for stars in planetinfo.plist, is it necessary to edit them all by hand? ...




Torus-driving to the station. Planets are much bigger so if you get caught in their masslock then covering six times the distance to make it to the station can be a pain. So masslock is set lower and torus decelleration sharper to enable hurtling towards the station. Atmosphere might be a little shallow here but at least it is here




I liked the names on the scanner that I showed before but can completely understand why they were dropped for the standard build. This is my take on doing similar without the clutter. Early days but yellow = freighter, orange = jump capable non-freighter, dark orange = non-jump capable. I've already tweaked the colours and there's a little more depth to it than I'm going to mention right now. Ambient light probably too high.




Just a pic I liked. Tweaked scanner colour and atmosphere shader clearly working.




Isinor again. Star from WP (looks similar from planet). I had already left the WP actually and got masslocked to find a wormhole. I didn't try it out but as masslocks go, that one was pretty interesting




Got that traffic right down. Need to account for both larger planets and longer space lane to get this one right.




So, what next?

Well, mostly tweaking.
When I hand over the code changes it won't be perfect but it would be nice to deal with any obvious issues first.
One way to look at it is that it seems that I have now found all of the dials, I just need to tune them to something resembling the right settings.

Once I've done that, I'll post my changes. Some things (like the scanner colours) will probably be oxp but this should be the most oxp friendly version of the experiment to date. Just remember to scale_factor those stations by 2.0 or...

[Disembodied]

This is looking really good, Redspear! The increased planet size alone helps make the whole game-universe seem so much more vast …

I liked the names on the scanner that I showed before but can completely understand why they were dropped for the standard build.

Out of curiosity, is it possible to only display the name of the currently targeted object next to its lollipop on the scanner? Could be handy, in a furball …

[Redspear]

This is looking really good, Redspear! The increased planet size alone helps make the whole game-universe seem so much more vast …

Thanks
I'd like to scale the galaxies too (as Pleb did years ago) but that's gonna mess up some missions... not to mention the online galaxy maps

Out of curiosity, is it possible to only display the name of the currently targeted object next to its lollipop on the scanner? Could be handy, in a furball …

All I know is how to turn it on and off , maybe a_c can answer that one. The targeting scanner enhancement does point you in the right direction though.

[another_commander]

maybe a_c can answer that one. The targeting scanner enhancement does point you in the right direction though.

It is a trivial change:

Code: Select all

#if IDENTIFY_SCANNER_LOLLIPOPS
	if ([scannedEntity isShip] && scannedEntity == [PLAYER primaryTarget])

(Not tested).