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

Wed Oct 21 01:33:44 PDT 2020

Richard,

This question is solved by the equation I propose above, with
"shadowTest_i". In general these kinds of questions are easy if you
realize that "the light source contribution is scaled down by shadows"
(which is true also in reality), that is why I'm pushing to follow
this prose in this thread. Do not think "shadows cast by a particular
light source [...] may be overlayed by shadows form another light
source" because that is not how shadows work, shadows are *not* some
dark objects that are drawn on each other, even if it may look like
that.

So following my equation, for 2 light sources you would have (simplifying):

finalColor =
  on_0 * shadowTest_0 * lightColor_0 * (.... the rest of light 0
contribution ...) +
  on_1 * shadowTest_1 * lightColor_1 * (.... the rest of light 1
contribution ...)

So what happens when, at a given place, both light 0 and light 1 are
obscured? Answer: then shadowTest_0 is < 1, and shadowTest_1 is < 1
(how much, it depends on their shadowIntensity). So the contribution
of each light source is scaled down by the shadowIntensity at this
light.

Regards,
Michalis

śr., 21 paź 2020 o 03:18 Richard F. Puk <puk at igraphics.com> napisał(a):
>
> 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
>