[x3d-public] x3d-public Digest, Vol 76, Issue 29

[Andreas Plesch]

> >> snip
> >>
> >>>> Perhaps light scope would need to be defined more flexibly than the
> >>>> global field allows. I could see a "scope" field which defaults to
> >>>> 'global' and otherwise contains the DEF of a group to which the light
> >>>> should be applied. Would this interfere with some default logic of
> >>>> scene traversal ?
> >>>
> >>> That's interesting, may lead to some ideas, but has a gotcha: the
> >>> transform stack above the DEF is needed too in order to pose the light
> >>
> >>
> >> Yes, the full transform stack affecting the group to be illuminated by
> >> the scoped light needs to be known to actually produce the correct
> >> rendering. I am rephrasing to make sure I understand. If I do, I am not
> >> sure where the gotcha is. Is something not well defined ? Or is it a
> >> potentially prohibitive difficulty in implementation ?
> >>
> >> There may be other ways to define a separation of the light scope from
> >> the lights position in the grouping and therefore transform hierarchy
> >> but I cannot think of one. Some wilder ideas are to use the routing
> >> concept ? "route" a light to a group ? Or have a separate hierarchy
> >> just for scoped lighting ?
> >
> >
> > The PickSensor has 2 parts in different sections of the scenegraph:
> >
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/picking.html#Abstracttypes
> > - pickableObject and pickSensor are in 2 different places in the
> scenegraph


I read through but still feel unfamiliar with this component.  So
PickableGroup tags its children as (un-)pickable.  And pickSensor
references the geometries it observes as children in its pickTarget field.

The transformation hierarchy is explicitly specified:

All transformations above those picked objects [in the pickTarget field)
are applied to the picking process. Picking is performed in world
coordinate space after transformations have been applied to both the pick
sensor and the target nodes.

Hm, this seems to describe the 'regular' hierarchical transform stack.

> New LocalLight / LightableGroup node types could likewise be split into 2
> parts
> > - the part that defines where the light is ie LocalLight, which could
> wrap/parent any of the current light types, and be anywhere in the
> scenegraph
> > - the part that is in the scenegraph where the geometry to be lit is
> -analogous to pickableGroup- wraps/parents the scengraph branch to be lit
> by the light ie LightableGroup
> > - a number or DEF name would/could link the two
> > - the software on each frame would
> > a) do a lighting pass first, to position each LocalLight in the scene
> (the locallight node would store the last transformed pose)
> > b) do the rendering pass and when it gets to LightableGroup, would do
> some matrix inverse and multiply to get the LocalLight transform into the
> current transform stack, and push the light onto the light stack, before
> rendering the children, then popping the light of the stack.
> >
>
Problem: what if there are multiple lights to be applied to a single
> object? That's why the sibling approach works better: there's a place to
> list multiple lights: as siblings in a parent's children field.
> So instead of LightableGroup it would/could/should be LightSibling.
> Or else LightableGroup could/should have an MFnode field for LocalLights.
> -D


Something like this ?

<LightableGroup>
  <Shape DEF='illuminated by scoped light'>
  ..
  </Shape>
  <LocalLight DEF='scopable light1' >
    <DirectionalLight />
  </LocalLight>
  <LocalLight DEF='scopable light2' >
    <DirectionLight />
  </LocalLight>
</LightableGroup>
<Shape DEF='not illuminated by scoped light'>

This way LightableGroup defines a many to many mapping between geometries
and lights and lets each light and geometry have its own transformations. I
think this would work. The key is to have an enclosing parent. Perhaps the
LocalLight wrapper would not be necessary if all lights in LightableGroup
could be defined as local lights ? Then the name could be something like
"LightScope" since the group in effect defines a scope.

<LightScope>
  <Shape DEF='illuminated by scoped light'>
  ..
  </Shape>
  <DirectionalLight />
  <DirectionalLight />
</LightScope>
<Shape DEF='not illuminated by scoped light'>

There could be a hierarchy of light scopes within light scopes. One could
DEF/USE lights to reuse in a different scope. Rendering would need to
accumulate all lights in and above a scope level plus the global lights to
apply to the geometries within that scope level (not above or below). A
boolean field "omit_global" to control the application of global lights may
be necessary. I think regular transform stacking would apply, eg.
LightScope would be a grouping node.

This probably needs some more thinking through,

-Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150730/9fe1fc38/attachment.html>