Improving design of materials, parameters...

[fabrobinet]

Because some bugs are too tied to be answered in detail separately,
I have created this umbrella bug to recap decision for the following bugs:
#82
#79

We will start by answering #82 so we see how parameters are specified and can be overrided at the material level.
That's the first step of this proposal, and it's in this current comment.

Then, in a following comment we'll describe #79 to propose override at the mesh level and also introduce meshInstance.

This proposal is not yet implemented but I plan to update the converter soon.
It should be recap of discussions especially recent ones with Remi.
Tony and Patrick, please let me know if anything needs to be clarified.

Currently we have for example, taking material.2 below, we will override the parameter ambient

To specify a parameter value, we currently have :

    "material.2": {
    "name": "Wood_Cherry_Original_",
        "technique": "technique1",
        "techniques": {
        "technique1": {
            "parameters": {
                "ambient": {
                    "type": "FLOAT_VEC3",
                        "value": [
                        0.2,
                        0.2,
                        0.2
                    ]
                }
            }
        }
    }
},

And in techniques , we have the techniques, that contains passes with program.
Program contains attributes and uniforms.
Note: we should probably have a top property programs with program inside, so that we can explicitly share them and not only via techniques.
This is discussed/proposed later in this issue.

"technique1": {
    "pass": "defaultPass",
        "passes": {
        "defaultPass": {
            "program": {
                "FRAGMENT_SHADER": "technique1Fs",
                    "VERTEX_SHADER": "technique1Vs",
                    "attributes": [
                    {
                        "semantic": "NORMAL",
                        "symbol": "a_normal",
                        "type": "FLOAT_VEC3"
                    },
                    {
                        "semantic": "POSITION",
                        "symbol": "a_position",
                        "type": "FLOAT_VEC3"
                    },
                    {
                        "semantic": "TEXCOORD_0",
                        "symbol": "a_texcoord0",
                        "type": "FLOAT_VEC2"
                    }
                ],
                    "uniforms": [
                    {
                        "semantic": "WORLDVIEWINVERSETRANSPOSE",
                        "symbol": "u_normalMatrix",
                        "type": "FLOAT_MAT3"
                    },
                    {
                        "semantic": "WORLDVIEW",
                        "symbol": "u_worldviewMatrix",
                        "type": "FLOAT_MAT4"
                    },
                    {
                        "semantic": "PROJECTION",
                        "symbol": "u_projectionMatrix",
                        "type": "FLOAT_MAT4"
                    },
                    {
                        "parameter": "diffuse",
                        "symbol": "u_diffuseTexture",
                        "type": "SAMPLER_2D"
                    }
                ]
            },
            "states": {
                "blendEnable": false,
                    "cullFaceEnable": true,
                    "depthMask": true,
                    "depthTestEnable": true
            }
        }
    }
},

That worked ok far, but it has some issues:

• in attributes/uniform you could get either a semantic or a parameter, not both.
  This had the side effect of preventing the override attributes set (like UVs, as it is specified with semantic).
• It is not obvious, what the path to animate a parameter would be.
  The reason was to make specific parameters for each techniques, but not doing so is not bad since it allows to share parameters when possible.

As shown below, by moving up the parameters in material, the path for animation becomes more apparent.
For instance in this example an animation would specify in its channel the following target to animate ambient in a material:
target: { "id" : "material.2" , "path" : "ambient" }.
Note 1: we thought about renamed "parameters" to "override" but it was before agreeing that parameters should appear explicitly in techniques (because parameters should be shared between passes).
Note 2: To prevent useless writing, parameters is excluded from the path, because for materials, a target is always a parameter.

So the above example becomes (simpler) now:

"material.2": {
    "name": "Wood_Cherry_Original_",
        "technique": "technique1",
        "parameters": {
        "ambient": {
            "type": "FLOAT_VEC3",
                "value": [
                0.2,
                0.2,
                0.2
            ]
        }
    }
},

In programs now every attribute - even those associated with a semantic - have a parameter that may set a value.
At the technique level, you can set default values for parameters.
The proposal, is an intermediate step:

