GLTFLoader: primitive type .extras

Description of the problem

From #14315

Currently GLTFLoader just sets .extras property to Three.js object’s .userData.

if ( nodeDef.extras ) node.userData = nodeDef.extras;

But .extras type in glTF is any while .userData type in Three.js is object. If .extras have primitive type value, like integer or strings, .userData will have invalid type value in Three.js.

I’m thinking of .userData.glTF (or .userData.extras) instead of .userData to set .extras to.

if ( nodeDef.extras ) node.userData.glTF = nodeDef.extras;

Another option is to set like { value: *.extras } to .userData if .extras is non-object.

if ( nodeDef.extras ) {

    node.userData = ( typeof nodeDef.extras === 'object' )
        ? nodeDef.extras
        : { value: nodeDef.extras };

}

Any thoughts?

/cc @donmccurdy @wlinna

(BTW, we should replace if ( *.extras ) with if ( *.extras !== undefined ) because .extras can be 0, false, or empty strings ‘’.)

Three.js version

• Dev

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, …)

[donmccurdy]

Thus, I’d prefer extras to be simply assigned to userData field, and primitive types would be handled as a special case.

+1. While technically allowed, no tools are doing this. Better to establish clear best practice that it be an object, and perhaps even disallow primitive extras types in a future version of glTF. If extras is a primitive type, we could log a warning and ignore it, but until/unless it causes a real issue I’d vote to avoid adding specific code for the case at all.

[takahirox]

Yeah, I prefer .userData.glTF too but one concern. How we should export .userData.

If we import .extras as .userData.glTF and export .userData as .extras, we’ll get .userData.glTF.glTF.glTF... if we repeatedly import and export.