Slashdot Mirror

They do.

For some reason the summary links to 5DT's MRI glove, which is specialized for use in MRI applications (no metal) and obviously costs more ... cheaper 'normal' glove is here.

• Two 5DT Data Gloves (one left, one right).
• Two Ascension Flock of Birds: again, one for each hand.

There are wireless gloves from various VR companies like Fifth Dimension Technologies and others.

http://www.5dt.com/products/pdataglove5.html

There's a little company in Pretoria (in South Africa) called 5DT that has been producing data gloves that can be used as a mouse for quite a while now. Check out these links.
Their homepage.
Their hardware page (includes data gloves).
One of the data glove pages.

There's a little company in Pretoria (in South Africa) called 5DT that has been producing data gloves that can be used as a mouse for quite a while now. Check out these links.
Their homepage.
Their hardware page (includes data gloves).
One of the data glove pages.

There's a little company in Pretoria (in South Africa) called 5DT that has been producing data gloves that can be used as a mouse for quite a while now. Check out these links.
Their homepage.
Their hardware page (includes data gloves).
One of the data glove pages.

The 5DT Data Glove has had gesture recognition built into the driver for years (and has a mouse emulation layer built into the hardware), and other gloves have had gesture recognition software available for longer.

The only "new" thing I can see in this project is their (currently not realised) longer term "smart dust" remote sensor technology. Gesture recognition is old though.

Was it by any chance this company: http://www.5dt.com/? Chances are it was .. there aren't more than a small handful of companies here doing this line of work. Anyway, I work for 5DT, so perhaps I could offer a little more background. We do mostly use DirectX, but we have developed a Software Development Kit for our own use that provides an abstraction of a generic 3D renderer. Behind this abstraction we have both Direct3D and OpenGL implementations. This allows our software to run using both OpenGL and Direct3D. The main reasons we have done this is (a) possible portability in future, should we need to sell systems using OpenGL, (b) Direct3D programming is clunky and difficult, and it is counter-productive if most of our programmers have to learn it, and lastly (c) by supporting both, we ensure the process has resulted in a "good abstraction". Using such an abstraction provides for easier/faster learning curves and more stable, robust software. So we now only really need one programmer dedicated to knowing all the ins and outs of Direct3D, the other programmers can focus more on the important stuff - the application development. Creating this SDK has allowed us to have much faster application development times, as well as having more robust software.

In the past, our OpenGL support lagged a little behind the Direct3D support - previous iterations of our software were Direct3D only, and the main reason in the beginning for this was a decision to try stick to Microsoft standards wherever possible (trust me, this was not my decision :) (See my website for my own opinion of DirectX) Anyway, our OpenGL support is now on about the same level as the Direct3D support, so all of our new applications work interchangable with both.

From the perspective of our clients, most of them couldn't be bothered if the software uses OpenGL or Direct3D - they just want the software to work. From a performance perspective, we've found that both OpenGL and Direct3D are extremely similar, there is no real advantage for clients to use any particular one. Interestingly enough though, when using dynamic texture techniques (procedural textures / texture caching), we've found that on Windows2000, Direct3D has some horrible performance problems (becomes very jerky), while OpenGL remains smooth. We've never had clients that insisted on one over the other (OpenGL/D3D) though.

We also use other components of DirectX for input and sound. For networking we use sockets (DirectPlay is a waste of time, tried it), although for that too we have our own abstraction layers, thus allowing our software to be more potentially cross-platform, should a client require a different platform. Pretty much all our clients up until now have used Windows.

D3D is technically in the lead, but using GL extensions makes up for this.

Its true, DirectX will be run reliably on cheap Windows boxes. But so will OpenGL. We primarily use nVidia cards, on which both are supported. However, this wasn't the case when we first made the decisions - when we first made the decisions to go with Direct3D, mainstream 3D acceleration had only just started to take off, and the future of OpenGL looked a little wobbly at that stage - acceleration support for OpenGL on mainstream cards was almost non-existent in the beginning, while most card manufacturers *were* getting D3D support. This was the main reason for the decision back then. This reasoning is no longer true, generally support for GL and D3D are very similar, but our software is anyway now structured such that both are as easy to use. One other main reason to focus on D3D? Its "safer" - Microsoft is most likely to be around ten years from now. The future of OpenGL (and of SGI itself) has looked a little wobbly in the past, and although better now, still isn't as assured).

The software we (http://www.5dt.com/) used to distribute with our Data Glove product had a demo that mapped gestures to actions way back in 1995 already. Some of our applications use it too, not unlike the way it appears in B&W. Our current glove driver has some simple gesture recognition built into it. Granted, this is "real" hand gestures, not gestures using the mouse, so it probably isn't quite the same thing.

-----