<div dir="ltr"><div><br></div><div>If we were doing RayTracing then a more general SceneryProjector would have a few things:</div><div>1) ray direction guidance (in theory could be ray path could be a function() other than straight line)</div><div>2) something for the ray to hit or miss:</div><div>- Scenegraph / Group / Shapes with Appearance and geometry</div><div>The reasons to parent the geometry to the Projector </div><div>a) so it moves with the projector</div><div>b) so it isn't rendered other than through projection</div><div>SceneryProjector :: Projector, Group</div><div>Since we are doing Rendering -not raytracing- we do things practical for that technology</div><div>1) parallel (ortho) or convergent (perspective) rays - easy to set up ray</div><div>2) planar shape with rectangular boundary - easy to compute intersection</div><div>That still leaves a question about whether the rectangular plane can have a full Appearance node or some subset.</div><div>But if it's limited to imageTextures, that simplifies the shader - can do a sampler2D.</div><div>And if we want something more complex - like raytracing might do - then we can do a RenderedTexture/GeneratedTexture step first to generate the texture from more complex geometry and appearance.</div><div><br></div><div>TextureProjector :: Projector, Texture</div><div><br></div><div>So I think our Korean friends were on the right track in some ways, and not their fault, but web3d needs to refactor its nodetype inheritance hierarchy to get the Kambu polymorphism(?)/abstraction(?) - to get spotlight and viewpoint to act like projectors.</div><div><br></div><div>PerspectiveProjector : Projector</div><div>OrthoProjector: Projector</div><div>Viewpoint :: PerspectiveProjector</div><div>OrthoViewpoint :: OrthoProjector</div><div>SpotLight :: PerspectiveProjector</div><div>DirectionalLight :: OrthoProjector</div><div><br></div><div>TextureProjector {</div><div>SFNode projector: {Projector, OrthoProjector, Viewpoint, OrthoViewpoint, SpotLight, DirectionalLight}</div><div>SFNode texture: { Texture, MultiTexture }</div><div>}</div><div><br></div><div>Or something like that.</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 3:53 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>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" target="_blank">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>
</blockquote></div>