"technique1": {
    "parameters" : {
        "attribute0" : {
            "semantic": "NORMAL",
                "type": "FLOAT_VEC3"
        },
        "attribute1" : {
            "semantic": "POSITION",
                "type": "FLOAT_VEC3"
        },
        "ambient": {
            "value" : [0, 0, 0],
                "type": "FLOAT_VEC3"
        },
        "uniform0":  {
            "semantic": "WORLDVIEWINVERSETRANSPOSE",
                "type": "FLOAT_MAT3"
        },
        "uniform1" :  {
            "semantic": "WORLDVIEW",
                "type": "FLOAT_MAT4"
        },
        "uniform2" :  {
            "semantic": "PROJECTION",
                "type": "FLOAT_MAT4"
        },
    },

    "pass": "defaultPass",
        "passes": {
        "defaultPass": {
            "program": {
                "FRAGMENT_SHADER": "technique1Fs",
                    "VERTEX_SHADER": "technique1Vs",
                    "attributes": [
                    {
                        "parameter" : "attribute0",
                        "symbol": "a_normal",
                    },
                    {
                        "parameter" : "attribute1",
                        "symbol": "a_position",
                    },
                ],
                    "uniforms": [
                    {
                        "parameter" : "uniform0",
                        "symbol": "u_normalMatrix",
                    },
                    {
                        "parameter" : "uniform1",
                        "symbol": "u_worldviewMatrix",
                    },
                    {
                        "parameter" : "uniform2",
                        "symbol": "u_projectionMatrix",
                    },
                    {
                        "parameter": "ambient",
                        "symbol": "u_ambient",
                    }
                ]
            },
            "states": {
                "blendEnable": false,
                    "cullFaceEnable": true,
                    "depthMask": true,
                    "depthTestEnable": true
            }
        }
    }
}

From the step above, we can simplify the pass object (parameters, stays unchanged) by :

• moving program declaration out of passes, and just referencing to program
• using a map for symbols binding from symbol to program parameters. This map doesn't need to be split between attributes and uniforms.

"technique1": {
    "parameters" : {
        [.... as above]
    },

    "pass": "defaultPass",
        "passes": {
        "defaultPass": {
            "program" : "program1"
            "symbols" : {
                "a_normal" : "attribute0",
                    "a_position" : "attribute1",
                    "u_normalMatrix" : "uniform0",
                    "u_worldviewMatrix" : "uniform1",
                    "u_projectionMatrix" : "uniform2",
                    "u_ambient" : "u_ambient",
            },
            "states": {
                "blendEnable": false,
                    "cullFaceEnable": true,
                    "depthMask": true,
                    "depthTestEnable": true
            }
        }
    }
},

[pjcozzi]

@fabrobinet thanks for taking the time to write this up.

• Why is symbols part of the pass and not the program? When will the same program have different symbols?
• Why is semantic part of parameter? shouldn't it be part of program? When will it vary for the same input for the same program?
• Why does parameter in material need a type? Isn't the type known as part of the program? Why redefine it for all materials?
• We might have discussed this before, but why are attributes and uniforms grouped together? Isn't this harder for the client? GL treats them separately.

Note: we should probably have a top property programs with program inside, so that we can explicitly share them and not only via techniques.

OK with me.

FRAGMENT_SHADER and VERTEX_SHADER

Although I proposed these names at one point to match WebGL calls, they are too inconsistent with other glTF names, I suggest going back to fragmentShader and vertexShader.

        "states": {
            "blendEnable": false,
                "cullFaceEnable": true,
                "depthMask": true,
                "depthTestEnable": true
        }

This doesn't match the work we've done so far, but I suppose that is not important for this discussion.

[fabrobinet]

@pjcozzi : good feedback.!

• Why is symbols part of the pass and not the program?
  -> Good question: that's too to be aligned with the pattern used in materials to override parameters.
  We cannot define program here, just refer to it, so if we want something more self contained, we would need a new object, like "instanceProgram" such as { program: program1 , symbols: {} } , this might be clearer, but I didn't find it necessary, what do you think ? If we do such change here, we should also reflect in material for parameters.
