Hi Justin,
When you set Sensor values via one of the setNextSensorRead methods,
the values are copied. So you can set the same SensorRead and/or
Transform3D object in your implementation of the InputDevice interface
over and over safely.
I did not find this in the documentation either, and it will be filed
as a documentation bug. Thank you for pointing it out.
The Java 3D Sensor implementation does not create objects internally
while data values are being read, but uses a ring buffer of SensorRead
objects that are instantiated when the Sensor is first instantiated.
So an input device should not contribute to garbage collection
overhead.
For the benefit of everyone on the list, there is an example of using
input devices with Java 3D in the VirtualInputDevice example program
directory. A Sensor is the data structure through which a device
driver implementation of the InputDevice interface communicates data
consisting of a transform, a time stamp, and possibly button values to
Java 3D each time the device is queried. A Sensor holds the last N
sensor readings, where N is equal to the sensor read count, which is
a settable parameter with a default value of 30.
Travis Bryson
Sun Microsystems
> X-Authentication-Warning: fire.adisys.com.au: nobody set sender to
<[EMAIL PROTECTED]> using -f
> Date: Sat, 10 Apr 1999 15:00:00 +0800
> From: Justin Couch <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> To: J3D Dev List <[EMAIL PROTECTED]>
> Subject: [java3d] Sensor.setSensorRead clones or references?
> Content-Transfer-Encoding: 7bit
>
> When building an InputDevice, what happens when we set a new bunch of
> information in the sensor.
>
> In the various versions of setSensorRead, are the values copied to
> internal values or are they referenced?
>
> The reason for this is that I want to be able to compute how much
> garbage is going to be generated from a fast moving sensor input. Say I
> have sensor information 100Hz. Do I need to be generating a new
> SensorRead/Transform3d object each time pollAndProcessInput is called or
> use single instance and reset the values each time before passing it to
> setSensorRead. In the second case I need to be confident that the
> information is copied to internal structures otherwise I may be
> overwriting the outbound information used by the rest of the app and
> previous values of sensorRead (which would screw prediction really
> badly).
>
> This essential information is not contained in either the J3D spec or
> API docs. Why not? If you have two implementations and they interpreted
> what happens with setSensorRead differently it will break the device
> driver and the application very quickly. There are quite a number of
> other similar circumstances that I've run across in the spec that could
> cause the same types of effects.
>
> --
> Justin Couch Author, Java Hacker
> Snr Software Engineer [EMAIL PROTECTED]
> ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
> Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
> -------------------------------------------------------------------
> "Look through the lens, and the light breaks down into many lights.
> Turn it or move it, and a new set of arrangements appears... is it
> a single light or many lights, lights that one must know how to
> distinguish, recognise and appreciate? Is it one light with many
> frames or one frame for many lights?" -Subcomandante Marcos
> -------------------------------------------------------------------
> =====================================================================
> To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
> Java 3D Home Page: http://java.sun.com/products/java-media/3D/
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
