Technique parameter questions

[pjcozzi]

I'm writing the schema for techniques and want to confirm several things:

1. values is either a scalar or an array, depending on type, e.g.,

                "light0Color": {
                    "type": 35665,
                    "value": [1, 1, 1]
                },

I want to confirm that we prefer this over making value an array of size one for scalar values. What we have now makes the spec slightly more complicated, but it is slightly better code-wise for my implementation.

2. Do we want (a) type to always be required, or (b) type to be optional if semantic is provided and have a sensible default. For example:

(a) Required:

                "modelViewMatrix": {
                    "semantic": "MODELVIEW",
                    "type": 35676
                }

(b) Optional:

                "modelViewMatrix": {
                    "semantic": "MODELVIEW"
                }

3. Should we rename source to node? Or will this property reference other types?

                "lightTransform": {
                    "source": "directional_light_node_id",
                    "type": 35676
                }

4. We have a list of semantics for uniforms (#83), but what are the semantics for attributes. So far, I know of:

• JOINT
• JOINT_MATRIX
• WEIGHT
• POSITION
• NORMAL
• TEXCOORD_0 (and others I suspect)

[RemiArnaud]

(2) I'd shy away from making type optional.

On Tue, Feb 25, 2014 at 12:30 PM, Patrick Cozzi [email protected]:

I'm writing the schema for techniques and want to confirm several things:

1. values is either a scalar or an array, depending on type, e.g.,

            "light0Color": {
                "type": 35665,
                "value": [1, 1, 1]
            },

I want to confirm that we prefer this over making value an array of size
one for scalar values. What we have now makes the spec slightly more
complicated, but it is slightly better code-wise for my implementation.

2. Do we want (a) type to always be required, or (b) type to be optional
   if semantic is provided and have a sensible default. For example:

(a) Required:

            "modelViewMatrix": {
                "semantic": "MODELVIEW",
                "type": 35676
            }

(b) Optional:

            "modelViewMatrix": {
                "semantic": "MODELVIEW"
            }

3. Should we rename source to node? Or will this property reference other
   types?

            "lightTransform": {
                "source": "directional_light_node_id",
                "type": 35676
            }

4. We have a list of semantics for uniforms (default uniforms semantic need to be added to the spec #83default uniforms semantic need to be added to the spec #83 (comment)),
   but what are the semantics for attributes. So far, I know of:

• JOINT
• JOINT_MATRIX
• WEIGHT
• POSITION
• NORMAL
• TEXCOORD_0 (and others I suspect)

Reply to this email directly or view it on GitHubhttps://github.com//issues/239
.

[fabrobinet]

My suggestions:

1. yes value depends on type, we keep things as they are.
2. type is required
3. I used source to be symmetrical with animations where target is used so we have source for reading operations and target for write. also note light here is incomplete there should a semantic, should be fixed in converter with Light Semantics #93 (comment)
4. There is COLOR to for vertex colors and I would not include _0 in any of these but explain the rule that semantic may have multiple sets and we represent them as [semantic]_[set_index]
   It's also worth mentioning that semantics are proposed to allow details to be use to regerenate shaders, but a glTF file could be valid with totally different semantic as long as the sementics in mesh attributes are consistent with the ones in techniques.

[pjcozzi]

1. OK
2. OK
   3.a) Do you think it is more important to be consistent with animations or more important to be consistent with other parts of the spec, e.g., accessor.bufferView -> bufferView, bufferView.buffer -> buffer, node.meshes -> mesh, etc. I would rather be consistent with the other parts.
   3.b) What is the semantic (or semantics) for a light? Just LIGHT?
3. OK

[pjcozzi]

@fabrobinet what are your thoughts on 3.a and 3.b?

[tparisi]

+1 @pjcozzi on 3.a.

[fabrobinet]

