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

Thu Oct 22 04:12:14 PDT 2020

That is better! I still have problems with 2 sentences:

1. """Lighted geometric objects can cast shadows, meaning that the
amount of light reaching a given surface is decreased if a light
source is obscured by occluding geometry. """

    This is hard to read, because you talk about shadow casters and
shadow receivers like they would be the same thing. They are
independent things. Please change to

    -> """Lit geometric objects can have shadows. The amount of light
reaching a given surface is decreased if a light source is obscured by
occluding (shadow casting) geometry."""

2. Please remove this sentence """Secondary Shape geometry that is
already occluded behind an intervening Shape casting a shadow is not
required to cast a secondary shadow."""  . There's no such thing as a
secondary shadow -- there's no such thing in reality, there's no such
thing in modern shadow algorithms, there's no such thing in equations
I proposed above. The prose is more clear to me *without* this
sentence.

Regards,
Michalis

czw., 22 paź 2020 o 03:39 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Thanks for improved prose and continuing discussion, have further refined the draft.  We also do not want to forbid advance rendering capabilities, so I added a paragraph allowing some variation.
>
> How does the following look?  Questions and improvements welcome.  Have checked it in so that we are progressing steadily:
>
> ============================
> 17.2.2.8 Shadows
>
> Lighted geometric objects can cast shadows, meaning that the amount of light reaching a given surface is decreased if a light source is obscured by occluding geometry. Intervening geometry is only considered for occlusion effects when the /X3DShapeNode/ field /castShadow/ is TRUE.
>
> Multiple light sources can have shadows enabled. Lighting contributions from each light source, and the intensity of corresponding shadows that reduce light available at end points, are each computed independently before reaching lit surface points.
>
> Browser implementations are allowed some variations in shadow rendering. Secondary Shape geometry that is already occluded behind an intervening Shape casting a shadow is not required to cast a secondary shadow. High-fidelity physical effects such as umbra, penumbra and antumbra may be optionally applied during /shadowIntensity/ computations.
> ============================
>
> Next: the lighting equation computations (and subsequent discussion with Dick) all seem sensible to me.
>
> However not clear how to apply this to specification prose as written... you are welcome to integrate those if you like.  A further editorial pass for readability and conciseness is still planned by Dick and I for the Concepts section.
>
> On 10/20/2020 1:03 PM, Michalis Kamburelis wrote:
> >
> > 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
>
> 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