[x3d-public] Tony’s video; null Material considerations

Fri Aug 2 08:48:34 PDT 2024

I am trying to be extremely clear in this message.

The X3DOM documentation was confusing.  The Shape.appearance field had a
default value of [X3DAppearanceNode].  I don’t know if a default appearance
field value is constructed or not, if the appearance node is missing (NULL)
in the appearance field.  Plus an abstract node cannot be instantiated so
double whammy on X3DAppearanceNode not being the default value.  I
appreciate a double set of eyes on this.

So no problem with finding default values in the specifications.

An issue on iOS is finding whether a field is required.  I did very quick
scan in X3D Tooltips, but nothing popped out.  I thought I had seen
“required” in the past, but where I looked, I didn’t see anything obvious
this time.   I have been known to skip details.  I assumed that the field
above was not required, since it can be NULL in the X3D specifications, and
the default “value” domain is abstract in the X3DOM documentation.

I don’t know how a Shape node can have a Material node or material field,
except via an intermediate Appearance node.  Please correct my ignorance,
so we all can learn.  In particular, I have issue with this sentence from
below “A *Shape *node having a null *material *field is a fairly common
occurrence, particularly when constructing models.”  Please double check
the italicized words.  I will proceed with my original idea if not
corrected.  I’ve also double checked the specifications.

There’s no actionable issue with the X3D specification. There’s a possible
update to the X3DOM Shape API documentation.  If someone has an updated
snapshot, cool beans!

Note that I took some care to add a required fields property to X3D JSON
Schema, so it’s very disappointing not to be able to search it properly on
iOS Safari.  My thought is to break the schema up by component.

John

On Fri, Aug 2, 2024 at 8:42 AM Brutzman, Donald (Don) (CIV) via x3d-public <
x3d-public at web3d.org> wrote:

> Our X3D Architecture specification is the authoritative reference for what
> is supposed to happen.
>
> We are careful to define expected functional results wherever possible.
> This guides both implementations of X3D and authors as well.  A *Shape *node
> having a null *material *field is a fairly common occurrence,
> particularly when constructing models.
>
>
>    - Extensible 3D (X3D) v4.0 Part 1: Architecture and base components,
>    12 Shape component, 12.4.2 Appearance
>    -
>    https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#Appearance
>
>
>
>    - The *material* field, if specified, shall contain a Material
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#Material>,
>    PhysicalMaterial
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#PhysicalMaterial>,
>    TwoSidedMaterial (deprecated)
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#TwoSidedMaterial> or
>    UnlitMaterial
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#UnlitMaterial> node.
>    If the *material* field is NULL or unspecified, lighting is off (all
>    lights are ignored during rendering of the object that references this
>    Appearance) and the unlit object colour is (1, 1, 1). Details of the X3D
>    lighting model are in 17 Lighting component
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/lighting.html#PART8>
>    .
>    - The *backMaterial* field, if specified, shall contain a Material
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#Material>,
>    PhysicalMaterial
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#PhysicalMaterial> or
>    UnlitMaterial
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#UnlitMaterial> node.
>    It is only allowed to define a *backMaterial* if the *material* is
>    also defined (not NULL). The node type provided to *backMaterial* (if
>    any) shall match the node type provided to *material*. This field
>    allows to render back faces with a different material parameters than the
>    front faces. The meaning and all constraints of this field are explained in
>    the section Two-sided materials
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/components/shape.html#TwoSidedMaterials>
>    .
>
>
> We are careful to define default results for missing fields whenever
> practical.  If the detection or correction of such edge cases remains
> ambiguous or poses an undesirable computational burden on browsers, then
> the specification typically states that expected results are undefined
> (meaning author and user beware, a browser can handle it as they see fit).
>
> Clearly, guidance to authors and  validation tools can help complement the
> specification.
>
>
>    - X3D Tooltips, Appearance, material
>    -
>    https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Appearance.material
>    - *[material accessType inputOutput
>    <https://www.web3d.org/x3d/tooltips/X3dTooltips.html#accessType>, type
>    SFNode
>    <https://www.web3d.org/x3d/tooltips/X3dTooltips.html#SFNode> singleton,
>    NULL node] [X3DMaterialNode
>    <https://www.web3d.org/specifications/X3Dv4/ISO-IEC19775-1v4-IS/Part01/nodeIndex.html#X3DMaterialNode>]*
>    Single contained Material node that can specify visual attributes for
>    lighting response (color types, transparency, etc.) applied to
>    corresponding geometry.
>    *Warning**:* if material is NULL or unspecified, lighting is off (all
>    lights ignored) for this Shape and unlit object color is (1, 1, 1).
>
>
>
>    - X3D Resources, Quality Assurance (QA)
>    -
>    https://www.web3d.org/x3d/content/examples/X3dResources.html#QualityAssurance
>    - X3D Quality Assurance (QA) identifies errors and warnings in order
>    to make X3D scene content more portable and reliable. Improved Quality
>    Assurance (QA) helps achieve intended results in X3D scenes and metadata.
>    - This is important. providing high confidence that when 3D modeling
>    errors occur, they can be detected and then corrected. As a result, X3D
>    models can run in many different file formats and programming languages,
>    equivalently and correctly.
>
>
> If anyone finds an apparent "hole" in X3D architecture coverage, or
> contrary implementations, then such reports are always appreciated.
>
> Have fun with X3D4!   🙂
>
>
> 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
> https://faculty.nps.edu/brutzman
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240802/229338c2/attachment-0001.html>