Oolite Bulletins

Posted: **Thu Sep 08, 2022 8:14 am**

This is a call for testers for a new feature of Oolite on Windows, currently in its first steps of development: Support for HDR displays.

Typically Oolite generates video output that is sent to screens supporting the 8-bits per pixel color component sRGB colorspace, which is pretty much standard since forever. But we can do better than that. Modern HDR displays operate at colorspaces with much larger ranges of visible colors than sRGB and can produce a much better contrast between hihglights and dark areas, while preserving detail in both. I think I have the basic concept down and can generate screen backbuffer output with HDR content. I also believe I have a good tone mapping algorithm suitable for Rec2020 HDR displays. Unfortunately I do not have an HDR display myself to test my beliefs and the only one I have found - at an internet cafe somewhere - seems to be messed up and generates 6 instead of 10 bits per pixel color component output when its HDR mode is switched on from within Windows, which is not good, like, at all (even the sample movie in Windows settings itself looks completely screwed up in HDR there).

In short, I would need to know if there are any Windows users with proper HDR-enabled displays who would be willing to run a test or two for me. If this works as I hope it will, it would mean a huge improvement in visuals, provided the right hardware is present to support the software. If it doesn't work then hey, at least we tried

Please raise your hand if interested and if there are any volunteers I will proceed to upload test files and instructions. Thanks in advance to anyone willing to help.

Posted: **Thu Sep 08, 2022 7:55 pm**

Can't help you there, Admiral - my search for a suitable 4K monitor became complicated and is on hold, perhaps permanently.

Posted: **Thu Sep 08, 2022 10:55 pm**

I have a laptop with a 4k screen (HP EliteBook 1050 G1 Base Model). At least, I'm pretty sure the display is 4K. It's resolution is 3840 x 2160.

Posted: **Fri Sep 09, 2022 6:36 am**

phkb wrote: ↑Thu Sep 08, 2022 10:55 pm
I have a laptop with a 4k screen (HP EliteBook 1050 G1 Base Model). At least, I'm pretty sure the display is 4K. It's resolution is 3840 x 2160.

Does it support HDR though? If you go to Windows Settings -> System -> Display, do you see an on/off switch under Windows HD Color?

Posted: **Wed Sep 21, 2022 12:48 am**

another_commander wrote: ↑Thu Sep 08, 2022 8:14 am
...
Please raise your hand ...

I've got an LG UltraGear 2560 x 1440 @165 Hz, Bit depth 10-bit, color format RGB, color space HDR
connected to a NVIDIA GeForce RTX 2070 Super

Didn't turn on HDR until I read your post - man, is it bright! Turned brightness down from 100 to 60 to stop my eyes watering.

Don't mind testing but was wondering how to report results ...

Posted: **Wed Sep 21, 2022 6:05 am**

cag wrote: ↑Wed Sep 21, 2022 12:48 am
I've got an LG UltraGear 2560 x 1440 @165 Hz, Bit depth 10-bit, color format RGB, color space HDR
connected to a NVIDIA GeForce RTX 2070 Super

Didn't turn on HDR until I read your post - man, is it bright! Turned brightness down from 100 to 60 to stop my eyes watering.

Don't mind testing but was wondering how to report results ...

OK, this seems to be a good specification for our test.

And here are the instructions:
1. Download the 1.5GB (contains OXPs) test build from here: https://drive.google.com/file/d/17SyHRz ... sp=sharing
2. Unzip the file to a location of your preference. You should now have a build of Oolite with quite a few OXPs ready to go.
3. Create a shortcut of oolite.exe somewhere, let's say desktop.
4. Right click on the shortcut icon and select Properties.
5. Inside the box named Target, where the executable path is shown, add at the end -hdr
6. Open the shader file oolite.app/Resources/Shaders/oolite-final-hdr.fragment in a text editor.
7. At the top of the file, find the lines that read

Code: Select all

#define PAPERWHITENITS		180.0
#define MAXBRIGHTNESSNITS	1000.0

and change the values to match your monitor better. Having had a quick look online, it looks like your monitor is probably a 300 nits one, so that value should go in MAXBRIGHTNESSNITS. You can experiment with the PAPERWHITENITS, but I think something like around 140-180 should be OK. Save after applying the changes.
8. Make sure Windows HDR mode is turned on and that your color depth is 10 bit. You can check that in Start->Settings->System->Display->Advanced Display Settings.
9. Launch Oolite from the shortcut.

10. Look at the spinning Cobra and the BGS backgrounds. Does it look OK? Is there any color banding visible?
11. Launch from the station. Switch on external views and with Caps Lock on, rotate the view around your ship. Again, we are looking for overall picture quality, color banding (ideally there should be none) and brightness levels and contrast. How do the nebulae look? How does the sun look? I expect the sun to be quite dim, this is a known issue but I think there is a solution. Once happy with what you have seen, exit the game.

12. Please post here the top of your Latest.log along with your overall impressions. We are interested in your display.initGL lines and all the way down to the report of your gfx renderer (no need for the extensions list).

I should note here that in all of this testing, posting screenshots is unfortunately not going to be of any value. HDR cannot be represented fully on a standard SDR monitor, nor can we save HDR images as screenshots at the moment. So we will have to rely on your eyes and observations for everything. HDR is something that has to be viewed in real time; it cannot be described otherwise. The best we can hope for if a screenshot is necessary is to take a photo of your screen with the game running on it, but it still won't be exactly what you are seeing live.

