[x3d-public] Shadows
Don Brutzman
brutzman at nps.edu
Mon Oct 5 14:54:01 PDT 2020
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
More information about the x3d-public
mailing list