<div dir="ltr"><div>H3: Kambu had no concrete Projector class - just abstract - and when they say 'independen' they meant a separate concrete class for Projector:</div><div><br></div><div>Projector</div><div>Viewpoint :: Projector</div><div>SpotLight :: Projector</div><div><br></div><div>-Doug</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Thu, Jan 30, 2020 at 2:01 PM GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div>History - thanks Andreas - I'll read up </div><div>- they (2016 Korean researchers) say they implemented in FreeWRL but I've never seen the code</div><div>- H0: its in there but disabled /programmed over</div><div>- H1: it was done as a student project and is the property of the student, and never submitted to the opensource freewrl,<a href="http://sourceforge.net" target="_blank">sourceforge.net</a> </div><div>- H2: it was submitted, but to the wrong git branch or SVN repository </div><div>Inconvenience > hypotheses:</div><div>H0: researchers like to do something new while having rational reasons for doing it, not just fun, to get the research grant</div><div>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</div><div>H2: truly something generically inconvenient that we'll discover when implementing</div><div>-Doug</div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Thu, Jan 30, 2020 at 12:40 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">There is a fairly long history on efforts to standardize PTM:<br>
<br>
2011: <a href="https://www.web3d.org/content/updates-projective-texture-mapping" target="_blank" rel="noreferrer">https://www.web3d.org/content/updates-projective-texture-mapping</a><br>
<br>
2016: <a href="https://www.web3d.org/sites/default/files/attachment/node/2326/edit/02_KwanHeeYoo_ProjectiveTextureMapping_DraftPaper-optik20160903_0.pdf" target="_blank" rel="noreferrer">https://www.web3d.org/sites/default/files/attachment/node/2326/edit/02_KwanHeeYoo_ProjectiveTextureMapping_DraftPaper-optik20160903_0.pdf</a><br>
<a href="http://koreascience.or.kr/article/JAKO201620240501843.page" target="_blank" rel="noreferrer">http://koreascience.or.kr/article/JAKO201620240501843.page</a><br>
<br>
The authors actually reference Michalis' approach but call<br>
it'inconvenient. Let's see:<br>
<br>
"ImageTextureNode needs to be declared in order to receive<br>
ProjectionTextureImage, and ProjectedTexureCoordinateNode needs to be<br>
declared in order to get the projection texture coordinates. This<br>
inconveniency implies that this cannot be referred to as an<br>
independent ProjectionTextureNode. In this paper, we have expanded and<br>
implemented an independent ProjectionTexture and ProjectorNode in<br>
order to overcome the limitations of Kamburelis’ research [10]."<br>
<br>
The authors emphasize that it is important to have independence of the<br>
new node from existing facilities. With that in mind they derive the<br>
proposed node design.<br>
<br>
Let's see why independence may be a valuable goal. Unfortunately, the<br>
paper does not advance other reasons than the "inconvenience of<br>
separately creating ImageTexture and ProjectedTextureCoordinate nodes"<br>
. But there is actually no discernible inconvenience over the proposed<br>
mechanism as far as I can tell because in both cases the Texture<br>
content and the texture coordinates need to be specified in much the<br>
same way. Probably there is something which may have been lost in<br>
translation or writing.<br>
<br>
What may be considered a hurdle is the requirement to take into<br>
account the concept of texture coordinates which may not be<br>
immediately obvious to an author if the goal is projective texture<br>
mapping.<br>
<br>
Are there other arguments why it would be important to have PTM as a<br>
node and component independent of regular texture use ? There very<br>
well may be for typical use cases but I cannot think of any.<br>
<br>
On the other hand the advantageous of having tighter, more seamless<br>
integration are more apparent: Better reuse, no new concepts,<br>
automatic resolution of Multitexture, less to spec.<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank" rel="noreferrer">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div>