Is it possible in vvvv? Information about the virtual camera arrangement can be found here: http://paulbourke.net/stereographics/stereopanoramic/. I was trying to implement this approach by creating several 100 cameras capturing small vertical slices. But vvvv became really slow…
Attached a patch with a spread of 100 cameras. It results a 360° viewport, but the frame-rate goes down dramatically. Is there any way to spread views and keeping a good performance at the same time? Or another method to achieve something similar?
360ViewPort 100cams 2.v4p (21.2 kB)
I disabled the Text.EX9 and it works great ! _
I suppose that you need it only for demonstration purposes.
Thanks Nissidis, disable the text improves the performance.
I went some small steps further, added camera pairs with offset and lens-shift (for each eye) and merged them with an anaglyph patch I found here in the forum. I believe it somehow can work out, but the performance drops down again when adding a second renderer and increase the amount of cameras. Furthermore, the front-face culling and z-alignment of the 3d cubes in the renderer is messed up.
At this point, I don’t know how to solve this issues. I believe vvvv is capable of it (which would be actually really cool), but I’m not sure if I’m using the right approach. Any suggestions are very welcome!
stereo pano 02.zip (10.1 kB)
I just open your patch, a quick fix for culling is to use a render state node called Cull connected on the first pin Render State of PhongPoint(EX9.Effect) and select the “Counterclockwise” value on_Culling_
I will dig it more, nice job keep it up!
Thanks, the cull node helps a lot!
It seems that the z-order of the cubes isn’t correct either. Somehow, the problem did not occur in the first patch. In the second patch I used the projector node, because it allows to adjust the lens-offset and visualizes the camera cones (which is quite helpful). Maybe there is something related to the projector node settings that causes the culling and z-order problems…
Ok, I found the reason of the wrong Z-order: I set the camera near plane to zero. When it’s higher, the Z-alignment looks fine (patch attached). With the cubes in the right Z-order, it seems there is a nice positive and negative parallax.
Now, the big challenge is to optimize the performance. Any suggestions how to speed this thing up?
stereo pano 03.zip (10.0 kB)
super interesting topic!
did you also try the “capture using one camera” approach that paul bourke suggets?
this way you might be able to make the other renderer obsolete and gain some performance. just a thought, didn’t try…
Thanks for your suggestion Motzi,
The single camera approach is cool, but I have no clue how to extract the two vertical slices from the camera without using (probably CPU intensive) texture patching. Considering that Paul is suggesting 360 slices, which would result 360 cameras, it might still lead to performance issues.
Beside this, I came across another issue: When displaying 3D lines, it seems that some of the lines are vanishing in some cameras (while wireframe lines are still appearing correct). I tried to trace the problem down with a basic mono-panorama setup using 4 cameras. The patch pipeline starts with animations captured by four cameras looking out of the scene center. Then the texture from each camera is distorted and stitched together. Finally there is edge-blending and projector-distortion applied.
Attached the patch with an LFO circling a switch node through different animations. Animation No1 is using lines and some of them disappearing randomly in the four initial cameras. Similar things happen with the cube texture, cube to pano or fisheye lens node. Any ideas what happened to the lines and how to make them not disappear? …or how to speed up the stereoscopic version?
360 4cam mono.zip (2.9 MB)
i didn’t had a look in your patches here, but using 100 cams or so seems to be a strange approach to me.
attached is an old fisheye-shader, posted by someone on the forum ages ago. that might be a good starting point for a shaderbased panorama thingy.
Fisheye.zip (6.4 kB)