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

John Carlson yottzumm at gmail.com
Tue Oct 20 09:11:57 PDT 2020 

What about umbra and penumbra?

John

On Tue, Oct 20, 2020 at 10:55 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> The only suggestion I would have is to go back to "shadowIntensity"
> rather than "shadowsIntensity", for better grammar in my ears, and for
> friendly integration of existing browsers such as InstantReality.
> Perhaps then also use "shadow" rather then "shadows".
>
> Thanks, -Andreas
>
> On Tue, Oct 20, 2020 at 10:58 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > Thank you, this looks OK!
> >
> > I only have a comment for this sentence:
> >
> > """The shadowsIntensity field defines degree of darkness produced,
> > ranging from 0 (for no visible shadows) to 1 (for full-intensity
> > shadows).""""
> >
> > Shadows do not "produce darkness", this is not true in reality and not
> > true in computer graphics :) Shadows obscure lighting. So I would
> > change it to
> >
> > """The shadowsIntensity field defines how much light is obscured by
> > shadow casters, ranging from 0 (light not obscured, no visible
> > shadows) to 1 (light obscured completely, full-intensity shadows).""""
> >
> > Regards,
> > Michalis
> >
> > wt., 20 paź 2020 o 16:39 Don Brutzman <brutzman at nps.edu> napisał(a):
> > >
> > > Thanks for correlation to other tool definitions, and excellent
> suggestions on where to set the defaults for maximum authorability and ease
> of animation.
> > >
> > > Keeping the "shadows" boolean can help and certainly doesn't hurt.
> Hopefully have matched all of your other suggestions, they make good sense.
> > >
> > > Documented in Mantis 1327 and specification changes checked in.
> > >
> > > https://www.web3d.org/member-only/mantis/view.php?id=1327
> > > =========================================================
> > > Now that glTF-related Lighting Component design is complete, support
> for shadow definition is possible. Goal is simple markup of models to
> enable shadow definition.
> > >
> > > Multiple shadow algorithms are possible and continue to evolve. No
> special support is needed for them in X3D itself, such innovation and
> adoption can be part of how a browser might compatibly provide these
> capabilities.
> > >
> > > Additional Information: Long-running topic for many years. This issue
> provide summary of resolution.
> > >
> > > 12.3.5 X3DShapeNode and 12.4.8 Shape add the following.
> > >
> > >    SFBool [in out] castShadows       TRUE
> > >
> > > "The castShadows field defines whether this Shape casts shadows as
> produced by lighting nodes. If Shape /visible/ field is FALSE, then the
> Shape does not cast any shadows. Shape nodes defined as part of X3D version
> 3 models have this field set to TRUE when loaded within an X3D version 4
> scene."
> > >
> > > 17.3.1 X3DLightNode adds the following.
> > >
> > >    SFBool  [in,out] shadows          FALSE
> > >    SFFloat [in,out] shadowsIntensity 1     [0,1]
> > >
> > > "The shadows field indicates whether or not the parent node can cast
> shadows from illuminated X3DShapeNode geometry. The shadowsIntensity field
> defines degree of darkness produced, ranging from 0 (for no visible
> shadows) to 1 (for full-intensity shadows)."
> > >
> > > These two fields are also defined for each X3DLightNode, in this
> component and in TextureProjector component.
> > > =========================================================
> > >
> > > Implemented in X3D XML DOCTYPE and Schema, checked in and deployed.
> > >
> > >         https://www.web3d.org/specifications
> > >         https://www.web3d.org/specifications/X3dSchemaDocumentation4.0
> > >
> https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_X3DLightNode.html
> > >
> https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_DirectionalLight.html
> > >
> https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_PointLight.html
> > >
> https://www.web3d.org/specifications/X3dSchemaDocumentation4.0/x3d-4.0_SpotLight.html
> > >
> > >
> https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html
> > >
> https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#DirectionalLight
> > >
> https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#PointLight
> > >
> https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#SpotLight
> > >
> https://www.web3d.org/specifications/X3dDoctypeDocumentation4.0.html#Shape
> > >
> > > X3DUOM, Java, Python, Turtle and X3D Tooltips to follow soon as part
> of Sound Component additions.
> > >
> > > Dick and I will review specification prose during our next session,
> some adjustments may occur.
> > >
> > > So we seem to be in excellent shape here (um, so to speak).
> > >
> > > Have fun with X3D shadows!   8)
> > >
> > >
> > > On 10/19/2020 12:51 PM, Michalis Kamburelis wrote:
> > > >
> > > > 1. My first reaction is that having both a SFBool and SFFloat to
> > > > control shadows seems excessive at this stage. We wanted to have
> > > > shadows definition simple, having two fields to control "does this
> > > > light make shadows" feels too much (at this point).
> > > >
> > > >      The use-case "needs to remember 0.5678" is not convincing to me
> > > > yet, I admit. If someone needs it, then the code can save/restore
> this
> > > > value.
> > > >
> > > >      And most people will only use shadowIntensity = 0.0 or 1.0, not
> > > > partial. As per Andreas wording, what happens with partial values is
> > > > implementation-specific (because it is easy to implement for some
> > > > algorithms (shadow maps), but much harder for others (shadow volumes
> > > > in general case of multiple lights)).
> > > >
> > > > 2. That being said, this is also what Unity does, having "shadows"
> and
> > > > "shadowStrength".
> > > > https://docs.unity3d.com/ScriptReference/Light-shadowStrength.html
> > > > https://docs.unity3d.com/ScriptReference/Light-shadows.html . So I
> am
> > > > making a counter-argument to my own AD 1 here :)
> > > >
> > > > 3. *If* we decide to do this (have both SFBool and SFFloat), I will
> > > > strongly suggest:
> > > >
> > > > - call SFBool just "shadows" not "shadowEnabled", that is simpler.
> > > >
> > > > - make "shadowIntensity" default to 1.0. This way merely toggling
> > > > "shadows" to TRUE will make shadows appear. In your text, when by
> > > > default shadowEnabled = FALSE and shadowIntensity = 0.0 -> means that
> > > > authors will have to change 2 fields to actually see shadows. This
> > > > would be a source of confusion for new people ("I changed
> shadowEnable
> > > > to TRUE, but I see no shadows!").
> > > >
> > > > 4. Agreed that if you Inline X3D 3 model inside X3D 4, that the
> shapes
> > > > inside X3D 3 should cast shadows.
> > > >
> > > > 5. The prose """X3D3 Shapes loaded via Inline (or Prototype) adopt
> > > > X3D4 default behavior and cast shadows.""" :  I think you meant here
> > > > "External Prototypes", not just "Prototypes". For normal
> "Prototypes",
> > > > this statement would not make sense -- a PROTO inside X3Dv4 file is
> > > > also X3Dv4. So the shapes inside casts shadows by default simply
> > > > because in X3Dv4 castShadows = TRUE by default.
> > > >
> > > > 6. Agreed that shape with visible = FALSE doesn't cast shadows, this
> is natural.
> > > >
> > > >      (And if someone will say "I want to have fake shadows from
> > > > non-existing objects in my game", I would say that first we should
> > > > focus on use-cases that represent reality. Only later, we can think
> > > > about extending it to very special use-cases.)
> > > >
> > > > Regards,
> > > > Michalis
> > > >
> > > >
> > > >
> > > >
> > > > pon., 19 paź 2020 o 20:45 Don Brutzman <brutzman at nps.edu>
> napisał(a):
> > > >>
> > > >> Further discussion on shadows on/off: use case.
> > > >>
> > > >> - Careful authoring adjustments might determine that a specific
> shadowIntensity='0.5678' is correct.
> > > >> - Next author wants to see effect of no shadows... must currently
> set shadowIntensity='0'.
> > > >> - Requires scripting to remember/restore original value of .5678
> > > >> - Thus it helps animation to include an SFBool shadowEnable or
> shadowDisplay field:
> > > >>
> > > >> * SFBool [in out] shadowsEnabled FALSE # backwards compatible
> > > >>
> > > >> We also agree with Michalis' rationale to change Shape defaults,
> still acceptable with backwards X3D3 compatibility since the lights don't
> have shadows enabled.
> > > >>
> > > >> Test case:
> > > >> - X3D4 scene has light with shadowsEnabled  TRUE
> > > >> - X3D4 scene inlines X3D3 scene with X3D3 Shape
> > > >> - A shadow is cast, or not?  We think yes.
> > > >>
> > > >> and so will add this, and shadowIntensity, and Shape.castsShadows
> as follows:
> > > >>
> > > >> SUMMARY OF CHANGES
> > > >> ==================
> > > >>
> > > >> X3DLightNode (and all lights)
> > > >>
> > > >> * SFBool  [in out] shadowsEnabled   FALSE
> > > >>
> > > >> * SFFloat [in out] shadowIntensity  0.0    [0,1]
> > > >>
> > > >> ------------------
> > > >>
> > > >> X3DShapeNode (and thus Shape)
> > > >>
> > > >> * SFBool [in out] castShadows TRUE
> > > >>
> > > >> adding prose "If Shape /visible/ field is FALSE, then the Shape
> does not cast any shadows."
> > > >> ==================
> > > >>
> > > >> TODO: determine whether true (as written here) or not:
> > > >>
> > > >> * "X3D3 Shapes loaded via Inline (or Prototype) adopt X3D4 default
> behavior and cast shadows."
> > > >>
> > > >> We may want to generalize this for any node and any field, will
> think about it further.
> > > >>
> > > >> Have fun fine-tuning X3D4!   8)
> > > >>
> > > >>
> > > >> On 10/16/2020 10:24 AM, Don Brutzman wrote:
> > > >>> We had a very productive meeting today.
> > > >>>
> > > >>> Thanks to everyone active for all work on review, implementation
> and evaluation as we finalize X3D4 for release this year.
> > > >>>
> > > >>> Dialog always helps. Am happy to note that we are in the endgame
> for X3D4 technical improvements.
> > > >>> [...]
> > > >>
> > > >>
> > > >>
> > > >> On 10/17/2020 5:51 PM, Michalis Kamburelis wrote:
> > > >>>> 3. Shadows - or not?
> > > >>> [...]
> > > >>>> b. Is the best field X3DLightNode shadowIntensity?  Default value
> is 0.0 (for backwards compatibility of X3D content).  Is that sufficient to
> omit a boolean?
> > > >>>>
> > > >>>> OK on both counts...
> > > >>>>
> > > >>>> * SFFloat [in out] shadowIntensity  1  [0,1]
> > > >>> Default should be 0.0 ("no shadows"), as you write in the paragraph
> > > >>> above. This is not just for backward compatibility, it's also
> because
> > > >>> activating shadows has a performance cost. Don't even think about
> > > >>> activating shadows from all your 100 light sources:)  So shadows
> > > >>> should stay "off" by default. This is also what Blender, Unity, CGE
> > > >>> do.
> > > >>>
> > > >>>> ---
> > > >>>>
> > > >>>> c. Do we also provide a boolean field on Shape nodes indicating
> they can cast shadows?  If so, then is default on or off?
> > > >>>>
> > > >>>> Considered HELPFUL.  Not considered difficult.
> > > >>>>
> > > >>>> * SFBool [in out] castShadows FALSE
> > > >>>>
> > > >>>> Defaults to FALSE for backwards compatibility with all existing
> X3D/VRML content.  Authors must deliberately add shadows if they want them.
> > > >>> Should default to "TRUE". Otherwise authors may be confused,
> needing
> > > >>> to mark shapes as "shadow casters", otherwise shadows will not do
> > > >>> anything.
> > > >>>
> > > >>> Also in Blender, Unity and Castle Game Engine the default state is
> > > >>> "shadow caster = yes".
> > > >>>
> > > >>> Castle Game Engine already has this field, but with different name
> > > >>> "shadowCaster" (
> > > >>>
> https://castle-engine.io/x3d_extensions_shadow_maps.php#section_shadow_caster
> ).
> > > >>> I confirm it works well with shadow volumes and shadow maps. I
> agree
> > > >>> that the name "castShadows" is better than mine:)
> > > >> 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
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20201020/0b421f88/attachment-0001.html>

More information about the x3d-public mailing list