Let's hope it works out OK. Any problems, give a shout and many thanks for your help.

Edit to add: Running the build with the -hdr parameter on a non-HDR display will just look oversaturated and a bit weird.

Posted: **Thu Sep 22, 2022 12:57 am**

Let me start with "very nice". Shiny bits are shinier, colors are vivid. My only complaint would be with the brightness. That could be down to the fragment values; I started with:

Code: Select all

#define PAPERWHITENITS		140.0
#define MAXBRIGHTNESSNITS	300.0

another_commander wrote: ↑Wed Sep 21, 2022 6:05 am
posting screenshots is unfortunately not going to be of any value

I disagree, in part due to my lack of communication skills. While they contain NO quantitative value, similar scenes on the screen at the same time may have some qualitative value. I took photos of my screen with 2 Oolite instances running, the top is normal, the bottom is using '-hdr'. They're mostly useless as they're out of focus (my fault) and don't do justice to the colors (camera's fault). At least you can get a feel for the difference.

another_commander wrote: ↑Wed Sep 21, 2022 6:05 am
10. Look at the spinning Cobra and the BGS backgrounds. Does it look OK? Is there any color banding visible?

The Cobra looks more polished, literally. When the light reflects off a small flat detail, the glint is more defined/less hazy. There is color banding in the background; you can even see it in my camera pic (bottom instance, upper right).

I examined the resource (bgs_intro.png) and it's there too, so not your fault; you've reproduced the banding faithfully! This will always be a problem when we increase color resolution with a gradient present. Station backgrounds will need an HDR version that has no gradients or be in an HDR compatible format(?).

another_commander wrote: ↑Wed Sep 21, 2022 6:05 am
... we are looking for overall picture quality, color banding (ideally there should be none) and brightness levels and contrast. How do the nebulae look? How does the sun look? I expect the sun to be quite dim, this is a known issue but I think there is a solution.

I saw no banding once in space. The picture is much better, esp. seeing them side by side.
The planet in the 'normal' version seems washed out while the HDR one does not appear overly saturated.

Space is, well, full of stars! I know there are the same number but the dimmer ones are easier to see, so it looks busier. Not a bad thing, if you've ever seen the night sky from a rural location.

The nebulae really stand out. They're not over-done but when you look at the same one side by side, there are aspects you just cannot see in the 'normal' version. I ran with the -hdr parameter on a non-HDR display and they were more vivid & saturated. The HDR hits the sweet spot in-between.

The sun, however, has 2 problems. First, there is the central sphere surrounded by a cirular band just a hair dimmer than the sphere and as thick as the sun's diameter. In the 'normal' version, it's just a featureless sphere. Imagine you have a golf ball and a softball that have been rendered smooth (no dimples or stitches). The HDR version has you holding the golf ball in front of the softball while the 'normal' one has no golf ball. You cannot see it in my photo so I added the black ring to approximate its size.

Both suns have similar atmospheres but the HDR one has an inner 'border' (ie. there is a slim, faint ring between the sun and its atmosphere that is not present in the 'normal' version). When run with the -hdr parameter on a non-HDR display and position ship in planet's shadow, there is a similar 'border' effect (related?). Is it possible the sun/atmosphere has cirular banding?

The sun's other problem is glare. When I aimed at the sun's center, the 'normal' version had a bit of glare but the HDR has lots! About 30% on its way to being white!

another_commander wrote: ↑Wed Sep 21, 2022 6:05 am
external views and with Caps Lock on, rotate the view around your ship

