Oolite on HDR Displays

News and discussion of the PC port of Oolite.

Moderators: another_commander, winston

cag
Deadly
Deadly
Posts: 197
Joined: Fri Mar 17, 2017 1:49 am

Re: Oolite on HDR Displays

Post by cag »

cag wrote: Thu Sep 22, 2022 12:57 am
First, there is the central sphere surrounded by a cirular band just a hair dimmer than the sphere and ...
The central sphere is is gone! The central region of the sun is featureless & smooth.
cag wrote: Thu Sep 22, 2022 12:57 am
... similar atmospheres but the HDR one has an inner 'border' (ie. there is a slim, faint ring between the sun and its atmosphere ...
This is still present. The HDR and 'normal' versions' sun now appear similar. However, the HDR one still has perceptable circular banding that uses 4-5 gray levels as one moves outward to the sun's rim. The 'normal' version has this gradient too but is much less noticable as many more gray levels are used. This gradient may also be the cause of the inner 'border', as it appears that the gray level at the rim is darker (maybe?) than that of the corona. That being said, this is quite minor and would probably go unnoticed except by nit-picking beta testers staring at the sun too long. 8)

P.S. Sorry for the late reply but I received no notification of your post. In fact, it's been a while since I've received any; must check my spam filter (any gmail.com users getting notifications???)
"Better to be thought a fool, boy, than to open your trap and remove all doubt." - Grandma [over time, just "Shut your trap... fool"]
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

OK, thanks for the feedback. The new sun uses high HDR values for its disc color and you can see this if you position your ship in front of it in external view. You will then notice that the sun color bleeds into the edges of the ship, simulating a strong light source. Furthermore, you can adjust the strength of the sun's brightness by adding the key "sbf" in .GNUstepDefaults, like this:

Code: Select all

sbf = 150.0;
sbf is just a multiplier of the sun disc color, nothing special about it. If you don't have this key in .GNUstepDefaults, the default value 50.0 will be used internally. Since you have HDR display capability, you can try experimenting with other values, either lower or higher and see how this affects the apparent brightness of the sun. There is no limiter to the value for this key. It would be interesting to know what results you might get out of it.
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16059
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Oolite on HDR Displays

Post by Cody »

cag wrote: Sat Oct 15, 2022 5:35 pm
Sorry for the late reply but I received no notification of your post. In fact, it's been a while since I've received any; must check my spam filter (any gmail.com users getting notifications???)
You should receive notifications when quoted, and when subscribed to a thread. No notifications of PMs though (broken).
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
cag
Deadly
Deadly
Posts: 197
Joined: Fri Mar 17, 2017 1:49 am

Re: Oolite on HDR Displays

Post by cag »

another_commander wrote: Sat Oct 15, 2022 5:50 pm
...position your ship in front of it in external view. You will then notice that the sun color bleeds into the edges of the ship, simulating a strong light source.
This is weird. You can see the effect below. All show the phenomena you refer to. However, looking at an HDR screen, I see the outline of the ship in perfect detail (including the jaggie steps of the straight edge)! The regions that appear blurred in the images below only appear the a bit lighter in HDR, less effect than the corona has on the background. The 'normal' shot is a fair representation of what I see on my HDR display in a 'normal' version game but the HDR shot is not. That's why I took the photo, I was hoping to show how different they are but it shows way more bleed than my eye sees. weird.

'normal' screen shot
Image

HDR screen shot
Image

crap cellphone shot (HDR is the right window)
Image
another_commander wrote: Sat Oct 15, 2022 5:50 pm
Furthermore, you can adjust the strength of the sun's brightness by adding the key "sbf" in .GNUstepDefaults, like this:

Code: Select all

sbf = 150.0;
sbf is just a multiplier of the sun disc color, nothing special about it. If you don't have this key in .GNUstepDefaults, the default value 50.0 will be used internally. Since you have HDR display capability, you can try experimenting with other values, either lower or higher and see how this affects the apparent brightness of the sun. There is no limiter to the value for this key.
changing sbf
50 -> 150
changes central sphere's amorphous area
60% -> 80%

This shrinks the area of circular banding, so less noticable but still detectable <nit nit ooh, more nits>

