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

Mon Oct 19 12:51:25 PDT 2020

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