Hi there. I am looking to make a full screen Windows compositor, one that takes an image from Unity (preferably from standard render pipeline), doesn’t display to screen directly, but is intercepted by spout (either through a native dll that is loaded into Unity or through an external compositor) and spout can do some extra buffer management before sending to display.
The goal is that I want spout to run at the display refresh rate regardless of any frame drop that is coming out of Unity, so that I can do work on managing buffers in spout to mitigate the drops. In particular, I want to be able to hold onto previous buffers that were rendered, modify them slightly, and show them on-screen.
The question I have: is spout capable of handing the above situation? I can send more exact details if needed, but my hope is that if this is possible and a compositor can be created to run consistently at the native refresh monitor rate without drops, I will start investigating how to go about doing this. Contracting this out for help is also a potential option; I would rather have an expert handle this for me since I would like to make this happen sooner rather then later.
Thank you! Peter
Side note: I am pretty certain there is a path here, I was able to use Win32CaptureSample app to pull from a full-screen borderless Unity app (not from exclusive full-screen, which is the ideal setup for me) and then run it through SpoutReciever app. Aside from the extra CPU/GPU overhead, it seemed to work well; if I were able to get the SpoutReciever app source (which, by the way, doesn’t seem to exist, meaning I cannot see how full-screen mode is managed in the app) I could start hammering away at understanding how the buffer flow works under the hood and verify that my requirements can me met.
a Spout receiver will run at the application rate. It will copy a new texture from the sender, when it gets access. That is when the sender is not updating and when no other receiver is accessing the sender’s shared texture, and also if the Sender has produced a new frame. The receiver render rate is not influenced by the sender’s frame rate.
I think the UE4 plugin uses DirectX and not OpenGL. In that case there are two buffer staging textures for receiving images, but not for receiving GPU textures.
There will be frame drops if the receiver is cycling slower that the sender, or if it gains access to the sender’s texture just before the sender produces a new one. In the main these drops are rare. One way to avoid drops might be to lock the receiver to the sender using sync events. In that case, the receiver waits until the sender signals a sync event after producing a new frame. This is shown in the example where data is transferred along with the video :
The Spout Demo Sender and Receiver code is not suitable for open source because it’s based on an ancient tutorial by NEHE and it’s more trouble than it’s worth to clean it up. But a copy has been created in Openframeworks that uses the same methods, such as full-screen. You can examine the code for that. Full-screen is just a re-sized, borderless window and behaves exactly the same as if the Window had a border, caption etc.
If the Win32CaptureSample app works, you might be able to duplicate what you want from this.
You have options depending on what you base the application on and can use DirectX instead of OpenGL.
So have a look at the full screen and sync methods first and see if that’s any help.
This is incredible information, and I truly appreciate your response. I’m using DirectX11 at this time, and since for now Windows is my main (and only) platform, I will continue with it.
So what I’m gathering is that the sender can send data that a new frame exists. Which means, the receiver can work on older buffers at frame rate, and when the sync signal comes in, the receiver is free to copy (or do whatever) it wants with the new frame. Thus, the receiver should never be blocked (if the main thread has higher priority then the senders, possibly) and will be able to properly feed the buffer of choice to the display.
I will look into the examples, and will definitely update my findings here. Thanks again!!
Thank you. I would like to chat with an expert about possibly contracting out my requirements for the project I am working on. It’s an interesting project
Is there anyone that I might be able to reach out to for chatting about this? My guess is that the experts on Spout are all on this channel, so my hope is to talk directly with someone.
I totally appreciate your help. If anyone is reading this, all I am looking to do is validate that it’s possible to create a compositor that runs at a constant rate as the display, which can be used to inject or select proper buffers for outputting to the display. I can implement this, but do not have the time to do it; validating is more important then implementation. Validation will allow me to have the confidence to approach those which have the resources to bring this project together.
Have a look at what I’m doing at www.athanos.com if interested. This will give a better idea of what I’m making.
