VRPN-Can this work?


On 18/11/2010 at 12:42, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   11 
Platform:   Windows  ;   Mac OSX  ; 
Language(s) :     C++  ;

Hey all,

Well, my plugin is finally released, so no more "tip-toeing" around;)  Quick description: Use HID devices for realtime animation/recording in c4d (cross-platform and fully scriptable).

I'm already hard at work on the next update to it, in which I'm trying to add proper 3DConnexion and Wiimote tracker support.  For this I'm using a library called VRPN.  It's basically a server/client based approach to device interfaces; though I'm only really looking to use it on a local basis.

So, the basic premise is to create a server that recognizes devices and sends their data to a client that processes the data as one of several Remote types (analog, button, tracker, etc.).  This works fine in simple command line executables, but when I add the same working code to my plugin it doesn't work.  I'm testing with a 3DConnexion Space Navigator.

The really odd thing is when I was first testing I tried a simple client in my c4d plugin (in a scenehook with message that ticked by 30 times per second to ensure the mainloops were being called often enough) and a separate command line server.  Initially it didn't work (though it did successfully establish a connection to the server program when c4d launched).  It was supposed to output to the console (simple GePrint test message).  When I switch to some other window, move the device around, and then go back to c4d, a series of my prints output to the console.

When I contacted the developer of VRPN about this, this was the response I got:

This is the behavior that I would expect if the client app is not regularly calling mainloop() on the client object.  The results will buffer up on TCP (or get tossed on the floor if UDP) until the client starts calling mainloop() again.  Maybe there is a timer that is turned off when the app loses focus?

So my question is:  Is there some limitation in c4d that prevents it from responding to this TCP data correctly, or am I just approaching this wrong?

here's an example of a simple client from VRPN

#include <stdlib.h>
#include <stdio.h>
#include <vrpn_Button.h>
#include "vrpn_Analog.h"
#define PHANTOM_SERVER "[email protected]"
   Callback handler
void    VRPN_CALLBACK handle_tracker_change(void *userdata, const vrpn_ANALOGCB a)
	printf("Received %d analog output channels (first is %lf)\n", a.channel[1]);
void	VRPN_CALLBACK handle_button_change(void *userdata, const vrpn_BUTTONCB b)
  static int buttonstate = 1;
  if (b.state != buttonstate) {
    printf("button #%d is in state %d\n", b.button, b.state);
    buttonstate = b.state;
  *(int * )userdata = buttonstate;
int main(int argc, char *argv[])
  int     done = 0;
  vrpn_Analog_Remote *tracker;
  vrpn_Button_Remote *button;
  /* initialize the tracker */
  tracker = new vrpn_Analog_Remote(PHANTOM_SERVER);
  tracker->register_change_handler(NULL, handle_tracker_change);
  /* initialize the button */
  button = new vrpn_Button_Remote(PHANTOM_SERVER);
  button->register_change_handler(NULL, handle_button_change);
  // main loop
  while (! done )
    // Let tracker receive position information from remote tracker
    // Let button receive button status from remote button
}   /* main */

In my plugin, the mainloops are being called in the Message member of the scenehook, triggered by a MessageData class that ticks by 30 times per second.  The variables are declared as private class variables and filled in the Init member.
Thanks in advance:)


On 19/11/2010 at 04:24, xxxxxxxx wrote:


Ok, I don't think my methodology or approach is the flaw here (I know, right?!?  I can't believe it either 😂).  I think I found a bug in the 3DConnexion driver for OSX... or at least how it interacts with c4d😠.

I originally noticed this when working with SDL (3DConnexion support is in place on mac, but not on pc).  I found that with the 3DC driver installed and a Space Navigator as the active device in Control4D (my plugin) you had to actually have the system prefs window as the currently active window (not c4d).  That was the only way a 3DC device would send data to my plugin.  I wrote it off as a problem with SDL; since the 3DC support was just a patch and only for Mac... I assumed it was somewhat "thrown together"... or, well, lets just say I had a more faith in 3DConnexion than I did with just some random person who submitted a patch:D

So, on a whim, I decided to uninstall the 3DC driver.  Now I can get space nav axis output to the console without having to put focus on another, outside window👏  And I think the display lag was due to the number of prints that were being generated (30/sec*6=180 GePrints/sec).

This is sort of good news... as I didn't want to have to get into the IP functions of c4d (which is something I was worried about, since VRPN is designed for large network VR type setups).  But then again, I'm still not sure if the fix for the 3DC/c4d thing I've found falls on 3DC or Maxon... I'm hoping it's just a bug in the 3DC driver.  I'll pop over to their forum and issue a report.

Oh, and I "uninstalled" the spacemouse plugin from c4d early in my testing to make sure that wasn't the problem.

Luckily, both SDL and VRPN allow the use of such devices without the 3DC driver installed; but I don't want to have to ask my users to uninstall it to get support.  I'll have to do some tests on windows to confirm, of course.

If I encounter any other problems at least I have a thread all set up for it, but for the time being I think it's out of my hands and for the moment I'm in pretty good shape.