[x3d-public] wondering about Texture mapping specified in material nodes [corrected]

Michalis Kamburelis michalis.kambi at gmail.com
Tue Sep 22 14:37:47 PDT 2020


Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 2:24 PM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > We cannot really make diffuseTextureCoord, specularTextureCoord inside
> > a mesh -- since diffuse and specular are for Phong. For PBR
> > (PhysicalMaterial) we have base, metallicRoughness.
>
> Not sure I understand. Probably I am missing something. texCoords are
> a property of the mesh, in my mind (not of the texture data). They are
> specific to the details of the vertices and connectivity of a mesh.
>
> A diffuseTexCoord field in a geometry would not need to be populated
> if a PBR material is used for the Shape (but could be). The current
> texCoord field could be used as an alias for diffuseTexCoord (for
> backward compatibility) or as a default value for any xxxTexCoord
> field although this may be more confusing than helpful.

I meant that we would need to put into IndexedFaceSet (actually the
ancestor, X3DComposedGeometryNode) a number of new fields that are
*sum* of capabilities of (Phong) Material and PhysicalMaterial (and
UnlitMaterial, but actually this one doesn't add anything new). So we
would add to X3DComposedGeometryNode:

ambientTexCoord # used only when material is Material
diffuseTexCoord # used only when material is Material
specularTexCoord # used only when material is Material
shininessTexCoord # used only when material is Material
baseTexCoord # used only when material is PhysicalMaterial
materialRoughnessTexCoord # used only when material is PhysicalMaterial
emissiveTexCoord # useful always
normalTexCoord # useful always
occlusionTexCoord # used only when material is Material or PhysicalMaterial

I'm actually fine with that, the more I think about it :) Just
pointing it out loud. We would extend geometry with many new fields,
for all possible material parameters.

As for texCoord -- indeed this can be solved like you describe. I
would say them to be the "fallback", i.e. if you define a texture in
XxxMaterial that affects yyy, then

A. it uses geometry.yyyTexCoord, if yyyTexCoord <> NULL
B. otherwise it uses geometry.texCoord, if texCoord is <> NULL
C. otherwise the default texture coordinates are generated, following
the node's description

For primitives without explicit texture coordinates (Sphere, Box etc.)
only the point C would apply, which is fine and consistent.

This also means that for simple cases (when there's just one set of
tex coordinates to be used with all textures), authors can ignore this
complexity and place them in "texCoord", just like in X3D 3.

This also means that X3D 3 models (after merely changing header to
claim X3D 4) continue to work without any changes.

I would also keep my simplification in X3D 4 to limit possible
MultiTexture usage. It would remain allowed only for
"Appearance.texture", which means that you can use
MultiTextureCoordinate only in "texCoord" or (for Material)
diffuseTexCoord or (for PhysicalMaterial) baseTexCoord or (for
UnlitMaterial) emissiveTexCoord. Or maybe just simplify it further and
say it's only for "texCoord". Do you have comments about that? My
intention here was to deliberately constrain the need for (complicated
and not that useful anymore) MultiTexture implementation.

> > So we win A and B, we lose C. Maybe this is a way forward? Preserving
> > C has probably the lowest priority. I can agree here that merely
> > reusing the "meat" of geometry node can be a solution.
>
> I think this would be similar to gltf, as well. What do others think
> of making coordIndex and xxxtexcoordIndex into SFNode values (with an
> indices field) instead of MFInt32 values so they can be reused ? This
> is similar to the Coordinate node which just has a single field
> (point). It exists presumably for the same reason, eg. DEF/USE.
> Perhaps this would require too much specification work.

I would be cool with that, i.e. adding a node like "Indexes { MFInt32
index [] }" that can then be used to express indexes. Am also
interested in others' opinions about this :)

There remains a question of backward compatibility. I.e. whether we
force authors that upgrade from X3D 3 -> X3D 4 to also "upgrade" their
index fields, and wrap them in "Indexes". So far, the current design
of my X3D 4 stuff means that you can "just" change the file header to
say "this is X3D 4" and it will continue to work as it were in X3D 3.
Forcing to wrap in "Indexes" would be a departure from this, everyone
upgrading would need to process their models.

Granted, this upgrade process X3D 3 -> X3D 4 can be automated. Still,
it means that we introduce the need for such automation. Previously,
there was no need for it :) This automation isn't completely trivial
if your model uses extensions e.g. specific to X3DOM or CGE (the
automation tool must be able to preserve them; in case of classic
encoding, this means that automation tool must be able to parse them)
or if you hand-crafted your X3D models, and need to preserve
comments/indents etc.

But in exchange we keep the spec "clear" from necessary compatibility
mechanisms. Such a mechanism would mean that we introduce new fields
like coordIndexNode (SFNode), and the existing coordIndex (MFInt32) is
used as a fallback. This means that we complicate the X3D 4 spec --
but authors can upgrade their models with 0 effort.

So far I see the allure of both approaches (abandon backward
compatibility, keep backward compatibility), I am open to opinions :)

Regards,
Michalis



More information about the x3d-public mailing list