[x3d-public] PTM spec.

[GPU Group]

If we were doing RayTracing then a more general SceneryProjector would have
a few things:
1) ray direction guidance (in theory could be ray path could be a
function() other than straight line)
2) something for the ray to hit or miss:
- Scenegraph / Group / Shapes with Appearance and geometry
The reasons to parent the geometry to the Projector
a) so it moves with the projector
b) so it isn't rendered other than through projection
SceneryProjector :: Projector, Group
Since we are doing Rendering -not raytracing- we do things practical for
that technology
1) parallel (ortho) or convergent (perspective) rays - easy to set up ray
2) planar shape with rectangular boundary - easy to compute intersection
That still leaves a question about whether the rectangular plane can have a
full Appearance node or some subset.
But if it's limited to imageTextures, that simplifies the shader - can do a
sampler2D.
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.

TextureProjector :: Projector, Texture

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.

PerspectiveProjector : Projector
OrthoProjector: Projector
Viewpoint :: PerspectiveProjector
OrthoViewpoint :: OrthoProjector
SpotLight :: PerspectiveProjector
DirectionalLight :: OrthoProjector

TextureProjector {
SFNode projector: {Projector, OrthoProjector, Viewpoint, OrthoViewpoint,
SpotLight, DirectionalLight}
SFNode texture: { Texture, MultiTexture }
}

Or something like that.
-Doug


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

> 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/8fdb1ce4/attachment-0001.html>