3.a Source is good to not have to worry about potential other places in the future where we would get a transform of a light from, but have node is more straightfoward... so both solutions have pros and cons...
I have a preference for source but if you, @tparisi or @RemiArnaud prefer node I could live with that.
3.b. That's to specify the kind of transform you get from the source , could be MODELVIEWMATRIX ...

[pjcozzi]

3.a) I prefer node. I am open to source if we have strong potential use cases, but I don't see any right now and would rather have the best possible glTF 1.0.

3.b) I'm confused here. Why is semantic needed for light transforms? What will the app do with the semantic if the transform matrix is coming from the node as opposed to something built into the engine, e.g., MODELVIEWMATRIX?

[fabrobinet]

3.a) ok for node.
3.b) I am not sure to understand the confusion. If there is no semantic, how can your data driven engine know (without making hard coded assumption) that for a given node (typically, the one the node is attached) you want to use its MODELVIEWMATRIX or any other kind of transform...
You can think of this problem more generically, for any matrix in the shader, you want to use the matrix of a given node + a given type of transformation, who knows what people want to do in their shaders...

Also, since this is all generic, I believe we may not need light types, they are useless as the rendering is driven by the shaders, though, in details having them could be handy.

[pjcozzi]

3.a) Schema is updated. bbc3ad6

3.b) My current implementation is if there is a semantic, I use it; otherwise, if there is a source (now node), I use its transform (multiplied with transforms to its root). Sounds like this is wrong. Instead, when source is present, the semantic is used to determine exactly what matrix to construct from the source, e.g., just model transforms, model-view, etc. Is this right? If so, two questions:

• The duck model doesn't have a semantic for its light parameter. Shouldn't we require semantic if source is present? Or in this case, semantic could default to MODEL.
• When semantic is used for a source, not all semantics should be allowed, e.g., no PROJECTION semantics.

[fabrobinet]

3.b) Yes, that's the matrix from the source .. now node that you want to use.

• it is a flaw in the converter, a semantic should be there, but this issue was identified soon and discussed in the issue tracking lights. Default should be MODELVIEW IMO.
• I thought about it, and I believe adding a type for lights is a bad idea, it'd like this to be generic and consequently there would be no way for validating this sort of thing, and I don't think it is a bad thing. I don't want us to sort of reintroduce a fixed pipeline with old-school lighting models. We will support them as coming from COLLADA, but only as parameters and very generically, I will update the light proposal to make this clearer.

[pjcozzi]

Let's do the proposal in #93. I think I am on board with it, but let me see the details first.

Labeling this as converter just to rename source to node.

[pjcozzi]

@tfili we can close this issue once we rename a technique parameter's source to node in the converter. The 0.8 schema already has this update, but Cesium is looking for source so I suspect the converter is not updated.

[tparisi]

Sorry I'm lost on this one. It's currently source why not just keep that?

[tparisi]

And in fact, if we want to start dealing with issues I brought up r/e a light's direction #409 then we could in fact use a target attribute similar to animation channels. e.g.

                "light0Direction": {
                    "source": "directionalLight1",
                    "target": "direction",
                    "type": 35665
                },

[pjcozzi]

We decided on node above because it is consistent with glTF, when we reference something by id, we use the type as the name: bufferViews have a buffer property, accessors have a bufferView property, etc.

However, I am happy to pause on this rename until lights are solid.

[tparisi]

Actually I meant path but I wrote target so it should be

                "light0Direction": {
                    "source": "directionalLight1",
                    "path": "direction",
                    "type": 35665
                },

[tparisi]

But it could be node just as well as source; I get your consistency argument and it is more explicit.

So I say go for it. LMK when the converter change is made. I also need converted models for the Three.js loader to test it.

[pjcozzi]

Sounds good.

[tparisi]

Changed source->node in d84a366.

[pjcozzi]

Thanks @tparisi. @tfili this just needs a converter update for us to close it.

[pjcozzi]

@tfili is the converter updated?

[tfili]

The source->node change is in dev-1.0 branch.

[pjcozzi]

Nice.