[x3d-public] ... X3D4 PBR Material textures: normalScale

[Don Brutzman]

Have updated tooltip summaries, please review.

===================================
* https://www.web3d.org/x3d/content/X3dTooltips.html#Material.normalScale
* https://www.web3d.org/x3d/content/X3dTooltips.html#PhysicalMaterial.normalScale
* https://www.web3d.org/x3d/content/X3dTooltips.html#UnlitMaterial.normalScale

(X3D version 4.0 draft) [normalScale accessType inputOutput, type SFFloat CDATA "1"] [0,1]
normalScale controls the degree to which normalTexture RGB values apply XYZ-normal bump mapping to pixels in the parent material.
Hint: normalScale only affects computation of normalTexture modulations that affect lighting of characteristics of the parent Material and has no relation to normal vectors defined by corresponding geometry.
Hint: normalTexture techniques apply Bump mapping https://en.wikipedia.org/wiki/Bump_mapping

===================================
normalTexture	(X3D version 4.0 draft) [normalTexture accessType inputOutput, type SFNode singleton, NULL node] [X3DSingleTextureNode]
When applying normalScale for this material node, the contained texture provides Physically Based Rendering (PBR) modulation for each pixel.
Hint: normalTexture techniques apply Bump mapping https://en.wikipedia.org/wiki/Bump_mapping
Hint: if texture node is NULL or unspecified, no effect is applied to material values.
Hint: contained texture node must include containerField='normalTexture'

===================================
normalTextureMapping	(X3D version 4.0 draft) [normalTextureMapping accessType inputOutput, type NMTOKEN #IMPLIED]
The mapping label identifies nodes that together apply Physically Based Rendering (PBR) texture parameters from the given material node to corresponding geometry.
Hint: TODO support planned to perform multiple-node mapping validation checks using X3D Schematron or X3D Validator https://savage.nps.edu/X3dValidator

===================================

On 9/28/2020 9:00 PM, Don Brutzman wrote:
> makes great sense, thank you.
> 
> i've got the current WD2 nodes for PBR materials and texture mappings implemented OK and working satisfactorily in XML Schema, DTD, X3DUOM, X3D Tooltips, X3D Validator, and Java X3DJSAIL.  uploading tonight.  the Python X3DPSAIL has some other problem, won't get fixed right away.
> 
> On 9/28/2020 3:41 PM, Michalis Kamburelis wrote:
> 
>> The point of normalScale is to tweak the influence of the normalmap
>> texture. Intuitively speaking, the "bumps" caused by normalmap can be
>> emphasized / de-emphasized easily by changing normalScale.
>>
>> See the equation and prose on
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#X3DOneSidedMaterialNode
>> where I document normalScale, and how normalmaps (normalTexture) work.
>>
>>> a. Should normalScale have type SFVec3f instead of SFFloat?
>>
>> SFFloat is enough, and matching glTF perfectly.
>>
>> I was thinking about complicating it (making SFVec3f), but I decided
>> to go with simple design instead, that matches glTF in 100%. They have
>> analogous float that behaves 100% the same in glTF.
>>
>>> b. Does normalScale only apply to provided Normal vector arrays, or to both provided and computed normal vectors?
>>
>> normalScale only affects how the normals are read from the normalmap
>> texture. That is it's goal: to make normalmap influence higher or
>> lower.
>>
>> Neither the "provided Normal vector arrays" nor the "computed normal
>> vectors" are directly affected by normalScale. The provided / computed
>> per-vertex normals only serve as the basis, which is further modified
>> by normalmaps in the tangent space. This is the standard bump mapping
>> algorithm, that is why I explain the "tangent space" in the spec
>> section (of X3DOneSidedMaterialNode).
>>
>>> c. Sometimes provide Normal vector arrays are not normalized, likely we want to note in specification prose that they should be normalized in range [0..1] before modification
>>
>> That is unrelated to normalScale.
>>
>> We also already do this,
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/rendering.html#Normal
>> says "Normals shall be of unit length.".
>>
>> It is also ignored by some authors anyway, and I bet all existing
>> browsers normalize these vectors anyway. Practically, normalizing is
>> often necessary anyway, otherwise linear interpolation of per-vertex
>> normals would made non-unit-length normals in the fragment shader,
>> even if the vertex shader would only get "proper" unit-length normals
>> as the input.
>>
>> So, non-normalized values in "Normal" node is
>> - not really a problem for most implementations,
>> - and also we already address this in the spec :),
>> - and also it's unrelated to normalScale.
>>
>>> d. How to handle an initial or resulting normal value of (0 0 0) ?
>>
>> Formally speaking, such values are not allowed by the spec. Since we
>> require normals in "Normal" to be normalized, as I answered above.
>>
>> Practically speaking, shader code will just use such zero value inside
>> the lighting equations. Nothing will explode. The resulting value will
>> have no sensible real-world interpretation (since in real-world, the
>> surface, by definition, has some normal), but the lighting equation
>> can be computed for normal = zero. It will be a local artifact on the
>> surface, likely a sudden black spot on some pixel.
>>
>> Regards,
>> Michalis
>>
>> pon., 28 wrz 2020 o 16:38 Don Brutzman <brutzman at nps.edu> napisał(a):
>>>
>>> normalScale questions:
>>>
>>> a. Should normalScale have type SFVec3f instead of SFFloat?
>>>
>>> b. Does normalScale only apply to provided Normal vector arrays, or to both provided and computed normal vectors?
>>>
>>> c. Sometimes provide Normal vector arrays are not normalized, likely we want to note in specification prose that they should be normalized in range [0..1] before modification.
>>>
>>> d. How to handle an initial or resulting normal value of (0 0 0) ?
>>>
>>> all the best, Don
>>> -- 
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>>> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> 
> all the best, Don

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman