[x3d-public] Shadows

[Andreas Plesch]

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


On Mon, Oct 5, 2020 at 3:50 PM Don Brutzman <brutzman at nps.edu> wrote:
>
> 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> 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> 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
> >>> --
> >>> Andreas Plesch
> >>> Waltham, MA 02453
>
> 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