Explain why texture.source is not always required

[emackey]

Fixes #1226.

[lexaknyazev]

Should textures with nor source neither extensions be invalid?

[emackey]

Good question. Would there be some future way to supply a texture that didn't place an extension directly on the texture object, but still used a texture object? I don't... think so?

Current implementations mostly throw an exception if a source isn't supplied one way or another.

[lexaknyazev]

• It could be app-specific extras.
• An engine could use false color or other predefined value for missing textures.

[emackey]

Sure. So I don't think we can tighten the schema-level field requirements on this. Is my description here good enough then, or does it need to change to indicate that engines are free to use default colors or even reject models that don't properly specify a source? (Where "properly" in my mind is either specifying it with the source property, or marking a WebP or DDS type extension under "extensionsRequired").

The WebP extension for example specifically states that it must be placed in extensionsRequired in order for source to be left undefined.

[lexaknyazev]

Is my description here good enough...

At least, I'd change "must" -> "may". Otherwise, it sounds like textures without source or extensions are invalid by definition.

[emackey]

Would this make sense?

texture.source

The index of the image used by this texture. When undefined, it is expected that an extension or other mechanism will supply an alternate texture source.

[emackey]

@lexaknyazev Is this OK?

[lexaknyazev]

Should we suggest any behavior in case when nor source neither extensions are present?
If not, this looks good to me.

[emackey]

How about this:

The index of the image used by this texture. When undefined, it is expected that an extension or other mechanism will supply an alternate texture source, otherwise behavior is undefined.

[emackey]

Updated as we discussed.