Split: Re-scaling experiment

[another_commander]

Also, making a note here that these changes all refer to the code revision which is current at github, which is 1fcfbb8. Once the source files start changing as development goes on, the above instructions will be unavoidably rendered invalid.

[Redspear]

Nice, well done! I think there should also be a shader change for the atmosphere effect somewhere there?

Yes, you're quite right. I'll edit my previous post.

Also, making a note here that these changes all refer to the code revision which is current at github, which is 1fcfbb8. Once the source files start changing as development goes on, the above instructions will be unavoidably rendered invalid.

Worse still. They're from when I started tinkering on 31st March I think??? Hopefully that's sufficiently recent for just the odd line number to have changed.

[another_commander]

Code: Select all

totalColor.rgb = vec3(1.0) - exp(-totalColor.rgb * 1.5);

You can try simulating exposure also using an alternative, less computationally expensive way. You can use whichever feels better looking to you:

Code: Select all

totalColor.rgb *= x;

with x being your preferred exposure value.

Edit to add: The exponent version is also a tone mapping function. Since we apply filmic tonemapping a couple of lines later in the shader, if you use that version you effectively tonemap twice, which may not end up looking as good as you'd want. Chosing the exposure function to use is a matter of personal taste in the end, but because of the tonemapping thing the exp does, I have switched to using the multiplier one in my tests.

[Redspear]

You can try simulating exposure also using an alternative, less computationally expensive way. You can use whichever feels better looking to you:

Thanks

One very quick test later...
I don't know if it looks 'better' but whites appear less intense at higher values. This could be good news as it may enable me either to reduce ambient light to a more familiar value or just to get more from the setting I'm already using.

Given that ambient light will be set in one of the oxps I have brewing I'll stall just a little while I explore this option.

[Redspear]

Opted for the more economical method and will edit the 'code post' accordingly.

Meanwhile, the oxps...

Option 1: "Just a modest rescale thank you. Less is more, don't you know" Just a taste for me

Option 2: "If less is more, imagine how much more 'more' can be..." I want it all damn it!

So take them for a spin and/or find ways to break them.
They're certainly tweakable to a degree so there's the possibility of personalising them too.

As usual, feedback welcomed. Thanks.

[another_commander]

I think that releasing a binary would go a long way to enabling more extensive testing. Just a zip file with the oolite.app and AddOns folders should be all that is needed.

The atmospheres look a bit wrong to me. Probably the adjusted formula needs further tweaks. This is what I see with the rescaling experiment on Lave just before the sky starts turning blue:




And this is what it looks like with the standard binaries, again just before the sky starts turning blue:



Ignore the extra brightness there, but you can see that the atmospheres do not look the same. The rescaling one seems to end in a rough edge, instead of smoothly fading away to black.

[Redspear]

I think that releasing a binary would go a long way to enabling more extensive testing. Just a zip file with the oolite.app and AddOns folders should be all that is needed.

Fair enough, I'll give that a go.

you can see that the atmospheres do not look the same. The rescaling one seems to end in a rough edge, instead of smoothly fading away to black.

I did notice this and tried a few things but no luck. It's only obvious on planetary approach I think but there are a few quirks I'd like to point out.

• It's the planetary edge rather than the atmosphere edge that is rough.
• The whole thing appears to be set a little 'inside' of the planet's edge. Note the white line within and the extreme edge of the atmosphere just above (where it is not thick enough to hide the rough edge of the planet).
• The surface can appear more 'cloudy'. Partly this is a resolution issue but there seems to be an interaction going on.

It's one of those things that looks like it should be an easy fix but was evading my attempts (or my attempts were evading it).

[another_commander]

It's one of those things that looks like it should be an easy fix but was evading my attempts (or my attempts were evading it).

It is a truly difficult thing to get right. When I was faced with the same problem in the unscaled version, the way I tackled it was this:
1. I picked one large, one medium and one small sized planets, based on their radius ranges.
2. For each one, I experimented with cosThreshold values until the atmo effect was displaying correctly for each one.
3. I plotted the radius vs cosThreshold values I had and estimated a best fit curve. Luckily for my case, the relationship seemed to be very close to linear. This is what it looked like:

4. I used the estimated best fit curve as a formula in the shader, so that any planet with radius from about 2700 to about 6800 km would display its atmosphere right. This is where the -1.3333e-6 and 0.213333 factors are coming from.

So I guess if you are going to modify the radius of the planets, you will probably need to redefine that relationship between best looking cosThershold value and radius and that may be far from a simple task.

[Commander_X]

Wondering if the "distances" in the atmosphere shader should also need some tweaking (to be more specific, the values of 3500.0 in minDistance assignment, and 2000.0 in quant).
Also do both the uniforms passed to the shader have adjusted values (e.g. one of them is "collisionRadius" and I'd expect it to be reflected by the new planet scale, not sure though about "relativePosition")?

[Redspear]

Wondering if the "distances" in the atmosphere shader should also need some tweaking...

Yeah, I thought that and they were some of the things I adjusted without success. However...

Having this relationship explained certainly gives me fresh ideas (thanks a_c ).

It only seems to be a significant problem with the smaller planets (Lave isn't the biggest) and so that's likely also a clue, suggesting perhaps that a_c's formula loses accuracy to the left of the graph (smaller radius) rather than to the right (larger radius).

[gizmo]

I think that releasing a binary would go a long way to enabling more extensive testing. Just a zip file with the oolite.app and AddOns folders should be all that is needed.

Fair enough, I'll give that a go.

Yeah, that would be great as I haven't managed yet to compile Oolite on my system (Slackware Linux with Plasma 5).

[Redspear]

I plotted the radius vs cosThreshold values I had and estimated a best fit curve.

Do you still have the raw data? If so, please pass it on.

Extrapolating along a line will obviosly deviate from even the slightest curve. Increasing planet size by a factor of 10 for example would lead to negative values using your chart.

[another_commander]

I have uploaded the spreadsheet I used on https://drive.google.com/file/d/1viE2cr ... sp=sharing

The graph is associated with the data in columns B (radius * 10) and C (cosThreshold).

BTW, cosThreshold is supposed to be the value of the cosine of the angle between the planet surface normal and the light ray below which the atmosphere effect "reverses", i.e. from fading in from the planet center towards the edge to fading out towards space (hope I explained this in a somewhat understandable way).

[Redspear]

I have uploaded the spreadsheet I used on https://drive.google.com/file/d/1viE2cr ... sp=sharing

Thanks.

After trying various things I appear to be close to a solution (things certainly look better at both Lave and Diso). Tired of tweaking for now however, so I'll get back to it later.

Meanwhile, here's another (ab)use of Smivs' ship size chart. Rescales on the left, originals on the right.



Both oxp versions of the experiment use the same ship proportions if not the same sizes.
Anaconda is at x2 in the Rescale_Modest.oxp and at x3 in the Rescale_Plus.oxp - the latter halves time spent in masslock, the former reduced it only a little.

The only ship to actually be smaller in game is the Thargon, so please bear in mind that this is a comparison of proportions rather than sizes.

[Redspear]

OK, so as usual I make no claims for this adjustment to be optimal but so far it seems to be pretty good.

Code: Select all

float cosThreshold = -1.333333e-6 * atmRadius / 10 + 0.13333333;

I'll update the main code post on the previous page of this thread.