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

[Michalis Kamburelis]

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.

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.

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

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

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.

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.

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

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.

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
.

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