[x3d-public] Shadows

Don Brutzman brutzman at nps.edu
Mon Oct 5 12:50:50 PDT 2020


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> 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> 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
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453

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