Interfacing to external hardware
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2010 at 09:55, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R12
Platform: Windows ; Mac OSX ;
Language(s) : C++ ;---------
Hello,I'm working on a plugin to support an external 3D controller, and would like to know how I should best interface to OS-specific libraries. For example, on MacOSX, I need to interface to the IOKit library, while on Windows I have a host of different possibilities (WM_INPUT, using Windows message-passing, or direct interfacing to the HID.DLL device driver). The documentation gives no clue whatsoever, except that it discourages using OS-specific calls and external libraries. In that case, I definitely need to interface to the OS.
As the different methods (IOKit, WM_INPUT) spawn different threads in order to receive events from the hardware, I would also like to know which locking primitives I should best use. Should I stay with OS-specific locking (mutexes on windows, pthreads on macosx), or should I use the C4D locking/threads? The actual movement data is passed using a queue, so that the actual interfacing code is pretty much completely independent from C4D. This data is then received and passed to camera/active object/etc...
Any help would be very much appreciated.
Regards, manuel
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/09/2010 at 01:42, xxxxxxxx wrote:
Originally posted by xxxxxxxx
<ADDRESS>
User Information:
Cinema 4D Version: R12
Platform: Windows ;
Mac OSX ;
Language(s) :
C++ ;---------
</ADDRESS> Hello,
I'm working on a plugin to support an external 3D controller, and would like to know how I should best interface to OS-specific libraries. For example, on MacOSX, I need to interface to the IOKit library, while on Windows I have a host of different possibilities (WM_INPUT, using Windows message-passing, or direct interfacing to the HID.DLL device driver). The documentation gives no clue whatsoever, except that it discourages using OS-specific calls and external libraries. In that case, I definitely need to interface to the OS.
As the different methods (IOKit, WM_INPUT) spawn different threads in order to receive events from the hardware, I would also like to know which locking primitives I should best use. Should I stay with OS-specific locking (mutexes on windows, pthreads on macosx), or should I use the C4D locking/threads? The actual movement data is passed using a queue, so that the actual interfacing code is pretty much completely independent from C4D. This data is then received and passed to camera/active object/etc...
Any help would be very much appreciated.
Regards, manuelYou should use Cinema's thread & locking code. This code internally routes to the system specific pthread/win32 process code, allows you to use as much cross-platform code (that you only have to write once) in your plugin as possible and gives you the additional benefit of using Cinema's threadpool and fast lock/atomic functions.
Best regards,
Wilfried Behne
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/09/2010 at 02:35, xxxxxxxx wrote:
Thanks for the quick answer. So, the OS specific backend is left to me, there is no prescribed way of reading in HID data? Also, I could use the 3dconnexion menu (as I'm using the same HID multiaxis profile), but it doesn't seem to work anymore in R12 on MacOSX. I wonder if someone knows about that?
Regards, manuel
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/09/2010 at 03:04, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Thanks for the quick answer. So, the OS specific backend is left to me, there is no prescribed way of reading in HID data? Also, I could use the 3dconnexion menu (as I'm using the same HID multiaxis profile), but it doesn't seem to work anymore in R12 on MacOSX. I wonder if someone knows about that?
Regards, manuelThe OS specific backend to the hardware is your playground, as we don't directly interfere with USB hardware - we're using the framework (OS X)/DLL (Win) connection supplied by 3d connexion to to get the spacemouse data.
Best regards,
Wilfried Behne
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 20/09/2010 at 02:36, xxxxxxxx wrote:
Hi Wilfried,
thanks for the information, I think everything is clear. I was wary of using OS frameworks because of the SDK Guidelines.
Regards, Manuel