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

[Michalis Kamburelis]

Don Brutzman <brutzman at nps.edu> wrote:
>
> Appreciate your patience.   Clearly we need a meeting to discuss this since we seem to be circling.
>
> I have multiple workshops to attend this week.  Looks like my first available day to meet is Friday.  Can start as early as 0700 Pacific.  Regular X3D teleconference also available 08-0930 Pacific.  This remains high priority.

I can be at the teleconference (Friday 8 Pacific) this week. Indeed it
may be easier to talk in person :)

More answers below :)

>
> Reviewed again, summary: have offered more concise examples that seem to handle all of the shortfalls in the original failed alternatives.  Key details follow.
>
> a. I believe you stated as a functional definition that each of the Texture fields modify the corresponding Material - that certainly seems to be their purpose.  If any one of those fields needs to have different TextureTransform and TextureCoordinate values than the others, then it needs to be defined right there with the texture in question.  In other words, you can't have multiple texCoord values over on the geometry itself.

Texture coordinates and transformations *do not* need to be specified
"near the texture". Texture coordinates in particular are dependent on
the mesh topology, that is why they are (and should stay) within a
geometry node (like IndexedFaceSet). This is already the design in X3D
3, and I want to keep it, this was good (and is consistent with what
authoring tools expect, e.g. Blender also has texture coordinates
"tied" to a mesh, same as glTF).

You can have the multiple texCoord values on a single geometry. It is
called multi-texturing, you place multiple texture coordinates within
MultiTextureCoordinate. It effectively allows each geometry node to
have a number of different texture coordinates. This is also something
that maps naturally to e.g. Blender or glTF. The way how
MultiTextureCoordinate works with mapping is described in the section
"12.2.4 Texture mapping specified in material nodes".

>
> b. For the primary Appearance "texture" field and corresponding TextureTransform and corresponding geometry texCoord, there is no change implied from X3D3 (just like you have it).

Sure. And I advocate to keep this property (allow to reuse Appearance,
Material and geometry) possible also with new design, with new nodes
and approaches. We don't want to say to authors """you can reuse
Appearance... ups, unless you have placed texture coordinates in
Material; then you cannot""".

>
> c. Maximizing USE is not a design requirement per se, just helpful design when achievable.  Having distinct "mapping" fields across multiple node types does not make a node (or collection of nodes within a Shape) suddenly re-USE-able.  If any of the fields are different, including "mapping" then the nodes are different.  If they are the same, then USE is allowed.  Avoiding redefinition of MultiTexture itself by re-USE of the MultiTexture internal nodes is why my example simply used ImageTexture, case by case, with appropriate USE found in multiple places.
>
> Your Example C sidesteps this problem by overloading nodes with the same label, e.g.
>
>          TextureTransform {  # part of example A
>            mapping "diffuse-and-normal-mapping"
>            translation 0.5 0.5
>          }
>
>          TextureTransform {  # deliberately added to example A by example C
>            mapping "diffuse-and-normal-mapping"
>            translation 0 0
>          }

It's not "sidestepping", it's exactly the purpose of the mapping
field. Another geometry may refer to the same mapping string. This is
the very purpose of this design.

Again, it's not really new. That's how e.g. named attributes in
graphic APIs work.

>
> d. If the field approach has the same information as other programmatic styles, then it is functionally equivalent to (glTF, Blender, Unity, whatever).  The parent-child field relationship approach is certainly in keeping with X3D3.

Depends on what you mean by "functionally equivalent". If reusing
Appearance / Material / geometry becomes impossible in some cases,
then yes -- you can still make models that have the same look, but no
-- you have not preserved the original connections between authoring
tool concepts (like Blender materials and meshes).

If we break the possibility of reusing Appearance / Material /
geometry, then we make the browser's job much harder. Optimizing
resource loading and rendering becomes much harder.

Right now a browser can compare references to Material and/or
Appearance to know that it can reuse some OpenGL resources. Same for
geometry. This is a very important design feature.

Again, this is a feature that everyone else has :) I would lament if
we lose this in X3D 4. E.g. glTF has this, Collada has this, Blender
has this. And X3D 3 has this. They all have a concept of "material
library" from which particular meshes use materials, and multiple
meshes can refer to the same material. Because this is both natural to
authors, and allows a natural resource optimization on the
implementation side.

>
> e. If there is some aspect of model definition in your primary example not expressed in the field approach that I offered, please point out the gap.  My example was carefully derived step-by-step from yours, commenting each of your constructs in place when replaced by an alternative, so any logical misconception or disconnect should be isolable.  Here was the transition:
>
> # Version 1-original
> # Version 2-original-labeled   (simply adding DEF labels)
> # Version 3-fieldnames-verbose (keeping mapping fields in place, commented)
> # Version 4-fieldnames-terse   (same, minus comments)
>
> So, is anything missing?  I just rechecked again and all information in your original seems to be accounted for.

As I mentioned, you missed examples B, C, D from my text on
https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
. They present the important concept of "reuse". You have not shown
how to do this in your version. If you try, you will see you need to
essentially copy some node contents and "tweak" them, whereas in my
design you can just say "USE MyApperance" in the 2nd shape.

>
> f. Something you haven't said explicitly but may be thinking:  even if the two approaches are functionally equivalent, it is conceivable that we might decide to forego the usual X3D parent-child node relationships in order to preserve portability of content when translating to/from glTF etc.
>
> ... in which case we might well decide to keep "mapping" fields as a more-compatible but less-validatable approach,
>
> ... in which case we need to look at how difficult animation has become when author must change many parameters simultaneously (via Script node synchronization) in order to achieve a single effect,
>
> Example underlying glTF code might be helpful to compare.  Would it help us to look at that for your Example A?

This discussion is not about glTF, and it's not about animations.

I do not have ready glTF files that exactly correspond to my examples,
but you can read glTF specification to see their possibilities.

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

And I fully agree we should describe "mapping" field in the respective
nodes :) The necessary prose can be added easily, once we resolve this
discussion :)

Regards,
Michalis