Looking at my ship, I'm struck by the crispness of the sun's reflection off of the ship's details. The only real difference, which again could be down to my .fragment values, is the shadows are too light. I think that too much of the texture is visible when backlit by the sun. I'm between the planet and the sun, so is this down to planet-shine not apparent in 'normal' version? (ie. bug or feature

)
(see extra pics in dropbox folder below if your interested; I'm going to play w/ the .fragment values in the mean time)

I took my ship to the side of the planet opposite the sun, fully eclipsed and the planet's not dark enough.

With the external view, though, the ship's darkness was comparable in both versions but the HDR was still lighter.

Latest.log, trimmed:

Code: Select all

Opening log for Oolite version 1.91 (x86-64 test release) under Windows 10.0.19043.2006  64-bit at 2022-09-21 19:10:35 -0400.
AMD Ryzen 5 3600X 6-Core Processor              12 processors detected. System RAM: 32717 MB (free: 24962 MB).
Build options: OpenAL, GLSL shaders, new planets, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

19:10:36.035 [display.initGL]: V-Sync requested.
19:10:36.035 [display.mode.list.native]: Windows native resolution detected: 2560 x 1440
19:10:36.035 [display.initGL]: Trying 16-bpcc, 24-bit depth buffer
19:10:36.183 [gamma.set.failed]: ----- WARNING: Could not set gamma: Gamma ramp manipulation not supported
19:10:36.183 [display.initGL]: Achieved color / depth buffer sizes (bits):
19:10:36.183 [display.initGL]: Red: 16
19:10:36.183 [display.initGL]: Green: 16
19:10:36.183 [display.initGL]: Blue: 16
19:10:36.183 [display.initGL]: Alpha: 16
19:10:36.184 [display.initGL]: Depth Buffer: 24
19:10:36.184 [display.initGL]: Pixel type is float : 1
19:10:36.290 [joystick.init]: Number of joysticks detected: 1
19:10:36.292 [rendering.opengl.version]: OpenGL renderer version: 4.6.0 ("4.6.0 NVIDIA 512.15"). Vendor: "NVIDIA Corporation". Renderer: "NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2".
19:10:36.292 [rendering.opengl.extensions]: OpenGL extensions (400):
GL_NV_blend_square, GL_KHR_parallel_shader_compile, GL_ARB_map_buffer_range, GL_ARB_instanced_arrays, GL_ARB_shader_viewport_layer_array, GL_ARB_direct_state_access, GL_NV_memory_attachment, GL_ARB_clear_texture, GL_EXT_texture_compression_rgtc, GL_EXT_post_depth_coverage, GL_NV_texture_compression_vtc, GL_EXT_texture_storage, GL_NV_fragment_program, GL_ARB_query_buffer_object, GL_EXT_texture_shared_exponent, GL_EXT_sparse_texture2, GL_ARB_uniform_buffer_object, GL_EXT_texture_array, GL_ARB_shader_draw_parameters, GL_NV_mesh_shader, GL_ARB_shading_language_include, GL_ARB_separate_shader_objects, GL_NV_fragment_shader_interlock, GL_EXT_packed_pixels, GL_ARB_texture_query_levels, GL_ARB_fragment_layer_viewport, GL_NV_fence, GL_ARB_explicit_uniform_location, GL_ARB_stencil_texturing, GL_NV_conservative_raster, GL_EXT_gpu_program_parameters, GL_EXT_vertex_array, GL_EXT_provoking_vertex, GL_NV_draw_vulkan_image, GL_ARB_texture_view, GL_ARB_ES3_1_compatibility, GL_NV_texgen_reflection, GL_EXT_multi_draw_arrays, GL_NVX_gpu_multicast2, GL_ARB_clear_buffer_object, GL_EXT_texture_object, GL_EXT_packed_float, GL_EXT_texture_filter_anisotropic, GL_ARB_get_program_binary, GL_ARB_half_float_vertex, GL_ARB_program_interface_query, GL_EXT_bindable_uniform, GL_ARB_multi_draw_indirect, GL_NV_texture_multisample, GL_ARB_texture_buffer_object, GL_ARB_gpu_shader_fp64, GL_EXT_blend_minmax, GL_ARB_vertex_attrib_64bit, GL_ARB_texture_query_lod, GL_ARB_compressed_texture_pixel_storage, GL_EXT_texture_integer, GL_ARB_texture_non_power_of_two, GL_EXT_texture_compression_s3tc, GL_ARB_texture_stencil8, GL_KHR_no_error, GL_ARB_texture_mirror_clamp_to_edge, GL_ARB_framebuffer_no_attachments, GL_NV_parameter_buffer_object2, GL_ARB_shading_language_420pack, GL_ARB_sample_locations, GL_NV_texture_rectangle, GL_KHR_robustness, GL_SGIX_shadow, GL_EXT_vertex_array_bgra, GL_EXT_depth_bounds_test, GL_NV_conservative_raster_pre_snap, GL_NV_vertex_array_range2, GL_ARB_shader_texture_image_samples, GL_NV_vertex_program2, GL_ARB_texture_compression_bptc, GL_NV_vertex_program3, GL_EXT_stencil_wrap, GL_EXT_separate_shader_objects, GL_NV_shader_atomic_float, GL_NV_scissor_exclusive, GL_NV_packed_depth_stencil, GL_ARB_texture_gather, GL_ARB_shader_image_size, GL_EXT_texture_cube_map, GL_EXT_shader_image_load_formatted, GL_NV_register_combiners2, GL_NV_half_float, GL_ARB_map_buffer_alignment, GL_SUN_slice_accum, GL_ARB_provoking_vertex, GL_NV_shader_thread_shuffle, GL_ARB_tessellation_shader, GL_NV_stereo_view_rendering, GL_EXT_direct_state_access, GL_NVX_multigpu_info, GL_ARB_texture_rg, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_ARB_bindless_texture, GL_SGIX_depth_texture, GL_NVX_linked_gpu_multicast, GL_NV_texture_env_combine4, GL_EXT_polygon_offset_clamp, GL_EXT_draw_range_elements, GL_EXT_draw_buffers2, GL_EXT_texture_filter_minmax, GL_ARB_transform_feedback2, GL_ARB_geometry_shader4, GL_ARB_fragment_coord_conventions, GL_ARB_transform_feedback3, GL_ARB_shader_precision, GL_NV_gpu_program_fp64, GL_NV_blend_equation_advanced_coherent, GL_NV_shader_atomic_counters, GL_ARB_get_texture_sub_image, GL_EXT_blend_color, GL_ARB_vertex_array_object, GL_NV_query_resource, GL_ATI_draw_buffers, GL_ARB_texture_mirrored_repeat, GL_EXT_stencil_two_side, GL_NV_shader_texture_footprint, GL_ARB_timer_query, WGL_EXT_swap_control, GL_NV_parameter_buffer_object, GL_EXT_texture_sRGB_decode, GL_NV_transform_feedback, GL_EXT_timer_query, GL_EXT_texture_edge_clamp, GL_EXT_shader_image_load_store, GL_NV_gpu_program4_1, GL_IBM_rasterpos_clip, GL_NV_framebuffer_multisample_coverage, GL_ARB_base_instance, GL_ARB_texture_float, GL_ARB_imaging, GL_ARB_draw_elements_base_vertex, GL_EXT_texture3D, GL_ARB_cull_distance, GL_EXT_packed_depth_stencil, GL_EXT_compiled_vertex_array, GL_ARB_texture_cube_map, GL_NV_uniform_buffer_unified_memory, GL_NV_primitive_restart, GL_EXT_blend_subtract, GL_EXT_separate_specular_color, GL_S3_s3tc, GL_NV_fragment_program_option, GL_EXTX_framebuffer_mixed_formats, GL_ARB_texture_compression, GL_ARB_gl_spirv, GL_ARB_texture_compression_rgtc, GL_ARB_texture_filter_anisotropic, GL_ARB_ES2_compatibility, GL_NV_shader_subgroup_partitioned, GL_ARB_shader_ballot, GL_NV_gpu_multicast, GL_NV_shader_atomic_float64, GL_NVX_blend_equation_advanced_multi_draw_buffers, GL_ARB_depth_buffer_float, GL_NV_light_max_exponent, GL_ARB_vertex_buffer_object, GL_KHR_blend_equation_advanced, GL_NV_shader_atomic_int64, GL_ARB_shading_language_100, GL_NV_shader_storage_buffer_object, GL_ARB_texture_env_add, GL_ARB_fragment_program, GL_NV_copy_depth_to_color, GL_ARB_sparse_buffer, GL_EXT_import_sync_object, GL_EXT_texture_swizzle, GL_ARB_shadow, GL_NV_conservative_raster_pre_snap_triangles, GL_ARB_texture_filter_minmax, GL_NV_shading_rate_image, GL_NV_copy_image, GL_NVX_progress_fence, GL_NV_clip_space_w_scaling, GL_ARB_shader_texture_lod, GL_ARB_clip_control, GL_NV_conservative_raster_dilate, GL_ARB_texture_multisample, GL_EXT_texture_env_combine, GL_ARB_sync, GL_ATI_texture_mirror_once, GL_ARB_robustness, GL_ARB_compatibility, GL_EXT_texture_compression_dxt1, GL_NV_gpu_program4, GL_NV_gpu_program5, GL_ARB_transform_feedback_overflow_query, GL_NV_vertex_array_range, GL_ARB_multitexture, GL_EXT_transform_feedback2, GL_NV_vertex_program2_option, GL_KHR_shader_subgroup, GL_ARB_buffer_storage, GL_NV_compute_program5, GL_NV_vertex_program1_1, GL_NV_gpu_program5_mem_extended, GL_NV_conservative_raster_underestimation, GL_EXT_shadow_funcs, GL_ARB_occlusion_query, GL_ARB_fragment_program_shadow, GL_NVX_nvenc_interop, GL_NV_vertex_buffer_unified_memory, GL_ARB_texture_barrier, GL_EXT_geometry_shader4, GL_EXT_memory_object_win32, GL_ARB_texture_env_dot3, GL_ARB_seamless_cubemap_per_texture, GL_ARB_multisample, GL_ARB_copy_image, GL_ARB_gpu_shader_int64, GL_ARB_color_buffer_float, GL_EXT_texture_env_add, GL_ARB_ES3_compatibility, GL_ARB_point_parameters, GL_ARB_sampler_objects, GL_ARB_transform_feedback_instanced, GL_ARB_invalidate_subdata, GL_KTX_buffer_region, GL_NV_vertex_attrib_integer_64bit, GL_NV_bindless_multi_draw_indirect, GL_NV_sample_mask_override_coverage, GL_NVX_gpu_memory_info, GL_EXT_framebuffer_object, GL_NV_gpu_shader5, GL_ARB_texture_rgb10_a2ui, GL_NV_shader_atomic_fp16_vector, GL_NV_ES1_1_compatibility, GL_ARB_texture_border_clamp, GL_NV_alpha_to_coverage_dither_control, GL_ARB_shading_language_packing, GL_NV_fragment_shader_barycentric, GL_EXT_bgra, GL_ATI_texture_float, GL_ARB_occlusion_query2, GL_ARB_shader_clock, GL_ARB_texture_env_crossbar, GL_NV_shader_buffer_load, GL_NV_feature_query, GL_NV_depth_clamp, GL_ARB_derivative_control, GL_ARB_conservative_depth, GL_AMD_vertex_shader_layer, GL_EXT_win32_keyed_mutex, GL_AMD_multi_draw_indirect, GL_ARB_shader_atomic_counters, GL_ARB_texture_env_combine, GL_EXT_framebuffer_multisample, GL_NV_occlusion_query, GL_EXT_Cg_shader, GL_NV_texture_barrier, GL_NV_path_rendering, GL_ARB_ES3_2_compatibility, GL_ARB_draw_buffers, GL_SGIS_generate_mipmap, GL_NV_path_rendering_shared_edge, GL_ARB_texture_buffer_object_rgb32, GL_EXT_window_rectangles, GL_NVX_conditional_render, GL_NV_register_combiners, GL_EXT_texture_sRGB_R8, GL_EXT_framebuffer_blit, GL_ARB_vertex_array_bgra, GL_NV_multisample_coverage, GL_EXT_texture_shadow_lod, GL_EXT_fog_coord, GL_ARB_window_pos, GL_NV_fill_rectangle, GL_ARB_half_float_pixel, GL_SGIS_texture_lod, GL_IBM_texture_mirrored_repeat, GL_EXT_texture_lod, GL_EXT_blend_equation_separate, GL_OVR_multiview2, GL_ARB_point_sprite, GL_ARB_parallel_shader_compile, GL_NV_fragment_program2, GL_ARB_shader_group_vote, GL_ARB_fragment_shader, GL_NV_blend_minmax_factor, GL_ARB_framebuffer_sRGB, GL_EXT_memory_object, GL_ARB_shader_objects, GL_NV_internalformat_sample_query, GL_WIN_swap_hint, GL_ARB_polygon_offset_clamp, GL_EXT_framebuffer_multisample_blit_scaled, GL_ARB_sparse_texture_clamp, GL_ARB_blend_func_extended, GL_ARB_shader_subroutine, GL_NV_pixel_data_range, GL_NV_viewport_swizzle, GL_NV_memory_object_sparse, GL_ARB_sparse_texture, GL_ARB_multi_bind, GL_KHR_debug, GL_EXT_multiview_timer_query, GL_NV_representative_fragment_test, GL_NV_framebuffer_mixed_samples, GL_ARB_transpose_matrix, GL_EXT_texture_compression_latc, GL_ARB_texture_cube_map_array, GL_NV_ES3_1_compatibility, GL_ARB_texture_buffer_range, GL_ARB_robust_buffer_access_behavior, GL_ARB_texture_storage_multisample, GL_EXT_texture_env_dot3, GL_NV_compute_shader_derivatives, GL_ARB_vertex_type_10f_11f_11f_rev, GL_EXT_texture_sRGB, GL_EXT_secondary_color, GL_EXT_point_parameters, GL_ARB_shader_image_load_store, GL_EXT_pixel_buffer_object, GL_ARB_explicit_attrib_location, GL_ARB_internalformat_query2, GL_ARB_seamless_cube_map, GL_ARB_draw_instanced, GL_ARB_draw_buffers_blend, GL_NV_sample_locations, GL_ARB_post_depth_coverage, GL_NV_fragment_coverage_to_color, GL_EXT_draw_instanced, GL_ARB_pipeline_statistics_query, GL_NV_texture_rectangle_compressed, GL_ARB_framebuffer_object, GL_ARB_internalformat_query, GL_OVR_multiview, GL_EXT_texture_mirror_clamp, GL_ARB_texture_rectangle, GL_ARB_gpu_shader5, GL_EXT_gpu_shader4, GL_ARB_compute_shader, GL_AMD_seamless_cubemap_per_texture, GL_NV_fog_distance, GL_EXT_multiview_texture_multisample, GL_ARB_spirv_extensions, GL_ARB_depth_clamp, GL_KHR_robust_buffer_access_behavior, GL_NV_texture_shader, GL_NV_shader_thread_group, GL_NV_float_buffer, GL_ARB_vertex_type_2_10_10_10_rev, GL_KHR_blend_equation_advanced_coherent, GL_AMD_vertex_shader_viewport_index, GL_ARB_shader_storage_buffer_object, GL_NV_conditional_render, GL_ARB_vertex_program, GL_ARB_enhanced_layouts, GL_ARB_compute_variable_group_size, GL_NV_bindless_texture, GL_ARB_draw_indirect, GL_ARB_arrays_of_arrays, GL_NV_multisample_filter_hint, GL_ARB_indirect_parameters, GL_ARB_viewport_array, GL_NV_point_sprite, GL_ARB_texture_storage, GL_NV_geometry_shader4, GL_EXT_semaphore, GL_ARB_texture_swizzle, GL_ARB_sparse_texture2, GL_EXT_texture_lod_bias, GL_EXT_semaphore_win32, GL_EXT_abgr, GL_NV_viewport_array2, GL_ARB_vertex_shader, GL_ARB_vertex_attrib_binding, GL_NV_transform_feedback2, GL_ARB_depth_texture, GL_NV_query_resource_tag, GL_NV_vertex_program, GL_NV_blend_equation_advanced, GL_EXT_framebuffer_sRGB, GL_ARB_shader_atomic_counter_ops, GL_ARB_copy_buffer, GL_NV_depth_buffer_float, GL_EXT_raster_multisample, GL_ARB_pixel_buffer_object, GL_NV_explicit_multisample, GL_EXT_texture_buffer_object, GL_EXT_blend_func_separate, GL_ARB_fragment_shader_interlock, GL_NV_command_list, GL_NV_geometry_shader_passthrough, GL_NV_draw_texture, GL_EXT_vertex_attrib_64bit, GL_NV_timeline_semaphore, GL_EXT_rescale_normal, GL_ARB_sample_shading, GL_ARB_shader_bit_encoding, GL_KHR_context_flush_control, GL_EXT_shader_integer_mix, GL_NV_bindless_multi_draw_indirect_count, GL_ARB_debug_output, GL_ARB_conditional_render_inverted
19:10:36.308 [rendering.opengl.shader.support]: Shaders are supported.

19:10:36.379 [MSAA.setup]: Multisample anti-aliasing not requested.
19:10:40.060 [display.initGL]: Requested a new surface of 1194 x 716, windowed.
19:10:40.120 [display.initGL]: Created a new surface of 1194 x 716, windowed.
19:10:40.128 [startup.complete]: ========== Loading complete in 4.21 seconds. ==========

original log and all 10 pics: https://www.dropbox.com/sh/4jztn2woy2zu ... L58Ka?dl=0

P.S. For future testing, could you make me a differential archive (only new files)? My internet access is crap (almost an hour to DL)

Posted: **Thu Sep 22, 2022 6:17 am**

Wow, thank you so much for the very detailed and thorough report and for taking the time to test and write all this down! Much appreciated.

My only complaint would be with the brightness. That could be down to the fragment values; I started with:

I think you are right. Assuming the monitor is indeed 300 nits, this is a bit on the low side for HDR (considering that the VESA DisplayHDR monitor certification starts at 400 nits and that is already considered too low). So if that is the max brightness we can obtain, then maybe the starting value of 140 for paper white is too much. At this point, I would recommend trying a paper white value closer to the SDR range, say around 90 or 100 (nominal SDR paper white is at 80 nits). I think this might tone down the excessive brightness and result in better image quality. One more thing you can try is go to Start->Settings->System->Display->Windows HD Color settings and lower the slider titled HDR/SDR brightness balance. This will reduce brightness on the entire desktop.

The sun, however, has 2 problems. First, there is the central sphere surrounded by a cirular band just a hair dimmer than the sphere and as thick as the sun's diameter. In the 'normal' version, it's just a featureless sphere. Imagine you have a golf ball and a softball that have been rendered smooth (no dimples or stitches). The HDR version has you holding the golf ball in front of the softball while the 'normal' one has no golf ball. You cannot see it in my photo so I added the black ring to approximate its size.

Yes, I was expecting issues with this. The main issue with the sun is that its original visuals are designed to emulate a pseudo-bloom effect, which works extremely well on SDR because, well, that's what it was designed on. In such case, sun disc and corona colors levitate towards the highlights zone when tonemapped, which gives a nice consistent glow effect. With the extended brightness and color ranges available to us in HDR mode though, the same colors are now not highlights anymore, they are just "kind of bright, but not that much". Mind you, this version of the game you have tested contains an additional modification to increase the luminosity of the sun's colors by a factor of at least 3 and that seems to not be enough either. Without that code modification, the sun would look dimmer and you might be even able to distinguish more stripes on the disk colors. What I consider trying is remove all the pseudo-bloom effects when in -hdr and just render a flat disc with the actual sun color, increase the brightness by a factor of, say 50 or more (which would make the sun very bright, as one would expect) and let our new, real bloom effect do all the rest of the work. I am also considering substantially lowering the sun glare effect because that already is quite intrusive as-is and it would only be more pronounced in an HDR environment.

Both suns have similar atmospheres but the HDR one has an inner 'border' (ie. there is a slim, faint ring between the sun and its atmosphere that is not present in the 'normal' version). When run with the -hdr parameter on a non-HDR display and position ship in planet's shadow, there is a similar 'border' effect (related?). Is it possible the sun/atmosphere has cirular banding?

I am not sure, but I think this might be related to the way the sun is rendered. Simplifying its rendering in -hdr as mentioned above might help here too.

The sun's other problem is glare. When I aimed at the sun's center, the 'normal' version had a bit of glare but the HDR has lots! About 30% on its way to being white!

Yup, glare should be definitely toned down. A lot.

Looking at my ship, I'm struck by the crispness of the sun's reflection off of the ship's details. The only real difference, which again could be down to my .fragment values, is the shadows are too light. I think that too much of the texture is visible when backlit by the sun. I'm between the planet and the sun, so is this down to planet-shine not apparent in 'normal' version? (ie. bug or feature )

I think this is in part because of the overall heightened brightness, which hopefully can be mitigated by lowering the paper white level, and in part due to the nature of HDR, which gives better visibility both in the highlights and the darks. You might also want to experiment with the ambient light level when in -hdr, see if that helps a bit too.

P.S. For future testing, could you make me a differential archive (only new files)? My internet access is crap (almost an hour to DL)

No worries, from now on I think only the executable or a shader or two will require changes, so we are looking at a max of 2.5 to 4MB if the exe is zipped. Sorry for the huge initial download, but I just wanted to be sure that you are testing the exact same build and configuration that I am coding on.

Once again, thanks for the great feedback. It looks like we are on the right path. Just try to see if you can get better darks with adjustments of the paper white level and we should be golden (oh yeah, need to fix the sun too).

Posted: **Thu Sep 22, 2022 10:22 pm**

another_commander wrote: ↑Thu Sep 22, 2022 6:17 am
Assuming the monitor is indeed 300 nits, this is a bit on the low side for HDR (considering that the VESA DisplayHDR monitor certification starts at 400 nits and that is already considered too low)

Yeah, it's 350. It's last year's model and already obsolete <sigh>.

another_commander wrote: ↑Thu Sep 22, 2022 6:17 am
One more thing you can try is go to Start->Settings->System->Display->Windows HD Color settings and lower the slider titled HDR/SDR brightness balance. This will reduce brightness on the entire desktop.

Wow, didn't even see that (hadn't scrolled down). It appears to have no effect on Oolite in HDR mode! I had both versions of Oolite running plus browser and editor and moving that slider altered the balance in all windows except the Oolite in HDR mode. So the value at startup is locked in? Or does it only apply to how SDR gets mapped to HDR color space?

