Add support for KHR_materials_emissive_strength.

[abwood]

KHR_materials_emissive_strength is a new extension that recently entered the "Release Candidate" status. This one is pretty simple in that the core specification limits the emissiveFactor to values in the range of [0.0 - 1.0]. This extension provides an additional multiplier to amplify emission beyond 1.0.

After discussion (below) this implementation defines a new flag, has_emissive_strength and an emissive_strength struct that embodies this float property. The original approach is quoted here to preserve the history of this PR conversation, but no longer applies ...

Rather than following the route of other extensions with a has_emissive_strength flag and an emissive_strength struct, I figured it would be easier on the implementers if cgltf took the liberty of factoring in the emissiveStrength into the emissiveFactor internally. My thought is that someday we could see this extension pulled into a future version of glTF, but rather than having two "dials" to control the emissionFactor, the spec editors would instead just relax the schema constraints and allow for emission values to go beyond 1.0.

For confirmation, I locally updated Filament with these changes. Here is an altered DamagedHelmet, with the addition of the KHR_materials_emissive_strength extension that defines a strength of 5.0.

And here is the original DamagedHelmet model (i.e., emissiveFactor=[1.0, 1.0, 1.0])

TODO

• [x] Update cgltf_write.h to write this extension if emissiveFactor is greater than 1.0.
• [x] Update Readme

/CC @emackey @prideout

[zeux]

This is definitely easier for loaders but I'm not sure what the processing tools like gltfpack are supposed to do with this. You can decompose the color with components >1 into color+strength but that results in a different output compared to the input. The same question would arise for applications that use fixed-point quantization for material parameters to conserve material structure size.

Also if we ever get the [rather scary] property animation extension it's going to make it impossible to animate strength individually with this approach.

[jkuhlmann]

Thanks for implementing this @abwood! It feels like a great shortcut to do it this way, but I also understand the concerns raised by @zeux. I think if we follow that thought, maybe it would be better to implement this like the other extensions? Ultimately, the change to existing renderers/engines to support it then would be pretty minimal.

[abwood]

Great points, especially when considering the notional property animation extension. I can change it back to the original implementation.

[jkuhlmann]

That would be great! 😃

[abwood]

I think this is good now. I updated cgltf_write and tested it out by loading Box.gltf, cranking up emissive_strength to 5, and then writing it file. I loaded the resulting model into Filament and confirmed the results are as expected. Also ran it through the validator built into the VSCode gltf plugin and the written model came back clean.

Behold!