Remove the max 1.0 restriction on emissiveFactor

[emackey]

Fixes #1083

I came across a model using 1.5 for the emissiveFactor, seems to work fine in the JS engines I normally test (Cesium, Babylon, ThreeJS).

Note however, Windows 10's apps (I tested Paint 3D, Mixed Reality Viewer) are very strict about this value, and will reject models that contain >1.0 emissiveFactor. Is it OK for us to remove a restriction from the spec like this?

(The model I tested with was "blackvan" from AnalyticalGraphicsInc/gltf-vscode#80).

/cc @bghgary @sbtron

[pjcozzi]

Does the .md file also need to be updated?

[emackey]

@pjcozzi No, the min/max values are not listed in the readme.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materialemissivefactor

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

[emackey]

Although it looks like alphaCutoff has one, maybe this is already out of sync?

EDIT: Looks like that's due to wetzel handling min/max numbers, but not min/max for elements of an array.

[pjcozzi]

@emackey do you want to regenerate that part of the .md or update by hand?

[emackey]

It would need a wetzel feature addition (min/max for array values). I did some wetzel cleanup this morning but I don't think I'll have a chance to get to this one.

[javagl]

"Off-topic": The task to familiarize myself with wetzel (in order to fix #1013 ) has been pending for far too long now (only justified by "not having highest priority"), but maybe I can have a look at this issue as well when I get the chance. I'll add it to the TODO list...

[bghgary]

@emackey

Is it OK for us to remove a restriction from the spec like this?

I don't think this is okay. We can't change the schema like this and still meet versioning requirements. For example, older versions of native apps that use the old schema to validate will fail to load these new assets.

The ways I can see this working is if we add another factor value that either replaces the old value if recognized or multiplies against it. The old emissiveFactor must continue to be populated with a reasonable fallback value for older clients.

[zellski]

I agree changing the schema is dangerous. As @bghgary says, it's important that assets that were previously invalid aren't retroactively declared spec-compliant. A validating loader that could claim to handle all compliant content yesterday should not find themselves partial implementations today — not without a new schema revision.

[emackey]

Closed this. We should maybe clarify #1083 (comment) to make it clear this is not as simple as removing the 1.0 restriction.