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, manuel

You 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, manuel

The 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