• When will the same program have different symbols?
  -> Never, but it may have different parameters binded to these symbols, that's why we need this mapping.
• Why is semantic part of parameter? shouldn't it be part of program? When will it vary for the same input for the same program?
  -> This way you can override the parameter of say a UV by another by just changing the semantic.

Why does parameter in material need a type? Isn't the type known as part of the program? Why redefine it for all materials?
-> I am still not sure about this one, but I thought about offscreen rendering and the fact that we need to create textures for it and parameters, and for them the type has to be specified because it couldn't be inferred from a shader (as it exists only for the pass). And thus to make everything consistent I have let the types.
I also believe it is handy for the ones who want to instanciate a UI for shader parameters wihtout having to compile the shader to figure what the types are.
This is an open question to me. I would answer better with multi-pass in place for the reason mentioned above.

We might have discussed this before, but why are attributes and uniforms grouped together? Isn't this harder for the client? GL treats them separately.
-> this change was just introduced in this proposal, that's because the type can be inferred from the program. And that is actually more in line with your suggestion of not redefining the type. So we need to rework this and be consistent.

[tparisi]

Hi Fab

Ready to get on the call. Can you point to the latest proposal for all
this, one place? I got all confused with the back and forth...

On Thu, May 30, 2013 at 1:53 PM, Fabrice Robinet
[email protected]:

@pjcozzi https://github.com/pjcozzi : good feedback.!

Why is symbols part of the pass and not the program?
-> Good question: that's too to be aligned with the pattern used in
materials to override parameters.
We cannot define program here, just refer to it, so if we want
something more self contained, we would need a new object, like
"instanceProgram" such as { program: program1 , symbols: {} } , this might
be clearer, but I didn't find it necessary, what do you think ? If we do
such change here, we should also reflect in material for parameters.

When will the same program have different symbols?
-> Never, but it may have different parameters binded to these
symbols, that's why we need this mapping.

Why is semantic part of parameter? shouldn't it be part of program?
When will it vary for the same input for the same program?
-> This way you can override the parameter of say a UV by another by
just changing the semantic.

Why does parameter in material need a type? Isn't the type known as part
of the program? Why redefine it for all materials?
-> I am still not sure about this one, but I thought about offscreen
rendering and the fact that we need to create textures for it and
parameters, and for them the type has to be specified because it couldn't
be inferred from a shader (as it exists only for the pass). And thus to
make everything consistent I have let the types.
I also believe it is handy for the ones who want to instanciate a UI for
shader parameters wihtout having to compile the shader to figure what the
types are.
This is an open question to me. I would answer better with multi-pass in
place for the reason mentioned above.

We might have discussed this before, but why are attributes and uniforms
grouped together? Isn't this harder for the client? GL treats them
separately.
-> this change was just introduced in this proposal, that's because the
type can be inferred from the program. And that is actually more in line
with your suggestion of not redefining the type. So we need to rework this
and be consistent.

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

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]

We are currently brainstorming, there will be a new proposal based on discussion

[tparisi]

Simplified material syntax:

"material.2": {
"name": "Wood_Cherry_Original_",
"technique": "technique1",
"parameters": {
"ambient": [
0.2,
0.2,
0.2
]
}
}

On Thu, May 30, 2013 at 2:03 PM, Fabrice Robinet
[email protected]:

We are currently brainstorming, there will be a new proposal based on
discussion

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

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]

ok.

[fabrobinet]

@pjcozzi about symbols... we can arrange in a more explicit way.
I was saying it is not necessary to split attribute and uniforms, but - as you said - it's not same GL functions being used to set them, so we could get this instead to make implemention easier.

"pass": "defaultPass",
    "passes": {
    "defaultPass": {
        "program" : "program1"
        "attributes" : {
            "a_normal" : "attribute0",
                "a_position" : "attribute1"
        },
        "uniforms" : {
                "u_worldviewMatrix" : "uniform1",
                "u_projectionMatrix" : "uniform2",
                "u_ambient" : "ambient"
        },
        "states": {
            "blendEnable": false,
                "cullFaceEnable": true,
                "depthMask": true,
                "depthTestEnable": true
        }
    }
}

