[x3d-public] PTM paper from Michalis Kamburelis; proposed PTM component by Kwan Hee Yoo

[Michalis Kamburelis]

Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
>
> Many thanks for your in-depth analysis.  Kwan Hee, Dick and I similarly went on a big journey over the years about whether this is inside Shape node or not.  It is interesting and tricky.
>
> Treating PTM capabilities as somewhat similar to a direction projector light source within the scene, similar to other lights, seemed to resolve several logical conflicts.  Yet aspects of texture mapping remain. Hence the current approach treats it as a separate component, defined as a collection of functionality at a similar level in the specification organization.
>
> In the interests of further convergence, if you want to suggest diffs to the current draft that better integrates alternatives you have explored, please feel free to do so.

I understand. Yes, both our approaches make sense :)

When preparing example scenes for this component, I would suggest to
address the question """how does projecting a texture work on a shape
that already has textures?""".

- What if the shape is already using a simple texture, i.e. it has
"Application.texture" set to some "ImageTexture" and
"IndexedFaceSet.texCoord" set to "TextureCoordinate" or
"TextureCoordinateGenerator"?

- What if the shape is already using multi-texturing, i.e. it has
"Application.texture" set to a "MultiTexture" node e.g. with 2
"ImageTexture" instance, and "IndexedFaceSet.texCoord" contains a
"MultiTextureCoordinate"?

    What if it has 2 nodes in "MultiTexture", but only 1 node in
"MultiTextureCoordinate"?

- Remeber that in X3D 4 we plan to add materials that will contain
texture references inside too. "PhysicalMaterial" contains a texture
inside, for consistency normal "Material" should also be extended to
have them inside, and to get the same features as
"CommonSurfaceShader". See
https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
.

When you define a texture projector outside of the shape, you need to
address the above questions. My suggested solution is that the
projected texture should be added as an additional multi-texture
layer. If necessary, the sizes of "MultiTexture" and
"MultiTextureCoordinate" should be internally synchronized before
adding this new layer. If a shape wasn't using multi-texturing (it
only had 1 texture), it will effectively be internally converted to
use multi-texturing.

Of course I talk here about "internal conversion", not something
visible to the X3D author. But the X3D player should behave "as if"
there was an additional texture, and the X3D specification could
formulate requirements using this way ("The rendering result should be
as if the projected texture was an additional multi-texture
layer...").

And to make it reliable, we should make a rule "all textures modulate
by default" ( https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
), otherwise you will have problems because ImageTexture without
multi-texturing right now has different semantics than a single
ImageTexture inside a MultiTexture. The problem is described in this
link, and my proposed  solution is to "always modulate by default,
whether you use multi-texturing or not, whether the texture is RGB or
grayscale".

P.S. Sorry if this sounds complicated :) Texturing is a non-trivial
thing to define, and unfortunately X3D spec has a number of problems
related to this, I was reporting them already a few years ago. But
thinking about multi-texturing is necessary if you want to be able to
project a texture X on a shape that is already textured with texture
Y.

Regards,
Michalis