WORLDVIEWINVERSETRANSPOSE

[RemiArnaud]

This should be a mat4x4. But the shader in duck.json is using this as a mat3x3
what the shader really want is a 3x3 subset of this matrix, a.k.a. the NORMAL matrix.

So, either:

• each standard matrix can be used as 3x3 or 4x4 based on the type. This makes the code difficult
• a NORMAL matrix should be used to be 3x3 matrix
• the shader uses WORLDVIEWINVERSETRANSPOSE as a mat4x4

which one should it be?

[fabrobinet]

@RemiArnaud I don't find my notes about this :( , do you remember if we reach approval on this, and what was the decision ?
I remember to have brought the 2D use case, and we should be able to support pure 2D assets and thus be flexible about the types.(i.e just specify the semantic and adapt to the type declared in the shader.)

[pjcozzi]

Since this is used to transform normals, which do not use translation, I would use a 3x3. This is also what OpenGL/GLSL used when it was part of the API: uniform mat3 gl_NormalMatrix. See Section 7.5 of the GLSL 1.2 Spec.

For the most frictionless client-side implementation, I would like to see the type be known from the semantic.

As for 2D, perhaps we can introduce new semantics, e.g., NORMAL2D, WORLDVIEW2D`, etc. Many engines will just ignore them.

[RemiArnaud]

I don't mind what we do exactly, just that we need to be crystal clear about it. In particular, if matrices are going to have different type base on what they are applied to, then I will ask that the matrix type is backed in the name of ALL semantics. (for example: WORLDVIEW4D, WORLDVIEWINVERSETRANSPOSE3D ...)

[fabrobinet]

@RemiArnaud @pjcozzi yes we need to be consistent.

So I suggest we don't create more semantics to include the type, like WORLDVIEWINVERSETRANSPOSE3 vs just WORLDVIEWINVERSETRANSPOSE

There is enough possible combinations without the type already and the type will be in the parameter anyway.

And as an aside, without introducing yet another "normal matrix" for WORLDVIEWINVERSETRANSPOSE, we can't just use WORLDVIEWINVERSETRANSPOSE and specify that it would be 3x3. The usage of the normal matrix is specific and specifying a type (which will be here anyway), turn this WORLDVIEWINVERSETRANSPOSE into 3x3 , i.e the way we want in generic way.

[RemiArnaud]

I don't agree this is clear enough to say that the type is provided elsewhere.
Here's why it is a probem:

The application has to be prepared to handle all possible combinations of semantic and type. If I am going to only see 3x3 matrices for some semantic and 4x4 matrices for others, then I don't understand why we make the loadr check all possible combinations

Also. If we go this route, we need the spec to specify exacly what the application has to do when there is a type mismatch... A lot of work for a rigourous spec, a lot o possible implementation mistakes, that we can very simply avoid

[fabrobinet]

@RemiArnaud

• engines need to adapt to all types anyway for parameters that would have no semantic associated.
• If an engine just support FLOAT_MAT4 then we could have a converter option to force all matrices be FLOAT_MAT4.

If we cannot reach agreement about this, for further study and understanding could you propose a complete solution that covers both the 2D and 3D cases for all semantics ?

[pjcozzi]

Most engines will already have many of these semantic matrices built-in. For example, my engine has the PROJECTION built-in as a FLOAT_MAT4. If the semantic said it was a FLOAT_MAT2, I would have no idea what to do with it. Given the semantic (meaning) of a projection matrix, I'm not sure that FLOAT_MAT2 ever makes sense.

Can't each semantic have a list of possible types in the spec, e.g., WORLD, would allows either FLOAT_MAT4 or FLOAT_MAT3? This is easy to validate and easy for the client. @fabrobinet is this what you are already suggesting?

[fabrobinet]

@pjcozzi yes, this is what I suggest. And I suggest also eventually the converter can help by forcing types for some semantics if it fits better one destination engine. We could specify indeed that some edge cases may not be vkid like FLOAT_MAT2 for projection, but WORLD could be FLOAT_MAT2 too.

[pjcozzi]

but WORLD could be FLOAT_MAT2 too.

I'm not sure when this would happen. For 2D, this allows just rotation, not translation. If an app is doing something that specific, it can use a non-semantic matrix.

[fabrobinet]

@pjcozzi true.

[fabrobinet]

@pjcozzi @RemiArnaud @tparisi
Patrick and I reached agreement to specify for each semantic the supported types. The converter will convert to the most common ones (FLOAT_MAT4 for WORLD, FLOAT_MAT3 for WORLDVIEWINVERSETRANSPOSE). A JSON file could be associated to the converter to even profile more for the destination engine and thus this could be also negociated through Rest3D API.

@RemiArnaud would this work for you ?

[RemiArnaud]

Yes, exactly my point - there is only a small subset that we should allow/expose.

So I don't understand why we need a separate semantic and type. The semantic name should make it really clear on its own what the type is, and the separate type information should be removed.

Otherwise we need to spend time documenting all the possible combinasons, and I don't expect many developers to read the spec

Even more important, a google seach for WORLDVIEWINVERSETRANSPOSE will show that it is a Mat4x4 in most cases.

-----Original Message-----
From: Patrick Cozzi notifications@github.com
Date: Wed, 05 Jun 2013 10:12:13
To: KhronosGroup/glTFglTF@noreply.github.com
Reply-To: KhronosGroup/glTF reply@reply.github.com
Cc: Rémi Arnaudremi@acm.org
Subject: Re: [glTF] WORLDVIEWINVERSETRANSPOSE (#89)

Most engines will already have many of these semantic matrices built-in. For example, my engine has the PROJECTION built-in as a FLOAT_MAT4. If the semantic said it was a FLOAT_MAT2, I would have no idea what to do with it. Given the semantic (meaning) of a projection matrix, I'm not sure that FLOAT_MAT2 ever makes sense.

Can't each semantic have a list of possible types in the spec, e.g., WORLD, would allows either FLOAT_MAT4 or FLOAT_MAT3? This is easy to validate and easy for the client. @fabrobinet is this what you are already suggesting?

---

Reply to this email directly or view it on GitHub:
#89 (comment)

[fabrobinet]

@RemiArnaud the type will be there for parameters without semantic anyway. So adding type in the semantic name would be redundant.
And as you say even WORLDVIEWINVERSETRANSPOSE might be mat4 but we can make it a mat3 to handle the normal matrix.

[RemiArnaud]

"WORLDVIEWINVERSETRANSPOSE might be mat4 we can make it a mat3"

That's the part I have trouble with. Why adding that level of complexity?

[fabrobinet]

Exactly the same thing for WORLD which can be mat3 or mat4.
If I write a 2D game like Angry Birds, I don't want to support mat4 in my engine.
GL that is our target is generic and can be used either for 2D or 3D.

[fabrobinet]

And it's not like if it was interexchange format, you can use a converter (even if through Rest3D) so that you could force semantic that matches your destination engine.

[RemiArnaud]

Back to my original question. What are the list of valid combinations? Should the application be ready to handle all possible combinasons of types for each semantic? How is this helpful?
Why not making it clear by simply looking at the semantic name what we are dealing with? In that case the list of possible combinasons is very clear.

[fabrobinet]

Back to my original question. What are the list of valid combinations?

It's still to be done, but we need to agree on the principle starting with WORLDVIEWINVERSETRANSPOSE and WORLD the proposal is to have then MAT3 or MAT4

Should the application be ready to handle all possible combinasons of types for each semantic?

No, but converters yes, so that it is easy to handle for engines.

How is this helpful?

I explained above with the example of 2D and Angry Birds.

Why not making it clear by simply looking at the semantic name what we are dealing with? In that case the list of > possible combinasons is very clear.

Because having both WORLDVIEWINVERSETRANSPOSE3 and WORLDVIEWINVERSETRANSPOSE4

• is redundant with the type that will be in the parameter.
• multiplies the number of specified semantics which is already big.

[fabrobinet]

During our meeting, Remi and I agreed on the proposal of having semantic not carrying the type in its name and use the type that is on the parameter. We will have to specify for each semantic what are the supported types. The converter will have to support multiple possible type, so that the output fits well different destination engines.

Consequently specification work / implementation should continue on this issue: #83 and we can close this one.