[X3D-Public] Accelerometer environment sensor

[Johannes Behr]

Just my $0.02.

Do not add any device or device-class specific Sensor to the spec.

- The Spec is wisely written, even the PointingSensor, without any  
device specifics. This is an achievement we should follow.
- We would need to talk about device classes, relations and shared  
interfaces. The VR-community did not manage to get this right for 20  
years
- We would end up with new Nodes (+ ISO process) for every new device  
or device-class somebody needs.

My suggestion: If we really need a device-specific sensor in our
scene (wich is still odd for other reasons) we should not add one
for every device but add _just_ one for all devices:

  <IOSensor type='joystick'>
   <field accessType='outputOnly' name='xAxis' type='SFFloat'/>
   <field accessType='outputOnly' name='yAxis' type='SFFloat'/>
</IOSensor>

With a dynamic interface like Scripts. Therefore you can add any kind  
of field to do
your input/ouput and it will be mapped. If the system can not map the  
fields to
the given type you get a warning or interactive suggestion.

This can be used for Joysticks, AR-Cameras ( first attached example ) or
Accelerometer sensors ( second attached example )
(or 50 other devices ( including Compass and GPS) supported this
way: http://www.instantreality.org/device/)

The first example should run everywhere the second needs a macbook (or  
Pro)
using a instantReality.org runtime.

This is not portable right now but we could come up with a table
or web-page with suggested types and interfaces without adding a
new Node to the spec and ISO-process for every device or device-class.

And browser vendor could add experimental devices and interfaces
without new nodes.

best regards
johannes

> Dave wrote:
>> Don,
>> Cool! Very clever that CSS guy. After I wrote this I realized that  
>> such
>> things would be likely,
>> that external code could drive SAI, and that external code could
>> (hopefully) access
>> such devices.
>
> perhaps an X3D author using an X3D browser which utilizes the HTML
> browser's javascript engine would have access to these functions
> already.
>
> hey Johannes, can X3DOM read the accelerometer already?   8)
>
>> Keith Victor has been doing some thinking on a node for it. I would  
>> bet
>> that BM and Fraunhofer
>> have too, not really sure. I can draft up something if nobody else  
>> has,
>> would like others' input
>> of course.
>> While we are at it, access to the hardware compass and GPS would  
>> also be
>> very nice. Again, probably
>> could be driven externally, but having them handy is also, well,  
>> handy.
>
> yes we should think through Compass and GPS issues as well, we don't  
> want
> to define a partial and possibly incomplete/incompatible solution with
> just AccelerationSensor.
>
> all the best, Don
> -- 
> Don Brutzman  Naval Postgraduate School, Code USW/Br           brutzman at nps.edu
> Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA  work  
> +1.831.656.2149
> X3D, virtual worlds, underwater robots, XMSF  http://web.nps.navy.mil/~brutzman
>

--
Dr. Johannes Behr
Leiter Projektbereich VR

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-510  |  Fax +49 6151 155-196
johannes.behr at igd.fraunhofer.de  |  www.igd.fraunhofer.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ioSensor-video.x3d
Type: model/x3d+xml
Size: 1164 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20091118/3554b2c1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ioSensor-suddenMotion.x3d
Type: model/x3d+xml
Size: 1425 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20091118/3554b2c1/attachment-0001.bin>