[x3d-public] X3D Working Group minutes, endgame review: TextureProjector nodes, do we include shadows?

[Richard F. Puk]

Hi, Michelis --

I agree with your comments below.

  -- Dick

/******************************************
| Richard F. Puk, Ph.D., President
| Intelligraphics Incorporated
| 7644 Cortina Court
| Carlsbad, CA  92009-8206
| Tel: +1-760-753-9027  Mobile:  +1-760-809-9027
| Email:  puk at igraphics.com
\****************************************** 



-----Original Message-----
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Michalis
Kamburelis
Sent: Saturday, October 17, 2020 7:51 PM
To: Don Brutzman
Cc: X3D Graphics public mailing list; Holger Seelig; Andreas Plesch; doug
sanden
Subject: Re: [x3d-public] X3D Working Group minutes, endgame review:
TextureProjector nodes, do we include shadows?

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 :)

> ---
>
> 3. Shadows - or not?
[...]
>
> b. Is the best field X3DLightNode shadowIntensity?  Default value is 0.0
(for backwards compatibility of X3D content).  Is that sufficient to omit a
boolean?
>
> OK on both counts...
>
> * SFFloat [in out] shadowIntensity  1  [0,1]

Default should be 0.0 ("no shadows"), as you write in the paragraph
above. This is not just for backward compatibility, it's also because
activating shadows has a performance cost. Don't even think about
activating shadows from all your 100 light sources :) So shadows
should stay "off" by default. This is also what Blender, Unity, CGE
do.

>
> ---
>
> c. Do we also provide a boolean field on Shape nodes indicating they can
cast shadows?  If so, then is default on or off?
>
> Considered HELPFUL.  Not considered difficult.
>
> * SFBool [in out] castShadows FALSE
>
> Defaults to FALSE for backwards compatibility with all existing X3D/VRML
content.  Authors must deliberately add shadows if they want them.

Should default to "TRUE". Otherwise authors may be confused, needing
to mark shapes as "shadow casters", otherwise shadows will not do
anything.

Also in Blender, Unity and Castle Game Engine the default state is
"shadow caster = yes".

Castle Game Engine already has this field, but with different name
"shadowCaster" (
https://castle-engine.io/x3d_extensions_shadow_maps.php#section_shadow_caste
r).
I confirm it works well with shadow volumes and shadow maps. I agree
that the name "castShadows" is better than mine :)

Regards,
Michalis

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org