Thoughts on tightening up the spec #563

lexaknyazev · 2016-04-14T11:53:53Z

Base spec

Added from comments below

"Spec has a fixed list of valid attribute semantics. So how can we have custom attributes?", Thoughts on tightening up the spec #563 (comment)
- Updated spec, 17d3145
"There is no way to specify texture's width and height. This is needed for using raw binary texture data (not web-compressed formats).", Thoughts on tightening up the spec #563 (comment), Thoughts on tightening up the spec #563 (comment)
- Moved to Improving texture support for 1.0.1+ #620
Update maximumAnisotropy example, Thoughts on tightening up the spec #563 (comment)
- Updated example, Clarify extension example #613
Update aspectRatio default, Thoughts on tightening up the spec #563 (comment)
- Updated spec, aa152d8

KHR_binary_glTF

There is no requirement on sceneSize to be > 0.
- Updated extension, Clarify that sceneLength in KHR_binary_glTF must be greater than zero #612

KHR_materials_common

Default value for falloffAngle is PI/2 in spec but PI in light.spot.schema.json.
- Updated extension, Made default falloffAngle in KHR_materials_common consistent #611

WEB3D_quantized_attributes

~~1. Should decodedMax and decodedMin array lengths be aligned with accessor's type?~~
~~2. Can we enforce decodeMatrix length to be just one of [4, 9 16] instead of [1-16]?~~

Moved to #610

Original comment:

Base spec

There is no integers in JS, but other languages can have them. Spec is silent on implicit type casts of integers provided for values declared as FLOAT or FLOAT_VEC*. I believe that a little permissive comment about that would be enough.
MODELVIEWINVERSETRANSPOSE and MODELINVERSETRANSPOSE technique parameter semantics are declared as FLOAT_MAT3. At the same time presence of node field requires parameter to be FLOAT_MAT4. Spec is silent on this ambiguity. (see boxSemantics/glTF/boxSemantics.gltf)
Is it OK to have technique parameters that are mentioned neither in technique.uniforms nor in technique.attributes?
Can technique parameter be referenced in technique.attributes and have a value property at the same time?
~~Can technique parameter with FLOAT (or other scalar) type and "count": 3 be linked with FLOAT_VEC3 accessor?~~ More details in the comment below.
Are {POSITION|NORMAL|...}_%d semantics valid? Provided samples use only TEXTURE_%d.
There is no explicit requirement on the mesh.primitive.indices accessor to not to be FLOAT and to reference bufferView with ELEMENT_ARRAY_BUFFER target.
Default material example (Appendix A) has an extra a_texcoord_0 attribute.
Also I think that spec could be more verbose on required semantics for mesh to be rendered with default material. Without NORMAL runtime can try to calculate them on-the-fly, but without POSITION there's nothing to render at all.
Do we need 2D versions of default material shaders for pure 2D content? Or in that case users must provide shader code themselves?
Spec refers to EXT_binary_glTF instead of KHR_binary_glTF.
Spec lacks examples of using WebGL extensions, i.e., how to declare usage of OES_element_index_uint?
millennium_falcon.gltf from fr24-3d-models has accessors with "componentType": 5125 (UNSIGNED_INT) which isn't a valid value without extension.

KHR_binary_glTF

There is no requirement on sceneSize to be > 0.

KHR_materials_common

Default value for falloffAngle is PI/2 in spec but PI in light.spot.schema.json.

WEB3D_quantized_attributes

Should decodedMax and decodedMin array lengths be aligned with accessor's type?
Can we enforce decodeMatrix length to be just one of [4, 9 16] instead of [1-16]?

The text was updated successfully, but these errors were encountered:

pjcozzi · 2016-04-14T16:12:20Z

Thanks @lexaknyazev! This is great feedback. I created a 1.0.1 label and tagged this. I'll do some spec updates for the obvious ones and get back to you with questions on any others. I have a few things on my plate right now so please give me some time.

lexaknyazev · 2016-04-17T10:21:49Z

Let's say we have an accessor with "type": "VEC3" and "componentType": 5126 //FLOAT.
Are both kinds of technique parameters (see below) allowed to reference it?

 "technique0": {
      "attributes": {
        "a_1": "param1",
        "a_2": "param2"
      },
      "parameters": {
        "param1": {
          "type": 35665 // FLOAT_VEC3
        },
       "param2": {
          "count": 3,
          "type": 5126 // FLOAT
        },
      }
    }

