[x3d-public] Projective Texture Mapping PTM node definitions

Michalis Kamburelis michalis.kambi at gmail.com
Tue Oct 6 16:04:59 PDT 2020


I will not be able to attend this Friday, but I can next Friday.

PTM should be reflected in the lighting equations on
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html
. Clearly showing how the equation looks (where does PTM "plug" into
the existing equations) would make it clear how the PTM should be
implemented. From what you say, PTM would act as an additional light
source, whose "color" is derived from the projected texture (instead
of being constant "X3DLightNode.color").

I'm happy to work to encode this in spec :) But I would like a
confirmation / test that indeed it is implemented like this in X_ITE,
that (as far as I understand) already implements this part of X3Dv4
spec.

And I just saw that I made an important omission in my updated
lighting equations on
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#LightingCommon
: I forgot to include in the lightContribution_i factor the
"lightSource.color * ..." factor. That's just my stupid human error :)
So this should be updated to say

- lightContribution_i is multiplied by X3DLightNode.color in case of
normal lights (to fix my mistake)
- lightContribution_i is multiplied by texture color in case of PTM
(to make PTM spec unambiguous)

Regards,
Michalis


wt., 6 paź 2020 o 19:30 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Dick and I worked on this today.  First, we allowed a value of -1 (meaning no effect) similar to X3DViewpointNode nearClippingPlane and farClippingPlane.
>
>    SFFloat  [in,out] farDistance  -1     -1 or (0,∞)
>    SFFloat  [in,out] nearDistance -1     -1 or (0,∞)
>
> The nearDistance and farDistance are the minimum and maximum distance traveled, respectively, for a projected texture that is shown on the screen. A default value of -1 for nearDistance or farDistance means that the field has no effect on currently active projection boundaries.
>
> We have a TODO: [convert to ClassicVRML syntax] for the excerpted examples, anyone care to provide those?
>
> Perhaps Kwan-Hee Yoo, can we have each example model?
>
> Today's changes have been pushed to github.
>
> On 10/6/2020 12:39 AM, Michalis Kamburelis wrote:
> >
> > I recall we talked that the PTM specification needs to address how the
> > projected texture affects the existing textures.
> >
> > You once mentioned that the original PTM proposal contained the text
> > effectively meaning that "projected texture is like a light source",
> > but then this text was simplified (maybe too much) for the actual
> > spec. As an implementor, looking at WD2 of PTM (
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/ProjectiveTextureMapping.html
> > ), I don't know how exactly the projected color should be used (at
> > which point of the lighting equation is it applied).
> >
> > My old notion about it is on
> > https://github.com/michaliskambi/x3d-tests/wiki/Clarify-%22Projective-texturing%22-component
> > , see the section """TODO: Address how the projective texturing in X3D
> > 4 spec affects existing textures""". We talked about this issue on the
> > mailing list and teleconferences :)
> >
> > Regards,
> > Michalis
>
> As ever, thanks for your tremendous thoroughness.  We took a quick look at these.  Now that we have the Shape component and updated lighting/rendering sorted out, it seems we can finally address the concerns.
>
> You have best perspective on how PTM might fit into the X3D4 specification.  We are thinking that the basic approach is to treat the modification of every pixel affected by a projected texel as similar to any other light source, with the main difference simply being that color of light varies from the PTM light source.
>
> Dick thinks that specification probably goes in the PTM component Concepts section.  Perhaps additional words and even equation modifications are needed elsewhere in the X3D4 specification.
>
> Hoping you can revisit.  We can dedicate X3D working group meeting this Friday, or following Friday, to review this topic.
>
> Step by step....
>
>
> > wt., 6 paź 2020 o 06:00 Don Brutzman <brutzman at nps.edu> napisał(a):
> >>
> >> Found that the PTM nodes had never been put into X3D XML Schema, DOCTYPE or X3DUOM, etc. etc.  Working to remedy that.
> >>
> >> [1] 42  Projective Texture Mapping (PTM) Component
> >>       https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/ProjectiveTextureMapping.html
> >>
> >> Suggest following changes in nodes below:
> >>
> >> a. modify farDistance, nearDistance to have bounds of [0,∞)
> >>
> >> b. farDistance default of 10m seems like a good value if used in virtual rooms. nevertheless might consider longer default value for farDistance, perhaps 100 (meters) to reduce potential for future author puzzlement.
> >>
> >> Anything else?
> >>
> >> =============================
> >> 42.3.1 X3DTextureProjectorNode
> >>
> >> X3DTextureProjectorNode : X3DChildNode {
> >>     SFString [in,out] description  ""
> >>     SFVec3f  [in,out] direction    0 0 1  (-∞,∞)
> >>     SFFloat  [in,out] farDistance  10
> >>     SFBool   [in,out] global       TRUE
> >>     SFVec3f  [in,out] location     0 0 0  (-∞,∞)
> >>     SFNode   [in,out] metadata     NULL   [X3DMetadataObject]
> >>     SFFloat  [in,out] nearDistance 1
> >>     SFBool   [in,out] on           TRUE
> >>     SFNode   [in,out] texture      NULL   [X3DTexture2DNode]
> >>     SFFloat  [out]    aspectRatio         (0,∞)
> >> }
> >> =============================
> >> 42.4.1 TextureProjectorParallel
> >>
> >> TextureProjectorParallel : X3DTextureProjectorNode {
> >>     SFString [in,out] description  ""
> >>     SFVec3f  [in,out] direction    0 0 1     (-∞,∞)
> >>     SFFloat  [in,out] farDistance  10
> >>     SFVec4f  [in,out] fieldOfView  -1 -1 1 1 (-∞,∞)
> >>     SFBool   [in,out] global       TRUE
> >>     SFVec3f  [in,out] location     0 0 0     (-∞,∞)
> >>     SFNode   [in,out] metadata     NULL      [X3DMetadataObject]
> >>     SFFloat  [in,out] nearDistance 1
> >>     SFBool   [in,out] on           TRUE
> >>     SFNode   [in,out] texture      NULL      [X3DTexture2DNode]
> >>     SFFloat  [out]    aspectRatio            (0,∞)
> >> }
> >> =============================
> >> 42.4.2 TextureProjectorPerspective
> >>
> >> TextureProjectorPerspective : X3DTextureProjectorNode {
> >>     SFString [in,out] description  ""
> >>     SFVec3f  [in,out] direction    0 0 1  (-∞,∞)
> >>     SFFloat  [in,out] farDistance  10
> >>     SFFloat  [in,out] fieldOfView  π/4 (0,π)
> >>     SFBool   [in,out] global       TRUE
> >>     SFVec3f  [in,out] location     0 0 0  (-∞,∞)
> >>     SFNode   [in,out] metadata     NULL   [X3DMetadataObject]
> >>     SFFloat  [in,out] nearDistance 1
> >>     SFBool   [in,out] on           TRUE
> >>     SFNode   [in,out] texture      NULL   [X3DTexture2DNode]
> >>     SFVec3f  [in,out] upVector    0 0 1
> >>     SFFloat  [out]    aspectRatio         (0,∞)
> >> }
> >> =============================
> >>
> >> 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
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> 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



More information about the x3d-public mailing list