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

[Don Brutzman]

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
-- 
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