Spout Receiver in OpenGL C++

Home Forums Spout Developer Spout Receiver in OpenGL C++

This topic contains 17 replies, has 2 voices, and was last updated by  meebs 2 days, 19 hours ago.

Viewing 3 posts - 16 through 18 (of 18 total)
  • Author
    Posts
  • #4121

    leadedge
    Keymaster

    Spam is actually the problem we have and the anti-spam plugin is being too strict. We are looking at possible solutions. Meanwhile I think the post history shows people the sequence of events.

    So anyway here is my reply (I hope it isn’t rejected).

    Following from the reply about CheckReceiver. This function is called first within ReceiveTexture, so it should not be necessary to call it twice. I am not sure why this is failing if you have already called CreateRecievr and it has connected OK.

    When I create a receiver, I have to pass it the sender name I want to receive from. However, when I ReceiveTexture, I also have to pass a sender name, right? How do those two interact?

    If the sender established in CreateReceiver exists and there are no changes, the current name and dimensions are returned and Receivetexture returns true. If not yet inititalized, ReceiveTexture (via CheckReceiver) will connect to the name provided or the active sender and still return true but the new sender name and dimensons will be returned. So if you find that the sender dimensionsl have changed and you will need to re-initialize your receiving texture.

    although I called CreateReceiver with the proper name, I was sending a blank string to ReceiveTexture.

    If the name you provide is empty (zeros not spaces) CheckReceiver will try to find the active sender but only if not initialized yet. Otherwise the connected sender name is returned.

    perhaps this is because it was ignoring my blank string and using the one I set when I called CreateReceiver?

    That is what is happening but it will still return the current sender name if already initialized.

    If CheckReceiver connects to a different sender, the new sender name and dimensions are returned. ReceiveTexture still returns true but it is up to the application to test for dimension or sender name change. Normally dimension is the important thing because you have to resize your texture. You can use the sender name returned to display what sender is being received from.

    — Regarding fbo —

    This means that if I had previously bound an FBO to render to, I’ll need to rebind it. Alternately, I can pass in the FBO as an optional argument to this function and Spout will call glBindFramebuffer(GL_FRAMEBUFFER, myFBO)); so I don’t have to call it.

    That is correct

    Is me passing in an FBO and me calling this line right after ReceiveTexture completely equivalent?

    Sort of – but ReceiveTexture will call glBindFramebuffer(GL_FRAMEBUFFER, 0) first. So it’s better to eliminate this step.

    During my render code, I always call glBindFramebuffer right before glDrawArrays, so I shouldn’t need to pass in any FBO right?

    You only need to pass an fbo ID if that fbo is currently bound. If you bind it later you don’t need to. In fact it would bind the fbo and possibly mess things up unless you used that fbo immediately.

    — future changes —

    I can see that this can get confusing, so I am working on high level functions within the receiver class that will hopefully be easier. The plan is that you will be able to do the following :

    // Allocate an RGBA texture of any size to receive from the sender.
    // so that there is a valid ID and target to set up the receiver.
    myTexture allocate(width, height, GL_RGBA);

    // Set up the receiver with the texture details.
    spoutreceiver.Setup(textureID, textureTarget);

    Then in your render loop :

    if (spoutreceiver.ReceiveTexture()) {

    // If Updated returns true, the sender size has changed
    // and the receiving texture must be re-sized
    if (spoutreceiver.Updated())
    myTexture.allocate(spoutreceiver.GetSenderWidth(), spoutreceiver.GetSenderHeight(), GL_RGBA);

    // Draw the current texture

    // You can also get the current sender name
    // It changes if the user selects another one
    // spoutreceiver.GetSenderName();

    }
    else {
    // Sender has closed
    }

    And at program termination.

    spoutreceiver.Close();

    Meanwhile though you need to use the current process. Although you have it working, it should not be necessary to call CheckReceiver first and I am not sure what is happening here.

    #4124

    leadedge
    Keymaster

    You may want to clear up in the SDK guide that the width and height define the size of the texture you’ve created. I’m also still confused as to why ReceiveTexture can return a success if I pass in uninitialized or mis-sized width and height, making it fail at copying the texture.

    The way it is supposed to work is that name, width and height are always returned as those of the sender the receiver connects to. Then you adjust your texture after you know the size.

    ReceiveTexture can return success because once the sender is connected, global variables are established for the name, width and height. It is using those, not the ones you pass in, so it can return true if they all match up and a texture is received.

    In the proposed changes you will see that you don’t pass anything in to ReceiveTexture at all, but can get back the connected sender details which I think is a less confusing way. But it will be a little while yet because there are quite a few other changes as well.

    If you have it working that’s the main thing. If it passes testing with user sender selection and sender size change it should be reliable.

    #4127

    meebs
    Participant

    Okay, that all makes sense and those proposed changes sound like awesome quality-of-life changes for devs like me who are not fully fledged GL wizards yet. Yep, I did some stress testing last night with various sizes and receivers. All seems to be working well on switches and ends up being very performant. Excited to be releasing Spout Input in our next build of Synesthesia (www.synesthesia.live). Thanks for following through my chaos and misuse of the API!

Viewing 3 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic.