[x3d-public] Player inconsistency > CylinderSensor > interpretation of local vs sensor-local

Andreas Plesch andreasplesch at gmail.com
Fri Dec 8 07:16:27 PST 2017


Doug,

another option to deal with inconsistencies may be to use the
component system to move identified fields to higher, full or
experimental levels. Or a dedicated level for not fully specified
fields which ideally should not exist but in practice may exist
anyways and need a label.

Sometimes it is also necessary to deprecate fields which should be
seen as an opportunity rather than a drawback. I think we may be close
to showing that axisRotation is rarely or perhaps never needed, and
therefore could be deprecated and eventually be removed.

This reminds me that often before a new field or node is introduced it
is implemented in a proto with scripting. If that was the case for
axisRotation then there should be no ambiguity. Perhaps there is
somewhere a proto from around 2008 or so ?

-Andreas


On Fri, Dec 8, 2017 at 9:27 AM, doug sanden <highaspirations at hotmail.com> wrote:
> Andreas,
>> In any case, it seems safest to avoid use of axisRotation currently.
> Sadly, agreed. Want to fix that.
> -Doug
>
> Sadly agreed for scene authors wanting (trying to think of the word) browser-portability / archive-quality , until there's more consistency among browsers. When authoring that kind of scene content myself, I tend to avoid the fancier nodes and fields that may not be supported in all browsers or not implemented consistently.
>
> But isn't that a bit of a shame? For those seeking portability, what's the point of adding new node types in version 4 if v3.3 not implemented consistently? Fancy new nodes not likely to be used anyway by those seeking portability.
>
> Not that web3d is the only content like that. Programming languages / compilers do that too: try to improve, while risking portability, backward compatibility.
> One thing web3d has done right: version strictness. So if a browser knows what standard version the content file is from, they can interpret differently.
>
> IDEAs for retroactively resolving inconsistencies in current implementations:
> 1. Browsers add a node field SFString initializeOnly interpretation 'A'  [A,B,C,...]  and default to their own interpretation, for each inconsistent node, but allow other interpretations to be specified.
> 2. in the header area of scene or on commandline of browser, a browserInterpretation='Vivaty' etc
> 3. ETL (extract, transform, load) utility that can convert between equivalent browser interpretations, or thunk fancy nodes to simpler nodes
> 4. summer students / interns spend a summer making all browsers consistent
> 5. whoever sponsors / recommends a new node type must stick around and verify all browsers implementations, and/or implement in each browser.
>
> And I suppose there are a few upstream causes for these inconsistencies:
> - public test scenes don't cover all features, and don't have screenshots/video for comparison
> - specs ambiguous: awkward/misleading field names, missing details such as local vs sensor-local
> - requirements tracability (or equivalent) not publicly available, to resolve spec ambiguity
> - web3d membership fees for access to some details, while most browsers making no revenue / freeware
> - no guardians / police / testers comparing - oh wait, we just did that.
>
> I think we can all gain from consistency. There are other formats. Being consistent across browsers - for portability, archive quality - will help 'lift all boats' and make new versions and new nodes worth implementing.
>
> The saving grace for axisRotation: its likely rarely used by scene authors in part for the reason you cite, and so retroactively changing its implementation (in attempt to standardize/harmonize) will break few scenes.
>
> So for freewrl I'm willing, trying to get it 'right' and also harmonize.
> You're being a big help Andreas - thanks.
>
>
>
>
>
> ________________________________________
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: December 7, 2017 7:48 PM
> To: doug sanden
> Cc: x3d-public at web3d.org
> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>
> Hi Doug,
>
> On Thu, Dec 7, 2017 at 12:26 PM, doug sanden
> <highaspirations at hotmail.com> wrote:
>> Andreas,
>> I'll do another spec comment to update the stale parts of my yesterday comment.
>> -Doug
>>
>> Andreas found the Linesensor configuration of planesensors in all/most browsers did use the rotation angle of axisRotation.
>>
>> PlaneSensorAxisRotation2.x3d
>> - shows plansensor in 'linesensor' mode, with minPosition y = 0, maxPosition y = 0;
>> x3dom:
>> https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b#PlaneSensorAxisRotation2.x3d
>> cobweb:
>> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis2.html
>> native:
>> http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation2.x3d
>>
>>
>> Left Pad:
>> sensor axisRotation 0 0 1 .79
>> A. Freewrl, x3dom, view3dscene:
>> - clamping/minmax range is rotated
>> - translation_changed comes out in sensor-local (not local) coords, so is not rotated, but is clamped.
>> B. H3D, Octaga, cobweb
>> - clamping/minmax range is rotated
>> - translation_changed comes out on an angle / in local coords
>> C. Instant, Vivaty
>> - clamping not rotated
>> - translation_changed not rotated
>>
>> Middle Pad 1:
>> no sensor or transform rotation
>> All browsers do default planesensor the same
>>
>> Right Pad 2:
>> default (no) axisRotation, attempt to do Linesensor mode using (old fashioned) 2 transforms
>> - as a way to reverse engineer the need/purpose for axisRotation field
>> Transform rotation 0 0 1 .78
>>    Transform rotation 0 0 1 -.79
>>       shape
>>    /Transform
>>    Sensor - no axisRotation
>> /Transform
>> x3dom, cobweb, freewrl, H3D, instant, octaga, vivaty, view3dscene:
>> - 'linesensor' clamp axes are rotated, and output translation is not rotated
>> - similar to interpretation A of Left Pad above
>> Andreas:
>>> pad3 explains for me why axisRotation may be necessary. It does not
>>> help to rotate the local coordinate system because the reported
>>> translation is still relative to it and therefore still has a fixed Y
>>> of 0. It also does not help to rotate the sibling geometry because it
>>> does not affect the local coordinate system of the plane sensor. So
>>> the only way to get rotated translations is with axisRotation.
>> Doug:
>> -for above tests, the translated spherelet/trackingpoint was at the scene root.
>> -By putting trackpoint transform inside the right pad 3 transform you can get an angled drag
>> -- see lower pad 4 in
>>         http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation3.x3d
>> - so a bit more scene plumbing but then even older player vivaty (H: no axisRotation) can do angled linesensor drag
>> - therefore linesensor-rotation-convenience-needs not an absolute/definitive answer to need for axisRotation field in PlaneSensor, although its a good/prime hypothesis.
>>
>>
>
> https://bl.ocks.org/andreasplesch/0d59b7c769565b0e2d1880562fbff1b0
>
> is the x3dom version of PlaneSensorAxisRotation3.x3d
>
> Yes, I suppose it may always be possible to apply what would be the
> axisRotation as a transform rotation around the target of the sensor
> output translation instead. So I agree that this means there is still
> no real need for axisRotation. But would it not have been introduced
> for a reason other than convenience ?
>
> In any case, it seems safest to avoid use of axisRotation currently.
>
> -Andreas
>>
>> ________________________________________
>> From: Andreas Plesch <andreasplesch at gmail.com>
>> Sent: December 6, 2017 6:56 PM
>> To: doug sanden
>> Cc: x3d-public at web3d.org
>> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>>
>> Octaga behaves like x-ite, eg. produces a diagonal line sensor,
>> freeWrl like the other browsers.
>>
>> To me the Octaga, x-ite behaviour makes the most sense. I think it
>> means applying the axisRotation rotation to the local coordinate
>> system to produce the sensor local coordinate system but then
>> reporting translations with respect to the local coordinate system,
>> not the sensor local coordinate system.
>>
>> I think strictly the same outcome is achieved by applying the
>> axisRotation rotation to the sensed translation and reporting the
>> rotated translation as output. If this is the case, then I suggest
>> that the language in the spec. is adjusted by getting rid of the
>> sensor local coordinate system, and instead saying that
>> translation(trackpoint)_changed is the result after applying
>> axisRotation rotation. To me that would be friendlier and less
>> ambiguous for implementers.
>>
>> Let's see if something similar is also applicable to CylinderSensor ...
>>
>> -Andreas
>>
>>
>> On Wed, Dec 6, 2017 at 8:13 PM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>>> I added another test with the min max clamping:
>>>
>>> https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b#PlaneSensorAxisRotation2.x3d
>>>
>>> Only x-ite appears to apply axisRotation to the output to produce a
>>> diagonal LineSensor. BS, Instant, and view3dscene do not. WIll look at
>>> the others as well.
>>>
>>> pad3 explains for me why axisRotation may be necessary. It does not
>>> help to rotate the local coordinate system because the reported
>>> translation is still relative to it and therefore still has a fixed Y
>>> of 0. It also does not help to rotate the sibling geometry because it
>>> does not affect the local coordinate system of the plane sensor. So
>>> the only way to get rotated translations is with axisRotation.
>>>
>>> -Andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Dec 6, 2017 at 6:39 PM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>>>> Doug,
>>>>
>>>> reading the PlaneSensor spec., I noticed the min/maxPosition clamping
>>>> and how it can be used to make a LineSensor along the X or Y axis of
>>>> the sensor local coordinate system. So perhaps an intended use of
>>>> axisRotation would be a diagonal LineSensor on a rectangle.
>>>>
>>>> But on the other hand, I think the same effect could be achieved by a
>>>> rotated rectangle next to PlaneSensor ?
>>>>
>>>> <Group>
>>>>   <PlaneSensor minPosition='0 -1' maxPosition='0 1'/>
>>>>   <Transform rotation='0 0 1 0.78'>
>>>>     <Shape>
>>>>       <Box size='2 2 0.1' />
>>>>     </Shape>
>>>>   </Transform>
>>>> </Group>
>>>>
>>>> I guess I am still looking for a useful application of axisRotation.
>>>>
>>>> -Andreas
>>>>
>>>>
>>>> On Wed, Dec 6, 2017 at 12:27 PM, doug sanden
>>>> <highaspirations at hotmail.com> wrote:
>>>>> For now I'll harmonize freewrl with the closest compatible interpretations:
>>>>> - view3dscene for cyclinderSensor axisRotation
>>>>> - view3dscene and x3dom for PlaneSensor axisRotation
>>>>> And I'll put a spec comment suggesting it needs clarification.
>>>>> -Doug
>>>>> ________________________________________
>>>>> From: doug sanden <highaspirations at hotmail.com>
>>>>> Sent: December 5, 2017 7:19 AM
>>>>> To: Andreas Plesch
>>>>> Cc: x3d-public at web3d.org
>>>>> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>>>>>
>>>>> Andreas
>>>>> Thanks for the x3dom and BS tests.
>>>>> I can see freewrl has at least the angle sense wrong to match x3dom and view3dscene.
>>>>>
>>>>> Q. For planesensor does axisRotation mean
>>>>> a) sensor virtual geometry plane normal, or
>>>>> b) a full SFRotation applied to local coords to get to sensor-local-coords
>>>>>
>>>>> If a), then specs could/should change field type and name to SFVec3f .normal or .planeNormal
>>>>> if b), then specs could/should change field name to .rotation
>>>>> -Doug
>>>>> ...
>>>>> And which ever it is, same treatment/sense/meaning for cylindersensor axisRotation.
>>>>> ...
>>>>> Planesensor >
>>>>> - freewrl is rotating opposite direction (-angle) to view3dscene and x3dom, but same concept of using axisRotation as an SFRotation
>>>>> - (my version of instant does planesensor like octaga, h3d, cobweb. I haven't upgraded in several months)
>>>>>
>>>>>> I think the translation_changed translations have to be relative to
>>>>>> the local coordinate system, not relative to the sensor local
>>>>>> coordinate system since the translations will be applied (in most
>>>>>> cases) to transforms in the local coordinate system (and not in the
>>>>>> sensor local coordinate system).
>>>>>
>>>>> And that's the case when axisRotation is default, or more precisely local-coords == sensor-local-coords.
>>>>> So if you want to give the translation_changed an extra twist, I think all the browsers (except older vivaty) are doing something and it looks like they are re-oriented the sensor plane virtual geometry.
>>>>> The difference seems to be in how the axisRotation is being interpreted.
>>>>>
>>>>> The right pad in the scene (repeat of our scene links:
>>>>> http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation.x3d
>>>>> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis.html
>>>>> https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b
>>>>> ) has axisAngle 0 1 0 1.57, in SFRotation terms its a rotation around the Y axis by 90.
>>>>> Notice in octaga/cobweb/h3d/oldinstant, when you drag on the right plane vertically, it seems to stick around y=0. That can be explained if they are using the xyz of the axisRotation as a sensor plane normal, so the plane normal is going up the screen (Y).
>>>>> A drag on the left pad -which has axisRotation 0 0 1 1.57- in (octaga/cobweb/h3d/oldinstant) shows no net rotation. That could be explained by these browsers using only the xyz -which is default 0 0 1- and discarding the angle from axisRotation.
>>>>> H0: older specs did something different
>>>>> H1: confusion by the name axisRotation which sounds like an axis
>>>>>
>>>>> So at least perhaps there could/should be some clarification in the specs for planesensor. It has one sentence:
>>>>> """
>>>>> The local sensor coordinate system is created by applying the axisRotation field value to the local coordinate system.
>>>>> """
>>>>> If the specs mean axisRotation to be the plane normal, then then specs should change the name to SFVec3f .planeNormal
>>>>> If the specs mean axisRotation to be a full SFRotation perhaps the name should just be SFRotation .rotation.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ________________________________________
>>>>> From: Andreas Plesch <andreasplesch at gmail.com>
>>>>> Sent: December 4, 2017 9:09 PM
>>>>> To: X3D Graphics public mailing list
>>>>> Cc: doug sanden
>>>>> Subject: Re: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>>>>>
>>>>> Here is the x3dom PlaneSensor test version:
>>>>>
>>>>> https://bl.ocks.org/andreasplesch/0894babf2acb9d3afac23c5980d36b7b
>>>>>
>>>>> It behaves like Instant, eg. dragging horizontally on the left panel
>>>>> leads to vertical translation of the ball.
>>>>>
>>>>> BS Contact behaves like Octaga and cobweb.
>>>>>
>>>>> I think the translation_changed translations have to be relative to
>>>>> the local coordinate system, not relative to the sensor local
>>>>> coordinate system since the translations will be applied (in most
>>>>> cases) to transforms in the local coordinate system (and not in the
>>>>> sensor local coordinate system).
>>>>>
>>>>> It seems it will be necessary to clearly state the intent of the
>>>>> axisRotation field (and not just its effect). Why do we need it ?
>>>>>
>>>>> -Andreas
>>>>>
>>>>>
>>>>> On Mon, Dec 4, 2017 at 3:00 PM, <x3d-public-request at web3d.org> wrote:
>>>>>>
>>>>>> Message: 1
>>>>>> Date: Mon, 4 Dec 2017 15:22:43 +0000
>>>>>> From: doug sanden <highaspirations at hotmail.com>
>>>>>> To: "x3d-public at web3d.org" <x3d-public at web3d.org>
>>>>>> Subject: Re: [x3d-public] Player inconsistency > CylinderSensor >
>>>>>>         interpretation of local vs sensor-local
>>>>>> Message-ID:
>>>>>>         <MWHPR1401MB19828209A7806EB323A25583B63C0 at MWHPR1401MB1982.namprd14.prod.outlook.com>
>>>>>>
>>>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>>>>
>>>>>> Hypothesis (for planesensor inconsistency):
>>>>>> - some browsers interpret axisRotation to be an xyz axis vector (and ignor the rotation angle)
>>>>>> -- octaga, instant, cobweb, h3d
>>>>>> - some browsers interpret axisRotation to be an SF rotation and do nothing if angle is 0
>>>>>> -- freewrl, view3dscene
>>>>>>
>>>>>> ________________________________________
>>>>>> From: doug sanden <highaspirations at hotmail.com>
>>>>>> Sent: December 4, 2017 8:05 AM
>>>>>> To: x3d-public at web3d.org
>>>>>> Subject: Player inconsistency > CylinderSensor > interpretation of local vs sensor-local
>>>>>>
>>>>>> Thanks very much Andreas for looking into this.
>>>>>> > > To me the intended function of the axisRotation field is to control the direction of the rotation output such that rotations other than about the Y axis become available. If that is the case then the rotation_changed output should be affected by the axisRotation field, eg. be rotated.
>>>>>> > >
>>>>>> > > A related question is if the axisRotation field is intended to provide functionality which cannot be achieved by wrapping the Sensor in a Transform with the same rotation value which would also result in a rotated sensor local coordinate system. Presumably the answer is yes in order to justify its existence but I am not sure.
>>>>>>
>>>>>> That sounds interesting. We can't wrap a sensor in its own transform - it has to be a sibling to the sensitized geometry. So axisRotation might have been designed as a way to give it a bit of transform of its own.
>>>>>>
>>>>>> PlaneSensor also has axisRotation. Maybe that's clearer.
>>>>>> http://dug9.users.sourceforge.net/web3d/tests/sensors/PlaneSensorAxisRotation.x3d
>>>>>> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb_planeAxis.html
>>>>>> - left planesensor (invisible geometry) is rotated about z 90 by axisRotation
>>>>>> - right planesensor is rotated about y 90 (so its almost edgewise)
>>>>>>
>>>>>> In freewrl, by rotating only the invisible sensor geometry, the translation_changed is still in sensor-local coordinates.
>>>>>> Dragging on the left planesensor, does the translation_changed come out at 90 (y when you drag x)?
>>>>>> instant  no
>>>>>> octaga no
>>>>>> vivaty no
>>>>>> h3d no
>>>>>> cobweb no
>>>>>> view3dscene yes
>>>>>> freewrl yes
>>>>>>
>>>>>> More inconsistency. Help!
>>>>>> -Doug
>>>>>>
>>>>>> > >>
>>>>>> > >> Date: Sun, 3 Dec 2017 18:02:47 +0000
>>>>>> > >> From: doug sanden <highaspirations at hotmail.com>
>>>>>> > >> To: "x3d-public at web3d.org" <x3d-public at web3d.org>
>>>>>> > >> Subject: [x3d-public] Player inconsistency > CylinderSensor >
>>>>>> > >>         interpretation of local vs sensor-local
>>>>>> > >> Message-ID:
>>>>>> > >>         <MWHPR1401MB1982C8C77F571F605CDE02DBB63F0 at MWHPR1401MB1982.namprd14.prod.outlook.com>
>>>>>> > >>
>>>>>> > >> Content-Type: text/plain; charset="iso-8859-1"
>>>>>> > >>
>>>>>> > >> I noticed a bit of inconsistency among players when axisRotation is non-default.
>>>>>> > >> I wonder what's right.
>>>>>> > >> -Doug
>>>>>> > >>
>>>>>> > >> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/pointingsensor.html#CylinderSensor
>>>>>> > >> """
>>>>>> > >> ... pointer motion (e.g., a mouse or wand) into a rotation on an invisible cylinder that is aligned with the Y-axis of the local sensor coordinate system. The local sensor coordinate system is created by applying the axisRotation field value to the local coordinate system.
>>>>>> > >> ...
>>>>>> > >> rotation_changed event is sent that equals the sum of the rotation about the +Y-axis vector of the local sensor coordinate system
>>>>>> > >> ...
>>>>>> > >> trackPoint_changed events reflect the unclamped drag position on the surface of the invisible cylinder. [Q, in local or sensor-local?]
>>>>>> > >> """
>>>>>> > >> Q, Does that mean we should
>>>>>> > >> - rotate the invisible sensor geometry by axisRotation
>>>>>> > >> - leave rotation_changed in sensor-local
>>>>>> > >> - put trackpoint_changed  into local coordinates (not sensor-local)?
>>>>>> > >>
>>>>>> > >> more..
>>>>>> > >>
>>>>>> > >> http://dug9.users.sourceforge.net/web3d/tests/sensors/CylinderSensorCylinderAxisRotation90.x3d
>>>>>> > >> (http://dug9.users.sourceforge.net/web3d/tests/sensors/CylinderSensorCylinder.x3d default axisRotation)
>>>>>> > >> http://dug9.users.sourceforge.net/web3d/tests/sensors/cobweb90.html
>>>>>> > >> routing:
>>>>>> > >> - box is rotated by rotation_changed
>>>>>> > >> - little sphere is translated by trackpoint_changed
>>>>>> > >>
>>>>>> > >> player:         rotates:
>>>>>> > >> octaga - sensor-geometry, rotation_changed, trackpoint_changed
>>>>>> > >> instant - sensor-geometry, rotation_changed, trackpoint_changed moves diagonally
>>>>>> > >> H3D     - sensor-goemetry, rotation_changed
>>>>>> > >> vivaty - nil
>>>>>> > >> view3dscene - sensor-geometry, trackpoint_changed
>>>>>> > >> freewrl - sensor-geometry
>>>>>> > >> cobweb - sensor-geometry, rotation_changed
>>>>>> > >>
>>>>>> > >
>>>>>> > >
>>>>>> > > Two more players:
>>>>>> > > BS Contact: does not rotate rotation_changed, little sphere stays with dragging mouse pointer
>>>>>> >
>>>>>> > Ok, on a 2014 version the console has an error message that the
>>>>>> > axisRotation field value could not be set. So no surprise that it had
>>>>>> > no effect.
>>>>>> >
>>>>>> > >
>>>>>> > > x3dom:  does not rotate rotation_changed, does not translate little sphere (no trackpoint_changed event?)
>>>>>> >
>>>>>> > I looked into the implementation. I believe it would be
>>>>>> > straightforward to apply the axisRotation rotation to the
>>>>>> > rotation_changed output.
>>>>>> >
>>>>>> > >
>>>>>> > > https://bl.ocks.org/andreasplesch/34d6c24972d37a0ad9e2070cf3a8a2c6
>>>>>> > >
>>>>>> > > Focusing on rotation_changed as the principal node output we then have:
>>>>>> > >
>>>>>> > > Octaga, Instant, H3D, cobweb : rotate by axisRotation
>>>>>> > > BS, x3dom, view3dscene, freewrl: do not rotate by axisRotation
>>>>>> > >
>>>>>> > > 4:4, a perfect split (!).
>>>>>> > >
>>>>>> > > To me the intended function of the axisRotation field is to control the direction of the rotation output such that rotations other than about the Y axis become available. If that is the case then the rotation_changed output should be affected by the axisRotation field, eg. be rotated.
>>>>>> > >
>>>>>> > > A related question is if the axisRotation field is intended to provide functionality which cannot be achieved by wrapping the Sensor in a Transform with the same rotation value which would also result in a rotated sensor local coordinate system. Presumably the answer is yes in order to justify its existence but I am not sure.
>>>>>> > >
>>>>>> > > For reference, here are the conformance scenes but they do not seem to include non-default axisRotation sensors:
>>>>>> > >
>>>>>> > > http://www.web3d.org/x3d/content/examples/ConformanceNist/Sensors/CylinderSensor/index.html
>>>>>> > >
>>>>>> > > Perhaps axisRotation was introduced relatively later ?
>>>>>> >
>>>>>> > It looks the field was introduced in 2008 with v 3.2 since 3.1 and 3.0
>>>>>> > do not seem to have it ? So there should be some discussion somewhere
>>>>>> > ?
>>>>>> >
>>>>>> > >
>>>>>> > > -Andreas
>>>>>> > >
>>>>>> > > --
>>>>>> > > Andreas Plesch
>>>>>> > > Waltham, MA 02453
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Andreas Plesch
>>>>>> > Waltham, MA 02453
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Subject: Digest Footer
>>>>>>
>>>>>> _______________________________________________
>>>>>> x3d-public mailing list
>>>>>> x3d-public at web3d.org
>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> End of x3d-public Digest, Vol 105, Issue 4
>>>>>> ******************************************
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Andreas Plesch
>>>>> Waltham, MA 02453
>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list