another_commander wrote: ↑Thu Sep 22, 2022 6:17 am
... maybe the starting value of 140 for paper white is too much. At this point, I would recommend trying a paper white value closer to the SDR range, say around 90 or 100 (nominal SDR paper white is at 80 nits). I think this might tone down the excessive brightness and result in better image quality.

After a bunch of trials, I've settled on the following for now.

Code: Select all

#define PAPERWHITENITS		50.0
#define MAXBRIGHTNESSNITS	100.0

It's a pretty close match with the HDR version just a bit ahead in brighness.

Could you explain what these do in layman's terms? Which would be more responsive to adjustments? Would a game option slider be useful (or possible)? Are .fragment files like .plist in that a cache flush/restart is needed?

Thanks for implementing this. It's a brilliant addition to the game.

Posted: **Fri Sep 23, 2022 9:10 am**

So the value at startup is locked in? Or does it only apply to how SDR gets mapped to HDR color space?

Not sure what to tell you here. It could be that it applies only to how SDR gets mapped, but I was under the impression that it affects the desktop globally. If Oolite does something else with it, it does not do it intentionally.

After a bunch of trials, I've settled on the following for now.
Code: Select all
#define PAPERWHITENITS		50.0
#define MAXBRIGHTNESSNITS	100.0
It's a pretty close match with the HDR version just a bit ahead in brighness.

