[x3d-public] PTM paper from Michalis Kamburelis; proposed PTM component by Kwan Hee Yoo

[Nicholas Polys]

See also:

https://doc.x3dom.org/tutorials/lighting/shadows/index.html
https://doc.x3dom.org/tutorials/lighting/shadows/example.html

br,
_n


On Thu, Jan 24, 2019 at 10:29 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Many thanks for your in-depth analysis.  Kwan Hee, Dick and I similarly
> went on a big journey over the years about whether this is inside Shape
> node or not.  It is interesting and tricky.
>
> Treating PTM capabilities as somewhat similar to a direction projector
> light source within the scene, similar to other lights, seemed to resolve
> several logical conflicts.  Yet aspects of texture mapping remain. Hence
> the current approach treats it as a separate component, defined as a
> collection of functionality at a similar level in the specification
> organization.
>
> In the interests of further convergence, if you want to suggest diffs to
> the current draft that better integrates alternatives you have explored,
> please feel free to do so.
>
> As promised I will work with Kwan Hee Yoo to get examples online (along
> with X3D 4.0 XML schema/DTD plus X3DUOM) to facilitate further testing and
> implementation.  As it turns out, I am sitting next to him here in Seoul
> and we have agreed to work on further progress during lunch today!
>
> Having fun with X3D Projective Texture Mapping   8)
>
> On 1/23/2019 10:51 PM, Michalis Kamburelis wrote:
> >   Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
> >> Michalis, if you have done any further work beyond the reference below,
> could you please ensure that we have the latest greatest from you related
> to this topic.
> >
> > My work on projective texturing is part of my "shadow maps"
> > extensions, documented on
> > https://castle-engine.io/x3d_extensions_shadow_maps.php .
> >
> > Of course it can be used without shadow maps too, just to cast
> > textures. The goal was to easily define a way to project texture from
> > a light source or a viewpoint, using "ProjectedTextureCoordinate" node
> > that can be used in a similar way to the standard
> > "TextureCoordinateGenerator". In particular, casting a texture from a
> > light source is essential to perform shadow mapping, that's why I
> > developed my projective texturing extension "by the way" of developing
> > shadow maps extensions.
> >
> > A simple example how does it look like is on:
> >
> https://github.com/castle-engine/demo-models/blob/master/shadow_maps/projective_texturing_simple.x3dv
> > . You can open it with view3dscene (
> > http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ ). I also attach
> > a screenshot.
> >
> > Notable differences from my approach and Kwan's:
> >
> > (I'm not trying to say here which one is better! I like Kwan's
> > approach. But I explain how, and why, my approach was different.)
> >
> > 1. Kwan adds projector nodes that are defined outside of "Shape".
> > Projector node affects many shapes, using the "global" or "scoped"
> > mechanism.
> >
> >      In contrast, my "ProjectedTextureCoordinate" is placed within a
> > "texCoord" field of a geometry. So you need to explicitly add it to
> > the relevant geometry nodes. My "ProjectedTextureCoordinate" was
> > modeled after standard "TextureCoordinateGenerator", so it cooperates
> > with multi-texturing in the same way. You can have 1st texture layer
> > coordinates determined by "ProjectedTextureCoordinate", and 2nd
> > texture layer coordinates determined by something else (like
> > "TextureCoordinateGenerator" or explicit "TextureCoordinate").
> >
> > 2. Kwan projector nodes define their own projection parameters. The
> > node type ("TextureProjectorPerspective" or
> > "TextureProjectorParallel") determines if the projection is
> > perspective or orthogonal.
> >
> >      In contrast, my "ProjectedTextureCoordinate" refers to a light
> > source / viewpoint node. You can use DEF / USE mechanism to refer to
> > an existing light source / viewpoint this way, or you can define new
> > light source / viewpoint inside. The projection parameters and type
> > are determined looking at the node type (e.g. "OrthoViewpoint" or
> > "DirectionalLight" result in orthogonal projection, "Viewpoint" or
> > "SpotLight" result in perspective projection). In some cases I needed
> > to add addtional fields to lights, see
> >
> https://castle-engine.io/x3d_extensions_shadow_maps.php#section_light_parameters
> > . E.g. all light sources have a new "projectionNear", "projectionFar"
> > fields.
> >
> >      This was a necessity in my case. We *need* to have projection
> > parameters specified at a light source, to make shadows maps possible
> > from this light source. Then we can guarantee using the same
> > projection parameters when (A) generating the shadow maps, and when
> > (B) displaying the shadow maps. If projection parameters used for (A)
> > and (B) would be different, shadow maps would not work OK.
> >
> > 3. In summary, my specification modifies more stuff in X3D. It relies
> > on existing "texCoord" field, light sources and viewpoints nodes, and
> > uses them. I also had to extend existing light sources with new
> > fields.
> >
> > Regards,
> > Michalis
>
> 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
>


-- 
Nicholas F. Polys, Ph.D.

Director of Visual Computing
Virginia Tech Research Computing

Affiliate Professor
Virginia Tech Department of Computer Science
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190124/e29d5450/attachment-0001.html>