<div dir="ltr">Q1. would shadows look like SketchUp shadows?<div>Q2. does x3d have an appearance for the edge lines like SketchUp?</div><div>Q3. when does the SketchUp push/pull patent expire?</div><div>Doug Sanden</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 5, 2020 at 5:08 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As for the shadows color, I second what Andreas said: shadows are<br>
*not* black, shadows merely mean that light from a given light source<br>
doesn't reach there. The result of the shadows computation can be<br>
elegantly inserted in the middle of the existing light equations,<br>
light contribution is scaled by "(1-light.shadowIntensity *<br>
howMuchIsThisInShadow(geometryPoint,light))"<br>
<br>
As for shadows scope: for beginning, I would indeed leave it as-is,<br>
which means that<br>
<br>
- shadow caster == everything<br>
- shadow receiver == stuff that is affected by the light source<br>
(following the existing light source behaviour)<br>
<br>
In CGE I have a more flexible mechanism, to explicitly list shadow<br>
receivers, and control the shadow casters, but I feel that if we go<br>
this direction -> we go into complicating :) For reference, CGE stuff<br>
for shadow maps is on<br>
<a href="https://castle-engine.io/x3d_extensions_shadow_maps.php" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_extensions_shadow_maps.php</a> , in<br>
particular we have<br>
<br>
Appearance {<br>
...<br>
MFNode [] receiveShadows [] # [X3DLightNode] list<br>
SFBool [in,out] shadowCaster TRUE<br>
}<br>
<br>
This allows to configure at Appearance of each shape whether it casts<br>
shadows, and from what light sources it receives shadows. It's very<br>
flexible, and frankly has very low usage in practice... Authors don't<br>
want to think about these details, they want to treat shadows as<br>
"simple property of the light source, and everything else should Just<br>
Work" :)<br>
<br>
For reference, I also looked at Unity shadows configuration:<br>
<br>
- <a href="https://docs.unity3d.com/ScriptReference/Light.html" rel="noreferrer" target="_blank">https://docs.unity3d.com/ScriptReference/Light.html</a> (search Ctrl+F<br>
for "shadows")<br>
<br>
- in particular the main property is "Light.shadows" ,<br>
<a href="https://docs.unity3d.com/ScriptReference/LightShadows.html" rel="noreferrer" target="_blank">https://docs.unity3d.com/ScriptReference/LightShadows.html</a> with is an<br>
enum and can be None, Hard, Soft<br>
<br>
- there is also "Light.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> so<br>
it matches Don's proposed name<br>
<br>
- each mesh also has settings to control whether it receives and/or<br>
casts shadows, <a href="https://docs.unity3d.com/Manual/class-MeshRenderer.html" rel="noreferrer" target="_blank">https://docs.unity3d.com/Manual/class-MeshRenderer.html</a><br>
<br>
Regards,<br>
Michalis<br>
<br>
<br>
wt., 6 paź 2020 o 00:21 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br>
><br>
> Michalis, Don,<br>
><br>
> As a data point, I just checked and x_ite. Both allow and implement<br>
> [in] for shadowIntensity. x_ite probably generates the out event,<br>
> x3dom probably does not but that is not performance related.<br>
><br>
> I feel that shadowIntensity works well as a name, and is self<br>
> explanatory. There is little risk of confusion with intensity.<br>
><br>
> I do not think shadows would be expected to have a color. Shadows are<br>
> a deficit of light. The light itself is colored but shadows are not.<br>
><br>
> Any thoughts on the scope of shapes which receive shadows ? All shapes<br>
> in the scene, eg. global, or just the ones in the scope of the light.<br>
> Scoped shadow would potentially perform better. Is there a situation<br>
> where there is scoped light, say a room in a building but the shadows<br>
> from the light should be shown outside the scope, eg. outside the room<br>
> ?<br>
> If there is a window in the room, shadows from window decorations<br>
> should be shown on the street outside. But this also requires that<br>
> light from the room gets out of the window, so would not be scoped to<br>
> the room anymore.<br>
> I think this example generalizes. So I think only shapes within the<br>
> scope of the light can receive shadows from obstructing the light.<br>
> Probably there is no need for spec. language on this scoping.<br>
><br>
> -Andreas<br>
><br>
> On Mon, Oct 5, 2020 at 5:54 PM Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
> ><br>
> > Understand what you're saying Michalis, hmmm. Authoring/performance tradeoff analysis:<br>
> ><br>
> > - If initializeOnly then no animation of shadowIntensity is possible. Seems like this is an important authoring option at run time to see if shadows are at proper intensity. Also a likely animation technique.<br>
> ><br>
> > - Meanwhile authors can control whether this parameter is exposed to end users by interface (typically it is not) and so avoid any performance clobbers.<br>
> ><br>
> > - When putting parameters in X3D specification we try to design for long term, browser cleverness and Moore's Law both integrate nicely over time.<br>
> ><br>
> > Naming curiosity: shadowIntensity indicates degree of darkness applied, as opposed to more-common intensity field which is degree of lightness/brightness.<br>
> ><br>
> > - Just wondering, perhaps we should call it shadowStrength or somesuch?<br>
> ><br>
> > Also wondering, shouldn't we specify "All shadows are black" in the prose definition.<br>
> ><br>
> > Have fun thinking about X3D! 8)<br>
> ><br>
> > ---<br>
> ><br>
> > p.s. Double reverse, in case anyone isn't dizzy yet:<br>
> ><br>
> > * Peter Gabriel, 'White Shadow'<br>
> > <a href="https://en.wikipedia.org/wiki/Peter_Gabriel_(1978_album)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Peter_Gabriel_(1978_album)</a><br>
> > <a href="https://petergabriel.com/video/white-shadow" rel="noreferrer" target="_blank">https://petergabriel.com/video/white-shadow</a><br>
> ><br>
> ><br>
> ><br>
> > On 10/5/2020 2:15 PM, Michalis Kamburelis wrote:<br>
> > ><br>
> > > Yes, (almost) exactly.<br>
> > ><br>
> > > The only change I would do to what Don wrote is that I would start by making shadowIntensity initializeOnly, i.e. [] instead of [in,out]. While changing it at runtime is possible (as with everything), it could have very big cost when changing from 0 to 1. I'm not strongly opposed to [in,out], just saying I would start with [] and see at adoption in browsers and think about "upgrading" to [in,out] in next version.<br>
> > ><br>
> > > Regards,<br>
> > > Michalis<br>
> ><br>
> ><br>
> > On 10/5/2020 2:09 PM, Andreas Plesch wrote:<br>
> > ><br>
> > ><br>
> > > Hi Don,<br>
> > ><br>
> > > I believe the specifics is what we are trying to determine. I would<br>
> > > say, yes, exactly, such a signature and the abstract node<br>
> > > (X3DLightNode) would be how the field is applied.<br>
> > ><br>
> > > It would be backward compatible, with a default of 0, eg. no shadows.<br>
> > ><br>
> > > Let me also bring up that as far as I have seen lighting and shadow<br>
> > > casting in other frameworks often works on a per Shape (equivalent)<br>
> > > basis. Each shape defines for itself how it is lighted, and if it<br>
> > > casts or receives shadows. For shadows this approach can make sense<br>
> > > since shadowing is expensive and benefits from this kind of fine<br>
> > > control. I do not really think there are implications for a simple<br>
> > > shadowIntensity field in X3D but I thought it would be useful to<br>
> > > mention.<br>
> > ><br>
> > > -Andreas<br>
> ><br>
> > > W dniu pon., 5.10.2020 o 21:50 Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>> napisał(a):<br>
> > ><br>
> > > Specifics please: are you gentlemen talking about adding backwards-compatible field signature of<br>
> > ><br>
> > ><br>
> > ><br>
> > > SFFloat [in,out] shadowIntensity 0 [0,1]<br>
> > ><br>
> > ><br>
> > ><br>
> > > to X3DLightNode (and thus DirectionalLight, PointLight, SpotLight)?<br>
> > ><br>
> > ><br>
> > ><br>
> > > <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#X3DLightNode" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#X3DLightNode</a><br>
> > ><br>
> > ><br>
> > ><br>
> > > =============================================<br>
> > ><br>
> > > 17.3.1 X3DLightNode<br>
> > ><br>
> > ><br>
> > ><br>
> > > X3DLightNode : X3DChildNode {<br>
> > ><br>
> > > SFFloat [in,out] ambientIntensity 0 [0,1]<br>
> > ><br>
> > > SFColor [in,out] color 1 1 1 [0,1]<br>
> > ><br>
> > > SFBool [in,out] global FALSE<br>
> > ><br>
> > > SFFloat [in,out] intensity 1 [0,∞]<br>
> > ><br>
> > > SFNode [in,out] metadata NULL [X3DMetadataObject]<br>
> > ><br>
> > > SFBool [in,out] on TRUE<br>
> > ><br>
> > > }<br>
> > ><br>
> > > =============================================<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On 10/5/2020 7:08 AM, Andreas Plesch wrote:<br>
> > ><br>
> > > ><br>
> > ><br>
> > > > I think the exact interpretation of intermediate values would be<br>
> > ><br>
> > > > implementation dependent in any case. It may be ok to just stay that.<br>
> > ><br>
> > > ><br>
> > ><br>
> > > > "<br>
> > ><br>
> > > > shadowIntensity ranges from 0 to 1.0 [could be omitted because the<br>
> > ><br>
> > > > range is defined in the signature]. A value of 0, the default, has no<br>
> > ><br>
> > > > effect. A value of 1.0 has the effect that no light emitted by the<br>
> > ><br>
> > > > node reaches the areas where shadows are cast by shapes in the scope<br>
> > ><br>
> > > > of the light. A value between 0 and 1.0 has the effect that an<br>
> > ><br>
> > > > intermediate amount of light reaches shadowed areas. Support for<br>
> > ><br>
> > > > intermediate values is browser dependent.<br>
> > ><br>
> > > > "<br>
> > ><br>
> > > ><br>
> > ><br>
> > > > Only shapes in the scope of a light can cast shadows since only those<br>
> > ><br>
> > > > shapes are lit by the light. One general question then is which shapes<br>
> > ><br>
> > > > should be able to receive shadowing. Potentially all shapes in the<br>
> > ><br>
> > > > scene but perhaps it makes sense to restrict receiving shapes also to<br>
> > ><br>
> > > > the scope of the light ? The wording above does not offer further<br>
> > ><br>
> > > > detail which would mean that the browser is given room to answer that<br>
> > ><br>
> > > > question.<br>
> > ><br>
> > > ><br>
> > ><br>
> > > > -Andreas<br>
> > ><br>
> > > ><br>
> > ><br>
> > > ><br>
> > ><br>
> > > > On Mon, Oct 5, 2020 at 6:56 AM Michalis Kamburelis<br>
> > ><br>
> > > > <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a> <mailto:<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>>> wrote:<br>
> > ><br>
> > > >><br>
> > ><br>
> > > >> From Castle Game Engine / view3dscene side, I can go for "SFfloat<br>
> > ><br>
> > > >> shadowIntensity" with this interpretation too :)<br>
> > ><br>
> > > >><br>
> > ><br>
> > > >> Compared to my earlier proposal "SFBool shadows", the<br>
> > ><br>
> > > >> "shadowIntensity" is obviously more flexible, I can see the<br>
> > ><br>
> > > >> advantages. And with shadow maps, it is easy to support any<br>
> > ><br>
> > > >> intermediate value, e.g. allow 0.5 of the light to reach the surface.<br>
> > ><br>
> > > >><br>
> > ><br>
> > > >> With shadow volumes it's not possible (at least not easily) but then<br>
> > ><br>
> > > >> the implementation can always go with simple Andreas' wording """0<br>
> > ><br>
> > > >> means no shadows, 1 means full shadow.""". We would need to say what<br>
> > ><br>
> > > >> happens for intermediate values in this case, e.g. "if implementation<br>
> > ><br>
> > > >> only supports 0.0 and 1.0, then any value >= 0.5 behaves like 1.0,<br>
> > ><br>
> > > >> otherwise (value < 0.5) behaves like 0.0".<br>
> > ><br>
> > > >><br>
> > ><br>
> > > >> Regards,<br>
> > ><br>
> > > >> Michalis<br>
> > ><br>
> > > >><br>
> > ><br>
> > > >> pon., 5 paź 2020 o 04:49 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>> napisał(a):<br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> As motivation to make Shadows a high priority for the next version let<br>
> > ><br>
> > > >>> me share Holger's cool idea to use Sponza for shadows:<br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> <a href="https://create3000.github.io/media/examples/Navigation/NavigationInfo/example.html" rel="noreferrer" target="_blank">https://create3000.github.io/media/examples/Navigation/NavigationInfo/example.html</a><br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> I could adopt it pretty much as is for x3dom:<br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> <a href="https://raw.githack.com/andreasplesch/x3dom/scopedLights/test/functional/scopedLights/inline.html" rel="noreferrer" target="_blank">https://raw.githack.com/andreasplesch/x3dom/scopedLights/test/functional/scopedLights/inline.html</a><br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> (without the nice ParticleSystem, and with slightly changed<br>
> > ><br>
> > > >>> intensities and locations).<br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> The main required field for both x3dom and x_ite to enable shadows is<br>
> > ><br>
> > > >>> shadowIntensity. 0 means no shadows, 1 means full shadow.<br>
> > ><br>
> > > >>><br>
> > ><br>
> > > >>> -Andreas<br>
> ><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>