Could you explain what these do in layman's terms? Which would be more responsive to adjustments? Would a game option slider be useful (or possible)? Are .fragment files like .plist in that a cache flush/restart is needed?

OK, the paper white parameter is the number of nits that will represent white as a color, rather than as a highlight. It tells us how many nits correspond to the color triplet (1.0, 1.0, 1.0) and is the main brightness control. Nominally this has a value of 80 nits, but it can be adjusted according to the monitor specifications, usually to higher levels for HDR output. This is also the more responsive of the two adjustments.

The max brightness parameter is simply how many nits your monitor can display before it clips its output and cannot show any brighter anymore. This value should correspond to the monitor's max brightness specification and should really be adjusted only once.

Your values, although apparently resulting in an acceptable perceived brightness image, seem too low, quite a bit lower than an SDR setting even. Which means that either I am missing something in the implementation, or your monitor might maybe be calibrated to very bright levels when in HDR. What I would recommend is to set the values to 350.0 for max brightness and 90.0 for paper white, then try lowering the ambient level in the game a bit. I am running on a monitor which is quite dark overall, so I have set the ambient level to 0.25, but a value of 0.1 or even less could maybe work better than adjusting the shader values. You can set ambient level real-time with the debug console, by executing S.ambientLevel=0.05 for example.

