How do you choose the v1.1.9 color behavior?

[dov]

When using the the latest HEAD version of VulkanSceneGraph, did noticd see that the colors have changed, and are now much brighter (higher V value as in HSV) than in version 1.1.9. Is there an option to get the old 1.1.9 behavior back? Or is there another way to "tune" the color brightness?

[robertosfield]

I posted about these changes briefly last Friday just after I checked them, as I was doing the write up we got a power cut due to severe storm hitting Scotland. I post about this in thread #1376.

We now have power back, but I've been pondering how best to explain about the changes and ended deciding to make some further changes and am currently writing an vsgcolorspace example that will illustrate the topic.

Long story cut short, I've merged changes that make sRGB the default read format for images (as it always should be have, but they previous defaulted to RGB), and sRGB the default format for storage of frame buffer. There are also changes to built in ShaderSets that remove the previous sRGB_to_linear and linear_to_sRGB conversions that were happening as these are no longer required. Essentially the VSG is now doing what it should have done from the beginning w.r.t. being sRGB/Gamma correct.

Now there are several strategies you can take to update your application and data to take account of these changes to default, which one depends upon the window setup, data and shaders you have and what settings you are presently using. If the data, shaders and application window setup are all consistent then visuals should be pretty similar.

What type of data and shaders are you using?

How are you creating the windows?

[robertosfield]

The frame buffer/swap chain preferences now default to sRGB frame buffer image and sRGB colour space (how the desktop composition/display with treat it), whereas before they defaulted to linear RGB frame buffer image with sRGB colour space. sRGB storage does a conversion from linear RGB to sRGB automatically when the fragment is written from the fragment shader, while linear RGB storage won't do the conversion so typically the shader would have to do this conversion before outputting the fragment colour.

The vsgviewer example illustrates how to set the values to use when setting up WindowTraits:

/~https://github.com/vsg-dev/vsgExamples/blob/master/examples/app/vsgviewer/vsgviewer.cpp#L103

        if (arguments.read("--sRGB")) windowTraits->swapchainPreferences.surfaceFormat = {VK_FORMAT_B8G8R8A8_SRGB, VK_COLOR_SPACE_SRGB_NONLINEAR_KHR};
        if (arguments.read("--RGB")) windowTraits->swapchainPreferences.surfaceFormat = {VK_FORMAT_B8G8R8A8_UNORM, VK_COLOR_SPACE_SRGB_NONLINEAR_KHR};

So this is one thing to try, i.e. the --RGB line, but this might just be a short term change, and you'd be better off fixing the data/shaders as I'll go into tomorrow in the dedicated thread.

[dov]

Thanks. Indeed I need some more explanation. I tried both both these values --sRGB and ---RGB and it doesn't replicate the look of of v1.1.9.

Here's the difference from my clipping application:

v1.1.9:

And here it is with v1.1.10 (HEAD):

I didn't really see a big difference with the the two different surface format flags.

My fragment shader is a simplistic two fixed light source phong model:

void main() {
  // First light
  vec3 N = normalize(normal);
  vec3 L = normalize(lightPos - pos);
  vec3 R = reflect(-L, N);      // Reflected light vector
  vec3 V = -normalize(pos); // Vector to viewer

  float Kd = max(dot(L,N), 0.0);
  float Ks = pow(max(dot(R,V),0.0), material.shininess)*0.6;

  // Second light
  L = normalize(lightPos1 - pos);
  R = reflect(-L, N);
  Kd += max(dot(L,N), 0.0) * lightStrength1;
  Ks += pow(max(dot(R,V),0.0), material.shininess) * lightStrength1;
  
  outColor =  vec4(
    vec3(material.ambientColor.xyz
         + material.diffuseColor.xyz * Kd * 0.7
         + material.specularColor.xyz * Ks*0.02),
         fragVertexColor.w 
  );
}

Note that even the ImGui color has been changed.

[robertosfield]

The place for all the details is in a dedicated thread on the topic.

Essentially previously there was a bit of mixed combinations of colour spaces that weren't correct but got the result we got used to. The changes in VSG, vsgXchange and vsgExample master put things in a more explictit colour space order.

Now if you just load your scene graphs a fresh from their original sources and create the windows with defaults then mostly things should look similar, albeit not identical as the original results weren't correct.

If you have old scene graphs configured to roughly work with the older VSG setup and load them with new VSG then more significant visual changes are noticeable. Loading the data from the original sources might help if that's the source of the problem.

If you application sets up things like vsg::Light's then it might that it's over-saturating because the ambient light values are just too strong because previously they had an implicit gamma correction, but now they are being treated as linear.

Have a look at the changes checked into the vsgExample branch for clues as what might need changing.

You haven't said anything about how you sourced and setup the scene graph so I can't provide any specific advice.

[AnyOldName3]

Looking at that shader and the other context we have here, it's almost certainly mostly your ambient light being around ten times more intense than you want it to be. Before this set of fixes, the VSG would make dim colours dimmer than they should be, so the default light setup that was made to look good rather than anything empirical (e.g. by going into a photography studio with a light meter to learn what they used) compensated for that by using an unrealistically bright ambient light.

Also, if you're setting your material colours with a vec4 literal instead of loading them from a file, you might need to change them from sRGB to linear RGB (either by using an online converter tool like https://physicallybased.info/tools/ or by calling vsg::sRGB_to_linear). Previously, it was inconsistent whether they were interpreted as sRGB (e.g. by the built-in Phong shaderset) or linear RGB (e.g. by the built-in PBR shaderset), and now they always use linear RGB as that's the more natural one to do maths in. You've also got the option of changing how your own shader interprets them, but I wouldn't recommend it as it'll be more hassle.

The ImGui colour having changed is unexpected as vsgImGui should convert the ImGui style to use the right colourspace for your framebuffer automatically. If you've not updated vsgImGui, then doing so should fix your problem, otherwise we're going to need to know more about your specific application.

[robertosfield]

I have now written up the color space changes on the thread: At long last - a Gamma correct scene graph :-) #1379

[dov]

Thanks @robertosfield and @AnyOldName3 . Indeed it was just a question of tuning my shader color components, and now my application looks just like before.