[RemiArnaud]

Should uniforms/attributes have types?

On Thu, May 30, 2013 at 5:33 PM, Fabrice Robinet
[email protected]:

@pjcozzi https://github.com/pjcozzi about symbols... we can arrange in
a more explicit way.
I was saying it is not necessary to split attribute and uniforms, but - as
you said - it's not same GL functions being used to set them, so we could
get this instead to make implemention easier.

"pass": "defaultPass",
"passes": {
"defaultPass": {
"program" : "program1"
"attributes" : {
"a_normal" : "attribute0",
"a_position" : "attribute1"
},
"uniforms" : {
"u_worldviewMatrix" : "uniform1",
"u_projectionMatrix" : "uniform2",
"u_ambient" : "ambient"
},
"states": {
"blendEnable": false,
"cullFaceEnable": true,
"depthMask": true,
"depthTestEnable": true
}
}
}

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

[fabrobinet]

I would say, due to the redesign above, the question should be "Should parameters have types".
The uniforms / attributes above just refer to parameters.
During the call we agreed that in techniques only parameters should have attributes, this were they are declared.

• it is handy, so that developers don't have to figure the types, usefull for UIs. It (by making a shader compilation during loading time, which may be not practical).
• For offscreen rendering, the destination texture is not part of any progrom and so parameter will need type. More about that to follow.

[pjcozzi]

@fabrobinet your separation of attributes and uniforms above is OK. I'll look forward to a full example of your next revision for additional feedback.

[pjcozzi]

@fabrobinet any update here?

[fabrobinet]

@pjcozzi I have been thinking quite a lot about this... I'll try to write the update today.

[fabrobinet]

Starting by just summing up what was agreed so far we have in material (but not yet implemented),
we have the following JSON proposal:

"material.2":  { 
        "name" : "wood"
    "technique": "technique1", 
    "parameters":  { 
        "ambient": [ 0.2, 0.2, 0.2 ] 
    }
 }

and in techniques:

"techniques" {
    "technique1": {

        "parameters" : {
            "attribute0" : {
                "semantic": "NORMAL",
                    "type": "FLOAT_VEC3"
            },
            "attribute1" : {
                "semantic": "POSITION",
                    "type": "FLOAT_VEC3"
            },
            "ambient": {
                "value" : [0, 0, 0],
                    "type": "FLOAT_VEC3"
            },
            "uniform1" :  {
                "semantic": "WORLDVIEW",
                    "type": "FLOAT_MAT4"
            },
            "uniform2" :  {
                "semantic": "PROJECTION",
                    "type": "FLOAT_MAT4"
            },
        },


        "pass": "defaultPass",
            "passes": {
            "defaultPass": {
                "program" : "program1"
                "attributes" : {
                    "a_normal" : "attribute0",
                        "a_position" : "attribute1"
                },
                "uniforms" : {
                    "u_worldviewMatrix" : "uniform1",
                        "u_projectionMatrix" : "uniform2",
                        "u_ambient" : "ambient"
                },
                "states": {
                    "blendEnable": false,
                        "cullFaceEnable": true,
                        "depthMask": true,
                        "depthTestEnable": true
                }
            }
        }
    }
}

So, regarding parameters, we could stop there.
But there is still something a little bit annoying…

Uniforms and attributes would be better encapsulated together with program.
So, Instead of being directly in the pass.
It would look be cleaner to have instead (in the pass):

"defaultPass": {
    "program" : {
        "id": "program1",
        "attributes" : {
            "a_normal" : "attribute0",
            "a_position" : "attribute1",
        },
        "uniforms" : {
            "u_worldviewMatrix" : "uniform1",
            "u_projectionMatrix" : "uniform2",
            "u_ambient" : "ambient"
        }
    },
    "states": {
        "blendEnable": false,
        "cullFaceEnable": true,
        "depthMask": true,
        "depthTestEnable": true
    }
}

This said, the program definition as in programs is

"programs" : {
    "program1" : {
        "FRAGMENT_SHADER": "shaderFs1",
            "VERTEX_SHADER": "shaderFs2",
    }
}