A game option slider for those two is absolutely the right way to do it. Each monitor is different and users cannot be expected to edit shaders to match their hardware as part of the game's installation process. I just want to make sure that this thing works first, before dedicating any time to user interface upgrades for it.

Regarding editing, shader files can be changed without requiring a cache flush. Just edit, save and run the game.

Thanks for implementing this. It's a brilliant addition to the game.

Thank you for testing it. I hope for this to become the default one day, when HDR monitors get better standardization and become more approachable and commonplace.

Posted: **Fri Sep 23, 2022 4:24 pm**

another_commander wrote: ↑Fri Sep 23, 2022 9:10 am

cag wrote: ↑Thu Sep 22, 2022 10:22 pm
So the value at startup is locked in? Or does it only apply to how SDR gets mapped to HDR color space?
Not sure what to tell you here. It could be that it applies only to how SDR gets mapped, but I was under the impression that it affects the desktop globally. If Oolite does something else with it, it does not do it intentionally.

Having slept on it, I think the HDR/SDR brightness balance slider can only effect SDR apps. Their color palettes are a subset of the HDR's and the slider adjusts how much brightness they have relative to the HDR. That's why the Oolite window running SDR was effected but the HDR was not.

another_commander wrote: ↑Fri Sep 23, 2022 9:10 am
The max brightness parameter is ... the monitor's max brightness specification and should really be adjusted only once.

