[x3d-public] X3D Working Group minutes, endgame review: do we include shadows?
Don Brutzman
brutzman at nps.edu
Fri Oct 23 07:18:03 PDT 2020
More considerations emerging from the shadows...
On 10/22/2020 4:12 AM, Michalis Kamburelis wrote:
>
> 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."""
Yes they are independent things... seems like your prose is running into the same phrasing issue. Once piece of geometry occludes light (triggering shadow computation) and a secondary piece of geometry is rendered showing the result.
BTW was intentionally starting with phrase "can cast shadows" since Shape has a castShadows field.
We should say more about the lights as well, since a given light might have shadows=TRUE with shadowIntensity=0 and so not having any shadow contributions.
How about
"Lights can cause shadow effects if /shadows/ field is TRUE and /shadowIntensity/ field is greater than 0.
Lit geometric objects can cast shadows on secondary geometric objects.
The amount of light reaching a given surface for rendering can be decreased if a light source
is obscured by intermediate occluding geometry."
(which is already followed by)
"Intervening geometry is only considered for occlusion effects when the <i>X3DShapeNode</i> field <i>castShadow</i> is TRUE."
> 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.
Am thinking that making secondary shadows optional (rather than always required) gives browsers leeway to limit the fidelity of secondary shadow effects without being considered noncompliant to the specification.
Maybe we should be silent on this... but seems that there are some important additional cases to consider.
a. What about
- Light shadows=true shadowIntensity=0.25
- light on left, 10 boxes with castShadow=true on right, all in a row
- Cone on far right with all boxes obscuring the light.
Does rendering of each successive box have progressively darker shadow influence?
Do you have to compute 10 secondary shadows before rendering the Cone?
---
b. Another case we haven't considered is light "within" a shape:
- Same light in center
- 10 concentric boxes of sequentially greater size around it
- Cone on outside on far right
Do you have to compute 10 secondary shadows before rendering the Cone?
---
c. Single polygon casting a shadow
- Same light in center
- One quadrilateral to the right, normal vector pointing away
- Cone on far right
Does the away-facing polygon cast a shadow on the Cone?
Is there any difference if the normal is reversed, pointing to the light?
As currently written, the specification simply casts a shadow if a Shape is in between, with no consideration of inside/outside.
---
d. Seems to me that circumstances might get further complex, for example a global light in a courtyard with 100 buildings blocking it from the viewer. At what point does the browser stop casting real-time shadows?
---
Perhaps we should say more, perhaps not. But not requiring advanced computation seems prudent for establishing expectations, and is consistent with our current focus on modeling shadow elements rather than optical fidelity.
Thanks for considering these cases.
> Regards,
> Michalis
likewise
> 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
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
More information about the x3d-public
mailing list