Scene Description Format issues

[jackjt8]

• [x] SDF version has not been updated from Version 9 back from Chunky 1.4.4 despite multiple changes having been made to the SDF since then. Recommend incrementing to Version 10.
• [x] Sky Object mode (ie {"SIMULATED", "SOLID_COLOR", “GRADIENT”, “SKYMAP_PANORAMIC”, “SKYMAP_SPHERICAL”, “SKYBOX”, “BLACK”}) BLACK is redundant. We do not need it as SOLID_COLOR with rgb(0,0,0) works fine. It is one thing to have redundant options in the UI but we should not also write this to the SDF.
• [x] Sky Object color is not an RGB object like other color keys. It is instead an array of three numbers with no red, green, and blue keys. This is not consistent.
• [x] Gradient Object does not use a RGB object but instead has a rgb key and uses hex codes. This is not consistent.
• [x] cameraPresets - An array of Camera Preset Objects which have keys = Camera Object: name with values of Camera Object. Why not just an array of Camera Objects? We do not need to have keys set to the name from within the value. May also be worth moving camera into this new array as having Camera Objects in two places like this is a weird decision.

Or, as described much better with an example:

"Peregrine05 — Today at 15:58 What if we have cameras as an array of dictionaries (camera objects), and have a separate selectedCamera key that is just the name of the selected camera?

{
    "cameras": [
        {
            "name": "camera 1",
            ...
        },
        {
            "name": "camera 2",
            ...
        }
    ],
    "selectedCamera": "camera 1"
}

"

[leMaik]

• I'll bump the SDF version before releasing 2.5.0. We should also make sure to bump it whenever we introduce changes that won't work with older Chunky versions (Chunky is backward compatible, not forward compatible). We might want to show a warning in the UI if the scene file is too new and try loading it anyways as good as we can.
• Sky mode black can be deprecated and stored (and loaded) as RGB 0,0,0 instead.
• I like having hex codes for simple editing (compared to editing float rgb values). Why not allow both everywhere in the scene file?
• Agree that the cameraPresets objects is a mess. Sine the camera is not a preset but rather, well, the camera, I'd keep that as is. Having two camera objects isn't a weird decision imho. It's simply two different properties of a scene, similar to how we have colors at different places in the config file.

[jackjt8]

• I agree that we should probably allow both hex and float RGBs anywhere in the scene file. Maybe could add support for CMYK, HSV, and HSL as there might be some people who find them simple?

• I'm still a bit confused regarding the cameras.. but that's an issue for a discord discussion.

[leMaik]

Found another oddity: The beacon beam entity stores its color as an integer.

I'm currently improving the scene format such that anything that is called "color" can be an object with red, green and blue keys (range [0…1]) or a 3 or 6 digit hex string (with optional #).

[leMaik]

I updated the checkboxes above to reflect the changes in #1784, which is now finished. The serialization of colors can be toggled by setting the chunky.colorSerialization system property to hex (default is object).