Ideally, Oolite would discover this value rather than relying on the user to set correctly. But I doubt the OS knows. May someday be possible, when Windows advances beyond calling all monitors 'Generic PnP' (and pigs fly!).

another_commander wrote: ↑Fri Sep 23, 2022 9:10 am
Your values, although apparently resulting in an acceptable perceived brightness image, seem too low, quite a bit lower than an SDR setting even. Which means that either I am missing something in the implementation, or your monitor might maybe be calibrated to very bright levels when in HDR. What I would recommend is to set the values to 350.0 for max brightness and 90.0 for paper white, then try lowering the ambient level in the game a bit.

That's done the trick: 350.0 (max brightness), 90.0 (paper white) and ambient level to ~~0.7~~ 0.07.

another_commander wrote: ↑Fri Sep 23, 2022 9:10 am
A game option slider for those two is absolutely the right way to do it. Each monitor is different and users cannot be expected to edit shaders to match their hardware as part of the game's installation process.

An ambient level slider would be handy too. Will 3 sliders be overkill? MAXBRIGHTNESSNITS could be a bunch of choices (like the 'Full Screen Mode'); the values are not a continuum but descrete values (350, 400, 500, ...). Also, spec. sheets don't use nits but cd or cd/m^2.

Posted: **Fri Sep 23, 2022 8:15 pm**

