[x3d-public] PTM spec.
andreasplesch at gmail.com
Thu Jan 30 11:39:19 PST 2020
There is a fairly long history on efforts to standardize PTM:
The authors actually reference Michalis' approach but call
it'inconvenient. Let's see:
"ImageTextureNode needs to be declared in order to receive
ProjectionTextureImage, and ProjectedTexureCoordinateNode needs to be
declared in order to get the projection texture coordinates. This
inconveniency implies that this cannot be referred to as an
independent ProjectionTextureNode. In this paper, we have expanded and
implemented an independent ProjectionTexture and ProjectorNode in
order to overcome the limitations of Kamburelis’ research ."
The authors emphasize that it is important to have independence of the
new node from existing facilities. With that in mind they derive the
proposed node design.
Let's see why independence may be a valuable goal. Unfortunately, the
paper does not advance other reasons than the "inconvenience of
separately creating ImageTexture and ProjectedTextureCoordinate nodes"
. But there is actually no discernible inconvenience over the proposed
mechanism as far as I can tell because in both cases the Texture
content and the texture coordinates need to be specified in much the
same way. Probably there is something which may have been lost in
translation or writing.
What may be considered a hurdle is the requirement to take into
account the concept of texture coordinates which may not be
immediately obvious to an author if the goal is projective texture
Are there other arguments why it would be important to have PTM as a
node and component independent of regular texture use ? There very
well may be for typical use cases but I cannot think of any.
On the other hand the advantageous of having tighter, more seamless
integration are more apparent: Better reuse, no new concepts,
automatic resolution of Multitexture, less to spec.
Waltham, MA 02453
More information about the x3d-public