[x3d-public] combine light scoping with rotation

[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 ?

Q. would it work to rotate the parent instead of the light, then
> counter-rotate the shape sibling so as to nullify the shape being rotated??
>

Like this ?

<Transform rotation='rot'>
  <dLight direction='0 0 1' />
  <Transform rotation='counter_rot'>
    <Shape DEF='illuminated'>
..
    </Shape>
  </Transform>
</Transform>
<Group DEF='not illuminated'>
....
</Group>

Yes, I think that would work in principle. How do you get the
counter-rotation of the rotation output of a SphereSensor within x3d ? With
a x3d script which negates the amount of rotation but retains the axis ?
[To counter a GeoLocation transform a more general inverse of a full
transformation matrix needs to be derived since both translation and
rotation is involved.]
While this would work, it feels to me more like a work around than a proper
solution.

Or would having a transform around the shape cause the light to not find
> its local geometry in the browser of your choice?
>

The browser I am mostly interested in is x3dom but the choice should not
matter too much. x3dom does not support light scoping and x3d scripting.


> Do you have a sample scene?
>

I wanted to use light scoping here:

http://andreasplesch.github.io/x3dom/GeoElevationGrid_texture/terrain_spheresensor.xhtml

in order to quickly compare the effects of different kinds of shading.

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