lexaknyazev · 2016-04-17T10:56:24Z

Spec has a fixed list of valid attribute semantics. So how can we have custom attributes?
There was a comment about that but spec doesn't mention anything like that.

pjcozzi · 2016-04-17T13:00:11Z

Let's say we have an accessor with "type": "VEC3" and "componentType": 5126 //FLOAT.
Are both kinds of technique parameters (see below) allowed to reference it?

I don't think the spec defines this yet (or at least not well), but perhaps only param1 is valid. Do you have a use case for allowing param2?

Spec has a fixed list of valid attribute semantics. So how can we have custom attributes?

Semantics are optional: https://github.com/KhronosGroup/glTF/tree/master/specification#techniqueparameters-1

So a custom attribute would need to rely on a well-known attribute name - not semantic - to conform to the spec as it is written now. I think the question should be: can we have custom semantics, right? I think the answer should be yes, but we need to think about how to do it in a forward-compatible way, and how important that would be in practice (e.g., if an asset uses a custom semantic and then a later version of glTF defines that semantic, but it is different than the custom one's meaning; given that the future glTF version could have other breaking changes, it might be OK).

lexaknyazev · 2016-04-17T13:19:31Z

Please correct me if I'm wrong, we have:
mesh.primitive.attributes: {semantic: accessor_id, ...}
technique.attributes: {attributeName: parameterName, ...}
technique.parameters: {parameterName: {"semantic": semantic}, ...}
If attribute technique parameter doesn't have a semantic how can it be linked to an accessor?

lexaknyazev · 2016-04-21T13:27:38Z

There is no way to specify texture's width and height. This is needed for using raw binary texture data (not web-compressed formats).

lexaknyazev · 2016-04-22T12:08:05Z

I think the question should be: can we have custom semantics, right? I think the answer should be yes, but we need to think about how to do it in a forward-compatible way

Imho, the simpliest way to achieve forward-compatibility is to require all custom semantics to have some prefix (such as _) so they never collide with spec-defined names.

lexaknyazev · 2016-04-22T13:05:02Z

Looking at the extensions.json example I think we need to have some standardized way to define external extensions schemes. I see at least three possible approaches here:

Explicitly define extension-specific schemes for all possible extensions like

{
    "$schema" : "http://json-schema.org/draft-03/schema",
    "title" : "EXT_texture_filter_anisotropic",
    "type" : "object",
    "properties" : {
        "maximumAnisotropy" : {
            "type" : "integer",
            "default" : "0"
        }
    },
    "additionalProperties" : false
}

Do not define any additional schemes and just use appropriate GL names (TEXTURE_MAX_ANISOTROPY_EXT in this case) instead of js-like camelCase.

{
    "extensionsUsed" : ["EXT_texture_filter_anisotropic"],
    "samplers" : {
        "sampler_id": {
            "magFilter": 9729,
            "minFilter": 9987,
            "name": "user-defined sampler name",
            "wrapS": 10497,
            "wrapT": 10497,
            "extensions" : {
                "EXT_texture_filter_anisotropic" : {
                    "TEXTURE_MAX_ANISOTROPY_EXT" : 8
                }
            }
        }
    }
}

Do not use text-based properties and reference parameters as corresponding GL consts.

{
    "extensionsUsed" : ["EXT_texture_filter_anisotropic"],
    "samplers" : {
        "sampler_id": {
            "magFilter": 9729,
            "minFilter": 9987,
            "name": "user-defined sampler name",
            "wrapS": 10497,
            "wrapT": 10497,
            "extensions" : {
                "EXT_texture_filter_anisotropic" : {
                    "parameters": [
                        {
                            "pname": 0x84FE, //TEXTURE_MAX_ANISOTROPY_EXT
                            "value": 8
                        }
                    ]
                }
            }
        }
    }
}

And for extensions like OES_element_index_uint (with no additional properties or functions) maybe it should be sufficient just mentioning them in extensionsUsed property of the root object.

lexaknyazev · 2016-04-25T10:07:54Z

There is no way to specify texture's width and height. This is needed for using raw binary texture data (not web-compressed formats).

After more digging, I propose to add optional width, height and mimeType fields to image and remove them from KHR_binary_glTF\image. This will serve two purposes:

We'll be able to use uncompressed textures both from external files (with explicit width, height and "mimeType": "application/octet-stream") and from embedded data: URI. In the latter case, we should omit mimeType field and use URI: data:application/octet-stream;base64,....
KHR_binary_glTF\image will contain only bufferView just like KHR_binary_glTF\shader.

pjcozzi · 2016-04-25T18:22:44Z

Please correct me if I'm wrong, we have:
mesh.primitive.attributes: {semantic: accessor_id, ...}
technique.attributes: {attributeName: parameterName, ...}
technique.parameters: {parameterName: {"semantic": semantic}, ...}
If attribute technique parameter doesn't have a semantic how can it be linked to an accessor?

Looking at this again, I agree there is a disconnect here that we need to address in the spec. Will need to brainstorm if it is as simple as requiring the semantic.

I think the question should be: can we have custom semantics, right? I think the answer should be yes, but we need to think about how to do it in a forward-compatible way
Imho, the simpliest way to achieve forward-compatibility is to require all custom semantics to have some prefix (such as _) so they never collide with spec-defined names.

That could work.

Looking at the extensions.json example I think we need to have some standardized way to define external extensions schemes. I see at least three possible approaches here:

Each extension defines the JSON schema for the extra JSON properties, e.g., see https://github.com/KhronosGroup/glTF/blob/master/extensions/Vendor/CESIUM_RTC/CESIUM_RTC.schema.json from https://github.com/KhronosGroup/glTF/blob/master/extensions/Vendor/CESIUM_RTC/README.md

What else are you looking for here?

And for extensions like OES_element_index_uint (with no additional properties or functions) maybe it should be sufficient just mentioning them in extensionsUsed property of the root object.

This would be a bit of a magic value; I still think we need the extension explicitly defined even if it is quite short and simple.

There is no way to specify texture's width and height. This is needed for using raw binary texture data (not web-compressed formats).
After more digging, I propose to add optional width, height and mimeType fields to image and remove them from KHR_binary_glTF\image. This will serve two purposes:

We'll be able to use uncompressed textures both from external files (with explicit width, height and "mimeType": "application/octet-stream") and from embedded data: URI. In the latter case, we should omit mimeType field and use URI: data:application/octet-stream;base64,....

KHR_binary_glTF\image will contain only bufferView just like KHR_binary_glTF\shader.

This could work well. We should also consider it in the context of texture compression so we don't end of changing it again for that (additions would be fine, of course).

lexaknyazev · 2016-04-25T18:52:20Z

Each extension defines the JSON schema for the extra JSON properties, e.g., see https://github.com/KhronosGroup/glTF/blob/master/extensions/Vendor/CESIUM_RTC/CESIUM_RTC.schema.json from https://github.com/KhronosGroup/glTF/blob/master/extensions/Vendor/CESIUM_RTC/README.md
What else are you looking for here?

Some extensions (like OES_texture_float or OES_standard_derivatives) are already well-defined up to 3 times (OpenGL, OpenGL ES, WebGL). They don't have anything glTF-specific.

Do we really need glTF schemes for them? The lack of some sort of "fast lane" could slow down development of glTF implementations.

pjcozzi · 2016-05-11T15:35:38Z

Some extensions (like OES_texture_float or OES_standard_derivatives) are already well-defined up to 3 times (OpenGL, OpenGL ES, WebGL). They don't have anything glTF-specific.

Do we really need glTF schemes for them?

Sorry for the slow response; I was at a conference all last week.

We do need an extension (.md file) for them, but it can be very small and just reference, for example, the GL extension. In some cases, the extension will not require any new schema, in other cases, it may just be new allowed enums, and in other cases, it may be new properties/objects.

lexaknyazev · 2016-05-11T15:59:59Z

We do need an extension (.md file) for them

Of course.

it may be new properties/objects

My point is that we need conventions for translation GL names into new properties, e.g., how TEXTURE_MAX_ANISOTROPY_EXT become maximumAnisotropy?

pjcozzi · 2016-05-11T16:12:56Z

My point is that we need conventions for translation GL names into new properties, e.g., how TEXTURE_MAX_ANISOTROPY_EXT become maximumAnisotropy?

Ah, yes, I agree throughout glTF, not just extensions. maximumAnisotropy is just in an example, not in an actual extension, but it should copy the GL name, e.g., maxAnisotropy or textureMaxAnisotropy.

lexaknyazev · 2016-05-12T15:17:43Z

Does [camera.perspective.]aspectRatio: 0 mean the same as undefined aspectRatio?

pjcozzi · 2016-05-18T12:21:53Z

Does [camera.perspective.]aspectRatio: 0 mean the same as undefined aspectRatio?

The spec is not explicit about this. Perhaps the 1.0.1 spec should change this from >= 0 to> 0?

lexaknyazev · 2016-05-18T12:25:06Z

Perhaps the 1.0.1 spec should change this from >= 0 to > 0?

Makes sense.

pjcozzi · 2016-06-01T20:34:08Z

There is no integers in JS, but other languages can have them. Spec is silent on implicit type casts of integers provided for values declared as FLOAT or FLOAT_VEC*. I believe that a little permissive comment about that would be enough.

@lexaknyazev do you have a specific example for this? JSON schema actually allows us to define fields as integers, e.g., accessor. byteOffset.

lexaknyazev · 2016-06-01T20:55:20Z

shininess is defined as FLOAT
https://github.com/KhronosGroup/glTF/blob/master/sampleModels/Box/glTF/Box.gltf#L226
value is integer
https://github.com/KhronosGroup/glTF/blob/master/sampleModels/Box/glTF/Box.gltf#L90

pjcozzi · 2016-06-01T20:56:35Z

MODELVIEWINVERSETRANSPOSE and MODELINVERSETRANSPOSE technique parameter semantics are declared as FLOAT_MAT3. At the same time presence of node field requires parameter to be FLOAT_MAT4. Spec is silent on this ambiguity. (see boxSemantics/glTF/boxSemantics.gltf)

@lexaknyazev currently, this implies that a parameter with MODELVIEWINVERSETRANSPOSE or MODELINVERSETRANSPOSE semantic can't have a node property so it, therefore, can't get it's value from a node's transform. I think this is fine. I can make it more explicit if you want. Did you have other thoughts?

lexaknyazev · 2016-06-01T21:33:38Z

So it looks like there was a bug in collada2gltf some time ago:

glTF/sampleModels/boxSemantics/glTF/boxSemantics.gltf

Line 407 in d453cd1

"nodeModelInverseTransposeMatrix": {

I think spec can be explicit on that to prevent runtimes from somehow "converting" matrices.
Strictly speaking, MODELINVERSETRANSPOSE, MODELVIEWINVERSETRANSPOSE and VIEWPORT semantics can't coexist with node property.

pjcozzi · 2016-06-01T22:11:45Z

I think spec can be explicit on that to prevent runtimes from somehow "converting" matrices.
Strictly speaking, MODELINVERSETRANSPOSE, MODELVIEWINVERSETRANSPOSE and VIEWPORT semantics can't coexist with node property.

Thanks, updated the spec in f548e60. I will also cherry-pick this for master since it does not depend on the 1.0.1 spec.

BTW, pull requests into the 1.0.1 branch for any issues are welcome; in the meantime, I am working through items in this issue in the next few days.

pjcozzi · 2016-06-01T22:27:30Z

shininess is defined as FLOAT
https://github.com/KhronosGroup/glTF/blob/master/sampleModels/Box/glTF/Box.gltf#L226
value is integer
https://github.com/KhronosGroup/glTF/blob/master/sampleModels/Box/glTF/Box.gltf#L90

I suspect this is because JSON.stringify or equivalent just dropped the .0. JSON just stores Number and it is OK for a floating-point value to be a whole number. A clarification here just seems unnecessary. Are you sure it would be useful?

lexaknyazev · 2016-06-01T22:50:29Z

JSON just stores Number and it is OK for a floating-point value to be a whole number. A clarification here just seems unnecessary.

OK.

(If only GLSL was so permissive...)

pjcozzi · 2016-06-01T22:51:20Z

Is it OK to have technique parameters that are mentioned neither in technique.uniforms nor in technique.attributes?

No, but the spec wasn't explicit. Updated spec in the 1.0.1 branch: ff4ac97

pjcozzi · 2016-06-02T13:40:06Z

Will update so fovY and aspect ratio must be > 0, not >= 0.

See aa152d8.

pjcozzi · 2016-06-02T19:08:19Z

"Spec has a fixed list of valid attribute semantics. So how can we have custom attributes?", #563 (comment)

See 17d3145.

pjcozzi · 2016-06-02T19:19:09Z

There is no way to specify texture's width and height. This is needed for using raw binary texture data (not web-compressed formats).

After more digging, I propose to add optional width, height and mimeType fields to image and remove them from KHR_binary_glTF\image. This will serve two purposes:

We'll be able to use uncompressed textures both from external files (with explicit width, height and "mimeType": "application/octet-stream") and from embedded data: URI. In the latter case, we should omit mimeType field and use URI: data:application/octet-stream;base64,....

KHR_binary_glTF\image will contain only bufferView just like KHR_binary_glTF\shader.

After evaluating this, #563 (comment), more, I agree that this is the right direction; however, it will require a new version of the KHR_binary_glTF extension to take full advantage.

I'd like to limit the scope of the 1.0.1 spec largely to improvements for validation (a few exceptions are OK, for example, #573).

I feel like we might be better off holding off on this until glTF includes texture compression and then making all the changes at once: this, texture compression, and KHR_binary_glTF updates.

What do you think? Do you have pressing use cases that should drive this happening sooner?

lexaknyazev · 2016-06-03T13:04:01Z

What do you think? Do you have pressing use cases that should drive this happening sooner?

Several points, actually:

Uncompressed is the simplest possible pixel format. All GL implementations support it. It looks like texture.type has no use without KHR_binary_glTF while spec & extension are in their current state.
We need to consider multiple versions of the same texture for different compression formats (it's up to runtime to select one from RAW/PVRTC/ETC/S3TC/JPG). Export tools can provide only uncompressed file while all others can be generated during pipeline processing.
Adding fields to image is both ways compatible, removing fields from KHR_binary_glTF\image is not. We have to ask KHR_binary_glTF implementations for feedback on this.

lexaknyazev · 2016-06-03T13:18:30Z

I feel like we might be better off holding off on this until glTF includes texture compression and then making all the changes at once: this, texture compression, and KHR_binary_glTF updates.

Maybe we can establish some sort of framework for texture formats now to be able to add exact compression extensions later in non-destructive manner?

lexaknyazev · 2016-06-03T13:48:16Z

And we shouldn't forget about FLOAT textures - imho, the most important real-world uncompressed use case.

pjcozzi · 2016-06-03T18:29:17Z

@lexaknyazev are you up for proposing all these texture changes in a new issue (can still be labeled 1.0.1)? If we can nail this down enough - establish the framework as you suggest - than I think we can do it in the near-term. As for KHR_binary_glTF, I'm afraid that we would have to create a new KHR_binary_glTF2 (or something) to take advantage of this. That could be postponed until the extension potential calls for other changes.

Also - one more use case for this: creating glTF materials procedurally at runtime.

lexaknyazev · 2016-06-03T18:52:28Z

@lexaknyazev are you up for proposing all these texture changes in a new issue (can still be labeled 1.0.1)?

OK

As for KHR_binary_glTF, I'm afraid that we would have to create a new KHR_binary_glTF2 (or something) to take advantage of this. That could be postponed until the extension potential calls for other changes.

I understand that extension has been ratified already.
However it looks like almost all extension spec and known implementations contributors can be reached for feedback on this particular change.

pjcozzi · 2016-06-06T21:13:17Z

As for KHR_binary_glTF, I'm afraid that we would have to create a new KHR_binary_glTF2 (or something) to take advantage of this. That could be postponed until the extension potential calls for other changes.

I understand that extension has been ratified already.
However it looks like almost all extension spec and known implementations contributors can be reached for feedback on this particular change.

This extension is widely used in Cesium; it is the default. We could keep backwards-compatible code in the loader, but new assets won't work with older versions of Cesium, which would mean the converter would need another check box ([ ] Make compatible with Cesium 1.x and earlier).

I would rather queue this extension spec change up with other potential changes for a v2.

pjcozzi · 2016-06-06T21:33:10Z

Spec lacks examples of using WebGL extensions, i.e., how to declare usage of OES_element_index_uint? millennium_falcon.gltf from fr24-3d-models has accessors with "componentType": 5125 (UNSIGNED_INT) which isn't a valid value without extension.

I originally said that this should be a glTF extension, #563 (comment). I started writing the extension spec, and I now agree that it is overkill.

For the 1.0.1 spec, I suggest that we just allow UNSIGNED_INT as a valid accessor.componentType enum when the accessor is used for indices, not attributes (since this is not a valid value for vertexAttribPointer).

This means that the client will need to enable the OES_element_index_uint WebGL extension, or divide the accessor up (and all that entails) if the extension is not supported. However, given that the extension is widely supported, I do not think we need to worry about the later in practice.

What do you think?

lexaknyazev · 2016-06-06T21:48:11Z

I think this

This means that the client will need to enable the OES_element_index_uint WebGL extension

is a crucial point. Client has to know about uint indices, so I'd prefer to mention OES_element_index_uint in the extensionsUsed array for WebGL 1.0 profile.

pjcozzi · 2016-06-06T21:56:10Z

Client has to know about uint indices, so I'd prefer to mention OES_element_index_uint in the extensionsUsed array for WebGL 1.0 profile.

Yes, I thought about this too. extensionsUsed is for glTF extensions, not WebGL extensions so the right approach might be to introduce a new webglExtensionsUsed property so a client could check them and simply loop over and call getExtension if need be.

This could be convenient for clients and avoids double-tasking extensionsUsed. It also maps well to other WebGL extensions like OES_standard_derivatives and new texture and attribute formats.

Thoughts?

lexaknyazev · 2016-06-06T22:04:44Z

+1 for separate list.

The situation can become a bit more complex for GLSL extensions like EXT_shader_texture_lod.
Shader code may compile with or without extension support because of preprocessor directives.
So runtime has to know somehow is rendering possible without such extension.

lexaknyazev · 2016-06-06T22:46:09Z

This extension is widely used in Cesium; it is the default. We could keep backwards-compatible code in the loader, but new assets won't work with older versions of Cesium, which would mean the converter would need another check box ([ ] Make compatible with Cesium 1.x and earlier).

I would rather queue this extension spec change up with other potential changes for a v2.

I believe it's possible for 1.0.1 to support raw textures and prepare some foundation for compression formats.
Changes to KHR_binary_glTF could be queued up for the next version to preserve compatibility.

pjcozzi · 2016-06-07T11:58:36Z

This extension is widely used in Cesium; it is the default. We could keep backwards-compatible code in the loader, but new assets won't work with older versions of Cesium, which would mean the converter would need another check box ([ ] Make compatible with Cesium 1.x and earlier).

I would rather queue this extension spec change up with other potential changes for a v2.
I believe it's possible for 1.0.1 to support raw textures and prepare some foundation for compression formats.
Changes to KHR_binary_glTF could be queued up for the next version to preserve compatibility.

Yes, exactly. To keep things organized, can you please start the proposal in a new issue?

pjcozzi · 2016-06-07T12:25:45Z

Spec lacks examples of using WebGL extensions, i.e., how to declare usage of OES_element_index_uint? millennium_falcon.gltf from fr24-3d-models has accessors with "componentType": 5125 (UNSIGNED_INT) which isn't a valid value without extension.

See #619.

lexaknyazev · 2016-06-07T15:01:28Z

Yes, exactly. To keep things organized, can you please start the proposal in a new issue?

#620

pjcozzi · 2016-06-07T16:56:20Z

@lexaknyazev have all tasks in this issue been addressed or moved to other issues? If so, I will label this as resolved (and then close once the 1.0.1 spec is merged).

lexaknyazev · 2016-06-07T17:55:51Z

I've found only one unaddressed issue in this thread: attribute parameters must have semantic, otherwise they will be unlinkable to accessors (comment).

pjcozzi · 2016-06-08T11:29:10Z

I've found only one unaddressed issue in this thread: attribute parameters must have semantic, otherwise they will be unlinkable to accessors (comment).

Good eye. What do you think of 28e113d?

lexaknyazev · 2016-06-08T12:17:09Z

What do you think of 28e113d?

Lgtm

pjcozzi · 2016-06-08T16:39:48Z

Labeling this as resolved. Please submit future 1.0.1 spec issues in new issues.

pjcozzi · 2017-06-15T12:02:11Z

Updated in #826

lexaknyazev mentioned this issue Apr 14, 2016

Invalid fields in sample models #556

Closed

pjcozzi added the 2.0 label Apr 14, 2016

pjcozzi added the specification label Apr 25, 2016

lexaknyazev mentioned this issue Apr 25, 2016

uint32 indices #570

Closed

pjcozzi mentioned this issue Jun 1, 2016

Clarify that parameter.node does not allow some semantics #607

Merged

pjcozzi mentioned this issue Jun 2, 2016

Make indices accessor constraints explicit #615

Merged

lexaknyazev mentioned this issue Jun 7, 2016

Improving texture support for 1.0.1+ #620

Closed

5 tasks

pjcozzi added the resolved label Jun 8, 2016

lexaknyazev mentioned this issue Nov 18, 2016

Technique parameters with node specified fail validation if they are not FLOAT_MAT4 KhronosGroup/glTF-Validator#7

Closed

lexaknyazev mentioned this issue Dec 8, 2016

technique.parameter.type compatibility #789

Closed

pjcozzi closed this as completed Jun 15, 2017

Kif11 mentioned this issue Mar 3, 2019

GLTF Custom Vertex Attributes #1570

Closed

Thoughts on tightening up the spec #563

Thoughts on tightening up the spec #563

Comments

lexaknyazev commented Apr 14, 2016 • edited by pjcozzi Loading

Base spec

KHR_binary_glTF

KHR_materials_common

WEB3D_quantized_attributes

Base spec

KHR_binary_glTF

KHR_materials_common

WEB3D_quantized_attributes

pjcozzi commented Apr 14, 2016

lexaknyazev commented Apr 17, 2016

lexaknyazev commented Apr 17, 2016

pjcozzi commented Apr 17, 2016

lexaknyazev commented Apr 17, 2016

lexaknyazev commented Apr 21, 2016

lexaknyazev commented Apr 22, 2016 • edited Loading

lexaknyazev commented Apr 22, 2016

lexaknyazev commented Apr 25, 2016

pjcozzi commented Apr 25, 2016

lexaknyazev commented Apr 25, 2016

pjcozzi commented May 11, 2016

lexaknyazev commented May 11, 2016

pjcozzi commented May 11, 2016

lexaknyazev commented May 12, 2016

pjcozzi commented May 18, 2016

lexaknyazev commented May 18, 2016

pjcozzi commented Jun 1, 2016

lexaknyazev commented Jun 1, 2016

pjcozzi commented Jun 1, 2016

lexaknyazev commented Jun 1, 2016

pjcozzi commented Jun 1, 2016

pjcozzi commented Jun 1, 2016

lexaknyazev commented Jun 1, 2016

pjcozzi commented Jun 1, 2016

pjcozzi commented Jun 2, 2016

pjcozzi commented Jun 2, 2016

pjcozzi commented Jun 2, 2016

lexaknyazev commented Jun 3, 2016

lexaknyazev commented Jun 3, 2016

lexaknyazev commented Jun 3, 2016

pjcozzi commented Jun 3, 2016

lexaknyazev commented Jun 3, 2016

pjcozzi commented Jun 6, 2016

pjcozzi commented Jun 6, 2016

lexaknyazev commented Jun 6, 2016

pjcozzi commented Jun 6, 2016

lexaknyazev commented Jun 6, 2016

lexaknyazev commented Jun 6, 2016

pjcozzi commented Jun 7, 2016

pjcozzi commented Jun 7, 2016

lexaknyazev commented Jun 7, 2016 • edited Loading

pjcozzi commented Jun 7, 2016

lexaknyazev commented Jun 7, 2016

pjcozzi commented Jun 8, 2016

lexaknyazev commented Jun 8, 2016

pjcozzi commented Jun 8, 2016

pjcozzi commented Jun 15, 2017

lexaknyazev commented Apr 14, 2016 •

edited by pjcozzi

Loading

lexaknyazev commented Apr 22, 2016 •

edited

Loading

lexaknyazev commented Jun 7, 2016 •

edited

Loading