koobas.hobune.stream
Possible to manually control buffer swapping (for side-by-side distributed 3D Stereo)?
I am investigating using Unity for a 5-wall CAVE system. Our system uses side-by-side (horizontal span) stereo along with frame locking NVIDIA GSync Framelocking and soft-lock via "swap buffer" packets over the network (as in, the vertical sync signals are linked to the shutter glass system via GSync but the applications themselves swap buffers when receiving packets from the head node).
I am wondering if it is possible to accomplish something similar in Unity. I know side-by-side stereo is possible (dual camera, RTT arrangement) but I am not positive about the manual buffer swapping aspect. I am aware of WaitForEndOfFrame() which claims to trigger just before the frame appears on the screen) but, with my limited Unity-specific knowledge, I can not deduce whether this truly serves the purpose that I have (basic having the engine render the scene, then wait until receiving a packet over the network, THEN swapping buffers).
Can anyone confirm/deny whether this behavior is possible?
I've recently answered a question like this, and basically it comes down to using
camera.Render();
to manually render the screen whenever you recieve the signal to.
I'm not sure about this network-buffer thing- you'd have to make sure it's pretty low-latency if your rendering is dependant on it.
To my understanding, camera.Render() tells the camera to commence rendering. It gives you no control about when the back-buffer is brought forward when doing double buffering. If all the nodes in the cluster need exactly the same amount of time to render then everything is fine, however, if that is not the case, then you basically end up with unsynchronized rendering (which can be quite bad over multiple displays that are tiled).
That's why I'm looking for the more fine-grained control over glSwapBuffers(); That can be invoked once all nodes have reported that they've completed rendering but have not yet swapped buffers so the only discrepancies in synchronization will be due to network delay (which, in a LAN) is quite small.
