Vuzix and video Eyewears on Unity

The software that came along makes it be recognized by windows as a hardware, but not as a joystick. Plugins and custom drivers where the options I found too, but I had the following problems: The workaround with the plugin would probably require a lot of patching to make the camera work right, so I could center and use global positioning ins$$anonymous$$d of incrementing the movement (correct me if I'm wrong), so the driver solution seens better to me. I can't seen to integrate the SD$$anonymous$$ on Unity, could you give me some pointers about the custom driver?

thanks

Getting the data is the difficult part. There's no reason the plug-in solution should cause problems with the camera. If the data is a look direction, use Quaternion.LookRotation. If the data is deltas of some sort, you simply add/multiply them to the camera's transform. If the data is an orientation, you can set it directly. You may have to apply smoothing if the data is too choppy. I'm not sure I get your meaning about centering and using global positioning, but whatever data you get, it is fairly easy to convert it to camera movement

You can't really integrate the SD$$anonymous$$ explicitly into Unity. You author the code using the SD$$anonymous$$ outside of Unity and compile it into a dynamically linked library (Windows) or a bundle ($$anonymous$$ac) in the Plugins folder. In a Unity mono script, declare functions with the [DllImport ("PluginName")] attribute. See the docs and examples (http://unity3d.com/support/documentation/$$anonymous$$anual/Plugins.html). People here can help with the Unity side like getting the plug-in library into Unity and using the data, but the SD$$anonymous$$ stuff is something beyond the scope of these pages and we can only help as far as we know how.

I know this isn't helpful, but authoring custom drivers is something I have virtually no experience with. $$anonymous$$anufacturers develop custom protocols to interface with their devices. If the protocol is open or published, writing the driver is apparently a matter of identifying the device to the system (as a joystick in this case) and implementing functions that use the protocol to communicate with the device. If the protocol is not published, you will have to reverse-engineer by snooping while the manufacturer's driver is communicating which is easier if the device is USB it seems.

If you write a driver in the user space, there are possibly some libraries that can be used while kernel level program$$anonymous$$g your driver is much harder. microsoft.com/whdc/driver/foundation/default.mspx might be helpful as a place to start for Windows. Because of the complexity and logistics involved in using a custom driver, I would strongly recommend using the SD$$anonymous$$ and provided drivers through a plugin.