App support/config for different 3Dx Products

[neil_at_informatix]

we have started with the top end SpacePilot device (nice!) (we were given one...)
I note

• the SpacePilot has lots of buttons and an LCD display
• Google SketchUp and similar sophisticated client-apps both respond to the extra buttons, and display in the LCD

I also note a distinct lack of display or extra buttons on the tiny SpaceNavigator device.

So... my question is - how is an App meant to accommodate the lesser SpaceXXX devices?

If the app needs e.g. to switch between object/camera mode, or to tweak the speed of the device, how does one do that without the full whack sophistication of the SpacePilot?

There is a Type property on the ISimpleDevice COM interface, and a short list of (currently) defined codes - how does the implementer get a sensible list of the features which match to those device codes?
Should the App even be checking the device codes at all, or is there a preferred style of design which avoids device-specific mods, and uses application fall-back commands?
What should the app fall-back style be?

If (when) 3DxConnexion add a new device, how does one best prepare for that? Do 3DxConnexion send warnings in advance to all known supported App developers, saying "there will be a new product, with these features and this code - please update your App?"


If an app implements an Object Mode toggle, can it interact with the device in a manner similar to the Dominant Axis button or Translations button, and post a temporary "Object Mode On" "object Mode Off" label to the display?
How? (to post, and to clear after time interval, restoring previous text)
Clearly any such interaction can't be allowed to fail (badly) (only gracefully) on the lesser devices, and I presume we should not rely on the user being able to have such features... What then is the preferred style?

[alexus]

To me SpaceNavigator (and Pilot) is t just a mouth HID device, if you really going for comercial release you better write your own HID to be fully independant from any potential changes in softrware updates, yet that can be dangerous if they will change the hardwaree adresses.... I would say it is good to rcognize diferent products via direct HID and then use your app to talk to the given API and thelect the functions that are preset... I dont have SpacePilot and dont have budget nor need to buy it but i'm pretty sure that HID addreses are the same(hey can we get source files of the firmware for the device? [thats to Logitech guys])

As to the acceeleration and direction profiles, I did that on my own, just use timing avarage values and you have good simulation of speed, I also used that to filter out position inperfection and overlaping that is caused by the fact that you hold your hand at the angle.

[ngomes]

Hi alexus,

hey can we get source files of the firmware for the device? [thats to Logitech guys])

I do not think so... Why would you need the source? The devices are not reprogrammable and already implement an open hardware standard ("HID multi-axis controller").

Coding for HID manager is complex and time consuming. There are other options on Windows if a developers wishes to stay away from the interfaces provided by 3Dconnexion. Raw Input and Direct Input (if your app is already using DirectX) are the two other options.

[alexus]

I didnt know about DirectX options, will take a look at it (although never worked w/ dx)
Well my project is to controll car electronics via space navigator, so more direct access the better. I dont think ppl really need firmware but rather the addresses of the sensors. In my demo project I did rendom listen to all addresses and was able to get data exept I dont know what data is that

[ngomes]

Hi alexus,

was able to get data exept I dont know what data is that

All 3D mice from 3Dconnexion are "HID multi-axis controllers" as defined by the USB Forum. You should check the "HID usage tables" documentation.

[alexus]

yey that will work too =)
thanks!