Remote control objects and geometry - How to update objects each frame

Hi,

I’m using openframeworks since 6 month now and I really love the simplicity how the things works. Therefore a big thanks to all the developers.

I’ve just started a new tiny project. In this project I’d like to translate objects from a remote computer (server). The client (also a computer and later an android device) received the transformation data. In the update or draw method. I’ve already tried to realized it with the ofxOsc addon (which is my favor) and I’ve also tried it with the ofxNetwork (both UDP and TCP). Both worked nearly perfect but sometimes on the client side no data received which ends in a kind of jitter and the transformation is a bit jerky.

Simple Example:
server:

void ofApp::keyPressed(int key)
{
    ofxOscMessage m;
    m.setAddress("/transformation");
    m.addStringArg("left");
    sender.sendMessage(m);   
}

and the client:
in update or draw

 while(receiver.hasWaitingMessages())
 {
    // get the next message
    ofxOscMessage m;
    receiver.getNextMessage(&m);
    if(m.getAddress() == "/transformation") {
          blabla move left
    }

Do I use the wrong addons (ofxOsc and ofxNetwork) or what else can I do to get the update each frame?

Regards
Lasse

ofxOsc uses UDP network packets which are very fast, but are not guaranteed to be received by the client. They are useful for things like control data where if one packet is missed due to network problems, the next packet will soon come and keep the system up to date.

ofxNetwork uses TCP network packets which receive confirmation from the client when they are received. This process ensures that no packets are lost (if if they are, you know about it), but the confirmation overhead can create latency.

If you want to make sure that your transformations are in lock step, you really need a very fast direct connection between the two computers. ofxOsc should work well. The problem is that any packet loss due to network problems, like latency will be visually very obvious.

The other issue might be that when you send a lot of osc frames, the receiver won’t actually process them right when they are received. It will wait until the next update / draw loop. In some cases there might be more than one frame ready to apply, so that many transformations will occur before you actually draw the object, resulting in skipping. One solution here is to make sure that the receiver is running at an adequately high framerate and the sender is not running at a significantly higher framerate that will overwhelm the client.

Anyway … just a few ideas :slight_smile: