'texture.source' property is not required, but no default value is specified?

[tomolt]

From the spec:

	Type	Description	Required
source	integer	The index of the image used by this texture.	No

I can't seem to find any information on how a complying GLTF2 loader should actually behave if texture.source is not defined.
Usually, the spec states a default value to be used instead, as in texture.sampler:

	Type	Description	Required
sampler	integer	The index of the sampler used by this texture. When undefined, a sampler with repeat wrapping and auto filtering should be used.	No

However, I can't find any information on a default value for texture.source, neither in the properties reference nor in the Texture Data section.

The only other options I might be missing are that texture.source is not needed when some
other properties are set (but I can't find anything on that either, and it would be kind of absurd to exist anyway) or that the texture is supposed to be filled with zeroes, much like a buffer without uri (or that's at least my understanding of how a buffer without uri behaves).

I believe the intended behavior to be simply using the first / only image in the GLTF file per default as the source, but I am not sure.

Can someone please clarify this?

Thank you in advance.

[zellski]

I am curious, too. The use case I've assumed is that there are times when you author a model intending to provide a texture source at run-time (perhaps a photo frame), and you want artists to be able to control and export everything except the final actual pixel array. But that's just a guess.

As far as I can see, THREE.GLTFLoader (just to grab an example I'm familiar with) simply NPEs if it's missing, so I'm going to suggest it's a bit of an edge case to leave it undefined.

[takahirox]

What first came into my head is framebuffer.
It doesn't need an input image.

BTW I think we Three.js should update GLTFLoader if this specification is correct...

[tomolt]

But why make framebuffers so implicit ?
Wouldn't it be much more in GLTF's spirit to explicitly define an array of framebuffers for the entire file
and then have the texture object either supply a 'image' property (instead of the current 'source' property) or a 'framebuffer' property pointing at the framebuffer you should use.
That way, it might be easier for loaders to bind their framebuffers to the textures.
Also, I'm sure the spec right now doesn't even mention framebuffers, so having them be an undocumented edge-case seems kind of wrong to me.

[takahirox]

I just mentioned what texture without image can be for. I'd like to know the original purpose of non-image-required texture in glTF spec and expected use case, too.

[javagl]

This is actually a duplicate of #1016 , but ... there's not much information, and some more details should probably be added here, there, or in the spec.

(EDIT: My guess that a "compliant" renderer should treat such a texture as having a certain color, likely (0, 0, 0, 1), or some other default that is reasonable for GL and other APIs)

[pjcozzi]

Bump @lexaknyazev?

[lexaknyazev]

@pjcozzi
I still don't have an ultimate answer for this case. It falls under "undefined behavior", imo.
We can either propose a recommended fallback (e.g. a particular color) or explicitly say that engines may fail on such assets (this could be a validation warning).

[pjcozzi]

No strong preference. Up to you IMO.

[lexaknyazev]

Could we check with existing engines what do they do with such models?
It'd be nice to have them from the asset generator.
/cc @bghgary

[bghgary]

Could we check with existing engines what do they do with such models?

Current glTF loader in BabylonJS will throw an error when texture.source is missing or invalid.

It'd be nice to have them from the asset generator.

Yes, eventually. The asset generator currently only handles positive cases. This would fall into a negative case.

[takahirox]

In Three.js, currently glTF loader throws an error if texture.source is missing. Just missing the spec that texture.source is NOT required tho. Even if we take account of that spec, probably we'll just ignore that texture definition because Three.js requires image for texture unless the default value is defined in glTF.

[Jakouf]

Are there any new information about that? In my opinion the source should be required, otherwise the texture object doesn't really make sense to me.

[emackey]

Babylon, Cesium, and ThreeJS all throw uncaught exceptions when reading a texture object that does not contain a source.

@bghgary @lexaknyazev Can we just change it to required?

[donmccurdy]

I think the original motivation had to do with supporting cubemaps in the future? See #1366

[emackey]

In #1458 (comment) @lexaknyazev points out that we can't make this required. The DDS and WebP extensions rely on this being optional.

[pjcozzi]

@emackey do you suggest that we close this? add an implementation note? something else?

[emackey]

How about this:

texture.source

The index of the image used by this texture. When undefined, an extension must supply an alternate texture source.