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

Tue Oct 20 18:18:02 PDT 2020

Hi, Michelis --

My worry is if multiple light sources are casting shadows from different directions with each light source having a different color. The effect on shadows when shadows from one light source are partially illuminated by a different light with a different light color should be described. The shadows cast by a particular light source with one color may be overlayed by shadows form another light source with a different color. How do we describe how the shadow effect is colored? For example, a shadow cast by a white light may be partially illuminated by a shadow cast from a different direction from a, say, green light. Since X3D is required to support at least eight light sources each of which can be a different color and emanating from a different direction, the interaction of their various shadows needs to be described. What does physics say?

  -- 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: Tuesday, October 20, 2020 3:04 PM
To: Don Brutzman
Cc: Andreas Plesch; Holger Seelig; doug sanden; X3D Graphics public mailing list
Subject: Re: [x3d-public] X3D Working Group minutes, endgame review: do we include shadows?

Your prose:

"""
Lights can cast shadows that reduce the intensity of light behind
occluding shapes.

Shadows from multiple lights interact in a cumulative fashion.

Secondary Shape geometry that is occluded behind an intervening Shape
already casting a shadow does not cast a secondary shadow.
"""

This sounds convoluted, because it follows the idea that shadows
"produce something (darkness), that may be cummulated" :) It is more
straightforward (and true) to follow the thinking that shadows mean
that lighting is obscured, which e.g. makes it obvious without any
extra explanation that there's no such thing as "secondary shadow".
Here's my proposal instead:

"""
Lights can cast shadows, which means that the amount of lighting
reaching the surface is decreased if the light source is obscured at
the given point.

Multiple light sources can have shadows enabled. Contribution of each
light source is scaled down independently.
"""

The modification to lighting equations is quite simple. Where there's
"on_i" right now, it should be changed to "on_i * shadowTest_i" with
the following definition:

"""
shadowTest_i scales down the light contribution depending on shadow:

- shadowTest_i is 1.0 if the light source i has "shadow" = FALSE

- otherwise, shadowTest_i is 1.0 if the light source i has "shadow" =
TRUE but nothing obscures the light, i.e. there is no Shape (that has
visible and castShadow = TRUE) between the light source position and
the given point. The DirectionalLight is treated like a "point in
infinity", which means that shadow rays are all parallel to the light
direction.

- otherwise, shadowTest_i is "1.0 - shadowIntensity". This occurs when
"shadow" = TRUE and the light is obscured. For example,
"shadowIntensity" equal 1.0 (the default) means that light
contribution drops to zero when the light is obscured by the shadow
caster.
'"""

Note that it means that *all* light contribution is scaled down,
including ambient term in case of Phong lighting model. And I say this
is deliberate, otherwise Phong and physical lighting models would
require a bit different treatment for shadows, which causes more
problems than it solves IMHO. In physical lighting model there's no
notion of "ambient" anyway.

BTW, note that future EnvironmentLight will require a bit different
treatment. But we'll cross that bridge in the future, not to worry now
:) (My proposal will be that """It is optional for EnvironmentLight to
support shadows. If it does, it means that at each point, shadow is
applied, estimating how much of the sphere area around the given point
is obscured, assuming that light is cast from a sphere centered in the
middle of the Shape. Some implementations may limit this to
self-shadowing (i.e. only taking into account the same Shape).""" This
is implementable using e.g. radiance transfer.)

Regards,
Michalis

wt., 20 paź 2020 o 20:45 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Close inspection shows that ShadedVolumeStyle includes field "shadows" so we should keep this one the same.
>
> * X3D4 Tooltips ShadedVolumeStyle shadows
>    https://www.web3d.org/x3d/tooltips/X3dTooltips.html#ShadedVolumeStyle.shadows
>
> * X3D4 Volume rendering component, 41.4.10 ShadedVolumeStyle
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/volume.html#ShadedVolumeStyle
>
> Keeping X3DLightNode shadowIntensity and X3DShapeNode castShadow singular seems OK still.
>
> On 10/20/2020 10:20 AM, Don Brutzman wrote:
> >
> > Yes to Andreas on singular use of "shadow*" throughout which also facilitates search.  Was striving for consistency, this helps.
> >
> > Will apply shadows* -> shadow* change to DOCTYPE/Schema later.
>
> 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