fallbacks for techniques #84
Comments
|
|
name is too weak. On Fri, May 3, 2013 at 9:40 AM, Fabrice Robinet [email protected]:
|
|
How do you want to represent fallbacks ? |
|
Remi, seriously? This is exactly what I was saying 2 months ago and you For what it's worth, I agree, we should have predefined names for common On Fri, May 3, 2013 at 10:18 AM, Fabrice Robinet
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
Well, also... I suggested something like this initially , you can replace "description" by "fallback" if you like. It could be more clever and reuse parameters from the shaders to be aligned with Remi's input (2 months ago). Well, it needs refinement, but you get the idea. |
👍 @fabrobinet I'll need to see a more refined and complete example to provide feedback, but to start, I don't think we needed |
|
Agreed about generator. I'll provide an example that include #47 needs. |
|
What I was suggesting is that we have pre-defined fallback shaders, with Regards On Thu, May 16, 2013 at 12:46 PM, Fabrice Robinet
|
|
I believe we need to support 3 scenarios for shaders: 1 - Shipped with the content, the way the convert currently does it I am not sure what the priority of these should be. I need to think about Tony On Thu, May 16, 2013 at 1:37 PM, Rémi Arnaud [email protected]:
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
I am not sure then, how these fallback shaders would be different from the ones generated by the converter. We don't want to specify any shader implementation (I think we agreed on that), so I took fallback as way to use the provided shaders and use parameters to regenerate your own. Sorry for the misunderstanding. @RemiArnaud you started the issue by asking for an id instead of name, that is why I was proposing to mention explicitly where the generated shaders where coming from. |
|
@tparisi what you call the technique hints are the parameters and the name of the technique right ? by "override" I understand you mean regenerate shaders. Which is what a possibility we indeed agreed to provide since the beginning. Now I still don't really get how the fallbacks would work exactly. Also the shaders that are generated by the converter already follow naming convention for the parameters.That is why I don't know what the fallback shaders would be. |
|
Fab I think what Remi means by "fallbacks" is essentially default Here is my view: a valid glTF material could have any of the following.
Converters and exporters can provide options for what to output. Tony On Thu, May 16, 2013 at 1:44 PM, Fabrice Robinet
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
See my other message for clarification on how I think it should work. If we have "fallback implementations," (again I prefer to call the Am I making sense? On Thu, May 16, 2013 at 1:58 PM, Fabrice Robinet
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
My suggestion covers all the use cases. Regards On Thu, May 16, 2013 at 1:42 PM, Tony Parisi [email protected]:
|
|
Riight. I think it's just a nomenclature issue. If the idea is to have the implementation try to interpret the techniques If on the other hand, the default is to have the application honor the Subtle. Tony On Thu, May 16, 2013 at 2:04 PM, Rémi Arnaud [email protected]:
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
Ok thanks, I see what you mean now. Yes we talked about the possibility of passing/forcing shaders to the converter. I'd like to split this issue in two to keep things clear:
|
|
@RemiArnaud If you don't mind, please take the lead on this one. I will work in 1) in the meantime/before. |
ghost
assigned
|
BTW, it is ok not to have all attributes connected to the default shader, and it is ok not to have required attributed in the geometry (default values for attributes)
|
|
There could be more than one fallback. |
|
I think we probably should finalize the 'geometry/overrides' design first? |
|
Yes, good idea. On Thu, May 16, 2013 at 6:30 PM, Rémi Arnaud [email protected]:
Tony Parisi [email protected] Read my book! WebGL, Up and Running |
|
Yes I am working on #82 |
|
Acutally on #92 |
|
I think my confusion was that I wanted to discuss first about specifying a way to let developers regenerate states and shaders from high level information. Rather than fallback that may carry themself shaders and states. |
|
Please, let's take care of #97 first, then I'll be happy to discuss further details for fallbacks. |
|
right on all counts, fixed typos and yes I need to define default. |
|
@pjcozzi oh and I think that means that |
|
Yes, |
|
@pjcozzi can you review the common materials extension? Fairly done https://github.com/KhronosGroup/glTF/blob/spec-1.0/extensions/Khronos/KHR_materials_common/README.md |
|
Just wondering how per vertex color would fit in this model ? Regards On Oct 5, 2015, at 4:58 PM, Tony Parisi [email protected] wrote:
|
|
which model? common materials? yeah we probably need to handle per-vertex color and normal flags in there. good catch. |
|
@pjcozzi I need help figuring out rendering default if technique is optional. I mentioned 80% gray as a default. is that emissive or diffuse? e.g. if the implementation has lights it can do a diffuse color on that assuming normals are supplied (or generated). that's a lot more interesting than just emissive, which will look like indistinct blobs on the screen... requires more thought. feeling like opening a separate issue on this. |
|
Comments:
Maybe, but I did to finish the core spec reference doc first. Will let you know later this week. |
Or just use raw glTF techniques. I don't know that this is widely enough used to justify making the spec more complicated. |
I would think |
|
yeah that's a good idea. I'm going to open another issue for the common materials extension. too much noise in here. |
|
moved common materials discussion to #424 |
Just my $0.02, but if the only reason we need a default is so that this property can be optional for the sake of extensions, then I think it's reasonable to expect most users to either supply the property or implement an extension. So the default can be brain-dead, such as half-gray emmissive with no lighting, to keep it simple and to encourage supplying of better values. |
|
Good point @emackey. That would be fine with me. |
|
@pjcozzi please review the language... |
|
Looks good with two comments:
|
|
@tfili do you happen to have this?
|
|
Labeled |
|
A default material would be a constant gray color, like defined with the material below using the KHR_materials_common extension. "materials": {
"Effect1": {
"extensions": {
"KHR_materials_common": {
"technique": "CONSTANT",
"values": {
"emission": [
0.8,
0.8,
0.8,
1
]
}
}
}
}
},During runtime we would generate the following json objects "materials": {
"Effect1": {
"values": {
"emission": [
0.8,
0.8,
0.8,
1
]
},
"technique": "technique0"
}
},
"programs": {
"program0": {
"attributes": [
"a_normal",
"a_position",
"a_texcoord_0"
],
"fragmentShader": "fragmentShader0",
"vertexShader": "vertexShader0"
}
},
"shaders": {
"vertexShader0": {
"type": 35633,
"uri": "data:text/plain;base64,...",
},
"fragmentShader0": {
"type": 35632,
"uri": "data:text/plain;base64,..."
}
},
"techniques": {
"technique0": {
"attributes": {
"a_normal": "normal",
"a_position": "position"
},
"parameters": {
"modelViewMatrix": {
"semantic": "MODELVIEW",
"type": 35676
},
"normalMatrix": {
"semantic": "MODELVIEWINVERSETRANSPOSE",
"type": 35675
},
"projectionMatrix": {
"semantic": "PROJECTION",
"type": 35676
},
"emission": {
"type": 35666
},
"normal": {
"semantic": "NORMAL",
"type": 35665
},
"position": {
"semantic": "POSITION",
"type": 35665
}
},
"program": "program0",
"states": {
"enable": [
2884,
2929
]
},
"uniforms": {
"u_modelViewMatrix": "modelViewMatrix",
"u_normalMatrix": "normalMatrix",
"u_projectionMatrix": "projectionMatrix",
"u_emission": "emission"
}
}
}The shaders would be Vertex: precision highp float;
uniform mat4 u_modelViewMatrix;
uniform mat3 u_normalMatrix;
uniform mat4 u_projectionMatrix;
attribute vec3 a_normal;
attribute vec3 a_position;
void main(void) {
gl_Position = u_projectionMatrix * u_modelViewMatrix * vec4(a_position,1.0);
}Fragment: precision highp float;
uniform vec4 u_emission;
void main(void) {
gl_FragColor = u_emission;
}Obviously encoding in a data URI wouldn't be the ideal situation but it would work with existing engines. One option could be to add an |
According to the space, the following technique names can be provided to provide more guidance:
Lambert
Phong
Blinn-Phong
missing from that list: constant
the converter should follow the spec, specifically for duck.json, 'Blinn-Phong' should be used instead of 'technique1'
regarding the spec, this is not a name, this is an id.
The text was updated successfully, but these errors were encountered: