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

[Don Brutzman]

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