I went as high as 200 (~90%, is asymtotic?) and as low as 2 (~50%). At 1, the sun itself appears much smaller, a little bigger than the golf ball from above (but the corona is the same size and there is no inner 'border', just a smooth transition out to the corona's rather quick termination. (see below)

You should also trap for a lower bound, as setting sbf = 0; overwrites .GNUstepDefaults with the default, the Latest.log complaining

Code: Select all

19:20:23.661 [gnustep]: 2022-10-15 19:20:23.661 oolite[8152] File NSDictionary.m: 625. In -[NSDictionary initWithContentsOfFile:] Contents of file 'D:\testingHDR/oolite.app/GNUstep/Defaults/.GNUstepDefaults' does not contain a dictionary
Looking at screen shots of both suns, the rim of the 'normal' version looks smoother than that of the HDR. Is a different smoothing (anti-aliasing?) algorithm used? I don't think it's the cause of the inner 'border' but does draw attention to it.

Also, in the cropped & scaled screen shots below, the corona's gradient away from center is more pronounced than that in HDR. This is not a result of the screen shot (ok, the brightness levels are); this is distict when viewing 2 game instances. The corona in the 'normal' version fades away while that in HDR does not (it's quite uniform up until its edge) or perhaps the fading region is much smaller.

'normal' version
Image

HDR version
Image
"Better to be thought a fool, boy, than to open your trap and remove all doubt." - Grandma [over time, just "Shut your trap... fool"]
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

Once again,thank you for the detailed and concise feedback. It really does help.
This is weird. You can see the effect below. All show the phenomena you refer to. However, looking at an HDR screen, I see the outline of the ship in perfect detail (including the jaggie steps of the straight edge)! The regions that appear blurred in the images below only appear the a bit lighter in HDR, less effect than the corona has on the background. The 'normal' shot is a fair representation of what I see on my HDR display in a 'normal' version game but the HDR shot is not. That's why I took the photo, I was hoping to show how different they are but it shows way more bleed than my eye sees. weird.

'normal' screen shot
Image

HDR screen shot
Image

