-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glTF 2.0: New/modified KHR_materials_common extension #947
Comments
@McNopper Is this update work happening in public anywhere? I'm looking to implement these types in the UnityGLTF project, as they seem easier to work with on mobile than pbrMetallicRoughness. |
It is happening in this thread. As soon as glTF 2.0 is final, the working group will get back to extensions and issues.I am currently implementing the materials, lights in an experimental way, that we do have a base to discuss about.Regarding the lightmap, I suggest u define an extension and provide an example and/or schema. This could also be used as a start to discuss about.
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------Von: Steven Vergenz <[email protected]> Datum: 25.05.17 20:45 (GMT+01:00) An: KhronosGroup/glTF <[email protected]> Cc: Norbert Nopper <[email protected]>, Mention <[email protected]> Betreff: Re: [KhronosGroup/glTF] glTF 2.0: New/modified KHR_materials_common
extension (#947)
@McNopper Is this update work happening in public anywhere? I'm looking to implement these types in the UnityGLTF project, as they seem easier to work with on mobile than pbrMetallicRoughness.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/KhronosGroup/glTF","title":"KhronosGroup/glTF","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/KhronosGroup/glTF"}},"updates":{"snippets":[{"icon":"PERSON","message":"@stevenvergenz in #947: @McNopper Is this update work happening in public anywhere? I'm looking to implement these types in the UnityGLTF project, as they seem easier to work with on mobile than pbrMetallicRoughness."}],"action":{"name":"View Issue","url":"#947 (comment)"}}}
|
I've added a tentative lightmap implementation to the commonConstant material in UnityGLTF, since we use pre-computed lighting more routinely than PBR. What it looks like:
|
Does the lightmapTexture make sense in commonConstant, as its inflcuence is on the diffuse part? In my opinion it should be restricted to commonLambert, commonBlinn and commonPhong. |
In the case of the constant material, a lightmap is simply a multiply texture, but is still incredibly useful to my use cases. It gives you the ability to 1) have multiple variations of emissive textures without having to bake lighting onto them, 2) specify a separate UV channel, so you can vary the lightmap texel resolution w.r.t. the emissive texture. |
Ah, I see. Do you know, if other engines do have the same approach? Or it could be "easily" implemented? |
I'm sure light maps as multiply textures are easy to implement on Unity and Three.js, as those are the platforms I use. Not sure about any others. |
lightmaps are implemented in threejs, multiplied against indirect diffuse: https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/lightmap_fragment.glsl |
Steven, seems my original assumption is correct. The lightmap is just applied to the diffuse part. Can we make for your approach another extension? |
I don't want to derail this issue, which is meant for the materials definition. I'll write up a new issue with my proposal, we can discuss it there. |
Same with the current status of the common materials:
|
This looks reasonable to me — @UX3D-nopper are you able to share a complete model (with the |
You can use this scene: Basically, every scene based on Blender Render materials can be exported like that. |
Hey, great to see this! Just my 0.02$, after thinking again about this material model: Comparing to the PBR one, the materials_common model should be as simple as possible - which is also what @stevenvergenz names as a motivation to implement it (in this case for mobile):
Apart from that, I think one reason why it might be nice to have it is that many "traditional" pipelines and viewers (such as X3D viewers) built on a common model that became popular through standardization in the old OpenGL fixed function pipeline, offering ambient, diffuse, and specular material properites. Again, just my opinion, you know I'm not a material expert - wondering if anyone had similar thoughts on this? |
I personally think, we should call the common material just Phong or Blinn and "kick" out *Lambert and *Constant, as they can be described by using zero factors in Phong and/or Blinn. If someone wants to use sophisticated materials, one is using PBR nowadays anyway. Also, regarding PBR, we also did not fully specify(?), which terms should be used in the BRDF formula, see |
+1 from me. I think the original extension basically just copied COLLADA, which was not as simple as possible. |
Let's get more input here. It would be great to simplify this, but will it create challenges for exporters or runtimes? |
Due to a limited understanding of the technical implications (also for the application cases, or even details like shader performance), I don't have a strong opinion here, but iff I understood this correctly, then
Then, one could only support Blinn, because it is a good trade-off between simplicity and power (in terms of capability to emulate the others). It would be nice if the differences could be covered with default values. I'll have to re-read some details, but ... wouldn't it be possible to boil this down to something like this (roughly equivalent to what @McNopper posted initially) :
Or more specifically: Is it worth to differentiate between
when the shader implementation will basically be the same in all cases? |
An implementation note from three.js: we do not have an
Can Phong approximate Blinn? I'm not sure I understand the difference, THREE.MeshPhongMaterial implements a "Blinn-Phong" model. Other than that confusion, +1 on the idea of having a single model, assuming it is OK for exporters. |
I think we should just support Blinn-Phong, as if an engine does support non-PBR, in most (all?) cases it is this shading model. |
This is now using the structure from KhronosGroup/glTF#947 (comment), though perhaps liable to change soon this is what's currently used by Three.js.
From what I can pick up form this thread (and related), you seem to be converging on a model which effectively does the following diffuseTerm = * ? // extension ; texture is optional. Textures are optional, and if provided, will modulate the base Factor value? color = emissiveTerm + where N (normal) can be geometric or can be provided by tangent-space normalTexture (part of core material spec). Is that a fair assessment? I ask because we're building a pipeline and viewer based around glTF2.0 and we've got a ton of 'old' (pre-PBR) model data which we'd like to get converted, and it would be nice to have a clear definition to build against. |
Basically. it is what you have written, but the ambientTerm/ambientFactor is equal to the diffuseTerm: Please also have a look at the Khrons Blender glTF 2.0 exporter: |
Thanks for confirming. Interesting decision to drop ambient and replace with fixed diffuse term. Will be interesting to see how that looks. And just to double check, textures will multiply, not add/replace? |
Here is a nomenclature comment concerning 'Blinn', 'Phong', 'BlinnPhong' which is probably the result of my ignorance but which I could not resolve after going through the Blinn, 1977 paper: |
I did not do so much deep research, but it will be the Blinn-Phong lighting model, as it is the default shading model for - fixed - OpenGL and DirectX: For the future, if someone really needs Phong: But from my undersatnding, in the old spec, Blinn should be called BlinnPhong. So the Blinn in the old spec will be BlinnPhong in the current/future one. Also, it seems that you already invested much time in it. So my suggestion: |
Thanks for the links which confirm what I had started to put together. |
@McNopper : see https://github.com/UX3D-nopper/glTF/pull/1 . By official repo, did you mean this repo here ? |
Official repo is this one: Process is like this: You make a fork, make changes and then do a pull request to the official, original one. |
not sure i've seen this discussed in any thread, but is the 'technique' really needed for materials_common? With the correct default values, blinn, constant and lambert are all achievable by simply providing the appropriate values e.g. if you want 'constant' (baked) material effect, simply provide the emissiveFactor/texture values ; the other terms will multiply out to 0. |
@McNopper - do you want us to fork this one or fork the master? |
Please work on this one, as far as I know this is the latest one. Like the light extension, of course still some stuff to specify. |
#1075 is https://github.com/UX3D-nopper/glTF/pull/1 against this repo. |
there appear t be two KHR_common material definitions ongoing. |
@stevepg the page you link to is the latest, yes. Viewers do not support this yet, and some spec discussion is ongoing, so it may be a bit early to implement that extension yet. |
We currently have:
@McNopper Any objection to closing this issue, to avoid confusion? |
@donmccurdy i have my own viewer and i need to get test data into it asap so i might need to punt on one of these. Personally i think cmnBlinnPhong is good enough for what we need - i think its better to have the material typed like this, instead of a generic _common with a type=blabla field. I don't see much discussion on the specs to be honest ; there were questions a few weeks back, folks asked for input, there are pull requests waiting with that feedback. |
Oops, #1075 is the one I meant to reference. There are more recent comments there. What I mean to say is that it's not necessarily decided yet whether KHR_materials_cmnBlinnPhong or KHR_materials_common will be ratified, more likely the first after some further changes, but it will only be one or the other. I would advise against putting either into a publicly-available exporter without at least an "experimental" option to enable/disable the extension, to avoid circulation of invalid models. The Blender exporter does something along these lines now. |
this is internal so i'm not worried about models getting out there. not yet. thanks for the pointer to the other thread. i'll head over there.... |
Closing, as discussed in several threads. |
What is the current state of this extension? Which viewers support it and what format are they using? Thanks! |
I know you saw this already @chipweinberger, but copying zellski's response (#1207 (comment)) here for future readers:
|
Using the pbrMetallicRoughness and pbrSpecularGlossiness material "syntax", I have adapted the common materials. Again here by example:
Like the current PBR materials, they extend the "base" materials. So e.g. emissive would be inherited.
The text was updated successfully, but these errors were encountered: