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

[doug sanden]

Andreas,
Thanks for the link to your scene, I found a few bugs in freewrl.
Here's a simplified non-geo, non-x3dom version of your scene that works in freewrl, and does the counter-rotation idea:
http://dug9.users.sourceforge.net/web3d/temp/terrain_spheresensor_simple_B.x3d

A refinement of your ideas: perhaps allowing the lights and the lit to be in completely different branches/transform-stacks of the scenegraph:

..somewhere in scenegraph...
<LocalLight DEF='scopable light1'>
<DirectionalLight />
</LocalLight>
<LocalLight DEF='scopable light2'>
<DirectionLight />
</LocalLight>
-- on a pre-rendering pass through the scenegraph, the transform stack of each LocalLight would be stored with the LocalLight (on rendering pass, skip LocalLights)

...somewhere else in scenegraph, on the rendering pass
//method A parenting shape
<LightableGroup mfnode localLights='scopable light1, scopable light 2'>
<Shape DEF='illuminated by scoped light'>
</Shape>
</LightableGroup>
<Shape DEF='not illuminated by scoped light'>

//method B sibling to shape - similar to how  local lights are applied now to sibling shapes
<Group>
<LightSibling localLight='scopable light1'/>
<LightSibling localLight='scopable light 2'/>
<Shape DEF='illuminated by scoped light'>
</Shape>
</Group>

-Doug

>
>>> 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
>
> _______________________________________________ x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org