[x3d-public] Shadows
Michalis Kamburelis
michalis.kambi at gmail.com
Mon Oct 5 16:06:54 PDT 2020
As for the shadows color, I second what Andreas said: shadows are
*not* black, shadows merely mean that light from a given light source
doesn't reach there. The result of the shadows computation can be
elegantly inserted in the middle of the existing light equations,
light contribution is scaled by "(1-light.shadowIntensity *
howMuchIsThisInShadow(geometryPoint,light))"
As for shadows scope: for beginning, I would indeed leave it as-is,
which means that
- shadow caster == everything
- shadow receiver == stuff that is affected by the light source
(following the existing light source behaviour)
In CGE I have a more flexible mechanism, to explicitly list shadow
receivers, and control the shadow casters, but I feel that if we go
this direction -> we go into complicating :) For reference, CGE stuff
for shadow maps is on
https://castle-engine.io/x3d_extensions_shadow_maps.php , in
particular we have
Appearance {
...
MFNode [] receiveShadows [] # [X3DLightNode] list
SFBool [in,out] shadowCaster TRUE
}
This allows to configure at Appearance of each shape whether it casts
shadows, and from what light sources it receives shadows. It's very
flexible, and frankly has very low usage in practice... Authors don't
want to think about these details, they want to treat shadows as
"simple property of the light source, and everything else should Just
Work" :)
For reference, I also looked at Unity shadows configuration:
- https://docs.unity3d.com/ScriptReference/Light.html (search Ctrl+F
for "shadows")
- in particular the main property is "Light.shadows" ,
https://docs.unity3d.com/ScriptReference/LightShadows.html with is an
enum and can be None, Hard, Soft
- there is also "Light.shadowStrength" ,
https://docs.unity3d.com/ScriptReference/Light-shadowStrength.html so
it matches Don's proposed name
- each mesh also has settings to control whether it receives and/or
casts shadows, https://docs.unity3d.com/Manual/class-MeshRenderer.html
Regards,
Michalis
wt., 6 paź 2020 o 00:21 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> Michalis, Don,
>
> As a data point, I just checked and x_ite. Both allow and implement
> [in] for shadowIntensity. x_ite probably generates the out event,
> x3dom probably does not but that is not performance related.
>
> I feel that shadowIntensity works well as a name, and is self
> explanatory. There is little risk of confusion with intensity.
>
> I do not think shadows would be expected to have a color. Shadows are
> a deficit of light. The light itself is colored but shadows are not.
>
> Any thoughts on the scope of shapes which receive shadows ? All shapes
> in the scene, eg. global, or just the ones in the scope of the light.
> Scoped shadow would potentially perform better. Is there a situation
> where there is scoped light, say a room in a building but the shadows
> from the light should be shown outside the scope, eg. outside the room
> ?
> If there is a window in the room, shadows from window decorations
> should be shown on the street outside. But this also requires that
> light from the room gets out of the window, so would not be scoped to
> the room anymore.
> I think this example generalizes. So I think only shapes within the
> scope of the light can receive shadows from obstructing the light.
> Probably there is no need for spec. language on this scoping.
>
> -Andreas
>
> On Mon, Oct 5, 2020 at 5:54 PM Don Brutzman <brutzman at nps.edu> wrote:
> >
> > Understand what you're saying Michalis, hmmm. Authoring/performance tradeoff analysis:
> >
> > - If initializeOnly then no animation of shadowIntensity is possible. Seems like this is an important authoring option at run time to see if shadows are at proper intensity. Also a likely animation technique.
> >
> > - Meanwhile authors can control whether this parameter is exposed to end users by interface (typically it is not) and so avoid any performance clobbers.
> >
> > - When putting parameters in X3D specification we try to design for long term, browser cleverness and Moore's Law both integrate nicely over time.
> >
> > Naming curiosity: shadowIntensity indicates degree of darkness applied, as opposed to more-common intensity field which is degree of lightness/brightness.
> >
> > - Just wondering, perhaps we should call it shadowStrength or somesuch?
> >
> > Also wondering, shouldn't we specify "All shadows are black" in the prose definition.
> >
> > Have fun thinking about X3D! 8)
> >
> > ---
> >
> > p.s. Double reverse, in case anyone isn't dizzy yet:
> >
> > * Peter Gabriel, 'White Shadow'
> > https://en.wikipedia.org/wiki/Peter_Gabriel_(1978_album)
> > https://petergabriel.com/video/white-shadow
> >
> >
> >
> > On 10/5/2020 2:15 PM, Michalis Kamburelis wrote:
> > >
> > > Yes, (almost) exactly.
> > >
> > > The only change I would do to what Don wrote is that I would start by making shadowIntensity initializeOnly, i.e. [] instead of [in,out]. While changing it at runtime is possible (as with everything), it could have very big cost when changing from 0 to 1. I'm not strongly opposed to [in,out], just saying I would start with [] and see at adoption in browsers and think about "upgrading" to [in,out] in next version.
> > >
> > > Regards,
> > > Michalis
> >
> >
> > On 10/5/2020 2:09 PM, Andreas Plesch wrote:
> > >
> > >
> > > Hi Don,
> > >
> > > I believe the specifics is what we are trying to determine. I would
> > > say, yes, exactly, such a signature and the abstract node
> > > (X3DLightNode) would be how the field is applied.
> > >
> > > It would be backward compatible, with a default of 0, eg. no shadows.
> > >
> > > Let me also bring up that as far as I have seen lighting and shadow
> > > casting in other frameworks often works on a per Shape (equivalent)
> > > basis. Each shape defines for itself how it is lighted, and if it
> > > casts or receives shadows. For shadows this approach can make sense
> > > since shadowing is expensive and benefits from this kind of fine
> > > control. I do not really think there are implications for a simple
> > > shadowIntensity field in X3D but I thought it would be useful to
> > > mention.
> > >
> > > -Andreas
> >
> > > W dniu pon., 5.10.2020 o 21:50 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> napisał(a):
> > >
> > > Specifics please: are you gentlemen talking about adding backwards-compatible field signature of
> > >
> > >
> > >
> > > SFFloat [in,out] shadowIntensity 0 [0,1]
> > >
> > >
> > >
> > > to X3DLightNode (and thus DirectionalLight, PointLight, SpotLight)?
> > >
> > >
> > >
> > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#X3DLightNode
> > >
> > >
> > >
> > > =============================================
> > >
> > > 17.3.1 X3DLightNode
> > >
> > >
> > >
> > > X3DLightNode : X3DChildNode {
> > >
> > > SFFloat [in,out] ambientIntensity 0 [0,1]
> > >
> > > SFColor [in,out] color 1 1 1 [0,1]
> > >
> > > SFBool [in,out] global FALSE
> > >
> > > SFFloat [in,out] intensity 1 [0,∞]
> > >
> > > SFNode [in,out] metadata NULL [X3DMetadataObject]
> > >
> > > SFBool [in,out] on TRUE
> > >
> > > }
> > >
> > > =============================================
> > >
> > >
> > >
> > >
> > >
> > > On 10/5/2020 7:08 AM, Andreas Plesch wrote:
> > >
> > > >
> > >
> > > > I think the exact interpretation of intermediate values would be
> > >
> > > > implementation dependent in any case. It may be ok to just stay that.
> > >
> > > >
> > >
> > > > "
> > >
> > > > shadowIntensity ranges from 0 to 1.0 [could be omitted because the
> > >
> > > > range is defined in the signature]. A value of 0, the default, has no
> > >
> > > > effect. A value of 1.0 has the effect that no light emitted by the
> > >
> > > > node reaches the areas where shadows are cast by shapes in the scope
> > >
> > > > of the light. A value between 0 and 1.0 has the effect that an
> > >
> > > > intermediate amount of light reaches shadowed areas. Support for
> > >
> > > > intermediate values is browser dependent.
> > >
> > > > "
> > >
> > > >
> > >
> > > > Only shapes in the scope of a light can cast shadows since only those
> > >
> > > > shapes are lit by the light. One general question then is which shapes
> > >
> > > > should be able to receive shadowing. Potentially all shapes in the
> > >
> > > > scene but perhaps it makes sense to restrict receiving shapes also to
> > >
> > > > the scope of the light ? The wording above does not offer further
> > >
> > > > detail which would mean that the browser is given room to answer that
> > >
> > > > question.
> > >
> > > >
> > >
> > > > -Andreas
> > >
> > > >
> > >
> > > >
> > >
> > > > On Mon, Oct 5, 2020 at 6:56 AM Michalis Kamburelis
> > >
> > > > <michalis.kambi at gmail.com <mailto:michalis.kambi at gmail.com>> wrote:
> > >
> > > >>
> > >
> > > >> From Castle Game Engine / view3dscene side, I can go for "SFfloat
> > >
> > > >> shadowIntensity" with this interpretation too :)
> > >
> > > >>
> > >
> > > >> Compared to my earlier proposal "SFBool shadows", the
> > >
> > > >> "shadowIntensity" is obviously more flexible, I can see the
> > >
> > > >> advantages. And with shadow maps, it is easy to support any
> > >
> > > >> intermediate value, e.g. allow 0.5 of the light to reach the surface.
> > >
> > > >>
> > >
> > > >> With shadow volumes it's not possible (at least not easily) but then
> > >
> > > >> the implementation can always go with simple Andreas' wording """0
> > >
> > > >> means no shadows, 1 means full shadow.""". We would need to say what
> > >
> > > >> happens for intermediate values in this case, e.g. "if implementation
> > >
> > > >> only supports 0.0 and 1.0, then any value >= 0.5 behaves like 1.0,
> > >
> > > >> otherwise (value < 0.5) behaves like 0.0".
> > >
> > > >>
> > >
> > > >> Regards,
> > >
> > > >> Michalis
> > >
> > > >>
> > >
> > > >> pon., 5 paź 2020 o 04:49 Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> napisał(a):
> > >
> > > >>>
> > >
> > > >>> As motivation to make Shadows a high priority for the next version let
> > >
> > > >>> me share Holger's cool idea to use Sponza for shadows:
> > >
> > > >>>
> > >
> > > >>> https://create3000.github.io/media/examples/Navigation/NavigationInfo/example.html
> > >
> > > >>>
> > >
> > > >>> I could adopt it pretty much as is for x3dom:
> > >
> > > >>>
> > >
> > > >>> https://raw.githack.com/andreasplesch/x3dom/scopedLights/test/functional/scopedLights/inline.html
> > >
> > > >>>
> > >
> > > >>> (without the nice ParticleSystem, and with slightly changed
> > >
> > > >>> intensities and locations).
> > >
> > > >>>
> > >
> > > >>> The main required field for both x3dom and x_ite to enable shadows is
> > >
> > > >>> shadowIntensity. 0 means no shadows, 1 means full shadow.
> > >
> > > >>>
> > >
> > > >>> -Andreas
> >
> >
> > 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
More information about the x3d-public
mailing list