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

Andreas Plesch andreasplesch at gmail.com
Tue Sep 22 12:47:29 PDT 2020


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.

> That being said, I believe you're going toward something like my
> "Example F" on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> . This presents a situation where
>
> A. the Material and/or Appearance can be reused
>
> B. the mapping is performed without the need for SFstring "mapping",
> instead it is done using DEF / USE
>
> C. the IndexedFaceSet cannot be reused

Agreed. This is where this seems to be going.

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

Regards, -Andreas

> Regards,
> Michalis
>
>
>
> wt., 22 wrz 2020 o 19:21 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> >
> > see below:
> >
> > On Tue, Sep 22, 2020 at 9:30 AM Michalis Kamburelis
> > <michalis.kambi at gmail.com> wrote:
> > >
> > > Andreas Plesch <andreasplesch at gmail.com> wrote:
> > > >> But I don't see the proposed alternative solution as valid. If we
> > > >> prevent reusing Appearance or Material or geometry nodes, then we lose
> > > >> an important property of a model format design. (That other formats
> > > >> like glTF allow, and authoring tools like Blender explicitly support.)
> > > >
> > > >
> > > > I think gltf just allows reuse of data components of a geometry or a texture, not the complete geometry or appearance.
> > >
> > > glTF has a mechanism to reuse glTF materials (primitive links to
> > > material index,
> > > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> > > ).
> > >
> > > And "glTF material" is probably more like "X3D appearance" than "X3D
> > > material". E.g. glTF material also specifies things like alpha
> > > blending mode and alpha cutoff (neither of which has an official
> > > analogy in X3D spec, but one has CGE / InstantReality extension in
> > > Appearance.blendMode, one has X3DOM extension in Appearance.
> > > alphaClipThreshold). It's not a perfect correspondence though.
> >
> > ok. Complete materials can be reused in gltf.
> >
> > >
> > > Indeed glTF doesn't have a direct mechanism to reuse whole primitive
> > > with a different appearance. Since it expresses indexes as a buffer
> > > (unlike IndexedFaceSet.coordIndex), copying the "meat" of geometry is
> > > easy in case of glTF.
> >
> > So perhaps the design goal would be to make it easy in x3d as well ?
> >
> > >
> > > >> Reusing the "meat" of the geometry is quite involved, as not
> > > >> everything is prepared for this:
> > > >
> > > >
> > > > Still, this is as x3d currently is designed as I understand it.
> > >
> > > Right now you can easily reuse a mesh (IndexedFaceSet) by DEF / USE in
> > > X3D. Like in https://github.com/michaliskambi/x3d-tests/blob/master/pbr/enhanced_phong_material/mapping_second_shape_reusing_geometry.x3dv
> > > , "geometry USE MyMesh". This is possible since mesh doesn't have
> > > direct links to a material.
> >
> > Of course. I rather wanted to point out that currently in x3d you
> > would reuse a coordinate node, and would have to copy an index field.
> >
> > > >
> > > >>
> > > >> - For example indexes are not "wrapped" in another node in an
> > > >> IndexedFaceSet, so they would just have to be repeated. Unless we
> > > >> invent a new node "Indexes { MFInt32 index }" but it would complicate
> > > >> the overall design, and be a significant compatibility break from X3D
> > > >> 3.
> > > >
> > > >
> > > > True, perhaps we need such a break.
> > >
> > > I think that would be a big compatibility break :) Every
> > > IndexedFaceSet will be broken if we require to "wrap" indexes in a new
> > > node. So nearly all X3D 3 models would need to be reworked into X3D 4.
> >
> > Yes but it is worth considering. v3 models of course still work in v3.
> > The required reworking can be easily automated.
> >
> > > Unless we'll allow both methods (use "SFNode coordIndexNode" if
> > > non-NULL, otherwise fallback to "MFInt32 coordIndex"). But this then
> > > complicates our spec with a "compatibility cludge".
> > >
> > > >
> > > >>
> > > >> - Also such reuse doesn't allow the browser to easily "see" that we're
> > > >> not reusing geometry. If a browser has geometry-specific resources
> > > >> (like OpenGL VBOs) that could be reused, now it can just check that 2
> > > >> geometry nodes have equal references, and advise the author to reUSE
> > > >> the geometry nodes. If we instead make direct reusing of geometry
> > > >> nodes impossible (and the author can only reuse the "meat") then the
> > > >> browser would have to make field-by-field comparison (complicated, as
> > > >> it should account for various geometry nodes).
> > > >
> > > >
> > > > not sure if thinking about implementation details should guide a design.
> > >
> > > In general, IMHO: If we make an efficient implementation of some
> > > common use-case hard (harder than it is in e.g. glTF, or in Blender's
> > > information) then I say we did a poor job :) A proper design should be
> > > guided by the practical capabilities of the underlying systems. All
> > > real-time graphic API have a concept similar to "per-vertex data",
> > > "texture data", "compiled shader" etc.
> >
> > Hopefully a good design would also make the implementation efficient
> > if not easy.
> >
> > > But I agree that not everything needs to be a "common use-case", we
> > > should limit this label to really important things.
> > >
> > > If anything, I would say that reusing geometries is not really
> > > critical, so maybe there's a field to improve here.
> > >
> > > But reusing materials or appearances remains critical. In this case
> > > it's also about authoring tools usage. For authors, reusing materials
> > > or appearances makes intuitive sense too. Blender exposes this feature
> > > directly.
> >
> > Agreed. But the only requirement then is to decouple texture
> > coordinates from Appearance/Material (which is already the case in
> > v3).
> >
> > >
> > > >> Indeed it is tricky :) I certainly see the reason for this discussion,
> > > >> but I don't yet see any better solution than the current mapping
> > > >> SFString.
> > > >
> > > >
> > > > I do not think gltf has a similar mapping mechanism ?
> > > >
> > >
> > > See my answer to Don in the nearby thread :)
> >
> > Apologies, I missed that.
> >
> > >
> > > glTF doesn't have exactly this mechanism, but it has a simplified
> > > version of it. In particular glTF:
> > >
> > > - limits the number of textures to 2 (but X3D 3 has already committed
> > > to supporting arbitrary number of texture slots with multi-texturing)
> > >
> > > - glTF doesn't allow to specify mapping names as strings, instead they
> > > remain just integers on one side. So just 0 or 1. I'm cool with
> > > changing our mapping to be integers, but this was rejected as not
> > > descriptive.
> >
> > Well, is it then a major step to say "emissiveTexCoord" instead of
> > "texCoord_1" ?
> >
> > > Pasting here the relevant parts:
> > >
> > > """
> > > The important things:
> > >
> > > 1. a mesh can expose a number of attributes, in particular TEXCOORD_0
> > > and TEXCOORD_1 (identified just by strings in JSON, which can be
> > > directly used for our SFstring mapping). See
> > > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes
> > > .
> > >
> > > 2. a material can indicate using a specific texture with a texture
> > > coordinate number (0 or 1, matching to TEXCOORD_0 and TEXCOORD_1). See
> > > https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials
> >
> > I think this means then saying
> >
> > normalTexCoord USE="TEXCOORD_1"
> >
> > where TEXCOORD_1 was previously defined for another texture (say
> > emissiveTexCoord).
> >
> > Let's see if I can translate that to your example B:
> >
> > Shape {
> >   appearance DEF MyAppearance Appearance {
> >     material DEF MyMaterial Material {
> >       diffuseTexture ImageTexture { url "diffuse.png" }
> >       normalTexture ImageTexture { url "normal-map.png" }
> >       specularTexture ImageTexture { url "specular.png" }
> >     }
> >   }
> >   geometry DEF MyMesh IndexedFaceSet {
> >     coordIndex [ 0 1 2 3 ]
> >     coord Coordinate {
> >       point [
> >         0 0 0, ...
> >       ]
> >     }
> >         diffuseTextureCoord DEF TEXCOORD_0 texCoord {
> >           point [
> >             0 0,
> >             4 0,
> >             4 4,
> >             0 4,
> >           ]
> >         }
> >        normalTextureCoord USE TEXCOORD_0
> >        specularTextureCoord DEF TEXCOORD_1 texCoord {
> >           point [
> >             0.1 0,
> >             40 0,
> >             4 40,
> >             0 4,
> >           ]
> >         }
> >
> >     }
> >   }
> > }
> >
> > # EXAMPLE B First, define one shape that defines also MyAppearance, see above.
> >
> > # Then define another shape using MyAppearance.
> > Shape {
> >   appearance USE MyAppearance
> >   geometry IndexedFaceSet { # some different mesh
> >     coordIndex [ 0 1 2 3 4 5 .... ]
> >     coord Coordinate {
> >       point [
> >         ....
> >       ]
> >     }
> >     diffuseTextureCoord DEF B_TEXCOORD_0 texCoord {
> >           point [
> > ...
> >           ]
> >         }
> >        normalTextureCoord USE B_TEXCOORD_0
> >        specularTextureCoordinate DEF B_TEXCOORD_1 texCoord {
> >           point [
> > ...
> >           ]
> >         }
> >
> >     }
> >   }
> > }
> >
> > That seems to work ?
> >
> > Regards, -Andreas
> >
> > PS: I should check how x3dom currently does it.
> >
> > > So multiple meshes can use the same material. They only need to
> > > support the required number of texture coordinates. In our case, it
> > > would mean they need to expose the required texture mapping values.
> > >
> > > So it is similar to the mapping SFstring I propose, except we changed
> > > mapping to a more general SFstring while in glTF it is an integer.
> > > (This change was after our discussion some time ago; initially I
> > > proposed to make it SFInt32, which would map 100% to glTF).
> > > """
> > >
> > > Regards,
> > > Michalis
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453



--
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list