So, program in pass would be inconsistent with it.

I propose to introduce useProgram here, it matches "glUseProgram" in GL APIs.

it would give us.

"defaultPass": {
    "useProgram" : {
        "program": "program1",
        "attributes" : {
            "a_normal" : "attribute0",
            "a_position" : "attribute1",
        },
        "uniforms" : {
            "u_worldviewMatrix" : "uniform1",
            "u_projectionMatrix" : "uniform2",
            "u_ambient" : "ambient"
        }
    },
    "states": {
        "blendEnable": false,
        "cullFaceEnable": true,
        "depthMask": true,
        "depthTestEnable": true
    }
}

or we can take the COLLADA approach and use the instance concept and have instead.

"defaultPass": {
    "instanceProgram" : {
        "program": "program1",
        "attributes" : {
            "a_normal" : "attribute0",
            "a_position" : "attribute1",
        },
        "uniforms" : {
            "u_worldviewMatrix" : "uniform1",
            "u_projectionMatrix" : "uniform2",
            "u_ambient" : "ambient"
        }
    },
    "states": {
        "blendEnable": false,
        "cullFaceEnable": true,
        "depthMask": true,
        "depthTestEnable": true
    }
}

@tparisi @RemiArnaud @pjcozzi
I have more to propose, but let's check what you think at this point.
Thanks for your feedback.

[tparisi]

I like instanceProgram

All of our instancing naming conventions should follow that e.g.
instanceMesh

Tony

On Tue, Jun 4, 2013 at 3:01 PM, Fabrice Robinet [email protected]:

Starting by just summing up what was agreed so far we have in material
(but not yet implemented),
we have the following JSON proposal:

"material.2": {
"name" : "wood"
"technique": "technique1",
"parameters": {
"ambient": [ 0.2, 0.2, 0.2 ]
}
}

and in techniques:

"techniques" {
"technique1": {

    "parameters" : {
        "attribute0" : {
            "semantic": "NORMAL",
                "type": "FLOAT_VEC3"
        },
        "attribute1" : {
            "semantic": "POSITION",
                "type": "FLOAT_VEC3"
        },
        "ambient": {
            "value" : [0, 0, 0],
                "type": "FLOAT_VEC3"
        },
        "uniform1" :  {
            "semantic": "WORLDVIEW",
                "type": "FLOAT_MAT4"
        },
        "uniform2" :  {
            "semantic": "PROJECTION",
                "type": "FLOAT_MAT4"
        },
    },


    "pass": "defaultPass",
        "passes": {
        "defaultPass": {
            "program" : "program1"
            "attributes" : {
                "a_normal" : "attribute0",
                    "a_position" : "attribute1"
            },
            "uniforms" : {
                "u_worldviewMatrix" : "uniform1",
                    "u_projectionMatrix" : "uniform2",
                    "u_ambient" : "ambient"
            },
            "states": {
                "blendEnable": false,
                    "cullFaceEnable": true,
                    "depthMask": true,
                    "depthTestEnable": true
            }
        }
    }
}

}

So, regarding parameters, we could stop there.
But there is still something a little bit annoying…

Uniforms and attributes would be better encapsulated together with
program.
So, Instead of being directly in the pass.
It would look be cleaner to have instead (in the pass):

"defaultPass": {
"program" : {
"id": "program1",
"attributes" : {

"a_normal" : "attribute0",
"a_position" : "attribute1",
},
"uniforms" : {

"u_worldviewMatrix" : "uniform1",
"u_projectionMatrix" : "uniform2",
"u_ambient" : "ambient"

}
},
"states": {
"blendEnable": false,
"cullFaceEnable": true,
"depthMask": true,
"depthTestEnable": true
}
}

This said, the program definition as in programs is
"programs" : {
"program1" : {
"FRAGMENT_SHADER": "shaderFs1",
"VERTEX_SHADER": "shaderFs2",
}
}

So, program in pass would be inconsistent with it.

I propose to introduce useProgram here, it matches "glUseProgram" in GL
APIs.

it would give us.

