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

doug sanden highaspirations at hotmail.com
Fri Jul 31 06:46:47 PDT 2015


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

Switch -1 as declaration section:
Yes, and easy to move around the shape elements -a single USE instead of several lines of elevation grid- and a style I picked up from hacking collada/.dae which has an explicit declaration section before the scene.

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

Geoid makes a small (+- 15m) correction to ellipsoid, useful for large scenes with water ie water flows down gravity hills. I think it would be for the geospatial purist, ie if selecting a browser for its capabilities, they might give a check mark for having geoid. But for most rendered scenes you wouldn't notice much.

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

May be a win32 freewrl release in the next few weeks. I'll post here on x3dpublic when ready for download.

> My little laptop almost overheated rendering the example scene ... . Is
> there some framerate control, or does freewrl just render as fast as
> possible ?

Thanks Andreas, I'll look into that. It used to have it, I may have disabled it.

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

Lights with global=false (current local lights). If they implemented this already, MethodB would be a smaller change than MethodA.
-Doug

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


More information about the x3d-public mailing list