Hi, I created a Jini-service that works with Java 3D last week, and someone suggested that I share my experiences. I'm sorry I can't send out the source code for this, but I need to clear this through legal at the university before doing so. I hope to be able to do that at some point in the near future. Anyway, here goes a bit of background, and then an explanation of what I did. The Java 3D group here at NCSA is working with a variety of different input devices for our Java 3D programs. Many of these are only available on the PC for various reasons: the native hardware drivers are only available on the PC; the device interfaces with the game port; the voice synthesis software is only available on the PC; etc. Some of these are really interesting gizmos. We'd like to use them on any system that's running Java 3D (like our Solaris boxes), not just on the PCs. Jini seemed like an interesting way to make these devices available to any of the machines in our lab. All the machines are near each other, so using them in this way is fairly easy, especially for things like voice input. It seemed that a fairly reasonable way to get this to work with Jini is to write an InputDevice that would be a service. Then, when applications want to use it, they would just query the network for which devices were available and use the remote InputDevice as if it were local. Unfortunately, you can't do that because objects that are expected to be returned from methods in objects implementing InputDevice aren't serializable. (Sensor, and if you look further, Transform3D and SensorRead). I've written to the Java 3D guys, and they'll be looking into the best way to address this. Not everything in Java 3D can be made serializable because of the issues involving compiled and live scene graphs. So, as a work-around, the only alternative today is create the "real" InputDevice object on the client side, and have that do RMI calls to the real device to obtain information from it. The client side then takes the results of the call from the RMI calls and puts it into a SensorRead object, which should be returned when calls to getCurrentSensorRead() are done. Now, this on the face of it might look like a pretty good solution, but it's not. Ideally what you'd want is one version of the InputDevice that can be used either locally or remotely. In order to do this, you have to write a generic wrapper for the local InputDevice so that RMI calls can be made to the real device through the stub. This avoids having to two versions of the InputDevice. The JDK1.2 final version of Jini came out today (1/25/99) as I was writing this. Some of the packages changed in the release. Once I have my example working with the newest version, I'll release the binaries for people to play with. If anyone has any questions about any of this, please feel free to ask. Steve -- Steve Pietrowicz - [EMAIL PROTECTED] Project Manager - NCSA Java 3D Group NCSA Portfolio: http://havefun.ncsa.uiuc.edu/Java3D/portfolio/ New Beta 2a release! New Loaders, record and replay of your Java 3D apps and more! Freely available for non-commercial use! You Build It VR: http://havefun.ncsa.uiuc.edu/Java3D/YouBuildItVR/ Build your own multi-user virtual worlds with no programming experience! The Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html Java News Network: http://tintoy.ncsa.uiuc.edu/~srp/java/javanews.html ===================================================================== To subscribe/unsubscribe, send mail to [EMAIL PROTECTED] Java 3D Home Page: http://java.sun.com/products/java-media/3D/
