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

[Andreas Plesch]

see below.

On Tue, Sep 22, 2020 at 5:38 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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

Exactly. If there are explicit fields they need to go somewhere after
all. This is what I thought Don had in mind. But I may be wrong since
Don put the TexCoord fields in (Physical)Material as far as I
remember.

I think xxxTexCoordIndex fields are also needed for indexed geometries
(Hm, again, it would be helpful if these would be SFNode values).

> 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

Thinking about it, this fallback system could be quite useful since it
would avoid having to reUSE texCoords. On the other hand, it would be
perhaps the only place in X3D to use such a system, and add some
complexity.

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

Or just reUSE diffuseTexCoord.

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

This would also be the case if texCoord would be an alias for diffuseTexCoord.

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

I would tend to restrict usage as much as possible, eg. only to retain
backward compatibility. I think this means allowing MultiTexCoord only
for texCoord. Or just deprecate or remove from the spec. the
MultiTextureXXX nodes altogether. Perhaps it could be considered a
failed experiment ?

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

Perhaps also have an abstract node. So the signature for coordIndex would become

SFNode [in,out] coordIndex NULL [X3DIndexNode]

X3DIndexNode : X3DGeometricPropertyNode {
  SFNode [in,out] metadata NULL [X3DMetadataObject]
}

Indices : X3DIndexNode {
  SFNode  [in,out] metadata NULL   [X3DMetadataObject]
  MFInt32 [in,out] index    []     (0,∞)
}

It would require changing the spec. for all Indexed geometry nodes.

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

Note node names ending in Node are typically reserved for abstract nodes.

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

I think you captured the tension well.

One could ask: when if not now ? Meaning, breaking backward
compatibility is a real option. But of course this is easier said than
done.

Perhaps it is a good start to only define new index fields (such as
normalTexCoordIndex) as SFNode values.

Cheers, -Andreas

> Regards,
> Michalis

--
Andreas Plesch
Waltham, MA 02453