[x3d-public] proposed LocalLight, LightableGroup nodes, was combine light scoping with rotation

[doug sanden]

>
>>
>> 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
>
> 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.
>
> Would this work?

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