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