[x3d-public] beyond Blinn-Phong: PBR

Mon Feb 11 01:43:11 PST 2019

Doug,

Thanks! I have documents my thoughts on fixing this (making RGB and
grayscale treatment more consistent) in
https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
. I will want to put it into X3D spec at some point :)

Regards,
Michalis

niedz., 10 lut 2019 o 21:35 GPU Group <gpugroup at gmail.com> napisał(a):
>
> > - The lighting equations say to use the Apperance.texture for diffuse,
> > http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingmodel
> > . (And to treat RGB and grayscale textures differently, which is
> > another point I find bad -- RGB textures should "replace" by default,
> > while RGB should "modulate", according to the spec.)
>
> I remember Michalis explaining the replace vs modulate in the Lighting model a few years ago, and at that time I did internal flags in freewrl to do it various ways modulate vs (current) replace. I think freewrl is set half-way between right now.
> So I was thinking at that time when v4 comes out, freewrl could just test the scene file version, and set modulate, if modulate becomes the standard with v4. Or if there's another field or flag or option in the scene file somewhere.
> -Doug Sanden
>
>
> On Fri, Feb 8, 2019 at 3:49 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>
>> Thanks for many good ideas! I agree with everything, I only want to
>> add a note to the below paragraph:
>>
>> Andreas Plesch <andreasplesch at gmail.com> wrote:
>> > A node design choice was to add the texture maps as fields to
>> > PhyicalMaterial rather than Appearance. I think Timo's reasoning was
>> > that this way all new functionality can be contained in one new node.
>> > But this is a bit of a departure. Other designs are certainly
>> > possible.
>>
>> I see advantages of this design, where a material node allows to
>> configure every property by a constant factor (scalar, vector) and
>> optionally to multiply it by a texture.
>>
>> CommonSurfaceShader also uses this design, CGE docs (linking to X3DOM
>> and InstantReality docs):
>> https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_common_surface_shader
>>
>> E.g. in CommonSurfaceShader you have
>>
>>   SFVec3f diffuseFactor
>>   SFNode  diffuseTexture
>>   SFVec3f emissiveFactor
>>   SFNode  emissiveTexture
>>   SFVec3f specularFactor
>>   SFNode  specularTexture
>>   .. and so on
>>
>> (I'm simplifying a bit, in reality you need at least a way to provide
>> texture coordinate index to each texture slot, so there are more
>> fields.)
>>
>> In my view, we should follow this approach to the consistent end :) So
>> PhysicalMaterial would have
>>
>>   baseColorFactor
>>   baseColorTexture
>>   .. and so on
>>   (or maybe just baseColor, baseTexture)
>>
>> and to the regular Material we add
>>
>>   diffuseTexture
>>   specularTexture
>>   emissiveTexture
>>   .. and so on
>>
>> So all factors (scalars/vectors) have a counterpart texture, and the
>> texture field is present right next to the non-texture (scalar/vector)
>> value.
>>
>> Advantages:
>>
>> - This is simple for authors. """Question: What does the texture in
>> slot xxxTexture do? Answer: The same thing as xxxFactor, but it's a
>> texture so it allows to vary this material property over a surface.
>> See the xxx treatment in lighting equations."""
>>
>> - It is simple to implement. Plug the texture xxxTexture into the
>> shader at the same place where you use xxxFactor.
>>
>> Compare this to the current approach of X3D:
>>
>> - The lighting equations say to use the Apperance.texture for diffuse,
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingmodel
>> . (And to treat RGB and grayscale textures differently, which is
>> another point I find bad -- RGB textures should "replace" by default,
>> while RGB should "modulate", according to the spec.)
>>
>> - The multi-texturing specification says that when MultiTexture is
>> present, the "MultiTexture.mode" rules (and the default is "modulate",
>> regardless of RGB or grayscale,
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/texturing.html#MultiTexture
>> ). And the "MultiTexture.source" determines whether the texture
>> affects the diffuse or specular calculation.
>>
>> There are a couple of inconsistencies here. And it's not implemented
>> completely by X3D browsers, as far as I tested.
>>
>> And it still doesn't provide all the necessary flexibility. E.g. you
>> can only modify "diffuse" and "specular" by "MultiTexture.source", you
>> cannot modify "emissive" color, and it's unclear what modifies the
>> "transparency". Although some of these things could be easily fixed in
>> the multi-texturing spec, but I think that overall the approach of
>> PhysicalMaterial/CommonSurfaceShader is better.
>>
>> I discussed some of the above in """How does this relate to the
>> existing X3D multi-texturing nodes?""" on
>> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
>> . In short, I think we have to keep "Appearance.texture" supported,
>> and when it's present it should override "Material.diffuseTexture" or
>> "PhysicalMaterial.baseColorTexture" (depending whether
>> "Appearance.material" is Material or PhysicalMaterial). But new models
>> should be advised to instead add textures inside Material or
>> PhysicalMaterial.
>>
>> And the normalmap texture (that is not related to lighting equations)
>> should be specified outside of the material, in "Appearance.normalMap"
>> field. This is also consistent with glTF, that places "normalTexture"
>> outside of the "pbrMetallicRoughness" block, recognizing that
>> normalmaps make sense for all lighting models, since "varying normal
>> vectors over a surface" makes sense for all algorithms that look at
>> surface normals. CGE has "Appearance.normalMap" already.
>>
>> Sorry for a long train of thought :) Hopefully this is informative.
>>
>> Regards,
>> Michalis
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org