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