[x3d-public] TextureProjector nodes and textureTransform field; keystone effects

[Don Brutzman]

Thanks for the close review Michalis.  Not to worry about trying to add a capability that isn't desirable and implementable, that hasn't happened yet.

Meanwhile have realized that there is a related TextureProjector use case, a very important issue that we have overlooked: projector keystone adjustments.  People should look at the photos in the following reference page.

[1] Wikipedia: Keystone effect
     https://en.wikipedia.org/wiki/Keystone_effect

"The keystone effect is the apparent distortion of an image caused by projecting it onto an angled surface. It is the distortion of the image dimensions, such as making a square look like a trapezoid, the shape of an architectural keystone, hence the name of the feature. In the typical case of a projector sitting on a table, and looking upwards to the screen, the image is larger at the top than on the bottom. Some areas of the screen may not be focused correctly as the projector lens is focused at the average distance only."

It is important that our TextureProjector perspective display of light be able to model this commonplace real-world effect.  Authors will want to do this for rooms, auditoria, modeling projection onto building sides, etc.

Seems related geometrically to 3D projection and shearing effets.

[2] Wolfram Demonstrations Project: Understanding 3D Shearing
     https://demonstrations.wolfram.com/Understanding3DShearing

[3] Wikipedia: Perspective control
     https://en.wikipedia.org/wiki/Perspective_control

[4] Wikipedia: 3D projection
     https://en.wikipedia.org/wiki/3D_projection


On 10/17/2020 5:51 PM, Michalis Kamburelis wrote:
> Comments inline below.
> 
>> 2. Projective Texture Mapping (PTM)
> [...]
>> b. Include textureTransform?  This addition seems simple, logical and consistent.
>>
>> - Perhaps optional since the node itself can be rotated via a parent Transform... but that is not quite the same set of features as a textureTransform capability.
>>
>> - Problem seen implementing: none.
>>
>> Further opinions welcome.  Absent objections, am inclined to include it.
> "Absence of objections" is not a good enough argument to include
> something in the spec:)
> 
> Personally, while I don't think textureTransform (on projector) would
> be very hard to implement, but it's still some burden. And I don't see
> a big use for it -- you can rotate / move the projector.
> 
> And transforming the texture means that you land in a more complicated
> definition of "where are the bounds of the projected texture". Texture
> transformation would change where does the texture "hit" (e.g.
> "rotating by 45 degrees" or "scaling 10x times"). So it is*not*  just
> something that transforms texture coordinates.
> 
> I do not see this complication as justified, yet.
> 
> In general, it would be helpful to have example scenes (preferably
> real-world usage, not only conformance testcases) of this feature.
> Preferably working (as I understand, X_ITE already implements PTM
> following X3Dv4?). It's better to talk about actual use-cases, then to
> guess what the possible use-cases may be:)
> 

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