New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glTF roadmap - what would you like to see next in glTF? #1051

Open
pjcozzi opened this Issue Jul 30, 2017 · 116 comments

Comments

Projects
None yet
@pjcozzi
Member

pjcozzi commented Jul 30, 2017

Hi all - please chime in with any and all feedback to help drive the direction of glTF beyond 2.0. Even simple +1/-1's for topics are appreciated.

How much should we focus on building out the software ecosystem vs. moving forward the spec?

Should new spec features come in as extensions first, direct spec updates, or some combination? What mix?

Ecosystem Tools

What glTF software do we have the most immediate need for?

Conformance

  • How do we ensure a robust interoperable ecosystem?
  • How rigid and formal should conformance testing be?
  • What software tools are needed beyond the glTF Validator?

Infrastructure

  • How important is it for the validator to have a JSON schema for validation report, and a command-line and/or web service for integration?
  • JSON Schema 6. #929
  • Spec contributor's guide: glossary, terms. #1004
  • glTF Samples CI

Learning Material

  • What additional tutorials, sample models, and other learning material are needed?

Potential spec updates / extensions

  • LOD - BabylonJS prototype extension #1045
  • Progressive Geometry Streaming - Fraunhofer POP Buffer, WEB3D_streaming
  • Multi-vendor texture compression
  • PBR Next
    • E.g., transparency/refraction (#1027), multi-pass (#163) and clear coat (#1040)
  • API-specific features (they’re interconnected):
    • Textures: cube maps, formats, etc. #835, #620, #640, #728
    • Enhanced ES 3.0 / WebGL 2.0 support #832
    • Enhanced Vulkan support #663
  • Point Clouds
  • JSON reference other JSON #37
  • Bounding Volumes / Collision Volumes #507
  • Animation Compression #731

Really looking forward to continuing to move the field forward! Can't wait for your input!

@alteous

This comment has been minimized.

Show comment
Hide comment
@alteous

alteous Jul 30, 2017

The 2.0 specification is solid. I'd much prefer to see the software ecosystem building out than to see a glTF 3.0 specification.

alteous commented Jul 30, 2017

The 2.0 specification is solid. I'd much prefer to see the software ecosystem building out than to see a glTF 3.0 specification.

@realvictorprm

This comment has been minimized.

Show comment
Hide comment
@realvictorprm

realvictorprm Jul 30, 2017

Is it somehow possible to get a standard for Voxel data?

realvictorprm commented Jul 30, 2017

Is it somehow possible to get a standard for Voxel data?

@toji

This comment has been minimized.

Show comment
Hide comment
@toji

toji Jul 30, 2017

Agreed with @alteous that the glTF 2.0 spec is feeling pretty good at the moment. It addressed some real issues that emerged with the first spec in a very direct and useful way. I'd prefer to see new features emerge as extensions at this point rather than putting too much effort into a 3.0.

I would like to see an emphasis on tool ecosystem improvements. Especially in terms of exporter and other pipeline support. At the moment finding tools that meet a variety of needs is a bit of a coin toss even with some of the Khronos-backed tools. (I recently pushed a small change to the Blender exporter for this exact reason.) One nice thing to have available would be a collection of sample export targets similar to the fantastic set of sample models: A bunch of Collada, OBJ, FBX, etc files that all have different properties which tools developers can use to sanity check their exports. (Did the model with vertex colors come across right? Did the fact that this one has no UVs screw me up?)

Another thing that I'd like to see discussed is a way to verify/sign that a glTF file has specific properties that make it safe to use in a security-sensitive environment when loaded from a third party. (For example: Oculus mentioned using glTF files as favicons in a VR browser.) It's easy in that type of environment to say "We don't support extensions, animations, etc." but it's harder to usefully say "We won't attempt to render objects over 500k triangles" or "We won't load models that are collectively over 10MB" or "We don't support models with more than 100 different materials" which something like a browser would definitely want to do. The idea being that it could be relatively simple for a malicious source to provide a model that contained a few million individual meshes, each made up of a single, transparent, overlapping triangle that each have their own material each with a collection of unique 4K textures which is intentionally aimed at tanking the client's performance. Ideally a model could digitally verify before hand that it does, indeed, contain only 3 meshes with a mere 8k triangles with two materials between them that only use a couple 512 textures, so there's not a GPU in the world that should struggle with that.

That's a Hard Problem™️ , and I can't pretend to even begin to have the answers for it, but if solved it could make glTF a useful format for a massive range of applications that would otherwise balk at accepting external meshes.

toji commented Jul 30, 2017

Agreed with @alteous that the glTF 2.0 spec is feeling pretty good at the moment. It addressed some real issues that emerged with the first spec in a very direct and useful way. I'd prefer to see new features emerge as extensions at this point rather than putting too much effort into a 3.0.

I would like to see an emphasis on tool ecosystem improvements. Especially in terms of exporter and other pipeline support. At the moment finding tools that meet a variety of needs is a bit of a coin toss even with some of the Khronos-backed tools. (I recently pushed a small change to the Blender exporter for this exact reason.) One nice thing to have available would be a collection of sample export targets similar to the fantastic set of sample models: A bunch of Collada, OBJ, FBX, etc files that all have different properties which tools developers can use to sanity check their exports. (Did the model with vertex colors come across right? Did the fact that this one has no UVs screw me up?)

Another thing that I'd like to see discussed is a way to verify/sign that a glTF file has specific properties that make it safe to use in a security-sensitive environment when loaded from a third party. (For example: Oculus mentioned using glTF files as favicons in a VR browser.) It's easy in that type of environment to say "We don't support extensions, animations, etc." but it's harder to usefully say "We won't attempt to render objects over 500k triangles" or "We won't load models that are collectively over 10MB" or "We don't support models with more than 100 different materials" which something like a browser would definitely want to do. The idea being that it could be relatively simple for a malicious source to provide a model that contained a few million individual meshes, each made up of a single, transparent, overlapping triangle that each have their own material each with a collection of unique 4K textures which is intentionally aimed at tanking the client's performance. Ideally a model could digitally verify before hand that it does, indeed, contain only 3 meshes with a mere 8k triangles with two materials between them that only use a couple 512 textures, so there's not a GPU in the world that should struggle with that.

That's a Hard Problem™️ , and I can't pretend to even begin to have the answers for it, but if solved it could make glTF a useful format for a massive range of applications that would otherwise balk at accepting external meshes.

@Spaxe

This comment has been minimized.

Show comment
Hide comment
@Spaxe

Spaxe Jul 31, 2017

+1 on "Progressive Geometry Streaming - Fraunhofer POP Buffer, WEB3D_streaming"

Spaxe commented Jul 31, 2017

+1 on "Progressive Geometry Streaming - Fraunhofer POP Buffer, WEB3D_streaming"

@jbaicoianu

This comment has been minimized.

Show comment
Hide comment
@jbaicoianu

jbaicoianu Jul 31, 2017

@toji and @alteous took the words out of my mouth. glTF seems like it's in a good place with its featureset, but it's been very difficult to find a glTF asset pipeline that works well. Solid tools for getting glTF data into and out of all popular content creation tools would be a great next step. Some of the older tools like obj2gltf and FBX-glTF desperately need updating to the new specs to be usable (obj2gltf seems like it's making good progress on 2.0 lately, but FBX-glTF hasn't been updated in a year and has dependencies on projects which have been renamed and absorbed into other projects).

Very happy to see blender import support is on the list already - export without import has left me feeling a bit hamstrung sometimes, so this is something I'm definitely looking forward to.

jbaicoianu commented Jul 31, 2017

@toji and @alteous took the words out of my mouth. glTF seems like it's in a good place with its featureset, but it's been very difficult to find a glTF asset pipeline that works well. Solid tools for getting glTF data into and out of all popular content creation tools would be a great next step. Some of the older tools like obj2gltf and FBX-glTF desperately need updating to the new specs to be usable (obj2gltf seems like it's making good progress on 2.0 lately, but FBX-glTF hasn't been updated in a year and has dependencies on projects which have been renamed and absorbed into other projects).

Very happy to see blender import support is on the list already - export without import has left me feeling a bit hamstrung sometimes, so this is something I'm definitely looking forward to.

@c30ra

This comment has been minimized.

Show comment
Hide comment
@c30ra

c30ra Jul 31, 2017

For software ecosystem I would like to see official UE4 import and blender export. glTF is a good candidate to replace fbx, moreover it's open, so it should have better support in all pipelines/software data exchange.

c30ra commented Jul 31, 2017

For software ecosystem I would like to see official UE4 import and blender export. glTF is a good candidate to replace fbx, moreover it's open, so it should have better support in all pipelines/software data exchange.

@bwasty

This comment has been minimized.

Show comment
Hide comment
@bwasty

bwasty Jul 31, 2017

For conformance, I'd like to see more sample models, covering the whole spec. I already noticed a few missing things while developing my little viewer:

  • indices with component types UNSIGNED_BYTE and UNSIGNED_SHORT
  • color attributes, with all combinations of allowed types (only SmilingFace has one, but it seems to be black)
  • more than 1 texture coordinate set + a material that uses it

bwasty commented Jul 31, 2017

For conformance, I'd like to see more sample models, covering the whole spec. I already noticed a few missing things while developing my little viewer:

  • indices with component types UNSIGNED_BYTE and UNSIGNED_SHORT
  • color attributes, with all combinations of allowed types (only SmilingFace has one, but it seems to be black)
  • more than 1 texture coordinate set + a material that uses it
@AlbertoElias

This comment has been minimized.

Show comment
Hide comment
@AlbertoElias

AlbertoElias Jul 31, 2017

Definitely agree that the most urgent issue is improving the ecosystem so that we can all easily make use of what GLTF offers today, which is still a bit too hard to do.

Down the line though, I'd give a big +1 to streaming capabilities, it would be a massive improvement for serving GLTFs on the Web

AlbertoElias commented Jul 31, 2017

Definitely agree that the most urgent issue is improving the ecosystem so that we can all easily make use of what GLTF offers today, which is still a bit too hard to do.

Down the line though, I'd give a big +1 to streaming capabilities, it would be a massive improvement for serving GLTFs on the Web

@KageKirin

This comment has been minimized.

Show comment
Hide comment
@KageKirin

KageKirin Aug 1, 2017

Hi, I recently switched a company internal project from FBX to glTF (2.0). Here are a few tidbits that I would like to see:

  • a C or C++ reference implementation for creating/modifying assets (especially one that comes with few to no external dependencies)
  • an extension for custom shaders as pre-compiled SPIRV binary buffers
  • an extension for rigid body physical parameters for nodes (weight, joint rigidness, ...)
  • an extension for soft body physical parameters (deformable vertex hull, ...)
  • a compression mechanism for buffers (could be zip or lz4)

Although I agree that the extensions listed above could be easily implemented as custom extensions, I would like to see efforts to agree on a standard for physical data.

Best regards.

KageKirin commented Aug 1, 2017

Hi, I recently switched a company internal project from FBX to glTF (2.0). Here are a few tidbits that I would like to see:

  • a C or C++ reference implementation for creating/modifying assets (especially one that comes with few to no external dependencies)
  • an extension for custom shaders as pre-compiled SPIRV binary buffers
  • an extension for rigid body physical parameters for nodes (weight, joint rigidness, ...)
  • an extension for soft body physical parameters (deformable vertex hull, ...)
  • a compression mechanism for buffers (could be zip or lz4)

Although I agree that the extensions listed above could be easily implemented as custom extensions, I would like to see efforts to agree on a standard for physical data.

Best regards.

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Aug 3, 2017

Member

This is really insightful feedback, thanks everyone, keep it coming!

To summarize so far:

  • More focus on ecosystem than future spec/extensions (not to say no effort on spec/extensions)
  • Sample models
  • Ecosystem
    • FBX to glTF
    • Blender export 1.0
    • Blender import
    • UE4 import
    • C++ sample, #1051 (comment)
  • Spec/extensions

a compression mechanism for buffers (could be zip or lz4)

@KageKirin check out the draft Draco extension. The bitstream spec has reached 1.0 so we expect the glTF extension to move forward quickly, #874


@jbaicoianu obj2gltf 2.0 support should be ready any day now, would love your help testing the 2.0 branch: AnalyticalGraphicsInc/obj2gltf#67

Member

pjcozzi commented Aug 3, 2017

This is really insightful feedback, thanks everyone, keep it coming!

To summarize so far:

  • More focus on ecosystem than future spec/extensions (not to say no effort on spec/extensions)
  • Sample models
  • Ecosystem
    • FBX to glTF
    • Blender export 1.0
    • Blender import
    • UE4 import
    • C++ sample, #1051 (comment)
  • Spec/extensions

a compression mechanism for buffers (could be zip or lz4)

@KageKirin check out the draft Draco extension. The bitstream spec has reached 1.0 so we expect the glTF extension to move forward quickly, #874


@jbaicoianu obj2gltf 2.0 support should be ready any day now, would love your help testing the 2.0 branch: AnalyticalGraphicsInc/obj2gltf#67

@reduz

This comment has been minimized.

Show comment
Hide comment
@reduz

reduz Aug 3, 2017

Contributor

Please support multiple animations (#1052). Only supporting one makes it pretty limited (and a hassle) for exporting to a game engine. All modern DCCs (Blender, Maya, Max, etc) support animation clips, and all game engines support multiple animations, so this would make the workflow much better.

Contributor

reduz commented Aug 3, 2017

Please support multiple animations (#1052). Only supporting one makes it pretty limited (and a hassle) for exporting to a game engine. All modern DCCs (Blender, Maya, Max, etc) support animation clips, and all game engines support multiple animations, so this would make the workflow much better.

@CentaurMare

This comment has been minimized.

Show comment
Hide comment
@CentaurMare

CentaurMare Aug 3, 2017

I've posted both a glTF 2.0 exporter and now a glTF 2.0 importer for Sketchup on extensions.warehouse.com, but both are currently pending approval - not sure how long this process will take.

I'd like to see the specification document improved. I think the minimum and maximum values in the accessors were a difficulty for me, especially as they are conversions from float to string and I was plagued by rounding errors making the validations fail. There seems to be nothing in the document to explain why they are required, other than "there are cases when minimum and maximum must be defined". In the end my minimum and maximum values for normalized values looked like "min":[-1.0001,-1.0001,-1.0001],"max":[1.0001,1.0001,1.0001]

Decomposable matrices were another issue, and a matrix which I thought was decomposable (a matrix built from translate, scale & rotate) would still fail validation - again I don't know if it is because of rounding issues converting from float to string - but it would be nice if the spec included the code to decompose the matrix and what the expected precision and validation requirement would be. In the end I had to give up and just pre-multiply all the geometry by the transformations first, so exporting with identity matrix only for my version 1.0.0 exporter.

Other parts of the specification could have a bit more of a tidy up, e.g. "When nor sparse, neither bufferView is defined..."

CentaurMare commented Aug 3, 2017

I've posted both a glTF 2.0 exporter and now a glTF 2.0 importer for Sketchup on extensions.warehouse.com, but both are currently pending approval - not sure how long this process will take.

I'd like to see the specification document improved. I think the minimum and maximum values in the accessors were a difficulty for me, especially as they are conversions from float to string and I was plagued by rounding errors making the validations fail. There seems to be nothing in the document to explain why they are required, other than "there are cases when minimum and maximum must be defined". In the end my minimum and maximum values for normalized values looked like "min":[-1.0001,-1.0001,-1.0001],"max":[1.0001,1.0001,1.0001]

Decomposable matrices were another issue, and a matrix which I thought was decomposable (a matrix built from translate, scale & rotate) would still fail validation - again I don't know if it is because of rounding issues converting from float to string - but it would be nice if the spec included the code to decompose the matrix and what the expected precision and validation requirement would be. In the end I had to give up and just pre-multiply all the geometry by the transformations first, so exporting with identity matrix only for my version 1.0.0 exporter.

Other parts of the specification could have a bit more of a tidy up, e.g. "When nor sparse, neither bufferView is defined..."

@donmccurdy

This comment has been minimized.

Show comment
Hide comment
@donmccurdy

donmccurdy Aug 3, 2017

Member

Please support multiple animations (#1052).

I've posted more details on #1052, but this is already supported — our examples do not make it obvious. Definitely +1 from me on changing the example models to not use different animations for each node, and adding some examples that have multiple distinct animations.

Member

donmccurdy commented Aug 3, 2017

Please support multiple animations (#1052).

I've posted more details on #1052, but this is already supported — our examples do not make it obvious. Definitely +1 from me on changing the example models to not use different animations for each node, and adding some examples that have multiple distinct animations.

@fire

This comment has been minimized.

Show comment
Hide comment
@fire

fire Aug 4, 2017

What is the status of hdr formats? Openexr would be standard, but I'm open to ideas.

Openexr supports both 16 bit float and 32 bit float which corresponds to OES_texture_float; OES_texture_half_float.

fire commented Aug 4, 2017

What is the status of hdr formats? Openexr would be standard, but I'm open to ideas.

Openexr supports both 16 bit float and 32 bit float which corresponds to OES_texture_float; OES_texture_half_float.

@erwanmaigret

This comment has been minimized.

Show comment
Hide comment
@erwanmaigret

erwanmaigret Aug 4, 2017

Actually in general the missing bit to me is more about being able to add extensions/plugins. I strongly agree that 2.0 is already very strong and doing a lot, and going too deep may start to make it too specific (let's not make it grow into an FBX-style format).

So my main suggestion for extension would be to introduce some type of standard plugin solution that could allow custom extensions to be added and embedded inside gltf data.

As a simple example the rigging part is pretty standard today to map what you can do in Unity, but if you are in need deeper notion of constraints or deformers then you're stuck with only skinning/shapes.

The problem being that plugins mean evaluation mechanism during playback, most often seen as a complex problem. I actually think it's pretty simple if we could have a notion of scripted based behavior with embedded js or something like this (call it scripted operators, unity behaviors, or whatever). And avoid the big language debate by making this js-only since it's targeted mostly for web.

And btw, neither FBX now dot.xsi / KL / ... really tackled this right since they are all biased as companies, we have the luxury to make it right, and this could grow a huge community of developer IMO.

erwanmaigret commented Aug 4, 2017

Actually in general the missing bit to me is more about being able to add extensions/plugins. I strongly agree that 2.0 is already very strong and doing a lot, and going too deep may start to make it too specific (let's not make it grow into an FBX-style format).

So my main suggestion for extension would be to introduce some type of standard plugin solution that could allow custom extensions to be added and embedded inside gltf data.

As a simple example the rigging part is pretty standard today to map what you can do in Unity, but if you are in need deeper notion of constraints or deformers then you're stuck with only skinning/shapes.

The problem being that plugins mean evaluation mechanism during playback, most often seen as a complex problem. I actually think it's pretty simple if we could have a notion of scripted based behavior with embedded js or something like this (call it scripted operators, unity behaviors, or whatever). And avoid the big language debate by making this js-only since it's targeted mostly for web.

And btw, neither FBX now dot.xsi / KL / ... really tackled this right since they are all biased as companies, we have the luxury to make it right, and this could grow a huge community of developer IMO.

@Noxime

This comment has been minimized.

Show comment
Hide comment
@Noxime

Noxime Aug 4, 2017

@erwanmaigret

I don't think adding a scripting language to a model format is a good idea, especially JavaScript. What I would rather want to see (I haven't really read spec, so this might already be supported) is arbitrary data. Meaning you could embed anything you want to the file, possibly in base64 encoded binary.

Noxime commented Aug 4, 2017

@erwanmaigret

I don't think adding a scripting language to a model format is a good idea, especially JavaScript. What I would rather want to see (I haven't really read spec, so this might already be supported) is arbitrary data. Meaning you could embed anything you want to the file, possibly in base64 encoded binary.

@toji

This comment has been minimized.

Show comment
Hide comment
@toji

toji Aug 4, 2017

@Noxime: That already exists. Buffers and BufferViews in glTF are references to completely generic binary blobs which can contain anything you want in any format you want. If there's data that's unique to your use case you can easily create an object in a relevant extras property somewhere that points to a BufferView and provides whatever metadata is necessary to interpret it.

toji commented Aug 4, 2017

@Noxime: That already exists. Buffers and BufferViews in glTF are references to completely generic binary blobs which can contain anything you want in any format you want. If there's data that's unique to your use case you can easily create an object in a relevant extras property somewhere that points to a BufferView and provides whatever metadata is necessary to interpret it.

@c30ra

This comment has been minimized.

Show comment
Hide comment
@c30ra

c30ra Aug 4, 2017

@Noxime

Both javascript and arbitrary data are bad idea imo because this way you're are creating a vector of possible virus/exploit specially on pour coded library. With script you basically allow execution of arbitrary code, and arbitrary data may cause exploit by using particular string(something like happened to WhatsApp some time ago).

For conformance:
Also, I don't like much the idea of "extensions": Having an extension mean that an implementer may or not support it. This mean that a software may implement it and another one no. In case one want to pass data from this software to the other it virtually lose information. Instead a non extension spec, must be implemented to be compliant with the implemented version. There is also the problem of bloat the format with less used or exotic stuff..

c30ra commented Aug 4, 2017

@Noxime

Both javascript and arbitrary data are bad idea imo because this way you're are creating a vector of possible virus/exploit specially on pour coded library. With script you basically allow execution of arbitrary code, and arbitrary data may cause exploit by using particular string(something like happened to WhatsApp some time ago).

For conformance:
Also, I don't like much the idea of "extensions": Having an extension mean that an implementer may or not support it. This mean that a software may implement it and another one no. In case one want to pass data from this software to the other it virtually lose information. Instead a non extension spec, must be implemented to be compliant with the implemented version. There is also the problem of bloat the format with less used or exotic stuff..

@donmccurdy

This comment has been minimized.

Show comment
Hide comment
@donmccurdy

donmccurdy Aug 4, 2017

Member

More information on glTF's extension system, and why we have it, here. Extensions might specify extra data, intended to be used in a particular way by the runtime, but will not include scripts implementing that behavior.

Implementation of an extension's behavior may be handled by extending the loader for a specific engine, rather than as part of the glTF format itself. For example, we (three.js) are hoping to allow users to write plugins for THREE.GLTF2Loader without having to modify three.js directly (mrdoob/three.js#11682), so that you can experiment on extensions as needed.

Member

donmccurdy commented Aug 4, 2017

More information on glTF's extension system, and why we have it, here. Extensions might specify extra data, intended to be used in a particular way by the runtime, but will not include scripts implementing that behavior.

Implementation of an extension's behavior may be handled by extending the loader for a specific engine, rather than as part of the glTF format itself. For example, we (three.js) are hoping to allow users to write plugins for THREE.GLTF2Loader without having to modify three.js directly (mrdoob/three.js#11682), so that you can experiment on extensions as needed.

@donmccurdy

This comment has been minimized.

Show comment
Hide comment
@donmccurdy

donmccurdy Aug 4, 2017

Member

Also, I don't like much the idea of "extensions": Having an extension mean that an implementer may or not support it.

The intention here is, features that can and should be supported by all implementers will be part of the core specification, not extensions. As such, content authors who want their models to run everywhere should stick to the core spec.

However, we don't want to limit glTF so much that it only supports features possible on low-end mobile devices. For more expensive materials (like PBR specular-glossiness, or SSS) or WebGL 2.0 features, we hope to use extensions to enable experimentation, and then these features can be brought into the core spec if/when the time is right.

Member

donmccurdy commented Aug 4, 2017

Also, I don't like much the idea of "extensions": Having an extension mean that an implementer may or not support it.

The intention here is, features that can and should be supported by all implementers will be part of the core specification, not extensions. As such, content authors who want their models to run everywhere should stick to the core spec.

However, we don't want to limit glTF so much that it only supports features possible on low-end mobile devices. For more expensive materials (like PBR specular-glossiness, or SSS) or WebGL 2.0 features, we hope to use extensions to enable experimentation, and then these features can be brought into the core spec if/when the time is right.

@erwanmaigret

This comment has been minimized.

Show comment
Hide comment
@erwanmaigret

erwanmaigret Aug 4, 2017

I totally agree bringing some language in the game is far from ideal. But then I don't see any other options unless we start to get into predefined constraint+deformer notions.

Both could work in the end. I am afraid that if we don't do either, then the format will be limited to embedding only skinning/shapes/animation forever and side solutions will start to be created.

Let's just consider a very simple aiming constraint, which is very commonly used today in about any rig with a character. How could we make it so it's part of the data part?

Or maybe this just does not fit into the low-level gltf format but then we should consider specing out an official solution as a standard gltf behavior manager?

erwanmaigret commented Aug 4, 2017

I totally agree bringing some language in the game is far from ideal. But then I don't see any other options unless we start to get into predefined constraint+deformer notions.

Both could work in the end. I am afraid that if we don't do either, then the format will be limited to embedding only skinning/shapes/animation forever and side solutions will start to be created.

Let's just consider a very simple aiming constraint, which is very commonly used today in about any rig with a character. How could we make it so it's part of the data part?

Or maybe this just does not fit into the low-level gltf format but then we should consider specing out an official solution as a standard gltf behavior manager?

@stevenvergenz

This comment has been minimized.

Show comment
Hide comment
@stevenvergenz

stevenvergenz Aug 4, 2017

I disagree that glTF needs an embedded behavior system. At the end of the day, glTF is specifically a data transmission format. It's the jpeg of 3d, not the javascript. I think it would be useful to be able to serialize and transmit "entities" instead of "models", but trying to shoehorn that into glTF is a mistake. That deserves its own spec IMO.

stevenvergenz commented Aug 4, 2017

I disagree that glTF needs an embedded behavior system. At the end of the day, glTF is specifically a data transmission format. It's the jpeg of 3d, not the javascript. I think it would be useful to be able to serialize and transmit "entities" instead of "models", but trying to shoehorn that into glTF is a mistake. That deserves its own spec IMO.

@toji

This comment has been minimized.

Show comment
Hide comment
@toji

toji Aug 4, 2017

@erwanmaigret: Things like aiming constraints sound highly use-case (and probably engine) specific. That's what the extras attributes are for. Certainly there's nothing preventing you from putting a full scripting language into an extras attribute if you wish, and your content pipeline can be tuned to use that, but everyone else loading the file will only use the parts of it that are standardized. That sounds problematic, but in reality there's very little chance that something as specific as an aiming constraint will map cleanly between environments anyway.

toji commented Aug 4, 2017

@erwanmaigret: Things like aiming constraints sound highly use-case (and probably engine) specific. That's what the extras attributes are for. Certainly there's nothing preventing you from putting a full scripting language into an extras attribute if you wish, and your content pipeline can be tuned to use that, but everyone else loading the file will only use the parts of it that are standardized. That sounds problematic, but in reality there's very little chance that something as specific as an aiming constraint will map cleanly between environments anyway.

@erwanmaigret

This comment has been minimized.

Show comment
Hide comment
@erwanmaigret

erwanmaigret Aug 4, 2017

@toji Make sense I'll write this as a rigging/behavior engine riding on top of gltf then in a separate repo.

erwanmaigret commented Aug 4, 2017

@toji Make sense I'll write this as a rigging/behavior engine riding on top of gltf then in a separate repo.

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Aug 5, 2017

Member

(Minor summary update; italics indicates updates from #1051 (comment)).


Member

pjcozzi commented Aug 5, 2017

(Minor summary update; italics indicates updates from #1051 (comment)).


@steveghee

This comment has been minimized.

Show comment
Hide comment
@steveghee

steveghee Aug 5, 2017

Personally, I'd like to see focus on complexity management e.g. supporting levels-of-detail (and streaming), being able to support structured breakdown (json file referencing other json file(s) - #37 ) and finishing up the alternate material support e.g. a simplified blinn/phong model.

steveghee commented Aug 5, 2017

Personally, I'd like to see focus on complexity management e.g. supporting levels-of-detail (and streaming), being able to support structured breakdown (json file referencing other json file(s) - #37 ) and finishing up the alternate material support e.g. a simplified blinn/phong model.

@alteous

This comment has been minimized.

Show comment
Hide comment
@alteous

alteous Aug 5, 2017

For the sake of simplicity and ease of adoption, I hope that the scene hierarchy remains a strict tree. I say this because the nodes and heirarchy section of the specification mentions that this restriction may be lifted in the future.

alteous commented Aug 5, 2017

For the sake of simplicity and ease of adoption, I hope that the scene hierarchy remains a strict tree. I say this because the nodes and heirarchy section of the specification mentions that this restriction may be lifted in the future.

@steveghee

This comment has been minimized.

Show comment
Hide comment
@steveghee

steveghee Aug 5, 2017

I would assume that if this is going to be truly platform neutral, there is going to a cleanup of some of the GL-specific enums e.g. componentType : 5126 (GL_FLOAT).

steveghee commented Aug 5, 2017

I would assume that if this is going to be truly platform neutral, there is going to a cleanup of some of the GL-specific enums e.g. componentType : 5126 (GL_FLOAT).

@sonygod

This comment has been minimized.

Show comment
Hide comment
@sonygod

sonygod Oct 21, 2017

consider support playcanvas engine ,because current playcanvas have no binary format ,use originally text json is not suit for web transfer.

sonygod commented Oct 21, 2017

consider support playcanvas engine ,because current playcanvas have no binary format ,use originally text json is not suit for web transfer.

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Oct 21, 2017

Member

@sonygod consider letting the playcanvas team know that you are interested in glTF support.

Member

pjcozzi commented Oct 21, 2017

@sonygod consider letting the playcanvas team know that you are interested in glTF support.

@jratcliff63367

This comment has been minimized.

Show comment
Hide comment
@jratcliff63367

jratcliff63367 Oct 23, 2017

We are working on creating a DOM (data object model) for physics which will represent the 'union' of a number of popular physics engine; such that it can represent the features of all of them rather than doing something which is a watered down specification that can only represent the most minimal of common data types. This will be a somewhat time consuming process. but should yield something that everyone can be happy with in the end.

jratcliff63367 commented Oct 23, 2017

We are working on creating a DOM (data object model) for physics which will represent the 'union' of a number of popular physics engine; such that it can represent the features of all of them rather than doing something which is a watered down specification that can only represent the most minimal of common data types. This will be a somewhat time consuming process. but should yield something that everyone can be happy with in the end.

@paseb

This comment has been minimized.

Show comment
Hide comment
@paseb

paseb Oct 23, 2017

@jratcliff63367,

Thanks for your response. Is there a timeline for the draft DOM or WIP proposals? Do you have a list of what is being considered the popular physics engines for parity/union and is there a canonical set of data types we're looking to represent?

thanks,
-pat

paseb commented Oct 23, 2017

@jratcliff63367,

Thanks for your response. Is there a timeline for the draft DOM or WIP proposals? Do you have a list of what is being considered the popular physics engines for parity/union and is there a canonical set of data types we're looking to represent?

thanks,
-pat

@space2

This comment has been minimized.

Show comment
Hide comment
@space2

space2 Oct 23, 2017

Is there a plan to have LOD (level of detail) support for meshes (and textures)?
For example one mesh could have an attribute saying that it's a lower LOD of another mesh.
Could be useful also to have as a lo-res preview: the json/gltf file is usually quite small, ~100K. Most of the space is the buffer data and the images. So having an extra copy of the meshes, in much lower detail, and making sure the buffer views are located at the beginning of the buffer, one could already show a preview while still loading the rest of the data.

space2 commented Oct 23, 2017

Is there a plan to have LOD (level of detail) support for meshes (and textures)?
For example one mesh could have an attribute saying that it's a lower LOD of another mesh.
Could be useful also to have as a lo-res preview: the json/gltf file is usually quite small, ~100K. Most of the space is the buffer data and the images. So having an extra copy of the meshes, in much lower detail, and making sure the buffer views are located at the beginning of the buffer, one could already show a preview while still loading the rest of the data.

@vpenades

This comment has been minimized.

Show comment
Hide comment
@vpenades

vpenades Oct 23, 2017

@space2 thinking about how gltf has been designed, it would make sense to use the multiple scene support as a LOD system. in other words: you could create a Scene per LOD, and use the metadata of each scene to define the LOD info.

vpenades commented Oct 23, 2017

@space2 thinking about how gltf has been designed, it would make sense to use the multiple scene support as a LOD system. in other words: you could create a Scene per LOD, and use the metadata of each scene to define the LOD info.

@stevepg

This comment has been minimized.

Show comment
Hide comment
@stevepg

stevepg Oct 23, 2017

@space2 there are extensions being proposed that define LODs at the mesh, node and material level

stevepg commented Oct 23, 2017

@space2 there are extensions being proposed that define LODs at the mesh, node and material level

@sbtron

This comment has been minimized.

Show comment
Hide comment
@sbtron

sbtron Oct 23, 2017

Contributor

@space2 here is a potential approach: #1045
It needs to be iterated on and updated based on feedback to make a generic extension.

Contributor

sbtron commented Oct 23, 2017

@space2 here is a potential approach: #1045
It needs to be iterated on and updated based on feedback to make a generic extension.

@jratcliff63367

This comment has been minimized.

Show comment
Hide comment
@jratcliff63367

jratcliff63367 Oct 23, 2017

We have only just started discussing this process. We have identified two graduate students who should be able to begin working on the problem soon. My first thought is that we should evaluate PhysX, Bullet, and Mujoco.

jratcliff63367 commented Oct 23, 2017

We have only just started discussing this process. We have identified two graduate students who should be able to begin working on the problem soon. My first thought is that we should evaluate PhysX, Bullet, and Mujoco.

@nitrologic

This comment has been minimized.

Show comment
Hide comment
@nitrologic

nitrologic Oct 24, 2017

If GLTF wants to be the JPEG of 3D perhaps it would be useful to identify some features that GLTF is missing in such a context such as thumbnails for cataloging purposes and geotagging for placement and orientation in real world / augmented reality.

nitrologic commented Oct 24, 2017

If GLTF wants to be the JPEG of 3D perhaps it would be useful to identify some features that GLTF is missing in such a context such as thumbnails for cataloging purposes and geotagging for placement and orientation in real world / augmented reality.

@vpenades

This comment has been minimized.

Show comment
Hide comment
@vpenades

vpenades Oct 24, 2017

@nitrologic I've proposed the thumbnail feature a while ago and received mixed feelings, specially when trying to include it in the json text file as a mime64 embedded block.

In retrospect, I believe the only place in which a thumbnail would make sense, and would be really easy to skip, is the binary GLB file, as another binary chunk.

Another issue of the thumbnail is to actually generate it... image thumbnails are really easy to produce since they're scaled versions of the original images, but to produce a thumbnail of gltf you need to render the scene.

vpenades commented Oct 24, 2017

@nitrologic I've proposed the thumbnail feature a while ago and received mixed feelings, specially when trying to include it in the json text file as a mime64 embedded block.

In retrospect, I believe the only place in which a thumbnail would make sense, and would be really easy to skip, is the binary GLB file, as another binary chunk.

Another issue of the thumbnail is to actually generate it... image thumbnails are really easy to produce since they're scaled versions of the original images, but to produce a thumbnail of gltf you need to render the scene.

@CentaurMare

This comment has been minimized.

Show comment
Hide comment
@CentaurMare

CentaurMare Oct 25, 2017

@vpenades, @nitrologic, my view on this is that the glTF (or GLB) should in no way provide a provision for a thumbnail, except maybe a preferred scene and view camera for when a thumbnail is generated externally.
The reason being, is that the source of the glTF may be an exporter or converter that cannot generate a thumbnail itself.
In Windows, the explorer shell looks up the registry for the file type and if present calls the mapped DLL via the IThumbnailProvider interface - it would be this DLL (which someone needs to write) that creates the thumbnail so that the Windows Explorer can update its thumbnail cache.
This means tweaking a value (such as a colour) directly in the glTF file will cause its thumbnail to be regenerated, which is what we want.

CentaurMare commented Oct 25, 2017

@vpenades, @nitrologic, my view on this is that the glTF (or GLB) should in no way provide a provision for a thumbnail, except maybe a preferred scene and view camera for when a thumbnail is generated externally.
The reason being, is that the source of the glTF may be an exporter or converter that cannot generate a thumbnail itself.
In Windows, the explorer shell looks up the registry for the file type and if present calls the mapped DLL via the IThumbnailProvider interface - it would be this DLL (which someone needs to write) that creates the thumbnail so that the Windows Explorer can update its thumbnail cache.
This means tweaking a value (such as a colour) directly in the glTF file will cause its thumbnail to be regenerated, which is what we want.

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Oct 25, 2017

Member

@jratcliff63367 do you want to start a new issue in this GitHub repo for discussion of the physics extension? Seems like we could get lots of community input and maybe even contributors. 😃

Member

pjcozzi commented Oct 25, 2017

@jratcliff63367 do you want to start a new issue in this GitHub repo for discussion of the physics extension? Seems like we could get lots of community input and maybe even contributors. 😃

@jratcliff63367

This comment has been minimized.

Show comment
Hide comment
@jratcliff63367

jratcliff63367 Oct 25, 2017

Sure, I can do that.

jratcliff63367 commented Oct 25, 2017

Sure, I can do that.

@jratcliff63367

This comment has been minimized.

Show comment
Hide comment
@jratcliff63367

jratcliff63367 Oct 25, 2017

New issue created here:

#1135

jratcliff63367 commented Oct 25, 2017

New issue created here:

#1135

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Nov 7, 2017

Member

Hi all - great twitter thread on "What is the #1 thing we should do next for the glTF ecosystem?"

https://twitter.com/pjcozzi/status/927495782999007233

Feel free to chime in!

Member

pjcozzi commented Nov 7, 2017

Hi all - great twitter thread on "What is the #1 thing we should do next for the glTF ecosystem?"

https://twitter.com/pjcozzi/status/927495782999007233

Feel free to chime in!

@mlimper

This comment has been minimized.

Show comment
Hide comment
@mlimper

mlimper Mar 13, 2018

Contributor

just started a thread on object space normal maps as possible future feature: #1284

Contributor

mlimper commented Mar 13, 2018

just started a thread on object space normal maps as possible future feature: #1284

@CentaurMare

This comment has been minimized.

Show comment
Hide comment
@CentaurMare

CentaurMare Mar 22, 2018

Just including a thought for beyond glTF 2.0 (but please don't rush to a glTF 3.0 this decade).

COLOR_0 (vec3 or vec4) is a multiplier on the diffuse/alpha map or the base colour.
NORMAL (vec3) is a multiplier on the normal map or the normal.

So would it make sense to include...
METALLICROUGHNESS_0 (vec2) as a multiplier on the metallic/roughness map or the per vertex metallic roughness?
and
KHRSPECULARGLOSSINESS_0 (vec2) as a multiplier on the specular glossiness map or the per vertex specular glossiness? This could possibly be a vec4 if specular colour is defined.
and
AMBIENT_0 (vec3) per vertex ambient colour
EMISSIVE_0 (vec3) per vertex emissive colour

CentaurMare commented Mar 22, 2018

Just including a thought for beyond glTF 2.0 (but please don't rush to a glTF 3.0 this decade).

COLOR_0 (vec3 or vec4) is a multiplier on the diffuse/alpha map or the base colour.
NORMAL (vec3) is a multiplier on the normal map or the normal.

So would it make sense to include...
METALLICROUGHNESS_0 (vec2) as a multiplier on the metallic/roughness map or the per vertex metallic roughness?
and
KHRSPECULARGLOSSINESS_0 (vec2) as a multiplier on the specular glossiness map or the per vertex specular glossiness? This could possibly be a vec4 if specular colour is defined.
and
AMBIENT_0 (vec3) per vertex ambient colour
EMISSIVE_0 (vec3) per vertex emissive colour

@Vinc3r

This comment has been minimized.

Show comment
Hide comment
@Vinc3r

Vinc3r Mar 22, 2018

+1 for Blender import
(and also this already opened task :) - Add support for Principled BSDF Node )

Vinc3r commented Mar 22, 2018

+1 for Blender import
(and also this already opened task :) - Add support for Principled BSDF Node )

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Mar 25, 2018

Member

@CentaurMare could be good to open a separate issue for METALLICROUGHNESS_0, etc. discussion.

please don't rush to a glTF 3.0 this decade

lol.

@Vinc3r I agree on Blender import, and hope to see some movement here soon.

Member

pjcozzi commented Mar 25, 2018

@CentaurMare could be good to open a separate issue for METALLICROUGHNESS_0, etc. discussion.

please don't rush to a glTF 3.0 this decade

lol.

@Vinc3r I agree on Blender import, and hope to see some movement here soon.

@CentaurMare

This comment has been minimized.

Show comment
Hide comment
@CentaurMare

CentaurMare Mar 26, 2018

@pjcozzi , METALLICROUGHNESS_0, etc. discussion opened on #1294

CentaurMare commented Mar 26, 2018

@pjcozzi , METALLICROUGHNESS_0, etc. discussion opened on #1294

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi
Member

pjcozzi commented Mar 26, 2018

Thanks @CentaurMare!

@eobet

This comment has been minimized.

Show comment
Hide comment
@eobet

eobet Mar 28, 2018

3D Studio Max importer/exporter, please.

#1053

eobet commented Mar 28, 2018

3D Studio Max importer/exporter, please.

#1053

@Ben-Mack

This comment has been minimized.

Show comment
Hide comment
@Ben-Mack

Ben-Mack Jun 7, 2018

Please add support for Lightmap 🙏 Most 3D engine all have lightmap in their pbr material, not only helpful for game scene but architecture, product visualization... to achieve much better lighting quality (and performance) for static objects
#1017

(👍+1 for 3ds Max exporter too)

Ben-Mack commented Jun 7, 2018

Please add support for Lightmap 🙏 Most 3D engine all have lightmap in their pbr material, not only helpful for game scene but architecture, product visualization... to achieve much better lighting quality (and performance) for static objects
#1017

(👍+1 for 3ds Max exporter too)

@christopher4lis

This comment has been minimized.

Show comment
Hide comment
@christopher4lis

christopher4lis Jul 18, 2018

A Cinema 4D exporter would be godly. Right now the process is exporting as a DAE into Modo, getting textures and materials right there, then exporting into glb. Very tedious process, but would love to see it alleviated with a native glTF / glb exporter.

Thanks for all of the hard work so far, the glTF format works extremely well in the browser.

christopher4lis commented Jul 18, 2018

A Cinema 4D exporter would be godly. Right now the process is exporting as a DAE into Modo, getting textures and materials right there, then exporting into glb. Very tedious process, but would love to see it alleviated with a native glTF / glb exporter.

Thanks for all of the hard work so far, the glTF format works extremely well in the browser.

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Sep 12, 2018

Member

For folks interested in glTF materials, we are collecting requirements for next-gen PBR in glTF, please chime in to #1442.

Member

pjcozzi commented Sep 12, 2018

For folks interested in glTF materials, we are collecting requirements for next-gen PBR in glTF, please chime in to #1442.

@vyv03354

This comment has been minimized.

Show comment
Hide comment
@vyv03354

vyv03354 Sep 21, 2018

Are there any plans to release 2.1 to add license information (#839)?

vyv03354 commented Sep 21, 2018

Are there any plans to release 2.1 to add license information (#839)?

@pjcozzi

This comment has been minimized.

Show comment
Hide comment
@pjcozzi

pjcozzi Sep 24, 2018

Member

@vyv03354 there's no formal plans for a 2.1 at this point. In the meantime, perhaps you could store license info in an application-specific extras object?

Member

pjcozzi commented Sep 24, 2018

@vyv03354 there's no formal plans for a 2.1 at this point. In the meantime, perhaps you could store license info in an application-specific extras object?

@emackey

This comment has been minimized.

Show comment
Hide comment
@emackey

emackey Sep 25, 2018

Member

Note that Sketchfab's glTF downloads are already embedding license and misc metadata in the extras tag of the asset object. It would be great to see more adoption of this form.

  "asset": {
    "extras": {
      "author": "manilov.ap (https://sketchfab.com/manilov.ap)",
      "license": "CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)",
      "source": "https://sketchfab.com/models/908985d8ec544638bcd661bc315597ad",
      "title": "Sr71"
    },
    "generator": "Sketchfab-3.20.7",
    "version": "2.0"
  },
Member

emackey commented Sep 25, 2018

Note that Sketchfab's glTF downloads are already embedding license and misc metadata in the extras tag of the asset object. It would be great to see more adoption of this form.

  "asset": {
    "extras": {
      "author": "manilov.ap (https://sketchfab.com/manilov.ap)",
      "license": "CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)",
      "source": "https://sketchfab.com/models/908985d8ec544638bcd661bc315597ad",
      "title": "Sr71"
    },
    "generator": "Sketchfab-3.20.7",
    "version": "2.0"
  },
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment