[x3d-public] projective texture mapping (PTM) review

Don Brutzman brutzman at nps.edu
Wed Jun 24 19:39:05 PDT 2015

PTM review meeting today.  Attendees Kwan Hee Yoo, Dick Puk, Don Brutzman.

Getting closer for sure.  Minutes:

1. slide 11.  Rename X3DProjetiveTextureNode (in green area) to X3DTextureProjectorNode for consistency with the other nodes, and the rest of the slide.


2. slides 11-13.

2.a. We discussed whether to align field names with those defined for X3DViewpointNode, Viewpoint, and OrthoViewpoint.

For example, this might change location -> position, direction -> orientation, etc.

However, DirectionalLight use SFVec3f direction and PointLight uses SFVec3f location.  Spotlight uses direction and location.

We discussed how these projector nodes are most similar to lights, not as much with viewpoints.

So suggested field naming would be to stay the same as lights: location and direction.


2.b. Next fields:

- TextureProjectorPerspective fieldOfView should similar to Viewpoint SFFloat fieldOfView, and

- TextureProjectorParallel width/height should change instead to match OrthoViewpoint MFFloat (4-tuple) fieldOfView.

Rationale: we match fieldOfView for each node to be similar to the corresponding Viewpoint nodes.  This is simpler both for computation, and also simpler for authors to view the projector results.  For example:

- Viewpoint node could accompany a TextureProjectorPerspective, and

- OrthoViewpoint node could accompany TextureProjectorParallel.


2.c. Next field:

aspectRatio not needed per se, because it is implicit in the definition of the texture node (ImageTexture/MovieTexture/PixelTexture).  Each of these nodes has a width and height built into the texture already.

We discussed how there are many ways to transform a texture; upVector and perhaps some field for warping are complicated possibilities.

View volume is independent of texture being applied.

We discussed how simplest approach may be to add a TextureTranform (center rotation scale translation, all in U-V texture coordinates).  This would eliminate upVector and aspectRatio.  It would also likely make use of the contained texture simpler for both players and authors since it would be consistent with other texture use.

In other words, a texture node in combination withTextureTransform results in another texture.   So it remains simple.


3.  slide 14:

"How do we reflect lighting information into projective texture mapping nodes?"

The fields above seem to align the texture in some ways similar to a light source.

We do not need to adjust the lighting equations in the specification to include projector contributions, because they are not lights per se.  Rather they are applying textures to materials, which are later lit separately by the lights.


4.  Meanwhile, possibly aspectRatio (or maybe SFVec2f imageSize) ought to be an outputOnly field... this might benefit authors using any of the texture nodes.


5. References:

17 Lighting component
(X3DLightNode DirectionalLight PointLight Spotlight)

18 Texturing component
(X3DTexture2DNode X3DTextureTransformNode ImageTexture MovieTexture TextureTransform)

23 Navigation component
(X3DViewpointNode, Viewpoint, and OrthoViewpoint)


6. We plan to meet again via teleconference on July 22, and hopefully again at SIGGRAPH.


Excellent progress today... kam sa hab ni da, thank you!


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