@javagl for the models in https://github.com/javagl/gltfTutorialModels, do you prefer:

• That we just link to that repo from here, or
• That you open a PR to move all those models into this repo and then perhaps add an appendix to the tutorial with a list of the models and direct links to each?

It would be nice to include a model that uses sparse accessors. Do any good ones exist currently?

From KhronosGroup/glTF-Sample-Assets#55 it sounds like this is close in the Blender exporter.

We shouldn't provide samples that suggest it is ok to do bad things. This is a typical case where an infinite projection matrix would be a much better choice. The model already has enough aliasing artifacts as it is.

"cameras": {
"default-camera": {
"name": "default_3",
"perspective": {
"aspectRatio": 1,
"yfov": 0.2632462665746327,
"zfar": 1000000,
"znear": 0.0499999970197677
},
"type": "perspective"
}

Several models have the diffuse textures in an array:

"KHR_materials_common": {
    ...
    "values": {
        ...
        "diffuse": [
            0
        ],
        ...

From KhronosGroup/glTF#965, I assume that should be diffuseTexture: 0.

transparency and shininess are arrays, and should presumably be floats:

"shininess": [
    50.0
],
"transparency": [
    1.0
]

While testing the previous models and the new 2.0 to implement the specs diffs,
I've noticed some empty objects here and there, for instance cesiumMilkTruck as empty object as node 0
line 16.
"nodes": [
{},
{

and also as last entry in nodes.
It doesn't really affect my parsing, as the indices seems be sync.
Just wonder if this is a COLLADA2GLTF bug...

it is also used in scenes
"nodes": [
6,
1,
0
]

If there was simple model just for testing pbr like below, it would be great.

And it is very good for comparing 2 libraries supporting PBR.

Currently we have some glTF 2.0 models that have been graciously contributed that unfortunately we don't have source models for. This makes it hard to maintain this repo in general since these models have to be updated by hand when the schema changes, along with generation of the model variants. Adding these will also help me find and correct any issues with COLLADA2GLTF-2.0's PBR generation.

If you've contributed a glTF 2.0 model without a source model, I would really appreciate it (if possible) if you could open a PR contributing the source model as well, preferably in COLLADA format into the sourceModels directory.

The following don't have source models:

• AdvancedMaterial
• AnimatedCube
• AnimatedTriangle
• BoomBox
• Cameras
• Corset
• Cube
• Lantern
• MetalRoughSpheres
• NormalTangentTest
• SciFiHelmet
• SimpleMaterial
• SimpleMeshes
• SimpleOpacity
• SimpleSkin
• SimpleTexture
• Suzanne
• Triangle
• TriangleWithoutIndices
• TwoSidedPlane

Again, thank you all for everything you're doing to help push glTF 2.0 along.

@pjcozzi
@emackey
@javagl
@bghgary
@McNopper

Hello. Where and how I can get glTF 2.0 versions of sponza and chess models/scenes?

This sample seems not compatible with glTF 2.0.
As far as I see, this model schema is more like glTF 1.0 not 2.0.

This is several points I noticed that it is not matching with glTF 2.0.

• meshes should be mesh
• nodes should be array of numbers
• accessors should be array

I guess there should be more wrong points.

From #53

some glTF 1.0 models report a version 1.0.1, for example, the Avocado model, where as far as I know, a third number in the version string is not specified (as opposed to major and minor version).

via @peteroupc

As of ef49777.

• camera.type is absent;
• byteStride changes from 2.0 aren't implemented;
• integers in accessor.min/max are written with .0;
• length in GLB header is 8 bytes fewer than it must be;
• KHR_binary_glTF mustn't be written;
• IBM matrices mustn't be located in the same bufferView as vertex attributes;
• skin schema isn't updated.

@lasalvavida @pjcozzi

• Schema syntax bug: KhronosGroup/COLLADA2GLTF#43.

• Models without textures (2CylinderEngine, Box, BoxAnimated, BrainStem, Buggy, GearboxAssy, ReciprocatingSaw, RiggedFigure, RiggedSimple, WalkingLady) don't have SpecGloss material at all despite having glTF-pbrSpecularGlossiness directory.

• All SpecGloss models from COLLADA2GLTF use base64-encoded buffers and images.

Hi,

I see the gltf2 corset sample model has its occlusion/metallic/roughness textures packed into the one texture:

https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/Corset/glTF/Corset_occlusionRoughnessMetallic.png

But which texture channels go where? Is it R=occlusion, G=metallic, B=roughness? Is this hardcoded in or docced anywhere?

And will there be a cheat sheet for gltf2?

Bye!
Mark

The KHR_materials_common specification says that the diffuse property should be a VEC4 or string.
This BoxTextured sample, though, sets a diffuse property as an array with only one element.

Similar to the TextureSettingsTest, there should be a "texture coordinates test".

Of course, in some way, this will be covered by all other models that involve textures, but I think that it might be nice to have a dedicated, minimalistic test case for this distressingly common issue.

In order to avoid any further confusion:Can anybody confirm that

• putting this texture on a unit square

  

• using the texture coordinates matching the vertex positions, as shown in the image itself (!)

• rendering the quad with with the default camera

will result in the quad appearing exactly like the texture?

(Particularly: Is it right that the texture will not appear to be flipped ?)

GearboxAssy.glb has

    "light0Transform": {
      "node": "Sunlight__Front-Upper-Left-node",
      "semantic": "MODELVIEW",
      "type": 35676
    },

Is it legal to have a node and a semantic?

The glTF spec is not very specific:

parameter.node

The id of the node whose transform is used as the parameter's value. When this is defined, type must be 35676 (FLOAT_MAT4), therefore, when the semantic is "MODELINVERSETRANSPOSE", "MODELVIEWINVERSETRANSPOSE", or "VIEWPORT", the node property can't be defined.

Is this valid data?

https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/BoomBox/glTF/BoomBox.gltf#L93

I think this bufferView.target should be WebGLRenderingContext.ELEMENT_ARRAY_BUFFER not ARRAY_BUFFER.

Originally, the "Simple Test Models" (as they are listed in the first table of the current README ) had been created for the Tutorial. But then they have been added here (as requested in #16 ). The intention behind adding these models here was to have a set of models that people could use to develop their loaders incrementally: Starting with the simplest possible model, they could add support for one feature, and test this feature, using "the simplest possible model that contains exactly this feature".

So in some sense, the role of these "Simple" models is similar to that of the "Unit Test" models, that may be added here soon (as discussed offline). And there are some technical similarities, in the sense that neither the "Simple" models nor the "Unit Test" models have a "Source" model (as requested in #51 )

Are there any preferences about the structure and organization of these models? What is the intented structure and presentation of the "Unit Test" models? (Regarding the directory layout, naming, description etc...)

(A side note: Some of the "Unit Test" Models will probably be broken - intentionally! - in the sense that they have a structure that is invalid and should cause loaders to bail out. For example, for testing the Validator: There will probably be one model for each possible warning/error message, to make sure that the Validator actually detects the respective error. These "invalid" models should be clearly marked as such.)

@pjcozzi @lexaknyazev (+ please add other mentions as appropriate - I'm not sure who committed to creating the Unit Test Models...)

The sample file contains buffer data as embedded data. That should be resolved externally.

Some of the sample models for glTF 2.0 contain an empty animations array (such as Suzanne, TwoSidedPlane, and Cube). Since the current schema doesn't allow the animations property to appear as an empty array, the animations property should be removed from the affected models.

@Fabrice3D this looks like a nice test model that would be useful to the community if you want to contribute it to this repo?

https://sketchfab.com/models/7f47f3fc84174a8bbe0e375f6a21e6a5

I attempted to display the WalkingLady.gltf model of glTF 2.0 with the latest Three.js + glTF Loader.

Three.js r86 + glTF Loader result:

I could not judge whether it is a model (or converter) problem or a viewer problem.

Related: KhronosGroup/glTF#685

Hello, I'm sure this is an issue on my end rather then the model end, but I thought I'd post just in case someone can point me to a theory. On a 2.0 model loader I'm implementing, both the monster and the Cessium man are loading upside down for me. If I pretend their matrix is row major instead of column major they load in fine. I haven't seen this issue on any of the web based sample loaders I've been able to track down, So it's likely something I've doing incorrectly.
(I'm new to gitHub, so if there is a better place to post a question like this then to create an issue, please let me know)
Thanks!

I've seen this on other models as well but Box.glb sets up the uniforms "u_shininess" and "u_specular" while they are never actually used. When you lookup these uniforms in the fragment program you won't find them. Not the end of the world but it would be nice if the sample models were nice and clean.

It would also be nice if the JSON was laid out in expected parse order for super high performance parsing. The DOM-style JSON parser used for KhronosGroup/Vulkan-Samples is already faster than rapidjson but it is even faster if the JSON is laid out in the order it is parsed.

Some glTF 1.0 models report a version 1.0.1, for example, the Avocado model, where as far as I know--

• a third number in the version string is not specified (as opposed to major and minor version), and
• there has been no draft or ratified glTF specification with that version number.

Joints are just a bunch transforms now, that's good. Why not the same concept for meshes, getting easy instancing for free?

{
    "meshes": [
        {
            "transforms": [
                1,
                2
            ],
            "primitives": [
                {
                    "attributes": {
                        "NORMAL": 25,
                        "POSITION": 23,
                        "TEXCOORD_0": 27
                    },
                    "indices": 21,
                    "material": 3,
                    "mode": 4
                }
            ]
        }
    ]
}

The mesh property of nodes should then be removed. The same should be true for cameras, have an array of cameras per asset and let them reference transforms/nodes.

Hello. My renderer at now not support multiply buffers, only single (but support accessors). How I can get Boom Box model with unified buffer (unified bufferView)?
Also, only indices support separate buffers.

Hi,

I am currently working on a plugin that converts from glTF to OSG.
All the current glTF samples are working as expected, but need to go further and ensure that the plugin is able to correctly handle more complexe cases.
Would it be possible to have more complexe samples to rely on when developping around glTF ?

One case I am thinking about could be:
Having a single bone hierarchy and several nodes (different transforms) deformed by either the full hierarchy or a subset of bones inside this hierarchy.

I tried to make such sample using 3dsMax, exporting in Collada and then converting to glTF using COLLADA2GLTF, but I don't know about how it is handled and if I can rely on it.
For example, all the skeletons property are empty arrays (and fromt the glTF spec, these arrays should contain one or more nodes, right?).
Moreover, animations are incomplete in the output, I only have times, no keyframe values, but the collada seems valid since reimporting it inside 3dsMax gives back the expected animation.
(I am aware that 3dsMax may export data in a format that is not fully supported by other readers, so it's not clear)

Anyway, here is my sample with both collada and gltf version:
fries.zip

Is there any reliable sample somewhere that I could use ? Would it be possible to have one in this repository ?

Side question (unrelated): if several skins refers to a bone, should we expect the invBindMatrices to has the same value through the skins ? This is still not clear for me.

Sorry in advance if i missed something and thanks for your time!

According to the spec 2.0 here https://github.com/KhronosGroup/glTF/blob/2.0/specification/2.0/schema/glTF.schema.json, all objects under the root object should be an array, but I found only 3 sample models(BoomBox, Corset, Lantern) compliant to this spec.

Will the rest models update to the spec 2.0 or the spec 2.0 is still a draft?

The byteStride property has moved from accessor to bufferView (see KhronosGroup/glTF#827, KhronosGroup/glTF#605),
but as far as I see all samples that specify byteStride explicity still have it on accessor.

As of 2.0, glTF spec has explicit requirement about JSON-stored accessor.min/max floating-point values:

When componentType is 5126 (FLOAT) each array value must be stored as double-precision JSON number with numerical value which is equal to buffer-stored single-precision value to avoid extra runtime conversions.

Currently, most models don't follow this.

collada2gltf (or just rapidjson) uses a bit different conversion process than JS:

/2CylinderEngine/glTF/2CylinderEngine.gltf#/accessors/2/min

Single-precision bytes (as in buffer): [0x38, 0xE5, 0x13, 0xC2]

ECMA Script: -36.973846435546875
Double-precision bytes: [0x00, 0x00, 0x00, 0x00, 0xA7, 0x7C, 0x42, 0xC0]

JSON-stored: -36.97384643554688
Double-precision bytes: [0x01, 0x00, 0x00, 0x00, 0xA7, 0x7C, 0x42, 0xC0]

Unity Exporter truncates numbers so they are equal in single-precision only

/Lantern/glTF/Lantern.gltf#/accessors/0/min

Single-precision bytes (as in buffer): [0xE0, 0xE8, 0x2F, 0x3C]

ECMA Script: 0.010736674070358276
Double-precision bytes: [0x00, 0x00, 0x00, 0x00, 0x1C, 0xFD, 0x85, 0x3F]

JSON-stored: 0.0107366741
Double-precision bytes: [0x3A, 0xBB, 0x04, 0x01, 0x1C, 0xFD, 0x85, 0x3F]

CC @pjcozzi @lasalvavida @bghgary @UX3D-nopper

It would be awesome to be able to click on a .glb or .gltf file in GitHub and then view it like STL.

Is it possible to do this as a GitHub plugin? Or would GitHub have to implement this?

It would be even more amazing to be able to switch different engines for testing just like the VSCode plugin, https://github.com/AnalyticalGraphicsInc/gltf-vscode

Could be great to have this as the preview for CI, #26.

Contributions welcome, I only wish I had the time to do this myself. 😜

It would be super cool to setup CI that

• Runs @lexaknyazev's glTF Validator on new/updated models in a PR
• Use popular WebGL engines to preview them like @cx20's gltf-test. This could be great to find issues in the models and engines.
• Generate website to browse samples, #77

Contributions here are very welcome!

Go through and create all embedded/separate variants of each sample model, optimize them with glTF-pipeline to make them as small as possible, and make sure they render and pass validation.

• 2CylinderEngine (#4)
• Box (#6)
• BoxAnimated (#7)
• BoxSemantics
• BoxTextured
• BoxWithoutIndices
• BrainStem
• Buggy
• CesiumMan
• CesiumMilkTruck
• Duck
• GearboxAssy
• Monster
• ReciprocatingSaw
• RiggedFigure
• RiggedSimple
• VC

See KhronosGroup/glTF#770.

For example, RiggedSimple has two animations. The first one has linear interpolations that animate all the transforms to the same values for the entire timeline. The second one has a real curve for rotation, but translation and scale also have the same values for the entire timeline.

It would be good to update the models to at least remove the no-op animations from the list.

The uniforms "u_ambient", "u_jointMat" and "u_specular" are setup but never used.

The model doesn't list "KHR_binary_glTF"

"extensionsUsed": [ ],

@emackey
Could you regenerate MetalRoughSpheres and NormalTangentTest with the latest collada2gltf version?

So when someone first visits the repo, they see the README.md without having to scroll down.

I'm thinking about using this repo as a git submodule in other projects that could use sample models, specifically glTF-WebGL-PBR, and possibly @cx20's gltf-test if he's willing.

To make the models more discoverable, in an automated fashion, it might be nice to have a JSON file included with this repo that lists each of the available samples, along with its name, description, screenshot URL, and available variants (embedded, binary, pbrSpecGloss, etc).

I'm imagining a NodeJS script or similar that would scan the 1.0 and 2.0 folders and compile a list of this information, and save it into some generic JSON structure. The gltf-test project already has the beginnings of such a structure hard-coded into it, but I'm picturing one that's a little more fleshed out. The file would likely be called model-index.json in the root folder and could be rebuilt from the command line whenever the sample models change. Such a file could be used or ignored at will by any software looking to load sample models.

Thoughts?

Hi,

I'm trying to find a sample with some normal mapping.

BarramundiFish has a normal map in it's 'images' chunk, but it doesn't seem to be referenced by anything.

Is there another model I can try?

Bye!
Mark

I was trying to figure out the license, but the link is broken: https://github.com/KhronosGroup/glTF-Sample-Models/blame/master/2.0/Duck/README.md#L12

This may be a very specific issue, and awfully hard to debug (that's why I'm writing this at 3:30am).

• The VC model contains many texture images, but only one of them is a PNG that contains transparency (https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/VC/glTF/prop128.png - the propeller of a helicopter)
• The texture with this image is only used in a material that is called __-_Default_2 ( https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/VC/glTF/VC.gltf#L11182 ) (yes, odd names....)
• The technique of this material is called technique1. It contains states, but these states do not involve GL_BLEND. But, to my (limited) understanding of OpenGL, when using a transparent texture, then GL_BLEND is required - and some additional technique.states.functions settings.

There are other techniques that involve transparency (for example, for the windows of the aircrafts), and they contain the proper technique states with GL_BLEND, as well as the technique.states.functions. I also have an old copy of the VC model (from ~6 months ago, where it was still called vc, with lowercase names), and there, the technique that is used for this transparent texture image seems to be right.

I tried to go though the Git history, but it's hard to track this down, because there are some renamings and cases where all models have been re-generated. Someone with advanced Git-foo might have more luck here.

Possibly unrelated, but the context in which I noticed this:

I tried to get rid of the infamous "boxes" that have been reported in KhronosGroup/glTF#576 and that also still appeared in JglTF. Comparing the renderers from https://github.com/cx20/gltf-test (nice project, btw) showed that the boxes

• do not appear in Three.js, Babylon.js and Cesium.js
• do appear in xeogl and GLBoost (and in JglTF - I'm working on that)

It has something to do with transparency, blending, rendering order etc. I noticed that when changing the blend functions from 1 and 771 (GL_ONE and GL_ONE_MINUS_SRC_ALPHA) in the technique state functions...

                "blendFuncSeparate": [
                    1,
                    771,
                    1,
                    771
                ],

...to 770 (GL_SRC_ALPHA) and 771

                "blendFuncSeparate": [
                    770,
                    771,
                    770,
                    771
                ],

it seems to render properly. But this was just found out with trial-and-error. I thought that KhronosGroup/glTF#747 (and the linked pulls/issues) might be related, but the order of the parameters seems right. I read more about all this in the OpenGL docs, started looking at the .DAE input files and reading the COLLADA spec, and the section about "Determining Transparency (Opacity)" contains lots of information about the different cases, talking about A_ONE and A_ZERO opacity modes, where "transparency" sometimes means "transparency", and sometimes "transparency" means "opacity" (!!!). (Frankly: This is a mess...)

However, I'll probably try to create another "minimal example", consisting of two triangles, one opaque and one semi-transparent (and maybe something with a semi-transparent PNG). These examples could allow to quickly and easily check whether a renderer shows the intended behavior in regards to transparency handling. Right now, it's hard to say what the "intended behavior" is.

(BTW: Note that, in the renderer comparison mentioned above, Cesium.js also renders the heli propeller texture as a completely opaque one, although it should be transparent - but this is likely only caused by the error in the input file)

Edit:

Since I'm not sure whether this is an issue of glTF and the spec, the sample models (where VC unfortunately is the only one that uses technique.states.functions!), or the renderer implementation, I opened another issue detailing all this (and including a "simple test case") at javagl/JglTF#6

And another edit:

For a test, I uploaded the model from javagl/JglTF#6 to http://cesiumjs.org/convertmodel.html and it looks nice and correct. However, it also looks nice and correct when using

"blendFuncSeparate": [ 0, 0, 0, 0],

so I guess that this property is not taken into account at all. And at the moment, I think if it was taken into account, the settings

"blendFuncSeparate": [ 1, 771, 1, 771],

(that are currently used in the VC model) would cause the output to look like the first screenshot in the JglTF issue. But I might be utterly and embarassingly wrong here.

And a last edit - sorry about that:

The nice, correct rendering in Cesium is achieved by the order independent transparency. When disabling OIT, it looks like expected: With FUNC_ADD, and a completely transparent blue source (multiplied with GL_ONE (!)), and an opaque red destination (multiplied with GL_ONE_MINUS_SRC_ALPHA), the result is magenta. I don't think that this is the "right" way of blending, and think that the source factor should be GL_SRC_ALPHA (because that's what the alpha is for), but I think it is reasonable to say that, without OIT, there is no "right" way of blending anyhow...

Hi,

First of all, thanks a lot for these samples, they are very helpful.
When testing the BoomBox sample, I had an issue and saw that the mesh data in the node seems not compliant with the spec:

The samples has "mesh": 0, but the spec seems to expect this "meshes": [0],

Did I miss something or is it an actual small issue?

Thanks!

For example: https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/Triangle/glTF/Triangle.gltf#L65

CC @javagl

The following glTF 2.0 models don't have readme.md:

• 2CylinderEngine
• Avocado
• BarramundiFish
• Box
• BoxAnimated
• BoxTextured
• BrainStem
• Buggy
• CesiumMan
• CesiumMilkTruck
• Duck
• GearboxAssy
• Monster
• ReciprocatingSaw
• RiggedFigure
• RiggedSimple
• SmilingFace
• VC
• WalkingLady

I think that I forgot to copy from 1.0 when I regenerated.

The BoxSemantics model is supposed to "include extra uniforms to test all uniform semantics". But it seems to be the same as BoxTextured: The .gltf file is the same (except for the different buffer file name), and the shaders are also the same in both cases.

(Probably, something was lost there when a manual editing was overwritten during an automatic conversion. I tried to dig into the history, but did not spot the culprit yet...)

The sample glTF water bottle is featured in the last set of slides of the glTF launch presentation, and is present in the PBR reference shader repo and Microsoft's test BabylonJS repo. Here's a live demo.

That water bottle is missing from this sample model repo. Can it be added?

/cc @sbtron @bghgary