Support passing colors everywhere as sRGB

[rdb]

One of the first things that users will notice when switching to a gamma-correct pipeline is that all their light, material, and vertex colors will look different. While we provide the facility to automatically linearize their sRGB-encoded textures (via the Texture.F_srgb format setting), we just treat any directly-specified colors as linear values, with no conversion.

In principle, treating 0..1 colors as linear values seems to be the correct behavior, since this is the common convention, and people may get tripped up if they end up with different values in their shaders/framebuffers. By convention, colors that are specified in the 0..255 range—such as HTML colors like #ff0000—are on the other hand typically treated as sRGB-encoded colors, since web content is intended for direct unaltered display on a monitor.

Panda works with 0..1 colors pretty much everywhere it accepts colors, because it just directly passes them on to the shader. A pragmatic solution that would retain maximum compatibility with existing assets might be to treat these as non-linear, requiring linearization upon load or in the shader. That said, while that would make life easier for people converting existing assets, it'd be very strange behavior from any other perspective, not to mention annoy people who've already made the switch to gamma-correctness. I am therefore inclined to keep considering 0..1 colors as linear, and consider another solution for asset conversion.

A further issue with Panda accepting linear 0..1 colors everywhere is that once people adjust to gamma-corrected life, they will also encounter more difficulty entering their favorite colors (probably created in a color picker) into their Panda code, since they can't just divide by 255.

One thing that I think will help with all this will be to give people a more convenient way to directly specify sRGB colors, which most people will be more familiar with (especially those with some web background). I would therefore suggest that we do the following:

• Turn LColor into a class (currently it's a typedef to LVecBase4), with appropriate accessors (eg. rgba properties) and utility functions.
• Create a new convenience function: LColor.from_srgb(255, 255, 255, 255) which accepts colors in the 0-255 range and linearizes them.
• Accept HTML colors in .egg files and config variables, so that you can set (for example) background-color #ffffff and <Polygon> { <RGBA> { #aa00ee } }.
• Accept HTML-style colors in code, directly as a parsed string, like node.set_color("#ff0000")"? I'd be happy to hear how people feel about parsing strings in this manner.

If we were to add a global switch to enable/disable linearization across the board, it could apply to the LColor utilities as well. It would therewith become possible to author an .egg file that would work both in a gamma-correct pipeline as well as in a non-gamma-correct pipeline, by specifying vertex colors using the HTML syntax.

Feedback would be very welcome.

[Yonnji]

Accept HTML colors in .egg files and config variables, so that you can set (for example) background-color #ffffff and { { #aa00ee } }.

Accept HTML-style colors in code, directly as a parsed string, like node.set_color("#ff0000")"? I'd be happy to hear how people feel about parsing strings in this manner.

Maybe something like:

node.set_color(LColor.from_srgba(255, 255, 255, 255))
node.set_color(LColor.from_html('#ffffffff'))

It's nice to have HTML color notation. It's more readable than tuple of numbers. It's faster to copy-paste HTML color value from/to image editors, than copying each number.
Finally I could remove my own Color class with the same features. xD