direct GL APIs values in GLTF files.

[fabrobinet]

If we go for a states specification that is per profile, one side effect could be to put directly the values of the states. (numbers, not string)
That would make less readable GLTF files, but more straight forward to handle in APIs...BUT it would make each platform potentially incompatible…

I have been thinking of this, as I am looking at textures, there are so many values for format/internalFormat/type... that handling all these strings will be painful :(

@pjcozzi @RemiArnaud @tparisi
Thoughts ?

[RemiArnaud]

I like that a lot, an array of values. See the other thread about array vs objects for state parameters.
Can't be more straight forward to use.

glTF is a target format, that can be generated (and cached) per target/application needs - not a cross-platform interchange format.

[fabrobinet]

thanks for the quick answer Remi. Let's stick to the purpose of the bug agree on having straight value from GL headers. The array aspect is discussed in its own issue ;)

[pjcozzi]

@fabrobinet and I have already discussed a bit, but given that we care about ease of client implementation over readability, I think using the enum values directly is better, leads to a smaller file, and ensures a fast implementation, e.g., if we stored strings, a client could still just do gl[name], but it would not be as efficient unless the client cached it.

[tparisi]

Are we really saying that one glTF file can't be read across different gl
platforms?

Is string parsing really that hard?

I am not comfortable with this design decision. Can we table resolving this
until I am back next week so I can better understand the surrounding
issues? I am particularly uncomfortable with this first bit. If this is
inherently not cross-platform I am not sure of our design goals here.
People might as well create their own formats for every different
application and use their own tools for everything. What value are we
adding here?

Tony

On Fri, Jun 7, 2013 at 3:14 AM, Patrick Cozzi [email protected]:

@fabrobinet https://github.com/fabrobinet and I have already discussed
a bit, but given that we care about ease of client implementation over
readability, I think using the enum values directly is better, leads to a
smaller file, and ensures a fast implementation, e.g., if we stored
strings, a client could still just do gl[name], but it would not be as
efficient unless the client cached it.

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

Tony Parisi [email protected]
CTO at Large 415.902.8002
Skype auradeluxe
Follow me on Twitter! http://twitter.com/auradeluxe
Read my blog at http://www.tonyparisi.com/
Learn WebGL http://learningwebgl.com/

Read my book! WebGL, Up and Running
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X

[fabrobinet]

@tparisi
The compatibility will the same, not worse, not better.
You won't (*) take OpenGL 4.0 assets and use them for WebGL 1.0, even today.
It would defeat the purpose of this final format, it's not an inter-exchange format.
BUT there are some level of compatibility between platforms, like between OpenGL ES 2.0 and WebGL 1.0.
And this change won't break it.

You can verify that headers values are the same between http://www.khronos.org/registry/gles/api/2.0/gl2.h and http://www.khronos.org/registry/webgl/specs/latest/ and this is not accident, it is by design.

Then, I faced the issue of having to handle possibly a lot of strings for texture format/internal format, the kind of thing I would just like to pass through... Just for states you can have a look here, and see GLContextDidChange function where I build a table to handle all the strings. I don't feel like adding more and maintaining this for all strings...

(*) but with #97 , you may not depend on shaders and states, and you typically won't have to handle these values if you use a destination engine like Three.js.

[fabrobinet]

@tparisi does this seem more reasonable to you with the comment just above ?

[tparisi]

Yes

[fabrobinet]

Ok, so it's a green light. I will manage to implement this before Siggraph so that we can get feedback sooner than later about this choice.

[fabrobinet]

note: here this will apply for values to be written in states and textures (and written in gl calls). read only values like "type" will remain string.

[fabrobinet]

I want to make a double-check with you guys @pjcozzi @tparisi @RemiArnaud .
Also, according to the implementation work you did, what do you think ?

What about the comment I put above ? if we implement this should we do it for every GL value or just in selected places ?

[tparisi]

sure.

[fabrobinet]

We agreed to move on first on the implementation and see how it feels

[fabrobinet]

I am implementing it in a branch (dev-1) - will provide feedback soon.

[fabrobinet]

done in dev-1 branch and tested in the viewer.
Result is:

• less code in loader/runtime fd6d1d9
• more code in converter 34dd00d
  Which is typically the kind of trade-off we are OK with...
  Also, as expected the JSON file is bit less readable since you get GLEnum (int) in place of string, but we can improve this by adding a debugging option (converter option), so that GLEnum could be seen as string in extras.

[fabrobinet]

added a branch label, to keep track of the bugs fixed in branches, only when integrated in master they can be close...

[fabrobinet]

@tparisi @pjcozzi @RemiArnaud I'll merge into master when we get other converter bugs fixed. But it should be ready for specification work now.

[pjcozzi]

• less code in loader/runtime fd6d1d9
• more code in converter 34dd00d Which is typically the kind of trade-off we are OK with... Also, as expected the JSON file is bit less readable since you get GLEnum (int) in place of string, but we can improve this by adding a debugging option (converter option), so that GLEnum could be seen as string in extras.

Looks great.

[fabrobinet]

removing converter label - pushed on master.

[pjcozzi]

@fabrobinet schema is updated, let's close this.