[x3d-public] X3D working group meeting Friday on TextureProjector nodes: special light or texture-mapping technique?

[Don Brutzman]

On 10/13/2020 3:44 PM, GPU Group wrote:> 
> Either / both - like MultiTexture a parameter could say if you want to (add and clamp) or multiply or replace.
> -Doug

OK thanks for looking at this Doug.

The even bigger, fundamental question: are they Lighting nodes, or simply draping texture on geometry (that might still remain unlit and invisible)?

We must choose which approach: X3DLightNode (seems preferable) or X3DChildNode (possibly counterintuitive, seems to have limited use).

If you can (or already do) support the X3DLightNode lighting approach in the FreeWrl implementation, that will be good to know.

> On Tue, Oct 13, 2020 at 11:36 AM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>     We said about 10 days ago that we could look this Friday at how the Projective Texture Mapping nodes interact with lighting equations.
> 
>     [Doug can you join us please?  Anyone else?]
> 
>     Wondering if X3DOM or X_ITE have implemented these nodes.
> 
>     Dick and I took another pass at this topic today and uncovered a fundamental ambiguity: is each node a light, or simply a texture-mapping technique?
> 
>     =============
>     Use case. Shape/Box in a scene with no lights (and headlight="false").
> 
>     1. Shape/Box with Appearance/Texture applied is not rendered.
> 
>     2. If a light, TextureProjectorPerspective applied to Shape/Box makes it visible.
> 
>     3. If solely a texture, TextureProjectorPerspective applied to Shape/Box does not make it visible.
>     =============
> 
>     We had quite a discussion about whether it was (case 2) or (case 3).
> 
>     Undoubtedly this kind of thing was behind your questions before, "how to apply these nodes in the lighting equations?"
> 
>     Summary of specification-editing points follow, these are checked into Github as well.
> 
> 
>     EDITORS NOTES.
> 
>     a. (case 2) Is this node a white light modified by the texture? Does it need an ambientIntensity field in the abstract node? If so, then X3DTextureProjectorNode must implement X3DLightNode, rather than X3DChildNode.
> 
>     b. (case 3) Is this node simply a texture that is applied to geometry instead? If so, then how is that texture merged with any other texture that may already be present?
> 
>     c. If added in X3DTextureProjectorNode, textureTransform affects the texture prior to being projected.  Seems like a good idea.
> 
>     d. If (case 2) these nodes are light sources, are the similarly part of shadow definition? If not (case 3), then might need to state that this effect is not occluded by intervening geometry.
> 
>     We think that most intuitive (and likely most effective) approach is to treat the nodes as lights and go with (case 2)... hope we can reconcile this.
> 
>     all the best, Don
>     -- 
>     Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
>     Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>     X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> 
>     _______________________________________________
>     x3d-public mailing list
>     x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>     http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman