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

Tue Oct 20 07:57:49 PDT 2020

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