JSON refer other JSON? about gltf

[donmccurdy]

Closing this issue for now – we're definitely still open to considering glTF files that reference other external glTF files, but that idea isn't well-defined yet. If community members have strong use cases for this and some idea of how it should work, proposals are welcome.

[fabrobinet]

potentially, but can we consider after 1.0 ?

[RemiArnaud]

I'd rather look into having a single JSON that can reference glTFs. I think
that works better for a final format - the app loads (or does not if it
knows what it needs) the JSON file that references the rest of the data,
and then proceed to load what it wants from it.
Most web apps have a mapping file, that is loaded at the beginning. It
provides a translation between the generic name of the resource, and the
exact URL where to find it. This enable applications to update/move their
content at anytime, without breaking current users. So this is not uncommon.

On Fri, Mar 22, 2013 at 7:18 AM, Fabrice Robinet
[email protected]:

potentially, but can we consider after 1.0 ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-15298914
.

[fabrobinet]

I know it's appealing, and I like the idea.
This said, the precedent with COLLADA for the same feature hasn't been really supported.
I never saw (except Remi's produced) COLLADA with this.

As an aside, I believe in some case scenarios, this would be better handled by having Rest3D API do this for us (splitting scenes...).

So in short, I like the feature, but just like everything else here we want an implementation counter side to experiment.
I am not sure if the converter is the best place for this (it could handle COLLADA with referred files that this way, but again, that's a edge case), an an high level tool to produce such files (partiionning, or just merging scene, handling a library etc) could be better suited and keep the converter simple.

So I just want to practical, if someone sign-up to implement this feature with enough visibility so that it doesn't suffer the same fate than with COLLADA, then it's fine.

[pjcozzi]

@RemiArnaud's suggestion sounds application-specific to me. I'm not sure how this would be part of glTF. Perhaps an example would help me see.

As for my original proposal, I am OK with tabling it for post glTF 1.0.

[bhoske]

Can you suggest any work around for JSON refer another JSON...

[bhoske]

Hi fabrobinet,
Hope , you are doing well.
I am follower of GLTF viewer .. What is milestone for GLTF.
R u doing any work to progress / improve the viewer. Need some questionnaire to answer.

[fabrobinet]

@bhoske we hope to finalize a v1.0 for the specification in a few months but as mentioned above referring other JSON will probably not make it for v1.0. I have not been active on the viewer lately but it is still maintained. Thanks for your interest in the project.

[pjcozzi]

@mlimper let's use this issue to discuss your approach to this with SRC and how we could use it in glTF or an extension (it should probably be core spec though).

[mlimper]

Within SRC, there is a two-level addressing schema for meshes / mesh data and textures:

• A hash symbol is used to address a mesh or texture: http://foo.bar.myDataFile.src#myMesh
• A dot symbol is used to address a specific attribute of a mesh: http://foo.bar.myDataFile.src#myMesh.colors

(also see Figure 7 in the paper, for example: http://x3dom.org/src/files/Web3d2014_SRC.pdf)

This assumes that meshes and textures are first-class citizens of the SRC file, which share the same scope (and hence cannot have similar names). For the original idea of using SRC to externalize X3D Shape Data, this was sufficient - but this approach is probably not general enough for glTF, I suppose.

[pjcozzi]

Thanks @mlimper. I will need to implement this in Cesium before I am comfortable suggesting it for the core glTF spec. I'm not sure I can do that in time for the draft 1.0 spec, but we could propose it as an extension, and then put it in the 1.1 spec.

I agree that the SRC approach is not general enough, but I think it generalizes easy enough. Here's an example (assuming an external_glTF extension):

commonMaterials.gltf

{
    "materials": {
        "glass" : {
            // ...
        }
    }    
}

model.gltf

{
    "extensions": {
        "external_glTF" : {
            "commonMaterials" : "commonMaterials.gltf"
        }
    },
    "meshes" : {
        "a-geometry" : {
            "primitives" : [{
                "material" : "commonMaterials#glass"
            }]
        }
    }
}

Basically, any referenced property name with an # identifies an object in an external glTF file.

Here's a more complicated example with multiple external files creating the classic diamond of death.

commonShaders.gltf

{
    "shaders": {
        "commonShader": {
            // ...
        }
    }
}

commonMaterials.gltf

{
    "extensions": {
        "external_glTF" : {
            "commonShaders" : "commonShaders.gltf"
        }
    },
    // Reference "commonShaders" somewhere
    "materials": {
        "glass" : {
            // ...
        }
    }    
}

commonNodes.gltf

{
    "extensions": {
        "external_glTF" : {
            "commonShaders" : "commonShaders.gltf"
        }
    },
    // Reference "commonShaders" somewhere
    "nodes": {
        "arm": {
            // ...
        }
    }
}

model.gltf

{
    "extensions": {
        "external_glTF" : {
            "commonMaterials" : "commonMaterials.gltf",
            "commonNodes" : "commonNodes.gltf"
        }
    },
    "meshes" : {
        "a-geometry" : {
            "primitives" : [{
                "material" : "commonMaterials#glass"
            }]
        }
    },
    "nodes" : {
       "left-arm": {
            "children": [
                "commonNodes#arm"
            ]
        }
    }
}

Engines would have to be smart about caching to avoid duplicate resource creation. We could also impose restrictions - if we can justify them - like external glTF files can't reference more external glTF files, but this feel artificial.

It would also be nice to have an open-source tool that takes a set of glTF files and then optimizes them to reference common external glTF files, e.g., if all the models have the same material.

What do you think of the schema proposed above?

A dot symbol is used to address a specific attribute of a mesh: http://foo.bar.myDataFile.src#myMesh.colors

What is this used for?

[RemiArnaud]

Although available in COLLADA - an intermediate representation format - and rarely correctly implemented, I would not recommend generic external references in glTF - a presentation format.

The reason is that it becomes very hard to reference unique instances.
main.gltf could instance 2 forests from the same forest.gltf. forest.gltf instance the same tree several times.
you may end up with 4 trees for example, with 4 different paths to it:

forest1->tree1->tree
forest1->tree2->tree
forest2->tree1->tree
forest2->tree2->tree

the only way to differentiate between those 4 trees is to provide their full path.
If the user click on a tree, you have to return the full path to that tree to the application to know which tree it is.

What happen if you want to move the last of those trees, and only that tree?

you can't.
moving the tree node will move all the trees.
moving the tree1 node, will move two trees
moving the forest2 node, will move two different trees

In a run-time / presentation format, I'd recommend using a 'flat' scene, where instances get a new node.
There are several ways to do this, for example limiting external references to leaves objects (not container objects). So you could not instance a forest, you'd have to instance trees.

the collada2gltf tool could create such 'flat scenes' from COLLADA documents using external references.
PS : the openCOLLADA Maya exporter has been fixed to correctly export external references.

[pjcozzi]

@RemiArnaud I believe your point is a more general glTF discussion, so I created #401. Please chime in and let's converge on an approach.

As for external glTF references, I am open to reducing their scope, but let's decide on #401 first.

[mlimper]

A dot symbol is used to address a specific attribute of a mesh: http://foo.bar.myDataFile.src#myMesh.colors
What is this used for?

In our paper, this was mentioned as a way to perform data compositing, for example by overriding the original vertex colors of a mesh when using it again in some other place. But this is very advanced, and we don't have an implementation that supports this feature right now.

[pjcozzi]

A dot symbol is used to address a specific attribute of a mesh: http://foo.bar.myDataFile.src#myMesh.colors
What is this used for?

In our paper, this was mentioned as a way to perform data compositing, for example by overriding the original vertex colors of a mesh when using it again in some other place. But this is very advanced, and we don't have an implementation that supports this feature right now.

I suggest we save it for when have an implementation.

Do you have any other feedback on what I proposed here, e.g., restrictions to make the implementation simple, etc.?

[mlimper]

We have only implemented the hash delimiter, I am not aware of any implementation obstacles regarding that

[pjcozzi]

Requested in #837.

[coderofsalvation]

why not follow the standard of JSON references using $ref .
It basically acts as overlays, and allows decorating the glTF with dynamic data located elsewhere.

more on this how it could complement binary-only glTF: #1560 (comment)