cag wrote: ↑Fri Sep 23, 2022 4:24 pm
That's done the trick: 350.0 (max brightness), 90.0 (paper white) and ambient level to 0.7.

Is this really 0.7 (i.e. much higher than the original 0.25)? Or you mean 0.07?

An ambient level slider would be handy too. Will 3 sliders be overkill? MAXBRIGHTNESSNITS could be a bunch of choices (like the 'Full Screen Mode'); the values are not a continuum but descrete values (350, 400, 500, ...). Also, spec. sheets don't use nits but cd or cd/m^2.

Maybe 3 are indeed overkill, but what worries me more than that is that we may be running out of lines in the Game Options screen. That would mean that a new screen would be needed for hosting these options and that gives me chiils even thinking about it.

As for units of measurement, cd/m^2 and nits are the same thing.

Posted: **Sat Sep 24, 2022 7:24 pm**

another_commander wrote: ↑Fri Sep 23, 2022 8:15 pm

cag wrote: ↑Fri Sep 23, 2022 4:24 pm
That's done the trick: 350.0 (max brightness), 90.0 (paper white) and ambient level to 0.7.
Is this really 0.7 (i.e. much higher than the original 0.25)? Or you mean 0.07?

D'oh!

Posted: **Wed Oct 05, 2022 10:15 am**

For anyone wishing to play with this feature further, be advised that the code is available on github under the hdr_output branch.

Please note that compiling this branch requires a small modification to one file in your Windows development environment. We need a specially modified version of SDL.dll for this (already included in the Windows dependencies submodule for this branch) and one of its headers has to be edited in advance for the build to succeed. To apply the change, open the file <PathToDevEnv>\gcc\Msys_x2\1.0\Devlibs\include\SDL\SDL_video.h in a text editor, find the enum at line 201 that reads

Code: Select all

typedef enum {
    SDL_GL_RED_SIZE,
    SDL_GL_GREEN_SIZE,
    SDL_GL_BLUE_SIZE,
    SDL_GL_ALPHA_SIZE,
    SDL_GL_BUFFER_SIZE,
    SDL_GL_DOUBLEBUFFER,
    SDL_GL_DEPTH_SIZE,
    SDL_GL_STENCIL_SIZE,
    SDL_GL_ACCUM_RED_SIZE,
    SDL_GL_ACCUM_GREEN_SIZE,
    SDL_GL_ACCUM_BLUE_SIZE,
    SDL_GL_ACCUM_ALPHA_SIZE,
    SDL_GL_STEREO,
    SDL_GL_MULTISAMPLEBUFFERS,
    SDL_GL_MULTISAMPLESAMPLES,
    SDL_GL_ACCELERATED_VISUAL,
    SDL_GL_SWAP_CONTROL
} SDL_GLattr;

and change it to this:

Code: Select all

typedef enum {
    SDL_GL_RED_SIZE,
    SDL_GL_GREEN_SIZE,
    SDL_GL_BLUE_SIZE,
    SDL_GL_ALPHA_SIZE,
    SDL_GL_PIXEL_TYPE_FLOAT, // <---------- Add this line
    SDL_GL_BUFFER_SIZE,
    SDL_GL_DOUBLEBUFFER,
    SDL_GL_DEPTH_SIZE,
    SDL_GL_STENCIL_SIZE,
    SDL_GL_ACCUM_RED_SIZE,
    SDL_GL_ACCUM_GREEN_SIZE,
    SDL_GL_ACCUM_BLUE_SIZE,
    SDL_GL_ACCUM_ALPHA_SIZE,
    SDL_GL_STEREO,
    SDL_GL_MULTISAMPLEBUFFERS,
    SDL_GL_MULTISAMPLESAMPLES,
    SDL_GL_ACCELERATED_VISUAL,
    SDL_GL_SWAP_CONTROL
} SDL_GLattr;

You will then be ready to build the branch. Just to be sure, execute a make clean before compiling so that you start the build afresh.

The reason we need this modification is because for outputting to HDR displays we have to be able to tell SDL to request pixel formats of type float from the OS / graphics driver when creating the main game window.

Posted: **Fri Oct 07, 2022 3:00 pm**

@cag, there is a new (2MB zipped) executable for testing available from here. Can you please give it a go whenever you get a chance and let me know if the sun rendering is any better now?

You may want to use PS.sunGlareFilter=1 in the debug console or install an OXP that kills the sun glare completely for a proper test.

Oolite Bulletins

Oolite on HDR Displays

Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays

Re: Oolite on HDR Displays