Syphon JNI Binding

Home Forums Syphon Syphon Development – Developer Syphon JNI Binding

Tagged: , ,

Viewing 20 posts - 21 through 40 (of 41 total)
  • Author
    Posts
  • #5110
    vade
    Keymaster

    Here is a screenshot. I need to get Processing talking to native OpenGL, so I can get Raw texture IDs.

    View post on imgur.com

    I will upload this to SVN later this evening, maybe tomorrow, as I have some pressing engagements shortly, however this is great news 🙂

    #5111
    andres
    Participant

    Excellent! I’ll make a new library package that incorporates the opengl integration once you push all the latest changes to the trunk.

    #5112
    andres
    Participant

    BTW, I made some modifications to the OPENGL2 renderer so it is now easy to get the GL parameters from the textures encapsulated by a PImage, but this will work only on releases after 0195.

    #5113
    andres
    Participant

    Ok, I got everything running!

    View post on imgur.com

    The Processing library is here:

    http://interfaze.info/files/syphon/Syphon-0.0.1.zip

    However, it only works with the latest revision from Processing trunk 🙂

    I also would like to contribute a small ant build file that generates the jsyphon jar file, discarding the test files. You can include it in the syphon repo if you want.

    Cheers!

    #5114
    andres
    Participant

    And the frames being read by the syphon recorder:

    View post on imgur.com

    Awesome!!

    #5115
    vade
    Keymaster

    Oh awesome. So you can send a PImage now, and the Syphon java class will handle sending that to Syphon as a texture? Very cool. I got it working in 1.2.1 using the PGraphics object to get a GL handle and manually read a texture from the screen, like so:

    // OpenGL
    import javax.media.opengl.*;
    import processing.opengl.*;
    
    // Syphon
    import jsyphon.*;
    
    PGraphicsOpenGL pgl;
    
    float a;
    
    JSyphonServer mySyphon;
    
    void setup()
    {
      size(800, 600, OPENGL);
      mySyphon = new JSyphonServer();
      mySyphon.test();
      mySyphon.initWithName("Syphon - Processing");
    
      // get an OpenGL handle
      pgl = (PGraphicsOpenGL) g;
    
      // add shutdown and close handlers
    /*  Runtime.getRuntime().addShutdownHook(new Thread(new Runnable()
      {
        public void run()
        {
          ohGodStop();
        }
     }));
     */
    }
    
    void draw()
    {
      background(255);
    
      GL gl = pgl.beginGL();
    
      gl.glColor4f(0.7, 0.7, 0.7, 0.8);
      gl.glTranslatef(width/2, height/2, 0);
      gl.glRotatef(a, 1, 0, 0);
      gl.glRotatef(a*2, 0, 1, 0);
      gl.glRectf(-200, -200, 200, 200);
      gl.glRotatef(90, 1, 0, 0);
      gl.glRectf(-200, -200, 200, 200);
    
      // copy to texture, to send to Syphon.
      int[] texID = new int[1];
      gl.glEnable(gl.GL_TEXTURE_RECTANGLE_EXT);
      gl.glGenTextures(1, texID, 0);
      gl.glBindTexture(gl.GL_TEXTURE_RECTANGLE_EXT, texID[0]);
      gl.glTexImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0, gl.GL_RGBA8, width, height, 0, gl.GL_RGBA, gl.GL_UNSIGNED_BYTE, null);  
    
      gl.glCopyTexSubImage2D(gl.GL_TEXTURE_RECTANGLE_EXT, 0,0, 0, 0, 0, width, height); 
    
      mySyphon.publishFrameTexture(texID[0], gl.GL_TEXTURE_RECTANGLE_EXT, 0, 0, width, height, width, height, false); 
    
      gl.glDeleteTextures(1, texID, 0);   
    
      pgl.endGL();
    
      a += 0.5;
    }
    #5116
    vade
    Keymaster

    Oh, and thanks for the zip too, btw. How do you suggest we roll this into the SVN, organizationally speaking? Do you want SVN access as a committer so you can help handle the processing library and Java side, if thats would be something of interest?

    #5117
    vade
    Keymaster

    Oh, one last thing, the JSyphon java library will eventually have objects for clients and servers, so I would suggest that the Processing library be more specific, so creating a SyphonServer object for sending, and a SyphonClient object for receiving, etc, would be helpful for keeping the API more readable and conceptually sound. We can totally hammer this out though once we get that functionality actually working 🙂

    #5118
    andres
    Participant

    yes, you can add me as a committer, I think is good idea. Perhaps the Processing library could be just hosted in the syphon repo?

    I also agree about making the Processing library more specific. We will figure out the details of the API as we move along. So far, things look very good. Thanks for all your work!

    #5119
    vade
    Keymaster

    Thank you andres for your help and putting the library together.

    I’ve added you as a committer in the http://code.google.com/p/syphon-implementations/

    I’ve made a top level “Processing” folder along side the other implementations, so you can put the library there. Add a readme if you want and make sure to put yourself in the credits!

    Happy hacking, and thanks again! Let me know if you end up needed to mess with the JSyphon JNI shit, just so we can communicate. You can ping me at v a d e [at] v a d e [dot] i n f o if you need to.

    #5120
    andres
    Participant

    quick question: is the client API in jsyphon already functional?

    #5121
    bangnoise
    Keymaster

    Just looking at the source, it like it does everything apart from emitting images… so not very.

    #5122
    bangnoise
    Keymaster

    I’ve added an issue with a JSyphon TODO list. andres, I think you have more JNI experience than any of us if you’re interested in any of these…

    http://code.google.com/p/syphon-implementations/issues/detail?id=8

    #5123
    vade
    Keymaster

    Sorry guys, I was away the weekend. I will try and get to it today. I am thinking it may make sense to do without the SyphonImage, and simply have latestFrameImage return a texture ID which can be bound. The additional complexity of emmiting a jobject (the JNI’d version of the Syphon Image) that is temporary, seems kind of of limited use.

    Thoughts?

    #5124
    bangnoise
    Keymaster

    We need to encapsulate the SyphonImage which owns the texture, otherwise you’ll end up drawing with an invalid texture ID – the only way to do that without an extra object would be to have “lock” and “unlock” functions in the client which retain the current SyphonImage then release at unlock, but that greatly complicates multi-threaded use.

    #5125
    andres
    Participant

    Just to understand a little better how the client works, first thing it should do is to retrieve a list with the running servers, right? is this what JSyphonClient.serverDescription() is supposed to return?

    #5126
    bangnoise
    Keymaster

    In the framework itself, we have a separate object for server discovery, SyphonServerDirectory. Having that handled by a class method of JSyphonClient would be fine though I think.

    I imagine JSyphonClient.serverDescription() is intended as an exact match for the framework’s SyphonClient.serverDescription, which returns the dictionary describing the remote server. I’m not sure how we want to handle instantiation of clients in JSyphon though – for OpenFrameworks and Cinder we do it using a server name/app-name string pairs to avoid having to pass the serverDescription NSDictionaries used by the framework around, which might make sense here too..? In that case JSyphonClient.serverDescription() would probably be replaced by serverName() and serverAppName() methods.

    #5127
    andres
    Participant

    Hey guys, I finally managed to return to the Syphon code. After inspecting the simple server/client apps, it seems to me that one missing binding in the JSyphon wrapper is for the SyphonServerDirectory functionality, so the list of available servers can be queried before creating the client. I will start with this, and see if I can add a working getAvailableServers method to JSyphonClient that returns a dictionary of the currently available servers.

    #5128
    vade
    Keymaster

    It might make sense to rather than use and pass dictionaries, to use the “SyphonNameBoundClient” which is found in the QC, Jitter and Open Frameworks implementations. The idea is you can pass strings for just a server name, or an app name, and the internals in the name bound client will find the best match.

    Thanks *so much* for being interested and lending your talent. We really appreciate it.

    #5129
    andres
    Participant

    ok, I see. I will start with this SyphonNameBoundClient class and try to make it work through JNI.

    As a side comment, I just thought that another helper class, i.e: SyphonServerList, that uses the same server announce/update mechanism as in SyphonNameBoundClient but just to keep an list of up-to-date servers names, could be useful in order to implement in the Processing library a static method such as String[] SyphonClient.listServers().

Viewing 20 posts - 21 through 40 (of 41 total)
  • You must be logged in to reply to this topic.