crap cellphone shot (HDR is the right window)
Image
I think this is because in HDR the default brightness of the sun is still not enough to strongly engulf the ship in its light. I expect the effect to become similar if you increase the sbf in the HDR only version.
I went as high as 200 (~90%, is asymtotic?) and as low as 2 (~50%).
This HDR test works in the scRGB colorspace. This means that color values of 1.0 correspond to 80 nits luminance and values of 12.5 correspond to 1000 nits. By extrapolation, values of around 125 correspond to 10000 nits and values of 200 are even brighter. Given that your monitor can physically display no more than 300 nits, the HDR tonemapping that we do ensures that sbf values above 5.0 or so should in theory differ only in the percentage of the disc color covering the total sun area, without any observable changes in physical brightness. At least that is my expectation, hopefully it is what you actually see.
At 1, the sun itself appears much smaller, a little bigger than the golf ball from above (but the corona is the same size and there is no inner 'border', just a smooth transition out to the corona's rather quick termination. (see below)
This is what the sun is currently rendered like in trunk (i.e. as if sbf were 1.0). Although indeed there is no inner border in this case and the transition to the corona is very smooth, there is another problem with that which I think is more significant than the existence of an inner border: The sun is just not bright. Its reflections on ships and planets are brighter than the sun itself, which is a big no-no. I would like to reduce the intensity of the inner border and have already found a way to do that, but it is not the best way because it affects the apparent radius of the sun, which in turn results in changes in the mechanics of fuel scooping (isn't it great how a small rendering modification creates a huge avalanche of changes from anything between other graphics adjustments, up to and including gameplay elements?). I think I prefer the way it looks even with an inner border, if it means that the sun appears as bright as it should.
You should also trap for a lower bound, as setting sbf = 0; overwrites .GNUstepDefaults with the default, the Latest.log complaining

Code: Select all

19:20:23.661 [gnustep]: 2022-10-15 19:20:23.661 oolite[8152] File NSDictionary.m: 625. In -[NSDictionary initWithContentsOfFile:] Contents of file 'D:\testingHDR/oolite.app/GNUstep/Defaults/.GNUstepDefaults' does not contain a dictionary
Maybe this was due to a bad edit while changing the value? I just tried 0.0 and -3.0 here and it works (makes the sun look like a black hole though).
Looking at screen shots of both suns, the rim of the 'normal' version looks smoother than that of the HDR. Is a different smoothing (anti-aliasing?) algorithm used? I don't think it's the cause of the inner 'border' but does draw attention to it.
You have eagle eyes my friend. Well spotted! Indeed, the SDR version uses Multi Sample Anti Aliasing when requested, but MSAA and HDR are not compatible. As such, the HDR version is never antialiased.
Also, in the cropped & scaled screen shots below, the corona's gradient away from center is more pronounced than that in HDR. This is not a result of the screen shot (ok, the brightness levels are); this is distict when viewing 2 game instances. The corona in the 'normal' version fades away while that in HDR does not (it's quite uniform up until its edge) or perhaps the fading region is much smaller.

'normal' version
Image

HDR version
Image
I believe there is a fade out in the HDR version too, but as you say the fading region is smaller. It's just the way HDR does stuff I guess and maybe a separate sun rendering method will be meeded for best visuals.
User avatar
Cholmondely
Archivist
Archivist
Posts: 4997
Joined: Tue Jul 07, 2020 11:00 am
Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
Contact:

Re: Oolite on HDR Displays

Post by Cholmondely »

Just to say, as a dumb pilot reading through the wiki (Oolite JavaScript Reference: Sun, there seems to be few options in making the sun do very much.

Only the one sun. We can move it, change it's size, colour & name, blow it up ... and that's it!

With the new visuals software, might there be any possibiilty of improving things at some stage in the future?


Would it not be super to have something like this in our Ooniverses?
Image
Comments wanted:
Missing OXPs? What do you think is missing?
Lore: The economics of ship building How many built for Aronar?
Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

A set of alternative tone mapping options was checked in yesterday in the hdr_output branch on github. The new oolite-final-hdr.fragment shader can be found here: https://github.com/OoliteProject/oolite ... r.fragment

Feedback on the new options would be appreciated. Some create much more garish colors, others are more modest. Some testing will be needed in order to decide which of all the currently available tone mapping formulas would be best to go with, although I do understand that this type of preference is largely subjective. Just trying to get opinions other than my own.

To test, you must go to the end of the shader, in this part:

Code: Select all

// tone mapping
vec3 result = ACESFilmRec2020(hdrColor * (0.0125 * PAPERWHITENITS / MAXBRIGHTNESSNITS)) * MAXBRIGHTNESSNITS;
// alternative ways to tone map the result - testing is required to decide which of the available options could become official
//vec3 result = ACESFilmRec2020(hdrColor); // looks great but cannot be calibrated
//vec3 result = ACESFilmRec2020(hdrColor * PAPERWHITENITS / MAXBRIGHTNESSNITS) * MAXBRIGHTNESSNITS * 0.0125;
//vec3 result = ACESFilmRec2020(hdrColor * PAPERWHITENITS * MAXBRIGHTNESSNITS / SMPTE_ST2084MAXNITS);
and uncomment the line you want to test, at the same time commenting out all the other lines (only one option can be active at one time).

It should be noted here that the ACESFilmRec2020 tone mapper we use is tuned for 1000 nits brightness. Hopefully it can still look good on lower nits displays if max and paper white brightnesses are properly calibrated, but ideally we would need an OLED TV or some mega-expensive monitor to test fully.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

cag has been locked out of his forum account, so I am posting his reply at his request. @Cody and @Disembodied, would you be able to help him get back in?

reply by cag follows:
--------------------------------------------------------------------------------------------------
all run with
PAPERWHITENITS 140.0
MAXBRIGHTNESSNITS 500.0
sbf = 50



1) vec3 result = ACESFilmRec2020(hdrColor * (0.0125 * PAPERWHITENITS / MAXBRIGHTNESSNITS)) * MAXBRIGHTNESSNITS;
  • (version we've used in the past)
  • circular gradient bands,
  • well defined 'inner border' between solar disk and corona,
  • homogenous corona

2) vec3 result = ACESFilmRec2020(hdrColor);
  • no circular bands,
  • 'inner border' much less noticable,
  • corona still homogenous but seems a bit dimmer (may just be my perception due to chg in border, too close to call),
  • sun bleed when in silhouette more pronounced (detail a bit obscured, eg. can still see Mark III's small mast but not as crisp)

3) vec3 result = ACESFilmRec2020(hdrColor * PAPERWHITENITS / MAXBRIGHTNESSNITS) * MAXBRIGHTNESSNITS * 0.0125;
  • no circular bands,
  • 'inner border' less noticable but more so than 2) (which may be just down to the lack of circular banding reducing the impact of 'inner border'),
  • solar disk & corona brighter than 2),
  • sun bleed when in silhouette similar to 1), which given the increased brightness is odd

