<div dir="ltr"><div dir="auto">Super input. Just a few remarks.<br>
<br>
On Fri, Feb 8, 2019 at 5:48 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" rel="noreferrer noreferrer" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
><br>
> Thanks for many good ideas! I agree with everything, I only want to<br>
> add a note to the below paragraph:<br>
><br>
> Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> > A node design choice was to add the texture maps as fields to<br>
> > PhyicalMaterial rather than Appearance. I think Timo's reasoning was<br>
> > that this way all new functionality can be contained in one new node.<br>
> > But this is a bit of a departure. Other designs are certainly<br>
> > possible.<br>
><br>
> I see advantages of this design, where a material node allows to<br>
> configure every property by a constant factor (scalar, vector) and<br>
> optionally to multiply it by a texture.<br>
><br>
> CommonSurfaceShader also uses this design, CGE docs (linking to X3DOM<br>
> and InstantReality docs):<br>
> <a href="https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_common_surface_shader" rel="noreferrer noreferrer noreferrer" target="_blank">https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_common_surface_shader</a><br>
><br>
> E.g. in CommonSurfaceShader you have<br>
><br>
>   SFVec3f diffuseFactor<br>
>   SFNode  diffuseTexture<br>
>   SFVec3f emissiveFactor<br>
>   SFNode  emissiveTexture<br>
>   SFVec3f specularFactor<br>
>   SFNode  specularTexture<br>
>   .. and so on<br>
><br>
> (I'm simplifying a bit, in reality you need at least a way to provide<br>
> texture coordinate index to each texture slot, so there are more<br>
> fields.)<br>
<br>
> In my view, we should follow this approach to the consistent end :) So<br>
> PhysicalMaterial would have<br>
><br>
>   baseColorFactor<br>
>   baseColorTexture<br>
>   .. and so on<br>
>   (or maybe just baseColor, baseTexture)<br>
<br>
It is called basecolortexture in glTF but baseTexture would be following x3d conventions.<br>
<br>
> and to the regular Material we add<br>
><br>
>   diffuseTexture<br>
>   specularTexture<br>
>   emissiveTexture<br>
>   .. and so on<br>
><br>
> So all factors (scalars/vectors) have a counterpart texture, and the<br>
> texture field is present right next to the non-texture (scalar/vector)<br>
> value.<br>
<br>
> Advantages:<br>
><br>
> - This is simple for authors. """Question: What does the texture in<br>
> slot xxxTexture do? Answer: The same thing as xxxFactor, but it's a<br>
> texture so it allows to vary this material property over a surface.<br>
> See the xxx treatment in lighting equations."""<br>
><br>
> - It is simple to implement. Plug the texture xxxTexture into the<br>
> shader at the same place where you use xxxFactor.<br>
><br>
> Compare this to the current approach of X3D:<br>
<br>Perhaps somebody has insight into the underlying reasoning behind the current approach.<div dir="auto"><br></div><div dir="auto"><div dir="auto">In a way, the new Materials are on the level of the current Appearance. <br></div><div dir="auto"><br></div><div dir="auto">Structurally, the main question may be what works best for reuse of Appearance, Material and Texture.</div><div dir="auto"><br></div><div>Currently, reusing Material gives you the option to use a different diffuse texture for the same set colors. This does not seem to be a very common requirement. With the new design this flexibility disappears since colors (as factors) and existing maps are reused. This is the common requirement.<br></div><div dir="auto"><br>
> - The lighting equations say to use the Apperance.texture for diffuse,<br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingmodel" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/lighting.html#Lightingmodel</a><br>
> . (And to treat RGB and grayscale textures differently, which is<br>
> another point I find bad -- RGB textures should "replace" by default,<br>
> while RGB should "modulate", according to the spec.)<br>
><br>
> - The multi-texturing specification says that when MultiTexture is<br>
> present, the "MultiTexture.mode" rules (and the default is "modulate",<br>
> regardless of RGB or grayscale,<br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/texturing.html#MultiTexture" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/texturing.html#MultiTexture</a><br>
> ). And the "MultiTexture.source" determines whether the texture<br>
> affects the diffuse or specular calculation.<br>
><br>
> There are a couple of inconsistencies here. And it's not implemented<br>
> completely by X3D browsers, as far as I tested.<br>
><br>
> And it still doesn't provide all the necessary flexibility. E.g. you<br>
> can only modify "diffuse" and "specular" by "MultiTexture.source", you<br>
> cannot modify "emissive" color, and it's unclear what modifies the<br>
> "transparency". Although some of these things could be easily fixed in<br>
> the multi-texturing spec, but I think that overall the approach of<br>
> PhysicalMaterial/CommonSurfaceShader is better.<br>
><br>
> I discussed some of the above in """How does this relate to the<br>
> existing X3D multi-texturing nodes?""" on<br>
> <a href="https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F</a><br>
> . In short, I think we have to keep "Appearance.texture" supported,<br>
> and when it's present it should override "Material.diffuseTexture" or<br>
> "PhysicalMaterial.baseColorTexture" (depending whether<br>
> "Appearance.material" is Material or PhysicalMaterial). But new models<br>
> should be advised to instead add textures inside Material or<br>
> PhysicalMaterial.<br>
><br>
> And the normalmap texture (that is not related to lighting equations)<br>
> should be specified outside of the material, in "Appearance.normalMap"<br>
> field. This is also consistent with glTF, that places "normalTexture"<br>
> outside of the "pbrMetallicRoughness" block, recognizing that<br>
> normalmaps make sense for all lighting models, since "varying normal<br>
> vectors over a surface" makes sense for all algorithms that look at<br>
> surface normals. CGE has "Appearance.normalMap" already.</div><div dir="auto"><br></div><div>Although I agree that normal maps are generated independently of the lighting model, the use of a particular normal map is strongly coupled to use of a corresponding set of other maps. I do not see a situation where you would want to reuse a PhysicalMaterial and its maps with a different normal map. In fact, reusing a PhysicalMaterial should not require repeating the use of the same normal map (outside of PhysicalMaterial).</div><div><br></div><div>This does not leave much space for Appearance to act in, really only TextureTransform I believe. This may be appropriate as variations in TextureTransforms produces variations in the appearance of the same PBR material.</div><div><br></div><div> We may also have to discuss the option to use more than one set of texture coordinates for the same geometry, for different maps. I think glTF requires that two UV sets are supported. I think x3dom supports this for glTF but may not expose it for X3D. Let me check.<br></div><div dir="auto"><br></div><div>Cheers,</div><div><br></div><div>Andreas<br></div><div dir="auto"><br>
><br>
> Sorry for a long train of thought :) Hopefully this is informative.<br>
><br>
> Regards,<br>
> Michalis<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br></div></div></div>
</div>