[x3d-public] PTM spec.

[GPU Group]

H3: Kambu had no concrete Projector class - just abstract - and when they
say 'independen' they meant a separate concrete class for Projector:

Projector
Viewpoint :: Projector
SpotLight :: Projector

-Doug

On Thu, Jan 30, 2020 at 2:01 PM GPU Group <gpugroup at gmail.com> wrote:

> 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/4c5c252c/attachment.html>