Different HDR settings make it difficult to work with outlines

[AAAYaKo]

Currently, it’s difficult to match colors in the project with ColorSpace Gamma because the fill doesn’t use hdr, but the outline does
Is it possible to make HDR optional for colors or remove it entirely?

[TLabAltoh]

I see. Currently, we're recommending setting the color space to Linear for project setup, but I'd also like to make sure the package works with Gamma if possible. I'll look into it a bit.

[TLabAltoh]

This is complete speculation and would be different from making HDR optional, but when setting outline colors in shader properties, if we instead set gamma-corrected colors, wouldn't it be possible to match the color picker in the inspector with the shader's output color in cases where the project is in gamma space? I remember considering the use of HDR colors in gamma space a little while ago, so it's possible that I had already confirmed this approach wouldn't work at that time... I'll investigate this again along with the method of making it optional.

[TLabAltoh]

After some investigation, it seems that in order to use HDR colors with gamma (to match HDR color output between gamma and linear), it is necessary to set m_color.gamma as the material property, rather than m_color.

[shino-a]

The biggest issue here is the inconsistency of whether or not a color property is an HDR color, such as with fillColor and outlineColor, which I believe causes inconvenience regardless of what PlayerSettings.colorSpace is set to.

Is there a history or reason for why HDR colors are mixed in this way?

In my opinion, HDR colors should not be the default. I believe that many users of this package expect CSS-like behavior, and using the same hexadecimal color codes yields different results with HDR colors in a linear workflow.

[AAAYaKo]

As I remember HDR colours were added to create effects like glow or shadows

[TLabAltoh]

As @AAAYaKo and @shino-a suggested, it does seem better to make the HDR enabling setting for outlines and shadows a per-instance option (disabled by default). I'll proceed in that direction.

Regarding the color fields, I'm currently investigating a way to dynamically switch between enabling and disabling HDR display on the inspector.

If I can't find a way to dynamically change the ColorUsage attribute from C#, we'll probably have to handle it by splitting the fields into two like this:

[SerializeField, ColorUsage(true, true)] protected Color m_outlineColor = Color.cyan;

[SerializeField] protected Color m_outlineColorNonHdr = Color.cyan;

[SerializeField] protected bool m_outlineEnableHdr = false;

public Color outlineColor
{
    set {
        // Change the target field depending on m_outlineEnableHdr
    };
    get {
        // Change the field to return depending on m_outlineEnableHdr
    };
}

For the above, on the SDFUIEditor.cs side, it seems we'll need to change which field is displayed in the inspector based on m_outlineEnableHdr.

The shader side may also require some changes ...

[AAAYaKo]

Maybe instead of using an attribute to set the hdr, we should try setting it in the colour field

Unity - Scripting API: EditorGUI.ColorField https://share.google/i8UkUuZrdMgUxQloZ
Unity - Scripting API: ColorField https://share.google/JPhdp3ncd09pjkqmx

[TLabAltoh]

I see, so it is possible to specify HDR settings on the CustomEditorGUI side. That would definitely be better.

Making HDR optional seems like it would be a simpler change than I thought. I'll give it a try.

[shino-a]

I was just trying it out too. I'll create a draft pull request. I'd like to hear your opinions.

[TLabAltoh]

Thank you @shino-a . I was able to confirm that the sources you provided in the draft are working on both gamma and linear.

---

Regarding whether to make HDR settings individual or global, ideally I would like to configure them individually for each component. However, I'm pleased that you added properties to SDFUISettings. Would it be acceptable to assign SDFSettings.Instance.useHDR to m_useHDR (newly created fields) within the SDFUI.Reset function?

---

Regarding color space conversion, I think the current implementation you're working on—setting Color.gamma to materials (converting at the component level)—is fine.

(Considering shader load, I think we'd need to add if statements and pow functions to the shader, but I'd prefer to avoid both as much as possible when considering GPU load.)

---

I'd like to merge the source code you submitted in the pull request to master, but what I'm most concerned about is resolving conflicts with the latest source.

What I absolutely want to keep from master at this point is the gamma support for the rainbow effect. I've added gamma correction processing in the hsv2rgb function in Runtime\Resources\SDFUtil.cginc to match the rendering results between gamma and linear.

This change also affects Common.hlsl (addition of _Gamma property), SDFUI.cs (addition of _Gamma to _materialRecord), and {Shape}-Properties.hlsl (addition of _Gamma property, moving SDFUtil.cginc to the line below {Shape}-Properties.hlsl), so resolving conflicts might become a tedious task...

Also, if possible, I'd appreciate it if you could change the if statement that currently checks Playerasettings.colorSpace on lines 1863-1880 in the latest master's SDFUI.cs to check SDFUISettings.Instance.useHDR or m_useHDR instead. I'd like to consolidate it into a single if statement.

---

I'm thinking of merging the draft source you submitted. Therefore, although it might be tedious work, would it be possible for you to resolve the conflicts with the latest master?