"defaultPass": {
"useProgram" : {
"program": "program1",
"attributes" : {
"a_normal" : "attribute0",
"a_position" : "attribute1",
},
"uniforms" : {
"u_worldviewMatrix" : "uniform1",
"u_projectionMatrix" : "uniform2",
"u_ambient" : "ambient"
}
},
"states": {
"blendEnable": false,
"cullFaceEnable": true,
"depthMask": true,
"depthTestEnable": true
}
}

or we can take the COLLADA approach and use the instance concept and have
instead.

"defaultPass": {
"instanceProgram" : {
"program": "program1",
"attributes" : {
"a_normal" : "attribute0",
"a_position" : "attribute1",
},
"uniforms" : {
"u_worldviewMatrix" : "uniform1",
"u_projectionMatrix" : "uniform2",
"u_ambient" : "ambient"
}
},
"states": {
"blendEnable": false,
"cullFaceEnable": true,
"depthMask": true,
"depthTestEnable": true
}
}

@tparisi https://github.com/tparisi @RemiArnaudhttps://github.com/RemiArnaud
@pjcozzi https://github.com/pjcozzi
I have more to propose, but let's check what you think at this point.
Thanks for your feedback.

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

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

[pjcozzi]

Either is OK with me.

• If we are using instance elsewhere in glTF, and this is a similar case, then I prefer instanceProgram.
• Otherwise, I prefer useProgram, which maps well to WebGL here.

[fabrobinet]

@RemiArnaud let's move on, ok with instanceProgram ?
@pjcozzi yes, I will continue on the design thread and now introduce instanceMesh in the same issue

[fabrobinet]

@RemiArnaud and I discussed this during our meeting.
After having considered more aspects including mesh/instanceMesh, we have the following proposal:

First of all, to be consistent with instanceProgram, as proposed & agreed in previous discussion,
the instance concept is used where we refer to objects ids and set properties this referred id. (like in instanceProgram).
Note: this does not involve additional indirections but - like in instanceProgram - the creation of intermediate an object ({}) to keep together the referred ids and the properties to apply the referred object.

To illustrate this, we can update the material example discussed previously and use instanceTechnique:

"material_2":  { 
    "name" : "wood",
        "instanceTechnique": {
        "technique" : "technique1",
            "overrides": [{
            "parameter": "ambient",
            "value" :[ 0.2, 0.2, 0.2 ] 
            }]
    }
 }

As you may have noticed, this example contains other changes:

• Since parameters values are set in materials (not created) using overrides instead of parameters in material prevents confusion with parameters in techniques - where parameters are actually created.
• using an array instead of an object is more straight forward (since parameters ids aren't referred by other objects in this context, otherwise developers would have to get all keys of all keys in overrides)
• elements of overrides are objects because there are 2 possible type of override: value or semantic.

The previous proposal a few comments ago for technique does not change i.e (we go straight on the pass for the interesting part).

"defaultPass": {
    "instanceProgram" : {
        "program": "program1",
        "attributes" : {
            "a_normal" : "attribute0",
            "a_position" : "attribute1",
        },
        "uniforms" : {
            "u_worldviewMatrix" : "uniform1",
            "u_projectionMatrix" : "uniform2",
            "u_ambient" : "ambient"
        }
    },
    "states": {
        "blendEnable": false,
        "cullFaceEnable": true,
        "depthMask": true,
        "depthTestEnable": true
    }
}

[fabrobinet]

As a check-point, from here we agreed on:

• adding programs root property.
• instanceProgram

The remaining design discussion about what we called so far instanceMesh will happen here:
#79

[fabrobinet]

@tparisi @pjcozzi please have a look a few comments above about the instanceTechnique proposal.

[pjcozzi]

@fabrobinet this is OK with me.

[fabrobinet]

implemented everything discussed in this thread : 230169c
Note: values was implemented used instead of overrides.

[tparisi]

I think this works... looking forward to full examples to look over. Thanks for the hard work on this one.

[fabrobinet]

we're done here, spec should be updated.

[pjcozzi]

@fabrobinet schema is updated, can we close this?