Technique parameter questions #239

pjcozzi · 2014-02-25T20:30:30Z

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

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.

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"
                }

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

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

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)

The text was updated successfully, but these errors were encountered:

RemiArnaud · 2014-02-26T06:51:31Z

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

On Tue, Feb 25, 2014 at 12:30 PM, Patrick Cozzi notifications@gitpro.ttaallkk.topwrote:

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

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.

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"
            }
Should we rename source to node? Or will this property reference other
types?
            "lightTransform": {
                "source": "directional_light_node_id",
                "type": 35676
            }
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 · 2014-02-26T07:08:22Z

My suggestions:

yes value depends on type, we keep things as they are.
type is required
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)
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 · 2014-03-06T18:03:47Z

OK
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?
OK

pjcozzi · 2014-03-10T20:44:04Z

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

tparisi · 2014-03-10T20:47:37Z

+1 @pjcozzi on 3.a.

fabrobinet · 2014-03-10T20:58:16Z

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 · 2014-03-10T21:10:51Z

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 · 2014-03-10T23:07:04Z

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 · 2014-03-11T14:56:08Z

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 · 2014-03-11T15:04:44Z

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 · 2014-03-11T16:47:19Z

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 · 2015-09-17T20:01:35Z

@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 · 2015-09-17T20:03:39Z

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

tparisi · 2015-09-17T20:06:54Z

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 · 2015-09-17T20:12:01Z

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 · 2015-09-17T20:14:18Z

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

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

tparisi · 2015-09-17T20:15:40Z

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 · 2015-09-17T20:30:23Z

Sounds good.

tparisi · 2015-09-22T14:41:54Z

Changed source->node in d84a366.

pjcozzi · 2015-09-23T22:40:45Z

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

pjcozzi · 2015-10-01T14:51:19Z

@tfili is the converter updated?

tfili · 2015-10-01T15:57:58Z

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

pjcozzi · 2015-10-01T16:37:45Z

Nice.

pjcozzi added the specification label Feb 25, 2014

pjcozzi mentioned this issue Mar 6, 2014

Schema updates #241

Closed

10 tasks

pjcozzi added converter and removed specification labels Mar 11, 2014

pjcozzi added this to the Converter 1.0 milestone Apr 30, 2014

pjcozzi added the draft 1.0 label Aug 27, 2015

pjcozzi removed this from the Converter 1.0 milestone Aug 27, 2015

pjcozzi closed this as completed Oct 1, 2015

pjcozzi mentioned this issue Oct 10, 2015

glTF 0.8 to 1.0 Guide #406

Closed

lexaknyazev mentioned this issue Apr 17, 2016

Thoughts on tightening up the spec #563

Closed

20 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Technique parameter questions #239

Technique parameter questions #239

pjcozzi commented Feb 25, 2014

RemiArnaud commented Feb 26, 2014

fabrobinet commented Feb 26, 2014

pjcozzi commented Mar 6, 2014

pjcozzi commented Mar 10, 2014

tparisi commented Mar 10, 2014

fabrobinet commented Mar 10, 2014

pjcozzi commented Mar 10, 2014

fabrobinet commented Mar 10, 2014

pjcozzi commented Mar 11, 2014

fabrobinet commented Mar 11, 2014

pjcozzi commented Mar 11, 2014

pjcozzi commented Sep 17, 2015

tparisi commented Sep 17, 2015

tparisi commented Sep 17, 2015

pjcozzi commented Sep 17, 2015

tparisi commented Sep 17, 2015

tparisi commented Sep 17, 2015

pjcozzi commented Sep 17, 2015

tparisi commented Sep 22, 2015

pjcozzi commented Sep 23, 2015

pjcozzi commented Oct 1, 2015

tfili commented Oct 1, 2015

pjcozzi commented Oct 1, 2015

Technique parameter questions #239

Technique parameter questions #239

Comments

pjcozzi commented Feb 25, 2014

RemiArnaud commented Feb 26, 2014

fabrobinet commented Feb 26, 2014

pjcozzi commented Mar 6, 2014

pjcozzi commented Mar 10, 2014

tparisi commented Mar 10, 2014

fabrobinet commented Mar 10, 2014

pjcozzi commented Mar 10, 2014

fabrobinet commented Mar 10, 2014

pjcozzi commented Mar 11, 2014

fabrobinet commented Mar 11, 2014

pjcozzi commented Mar 11, 2014

pjcozzi commented Sep 17, 2015

tparisi commented Sep 17, 2015

tparisi commented Sep 17, 2015

pjcozzi commented Sep 17, 2015

tparisi commented Sep 17, 2015

tparisi commented Sep 17, 2015

pjcozzi commented Sep 17, 2015

tparisi commented Sep 22, 2015

pjcozzi commented Sep 23, 2015

pjcozzi commented Oct 1, 2015

tfili commented Oct 1, 2015

pjcozzi commented Oct 1, 2015