4) vec3 result = ACESFilmRec2020(hdrColor * PAPERWHITENITS * MAXBRIGHTNESSNITS / SMPTE_ST2084MAXNITS);
  • way too bright (station screens saturated),
  • stars & nebula quite vivid, like what you'd see in a hi-res cartoon; stars have quite noticable diffraction spikes (which were there all along but I'd never noticed),
  • 2nd corona apparent, ie. beyond the corona common to all views, there is a dimmer ring beyond about half as thick
  • has best sun bleed, naturally
Overall, 2) is my favorite (with sbf increased to 100) but that's not too useful since it's independent of PAPERWHITENITS & MAXBRIGHTNESSNITS.
I played w/ various values SMPTE_ST2084MAXNITS such that in 4) the argument to ACESFilmRec2020() is between 1 & 1.5 * hdrColor seems the best fit. You'll need to poll displays w/ different max nit values to see how it translates.

I accidently set sbf = 1000 and got 2nd my favorite: the bright ring in center of corona (seen when sbf = 0) appears just outside the solar disk and giving the sun's disk an 'atmosphere', which is less jarring than the original 'inner border'.

PS: when you want to try various values of sbf, it can be done w/o relaunching Oolite. Just edit .GNUstepDefaults & save, un-pause, pause, F8, F1 (sometime F8, F1 again). Oolite re-reads the file and applies the new value.

PPS: don't know if this is of any help but 1) & 3) have a 256x256 cursor shadow while 2) & 4) do not. By this I mean that if the mouse should stray over the sun, there is a 256x256 box (w/ the cursor's point in the upper left corner) that is visible and is transparent but slightly dimmer.

Cody wrote: Sat Oct 15, 2022 5:59 pm
You should receive notifications when quoted, and when subscribed to a thread. No notifications of PMs though (broken).
Nope, I am subscribed by virtue of posting (and I checked just in case) but no notification on a_c's new post or even when I'm quoted! I've gotten zero notifications from this topic and only knew to check because a_c emailed me. I tried white listing the board in gmail but nada. So I decided to try a different email address and am now royally screwed. The "board requires account reactivation on email changes" and "An activation key has been sent to the new email address you provided". It hasn't. <sigh> So let's log back in and revert to the original email address ... "The specified username is currently inactive. If you have problems activating your account, please contact a board administrator." <much impolite verbiage>
Who's our board administrator and does he get any notifications?

-----------------------------------------------------------------------------------------------------------------------------------------------------------
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16059
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Oolite on HDR Displays

Post by Cody »

@cag - I've just re-activated your original account. Please try and login again.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16059
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Oolite on HDR Displays

Post by Cody »

cag wrote: Sat Oct 15, 2022 11:55 pm
Who's our board administrator and does he get any notifications?
Testing, testing...


I'm what passes for an admin, but my permissions are limited.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
User avatar
Coyote
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 23
Joined: Sat Dec 17, 2011 12:53 am
Location: Deep space

Re: Oolite on HDR Displays

Post by Coyote »

Cody wrote: Sat Nov 05, 2022 10:25 am
cag wrote: Sat Oct 15, 2022 11:55 pm
Who's our board administrator and does he get any notifications?
Testing, testing...


I'm what passes for an admin, but my permissions are limited.
Testing, testing...
¿Dónde está la cerveza?
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16059
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Oolite on HDR Displays

Post by Cody »

Looks like email notifications of quotes (and subscriptions) are no longer working - another nail in the coffin!
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

