[x3d-public] PTM spec.

[GPU Group]

History - thanks Andreas - I'll read up
- they (2016 Korean researchers) say they implemented in FreeWRL but I've
never seen the code
- H0: its in there but disabled /programmed over
- H1: it was done as a student project and is the property of the student,
and never submitted to the opensource freewrl,sourceforge.net
- H2: it was submitted, but to the wrong git branch or SVN repository
Inconvenience > hypotheses:
H0: researchers like to do something new while having rational reasons for
doing it, not just fun, to get the research grant
H1: they were implementing in FreeWRL which is an accumulation of 2 decades
of hacking by a few dozen contributors taking shortcuts on top of shortcuts
- everything is inconvenient, but especially things that are done in an
integrated way - easier to do things independently than to find all the
pieces in freewrl code base
H2: truly something generically inconvenient that we'll discover when
implementing
-Doug


On Thu, Jan 30, 2020 at 12:40 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> There is a fairly long history on efforts to standardize PTM:
>
> 2011: https://www.web3d.org/content/updates-projective-texture-mapping
>
> 2016:
> https://www.web3d.org/sites/default/files/attachment/node/2326/edit/02_KwanHeeYoo_ProjectiveTextureMapping_DraftPaper-optik20160903_0.pdf
> http://koreascience.or.kr/article/JAKO201620240501843.page
>
> 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 [10]."
>
> 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
> mapping.
>
> 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.
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200130/832cd9bd/attachment.html>