[x3d-public] ... X3D4 PBR Material textures: normalScale bounds and 'mapping' tooltips
Don Brutzman
brutzman at nps.edu
Sun Oct 4 11:11:43 PDT 2020
[summary: fixed, plus one confirmation question]
On 9/29/2020 4:05 PM, Michalis Kamburelis wrote:
>
> Don,
>
> My main comment is that you should not combine normalmaps with PBR in
> the description. That is a bit confusing. Normalmaps do not provide
> something specific to PBR. Normalmap affects normal vectors. Thus,
> they affect how lighting is computed (in both Phong and PBR lighting
> models). They also affect TextureCoordinateGenerator modes based on
> normals (regardless of the lighting model).
point well taken, thanks
> Also, normalScale is not limited to [0,1] range, as your mail above
> shows. It is actually in [0,infinity] range, as spec says:
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#X3DOneSidedMaterialNode
> . Values > 1 of normalScale are very useful to emphasize the normal
> map.
got it. also confirmed X3D XML Schema and X3DUOM are OK.
double checking, please confirm: the following fields have range [0,1] which seems OK but normalScale is different... please confirm no slipups have occurred:
SFFloat [in,out] metallic 1 [0,1]
SFFloat [in,out] occlusionStrength 1 [0,1]
SFFloat [in,out] roughness 1 [0,1]
SFFloat [in,out] transparency 0 [0,1]
> 1. So in the normalTexture text, replace
>
> """"the contained texture provides Physically Based Rendering
> (PBR) modulation for each pixel""""
>
> ->
>
> """"the contained texture modulates normal vectors across the surface""""
sounds good, done
> 2 In normalTextureMapping text, replace
>
> """The mapping label identifies nodes that together apply
> Physically Based Rendering (PBR) texture parameters from the given
> material node to corresponding geometry."""
>
> ->
>
> """The label identifies which texture coordinates/transformations
> are used to apply the normalTexture over a corresponding geometry."""
good improvement, i went a bit further and adjusted phrasing for general applicability among all cases of mapping fields:
"The mapping label identifies which texture coordinates and transformations are used to compute texture effects from corresponding geometry on a given material."
* X3D 4.0 Tooltips, Material.normalTextureMapping
https://www.web3d.org/x3d/content/X3dTooltips.html#Material.normalTextureMapping
Also applied 'mapping' field to tooltips for TextureCoordinate3D TextureCoordinate4D TextureTransform3D TextureTransformMatrix3D. Example:
* X3D 4.0 Tooltips, TextureTransform3D.mapping
https://www.web3d.org/x3d/content/X3dTooltips.html#TextureTransform3D.mapping
> 3. Fix the range [0,1] -> [0,infinity] at normalScale description.
>
> Regards,
> Michalis
>
> wt., 29 wrz 2020 o 15:23 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> 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
More information about the x3d-public
mailing list