<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> snip<br>
>><br>
>>>> Perhaps light scope would need to be defined more flexibly than the<br>
>>>> global field allows. I could see a "scope" field which defaults to<br>
>>>> 'global' and otherwise contains the DEF of a group to which the light<br>
>>>> should be applied. Would this interfere with some default logic of<br>
>>>> scene traversal ?<br>
>>><br>
>>> That's interesting, may lead to some ideas, but has a gotcha: the<br>
>>> transform stack above the DEF is needed too in order to pose the light<br>
>><br>
>><br>
>> Yes, the full transform stack affecting the group to be illuminated by<br>
>> the scoped light needs to be known to actually produce the correct<br>
>> rendering. I am rephrasing to make sure I understand. If I do, I am not<br>
>> sure where the gotcha is. Is something not well defined ? Or is it a<br>
>> potentially prohibitive difficulty in implementation ?<br>
>><br>
>> There may be other ways to define a separation of the light scope from<br>
>> the lights position in the grouping and therefore transform hierarchy<br>
>> but I cannot think of one. Some wilder ideas are to use the routing<br>
>> concept ? "route" a light to a group ? Or have a separate hierarchy<br>
>> just for scoped lighting ?<br>
><br>
><br>
> The PickSensor has 2 parts in different sections of the scenegraph:<br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/picking.html#Abstracttypes" rel="noreferrer" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/picking.html#Abstracttypes</a><br>
> - pickableObject and pickSensor are in 2 different places in the scenegraph </blockquote><div><br></div><div>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.</div><div><br></div><div class="gmail_quote">The transformation hierarchy is explicitly specified:</div><br>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.<div> </div><div>Hm, this seems to describe the 'regular' hierarchical transform stack. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> New LocalLight / LightableGroup node types could likewise be split into 2 parts<br>
> - 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<br>
> - 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<br>
> - a number or DEF name would/could link the two<br>
> - the software on each frame would<br>
> a) do a lighting pass first, to position each LocalLight in the scene (the locallight node would store the last transformed pose)<br>
> 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.<br>
><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
So instead of LightableGroup it would/could/should be LightSibling.<br>
Or else LightableGroup could/should have an MFnode field for LocalLights.<br>
-D</blockquote><div><br></div><div>Something like this ?</div><div><br></div><div><font face="monospace, monospace"><LightableGroup><br></font></div><div><font face="monospace, monospace">  <Shape DEF='illuminated by scoped light'></font></div><div><font face="monospace, monospace">  ..</font></div><div><font face="monospace, monospace">  </Shape></font></div><div><div><font face="monospace, monospace">  <LocalLight DEF='scopable light1' ></font></div></div><div><font face="monospace, monospace">    <DirectionalLight /></font></div><div><font face="monospace, monospace">  </LocalLight>  </font></div><div><div><font face="monospace, monospace">  <LocalLight DEF='scopable light2' ></font></div></div><div><font face="monospace, monospace">    <DirectionLight /></font></div><div><font face="monospace, monospace">  </LocalLight></font></div><div><font face="monospace, monospace"></LightableGroup></font></div><div><font face="monospace, monospace"><Shape DEF='not illuminated by scoped light'></font></div><div><br></div><div>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.</div><div><br></div><div><font face="monospace, monospace"><LightScope></font></div><div><div><font face="monospace, monospace">  <Shape DEF='illuminated by scoped light'></font></div><div><font face="monospace, monospace">  ..</font></div><div><font face="monospace, monospace">  </Shape></font></div><div><font face="monospace, monospace">  <</font><span style="font-family:monospace,monospace">DirectionalLight /></span></div><div><font face="monospace, monospace">  <</font><span style="font-family:monospace,monospace">DirectionalLight /></span><span style="font-family:monospace,monospace"><br></span></div><div><font face="monospace, monospace"></LightScope></font></div></div><div><div><font face="monospace, monospace"><Shape DEF='not illuminated by scoped light'></font></div></div><div><font face="monospace, monospace"><br></font></div><div>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. </div><div><br></div><div>This probably needs some more thinking through,</div><div><br></div><div>-Andreas</div></div>
</div></div>