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

Michalis Kamburelis michalis.kambi at gmail.com
Mon Sep 28 15:41:25 PDT 2020


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



More information about the x3d-public mailing list