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

[John Carlson]

What can we learn from "The Rendering Equation"--Kajiya Is that still the
most up-to-date?

John

On Tue, Oct 20, 2020 at 8:19 PM Richard F. Puk <puk at igraphics.com> wrote:

> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201020/f732e789/attachment.html>