On Mon, Feb 11, 2013 at 7:22 PM, Sebastian Messerschmidt < [email protected]> wrote:
> Hello Jan, > > Actually VRPN looked a bit too bloated for me. Also I didn't find a simple > example grabbing keyboard events, directly accessing keyboard state etc. > Is there some good starting point into VRPN? > Well, it is a different approach than OIS. OIS is a for local applications using local resources, VRPN is based on a client-server concept, where you have one server handling the device and several clients connecting to it at the same time (even over network). I suggest to first have a look at this short paper: http://www.cs.unc.edu/Research/vrpn/VRST_2001_conference/vrst_vrpn_paper_reprint.pdf- it explains the architecture and rationale behind the design. The advantage of VRPN is network transparency (tracker/device doesn't need to be on the same machine as your application - useful for larger setups), device abstraction (no need to make your app depend on various proprietary SDKs that often conflict, change, etc), large amount of supported devices that can be swapped by changing the config file, no need to modify your application at all, etc. It all comes down to what exactly you need. If you need only a small desktop application that will always support only one type/brand of the 3D mouse, you are probably better off using the vendor SDK. If it is something where you need to be flexible with regards to the hw available at the deployment site, VRPN is much better. If you don't need to write custom servers, the client API is very simple, there are good tutorials here: http://www.cs.unc.edu/Research/vrpn/vrpn_getting_started.html If you want to interface e.g. a keyboard, that would be typically exposed as a vrpn_Button class, sending you the scancodes of the individual keys. However, that is probably not the method you want to use to make a text editor (it is a bit rudimentary). A more complex device, like the SpaceNavigator gives you both vrpn_Analog (for the joystick axes) and vrpn_Button (for the buttons) classes. That can then be routed on the server using a config file into the vrpn_Tracker_AnalogFly virtual tracker that will make a full 6DOF tracker returning position and orientation in space for you. Look at the example vrpn.cfg that comes with the library. Your application doesn't know anything about the tracker emulation - it simply talks to a vrpn_TrackerRemote instance. If you point that instance to a Polhemus or Vicon server instead, it will work "automagically", without you having to change anything in your code to support a completely different tracker. BTW, If you need keyboard events and such, OSG supports that already, why to duplicate that functionality? OIS doesn't give you anything more in that regard. In my case, I am usually relying on either OSG event system or Qt to provide the handling of mouse and keyboard and use VRPN for everything else - gamepads, wiimotes, 3D mice, all kinds of 3D tracking systems, etc. Regards, Jan
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
