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

[Andreas Plesch]

> Date: Thu, 30 Jul 2015 08:21:52 -0600
> From: doug sanden <highaspirations at hotmail.com>
>
> 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


ok, I see how the counter-rotation is produced by the script and applied by
the route. In x3dom, one would have to use javascript events and javascript
outside of x3d but it would be straightforward. BTW, this is an example of
why it is a question if the effort to implement the script node in x3dom is
worthwhile.
The switch node was there for quick testing using a box instead of the
elevationgrid ?
I took this opportunity to install freewrl 2.3.3 on my laptop, and to take
a look at the geospatial component implementation. The geoid vs. ellipsoid
option is there and intriguing as I had looked into this before. Quite a
bit of Quaternions there. In my limited experience, there was a reason why
historically quaternions were superseded by matrix math. It is just
convenient to multiply transformation matrices in the same way, no matter
if they concern scale, translation or rotation or some combination.
Overall, it was good to see that there is more or less the same approach
taken as in x3dom as far as I can tell.
I saw your latest commit. I think in x3dom all unrecognized geoSystem
values are simply ignored. As a side effect specifying "N" defaults to the
N UTM hemisphere since only "S" is recognized.
Is there a binary of the developer branch made available somewhere ?
My little laptop almost overheated rendering the example scene ... . Is
there some framerate control, or does freewrl just render as fast as
possible ?

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'>
>

This helps me understand your original suggestion and looks similar to what
I thought about. It would make parsing easier since within a LightableGroup
LocalLights only have an effect on their direct siblings. Outside of such a
group, LocalLights would not effect siblings. eg. be just a definition.
What I had in mind was perhaps more user-friendly but more difficult to do:
Within a LightableGroup, all LocalLights in or above the LightableGroup
level  as defined by the hierarchy of LightableGroups, not all grouping
nodes, effect all shapes at the same LightableGroup level. One would have
to construct and keep track of the LightableGroup hierarchy.

//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>
>

For this method, it would be somehow more "tempting" but wrong to wrap the
LightSiblings nodes in transforms. But I see that the method is equivalent
to method A. Are there other existing x3d sibling type nodes that relate to
their siblings without having this relationship controlled by a parent ? If
not, method B may be a bit foreign to x3d ?

Andreas

-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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150730/8393cb16/attachment.html>