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

Michalis Kamburelis michalis.kambi at gmail.com
Wed Jan 23 05:51:37 PST 2019


 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: projective_texturing_simple_0.png
Type: image/png
Size: 515117 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190123/a6a60528/attachment-0001.png>


More information about the x3d-public mailing list