Today I checked in one more tone mapping possibility in the hdr_output branch. This time, I am using the option which both cag and myself consider the best of the bunch (which happens to be the correct one too). In addition, this time I have addded the possibility of adjustment for max and paper white brightnesses. In the tests I've run this is by far my preferred result. @cag, if you can, would you mind running yet one more quick test and letting me know what you think? If you do try it out, please ensure that you include a test run with max brightness set to match your actual monitor's value.

The new shader is already primed to use this last option by default. It can be found here: https://github.com/OoliteProject/oolite ... r.fragment

I should also point out that the current result compares very well with the HDR injection done on the game by Special K. If you are not aware what this is, it is am amazing piece of software which (amongst other magic) can inject HDR in almost any game and Oolite plays very nicely with it; you can load the standard v1.91 game and play it on an appropriate display setup as if it had native HDR by default. So yeah, our native HDR result and Special K's result are very close now and I managed to run a good test on a system with a max brightness output of 600 nits.
cag
Deadly
Deadly
Posts: 197
Joined: Fri Mar 17, 2017 1:49 am

Re: Oolite on HDR Displays

Post by cag »

Cody wrote: Sat Nov 05, 2022 10:12 am
@cag - I've just re-activated your original account. Please try and login again.
Thanks for plugging this leaky ship!
another_commander wrote: Sat Nov 05, 2022 12:43 pm
@cag, if you can, would you mind running yet one more quick test and letting me know what you think? If you do try it out, please ensure that you include a test run with max brightness set to match your actual monitor's value.
I tested the default PAPERWHITENITS = 140.0, MAXBRIGHTNESSNITS = 500.0 and it looks fine. If I hadn't done any testing, I probably would have left it as is.

I tried our agreed upon settings for my monitor PAPERWHITENITS = 80.0, MAXBRIGHTNESSNITS = 350.0 and while nothing was amiss, it was a bit too dim. I bumped up PAPERWHITENITS to 100 for now. You'd think w/ a 0.001 multiplier, it wouldn't matter but the difference is quite apparent.

All this was done w/ sbf = 100. The difference at 150 was of course brighter but it seemed less so than the PAPERWHITENITS adjustment. Or I've been staring at these suns too long. Anyway, you may get away with a single slider (PAPERWHITENITS) and one time entry of MAXBRIGHTNESSNITS. Save sbf for those who are never satisfied. :twisted:

Edited to add: Stick a fork in it, it's done!
"Better to be thought a fool, boy, than to open your trap and remove all doubt." - Grandma [over time, just "Shut your trap... fool"]
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6552
Joined: Wed Feb 28, 2007 7:54 am

Re: Oolite on HDR Displays

Post by another_commander »

Update: The brightness options are now set in-game from the Game Options screen and you can see in real time how they affect the result. To set up correctly, the max brightness value closest to the actual monitor/TV max brightness must be selected first (options are 400, 500, 600, 800 and 1000 nits), then the result can be fine-tuned using the Paper White slider.

Image

Note that in order to fit the new options in the available space in Game Options, Wireframe Graphics had to be sacrificed when in HDR mode. I don't think that this is an option anyone has used for more than 5 minutes anyway, so I don't consider it a significant loss. If you must absolutely play in wireframe mode you can do so in normal SDR mode, no HDR is needed for that.

Additionally, the sun glare has been adjusted to more manageable, not blinding levels when running in HDR.

The new code will be committed to the hdr_output branch later today and it looks like a pull request for master will follow immediately afterwards. Looks like we are almost there.

There is a known issue though: screenshots in HDR mode will look incorrect because the buffers they are saved on are 8-bits per color. For this one, we may need to go to a higher libPNG version with expanded png support. This is something for much later though. For now, we'll have to live with this hopefully minor inconvenience.

The test files for this latest version are uploaded here: https://drive.google.com/file/d/1JD5j7k ... sp=sharing
Just unzip the contents to oolite.app, switch HDR on in Windows and run the game with the -hdr command line parameter. It will default to 1000 nits max brightness and 80 nits paperwhite; you can adjust that as described above.

Edit 20230113: Uploaded latest test package containing all features mentioned in this thread.
Post Reply