<div dir="ltr"><div dir="ltr">Thanks Andreas.<div>-Doug Sanden</div><div>...</div><div>What I personally need more than shadows, is energy modeling - in particular solar heat gain.</div><div>OpenStudio / EnergyPlus / DOE-2 / Radiance - energy modeling for buildings</div><div>- Radiance uses ray tracing, but with absolute float numbers, so it gets the solar flux in absolute units</div><div>I played a bit with Radiance - its a command line program and I modified a blender exporter for it</div><div><div><a href="http://dug9.users.sourceforge.net/web3d/radiance/bradd_wiki/wiki_bradd27_blend279.html">http://dug9.users.sourceforge.net/web3d/radiance/bradd_wiki/wiki_bradd27_blend279.html</a></div></div><div>The need relates to energy retrofits for buildings. There's talk about green stimulus, and apparently building retrofits are 'low hanging fruit'.</div><div>Some of my blind/canoppy/reflector ideas need proof of concept, but would improve solar heat gain in heating months (and reduce gain in summer. Animating the geometry while rendering radiance values would be interesting / helpful.</div><div>One idea is to have an x3d browser option that raytraces a snapshot on demand ie mouse-up at end of a navigation drag, or a special key.</div><div>Another is to adapt raidiance techniques to nVidia-style real-time-raytracing.</div><div>if or how that would related to x3d I don't know.</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 6, 2020 at 9:32 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:1px solid rgb(204,204,204);padding-left:1ex">Here is how sketchup does shadows<br>
<br>
<a href="https://help.sketchup.com/en/sketchup/casting-real-world-shadows" rel="noreferrer" target="_blank">https://help.sketchup.com/en/sketchup/casting-real-world-shadows</a><br>
<br>
Q1: yes, with the on Faces option, and the ability to use any light as<br>
source for shadows. The Dark slider would correspond to the value<br>
shadowIntensity<br>
<br>
-Andreas<br>
<br>
On Tue, Oct 6, 2020 at 9:11 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> Q1. would shadows look like SketchUp shadows?<br>
> Q2. does x3d have an appearance for the edge lines like SketchUp?<br>
> Q3. when does the SketchUp push/pull patent expire?<br>
> Doug Sanden<br>
><br>
> On Mon, Oct 5, 2020 at 5:08 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>><br>
>> 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>