[x3d-public] lights in switch nodes

Andreas Plesch andreasplesch at gmail.com
Sat May 12 14:18:41 PDT 2018


Michalis,

that is great background, I was not aware that DirectionalLight has
local scope by default while the other light are global by default.
Defaults are hard to update since scenes are encouraged to rely on
them. On the other hand new X3D users not being aware of history would
find it confusing that DirectionalLight is local, so perhaps that is
an possible topic for discussion for the next X3D version.

I put together a simple scene to test global lights in a Switch node:

https://x3d-switch-global-light.glitch.me/simpleLight.x3d

It is supposed to show a blinking sphere where the point light adds a
bit of red.

Most browser show the expected display:

- view3dscene
- x_ite
- Octaga 5.0
- BS Contact
- H3DViewer
- freeWRL4.0
- x3dom with fix

These keep the red light always active:

- InstantPlayer2.3.0
- x3dom


Best,
-Andreas










On Fri, May 11, 2018 at 10:15 PM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
> Note that we are touching two (independent) X3D specification rules
> about lights in this thread:
>
> (I just wanted to clarify that -- it doesn't contradict anything
> anyone said, I think :) )
>
> 1. One rule is that lights that are not traversed (e.g. are in unused
> Switch or LOD child) should not have any effect on the visible shapes.
> I.e. these lights do not contribute to the visible shapes' color.
>
> 2. The other rule is that lights can be global or not global (X3D spec
> "17.2.1.2 Scoping of lights"). This is controlled by the "global"
> field, which is by default TRUE for PointLight and SpotLight (meaning
> that they shine on all the geometry in the scene), and FALSE for
> DirectionalLight (meaning it shines only at shape nodes that are
> sibling nodes or lower).
>
>     This is backward-compatible with VRML 97, however VRML 97 didn't
> have a field "global" to change this. With X3D, you can just set
> global=TRUE on all the lights, if you don't want scoped lights.
>
>     The PointLight and SpotLight are by default global=TRUE, because
> they are limited anyway by their "radius" field, so they will not
> affect *every shape* on large scenes. The DirectionalLight is by
> default global=FALSE, because it doesn't have a radius, and
> DirectionalLight with global=FALSE would affect all the shapes in the
> scene, which would not be optimal. While modern rendering methods do
> not have the old fixed-function OpenGL limit of "8 lights per shape",
> in practice you should still limit your lights-per-shape to have a
> decent FPS, at least for classic "forward rendering" approach (as
> opposed to "deferred rendering", which has different considerations).
> I think it's reasonable for a renderer using "forward rendering" to
> use only the first e.g. 8 lights (at this shape), even when using
> shader rendering being able to in theory calculated 100 lights. It's
> reasonable to have 100 lights on a large scene, but each particular
> shape can probably be rendered accurately with at most 8 lights :)
>
>     The VRML 97 Annotated Reference about DirectionalLight (
> http://www.x-3-x.net/vrml/archive/annotatedVRML2/BOOK.HTM,
> http://www.x-3-x.net/vrml/archive/annotatedVRML2/CH3.HTM#DirectionalLight
> ) gives a reasoning for it.
>
>     The fact that Blender doesn't set global=TRUE on DirectionaLights
> is just a bug in Blender exporter, IMHO :)  It is also fixed in Castle
> Game Engine modified version of X3D exporter, see
> https://castle-engine.io/creating_data_blender.php ,
> https://github.com/castle-engine/castle-engine/wiki/Blender . If
> anyone has some time, it should be reported to the Blender's devs.
>
> Note that all the conditions above must be satisfied in order for the
> light to shine (contribute to a color) on a given shape:
>
> - The light node must be traversed (e.g. be in an active Switch or LOD child).
> - The shape must be within the light node scope (if global=FALSE).
> - The shape must be within the light node radius (for PointLight, SpotLight).
>
> This is all written of course based on my understanding on VRML and
> X3D specs :) The view3dscene and Castle Game Engine behave like this.
>
> Some of my testcases:
>
> - https://github.com/castle-engine/demo-models/blob/master/lights_materials/lights.x3dv
> - https://github.com/castle-engine/demo-models/blob/master/lights_materials/directional_light_scope.wrl
> - https://github.com/castle-engine/demo-models/blob/master/lights_materials/cubes_mesh_large.wrl
>
> Regards,
> Michalis



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list