default uniforms semantic need to be added to the spec

[RemiArnaud]

in duck.json :

"semantic": "WORLDVIEWINVERSETRANSPOSE",
"semantic": "WORLDVIEW",
"semantic": "PROJECTION",

those uniforms have to be provided by the application, so they need to be provided in the specification

[RemiArnaud]

and to the schema https://github.com/KhronosGroup/glTF/blob/master/specification/uniform.schema.json

[fabrobinet]

Full list is here: (origin: http://www.nvidia.com/object/using_sas.html)

So it's WORD / VIEW / PROJECTION combination.
We may want to add the transform of the node itself, can be called: "MODEL" or "OBJECT" or "LOCAL"...
But I do not have shader example that needs it now, and I believe we can start safely with this list...

WORLD
VIEW
PROJECTION
WORLDVIEW
VIEW PROJECTION
WORLDVIEWPROJECTION
WORLDINVERSE
VIEWINVERSE
PROJECTIONINVERSE
WORLDVIEWINVERSE
VIEW PROJECTIONINVERSE
WORLDVIEWPROJECTIONINVERSE
WORLDTRANSPOSE
VIEWTRANSPOSE
PROJECTIONTRANSPOSE
WORLDVIEWTRANSPOSE
VIEW PROJECTIONTRANSPOSE
WORLDVIEWPROJECTIONTRANSPOSE
WORLDINVERSETRANSPOSE
VIEWINVERSETRANSPOSE
PROJECTIONINVERSETRANSPOSE
WORLDVIEWINVERSETRANSPOSE
VIEW PROJECTIONINVERSETRANSPOSE
WORLDVIEWPROJECTIONINVERSETRANSPOSE

[RemiArnaud]

Where can you find a description of those uniforms?
I understand WORLDVIEW (world to view matrix), but what is WORLD or VIEW ?

[fabrobinet]

Sure we'll need to describe them...
WORD is the transform of the node including it's parents transforms. It is the absolute position in space.
VIEW is the transform of the active camera node

[RemiArnaud]

see also #89

[fabrobinet]

Following up on #89 required action here is to specify which are supproted for each semantic and implement support in the converter.

[pjcozzi]

I know I've discussed with @fabrobinet before, but I think WORLD should be called MODEL to better fit with WebGL terminology.

I also think that several of those semantics will never be used in practice so we shouldn't adopt them all just because NVIDIA has them listed. I'm happy to propose what to include and what not to.

[RemiArnaud]

I like this approach.

• Remi

[fabrobinet]

AFAIK MODEL was for immediate mode and is deprecated now, there is no such things now (in GL API updates).
IMO WORLD better carry than MODEL the fact that this transform includes parents transforms and is used for an absolute position in space.
If all editors want to it to be MODEL I could live with it.
One last thing to consider, is that we might need (later) to support relative position in space,
then what would it be ? LOCAL ? and then we would have MODEL and LOCAL, versus WORLD and LOCAL.
I would say that the later combination is more explicit...

[tparisi]

I'm with fab, I like WORLD better. And I would like to leave room for LOCAL later.

[fabrobinet]

@pjcozzi @RemiArnaud @tparisi

(@tparsi oops I changed my mind, and I put the reason below, it's subtle so one solution or another is eventually fine with me)

short story: I am OK to move-on and use MODEL in place of WORLD. Without a veto I will proceed to change the converter.

I agree to let down WORLD because I figured that speaking of the VIEW the nomenclature above is unclear if that's implicitly world view (meaning the a node with camera will be the view matrix including all parents) or not. Obviously it should be view in "world" space but I agree that if we have MODEL and VIEW then by contract these guys are in world space understand include parents transforms so it's better IMO and matches GL (they are not local because they are used to compute the final position of the vertex).

Also, just like Tony would like , being able to specify what is the local matrix in opposition to the matrix that carries the concatenation of all the parents still need to be resolved but we can see that later as a second step.

[tparisi]

To me, MODEL is synonymous with LOCAL (it's just the transform at that particular leaf of the tree). So I personally think it's a bad choice. Therefore I am exercising my veto... pending a sit-down with you.

[fabrobinet]

That's was what I sort of intuitively thought too, but it is wrong, speaking of GL when you used to set the MODEL matrix (concatenated with VIEW as MODELVIEW) that's the absolute position in space use to make the gl_Position hence that's not the LOCAL.

[tparisi]

Oh so this is GL speak? I guess we should go with it, even thought it's dead wrong.

[fabrobinet]

@pjcozzi confirmed he is for this and will propose a set of semantic.

[pjcozzi]

Here are the semantics I propose along with descriptions and the allowed parameter type:

Standard

• LOCAL - mat4 - Transforms from the node's coordinate system to its parents. This is the node's matrix property (or dervived matrix from translation, rotation, and scale properties).
• MODEL - mat4 - Transforms from model to world coordinates using the transform's node and all of its parents.
• VIEW - mat4 - Transforms from world to view coordinates using the active camera node.
• PROJECTION - mat4 - Transforms from view to clip coordinates using the active camera node.
• MODELVIEW - mat4 - Combined MODEL and VIEW.
• MODELVIEWPROJECTION - mat4 or mat3 - Combined MODEL, VIEW, and PROJECTION.

Inverses

• MODELINVERSE - mat4 - Inverse of MODEL.
• VIEWINVERSE - mat4 - Inverse of VIEW.
• PROJECTIONINVERSE - mat4 - Inverse of PROJECTION.
• MODELVIEWINVERSE - mat4 - Inverse of MODELVIEW.
• MODELVIEWPROJECTIONINVERSE - mat4 - Inverse of MODELVIEWPROJECTION.

Inverse transposes

• MODELINVERSETRANSPOSE - mat3 - The inverse-transpose of MODEL without the translation. This translates normals in model coordinates to world coordinates.
• MODELVIEWINVERSETRANSPOSE - mat3 - The inverse-transpose of MODELVIEW without the translation. This translates normals in model coordinates to eye coordinates.

New ones I propose not listed above

• VIEWPORT - vec4 - The viewport's x, y, width, and height properties stored in the x, y, z, and w components, respectively. For example, this is used to scale window coordinates to [0, 1]: vec2 v = gl_FragCoord.xy / viewport.zw;

Not needed:

All of the following are rarely or never used in my experience.

VIEWPROJECTION
VIEWPROJECTIONINVERSE

MODELTRANSPOSE
VIEWTRANSPOSE
PROJECTIONTRANSPOSE
MODELVIEWTRANSPOSE
VIEWPROJECTIONTRANSPOSE
MODELVIEWPROJECTIONTRANSPOSE

VIEWINVERSETRANSPOSE
PROJECTIONINVERSETRANSPOSE
VIEWPROJECTIONINVERSETRANSPOSE
MODELVIEWPROJECTIONINVERSETRANSPOSE

[tparisi]

This looks like a really useful set to start. If we missed something, people will let us know. I approve!

[pjcozzi]

If we missed something, people will let us know

Agreed. I am open to adding more over time. It's nice to start small to not hinder engine developers with needless uniforms.

[fabrobinet]

This set is fine with me too, I think we'll get request for "local". (the transform at a given node not including parents).
Also, just being (maybe) peaky but it could be confusing to use "Model" to define "model" as in:
" Transforms from model to world coordinates " , maybe instead "Transforms from local to world coordinates" would work better ?

[pjcozzi]

" Transforms from model to world coordinates " , maybe instead "Transforms from local to world coordinates" would work better ?

The GL terminology is model and world coordinates. Folks rarely mix terms, so we wouldn't say "local" and "world"; we would say "local" and "global." In the spec, I would probably write something like:

Transforms from model (local) to world (global) coordinates.

I think we'll get request for "local". (the transform at a given node not including parents).

If we have a good use case, I am OK with adding it now. Perhaps it's useful for animation so we don't have to traverse all the way up to the root node - at the cost of an extra matrix multiply in the vertex shader.

[tparisi]

I can see "local" being useful. Let's add it.

[fabrobinet]

I'll start integrate what we have in the converter

[fabrobinet]

pushed in dev-2 branch acdce2c

[fabrobinet]

convertir fix: now on master

[pjcozzi]

Related spec question: In a technique's parameters, will a semantic only appear at most once? Feels like yes to me.

[pjcozzi]

I can see "local" being useful. Let's add it.

I added LOCAL to the list above. Sorry for the delay here.

@fabrobinet do we have full support in the converter for all semantics above?

[fabrobinet]

We support them now in the converter, though not all of them are in use yet.

[pjcozzi]

I updated the list above to only account for 3D transforms per discussion with @fabrobinet, @tparisi, and @RemiArnaud.

[fabrobinet]

@pjcozzi I think we also need some semantics for vec3.

Use cases are when you need a position, say for a light... The thing we are doing is passing a matrix, but this is a bit overkill and will seem non natural for adopters willing to write their own shaders to generate glTF.

Just taking as an example MODELVIEWMATRIX, if we want the position, could something like MODELVIEWPOSITION as a vec3 be OK ?

I will put this more thoughts asap...

[pjcozzi]

I'm open to hearing out a potential list of additional vec3 semantics. We have to weigh the added spec complexity and implementation burden vs. the potential performance win (e.g., only setting a vec3 uniform instead of a mat4) and syntax win. I think the example above is questionable given that it is most likely a performance hit (an extra uniform compared to the transform matrix) and it is common and trivial for a shader to pull out a column vector, e.g., mat[3].xyz.

[pjcozzi]

• Discuss gl_PointSize support from #85.

[fabrobinet]

For the vec3 semantics, it's orthogonal and not blocking dev-8 so I'll follow-up for dev-9

[pjcozzi]

@tparisi for the draft 1.0 spec, use the following where the spec currently has "Todo: do we need a table here listing all the semantics and their meanings? Or in a reference section since this section is non-normative?":

---

Uniform semantics:

Semantic	Type	Description
LOCAL	FLOAT_MAT4	Transforms from the node's coordinate system to its parents. This is the node's matrix property (or derived matrix from translation, rotation, and scale properties).
MODEL	FLOAT_MAT4	Transforms from model to world coordinates using the transform's node and all of its parents.
VIEW	FLOAT_MAT4	Transforms from world to view coordinates using the active camera node.
PROJECTION	FLOAT_MAT4	Transforms from view to clip coordinates using the active camera node.
MODELVIEW	FLOAT_MAT4	Combined MODEL and VIEW.
MODELVIEWPROJECTION	FLOAT_MAT4	Combined MODEL, VIEW, and PROJECTION.
MODELINVERSE	FLOAT_MAT4	Inverse of MODEL.
VIEWINVERSE	FLOAT_MAT4	Inverse of VIEW.
PROJECTIONINVERSE	FLOAT_MAT4	Inverse of PROJECTION.
MODELVIEWINVERSE	FLOAT_MAT4	Inverse of MODELVIEW.
MODELVIEWPROJECTIONINVERSE	FLOAT_MAT4	Inverse of MODELVIEWPROJECTION.
MODELINVERSETRANSPOSE	FLOAT_MAT3	The inverse-transpose of MODEL without the translation. This translates normals in model coordinates to world coordinates.
MODELVIEWINVERSETRANSPOSE	FLOAT_MAT3	The inverse-transpose of MODELVIEW without the translation. This translates normals in model coordinates to eye coordinates.
VIEWPORT	FLOAT_VEC4	The viewport's x, y, width, and height properties stored in the x, y, z, and w components, respectively. For example, this is used to scale window coordinates to [0, 1]: vec2 v = gl_FragCoord.xy / viewport.zw;

Attribute semantics include POSITION, NORMAL, TEXCOORD, COLOR, JOINT, JOINTMATRIX, and WEIGHT. Attribute semantics can be of the form [semantic]_[set_index], e.g, TEXCOORD_0, TEXCOORD_1, etc.