[x3d-public] X3D Working Group minutes, endgame review: do we include shadows?
Don Brutzman
brutzman at nps.edu
Tue Oct 20 07:39:41 PDT 2020
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
More information about the x3d-public
mailing list