09-06-2015 12:51 PM - edited 09-06-2015 01:05 PM
Just a few comments on your summary:
I don't think that your step 3 is correct. In any case, I think it is much easier to use the Camera Setup invoke node than to try to play with the matrices whenever possible.
1. You need to modify the Model View Matrix only if you use the Side-by-Side format. If the 3D picture control has the dimensions of the final image (as for the Oculus Rift for example), no Matrix multiplication is necessary.
2. If modification of Model View Matrix is necessary, you need to do it for both eyes.
3. If modification of Model View Matrix is necessary, you need to do it after each change of Camera positions (either programmatically or from the user).
4. The value of 64 mm for the interpupillary distance (IPD) is an adjustable parameter, depending on the viewer. The wrong IPD is one of the alleged cause of the discomfort experimented by users when using 3D.
5. I personally prefer to offset each camera by half the inter-pupillary distance so that the center (0,0,0) is the center of the viewer. This way it is easier to keep the view symmetrical from both eyes when looking at a specific target position.
09-07-2015 01:01 AM
Hi MarcDub
My wording of step 3 was poor: not "give" 64 to the right hand image, but "right hand image" = "left hand image" + [[0,0,0,64],[0,0,0,0],[0,0,0,0],[0,0,0,0]].
I agree, adding 32 to the right and subtrating 32 from the left is better (or whatever your interocular distance may be), but in my case I still wanted to make use of the mouse control.... on at least one of the images. I then just make the other image follow the first (mouse control in one image only).... possibly I must draw a fake mouse cursor on the other display (and then it can be a 3D mouse ! awesome !)
In games, the controller is not usually the mouse, so I agree with you that +32 and -32 would be better.
09-07-2015 07:47 AM
Hi MarkDub
Tried your flying balls example with only wiring the left eye to both 3Dpicture controls.....
Works exactly the same.
I am not sure how opengl handles duplicate objects internally, but I suspect the memory requirement can be halved by not duplicating the objects.
This will be especially usefull when you have a large scene with many textures.
09-07-2015 08:10 AM
OpenGL has no problem drawing any given object multiple times without duplicating the object in memory (aside from graphics memory that is).
How LV handles the same thing (it's essentially using an OpenGL Wrapper but not only) I'm not so sure but you CAN add the same object multiple times, I just don't know if LV internally copies or not.
09-07-2015 08:49 AM
You are totally correct. It is a mistake on my part, there is no need for 2 scenes. The stereo effects are obtained by the shift in the camera of the 3D picture controls. I started building the VI thinking that I would use references for the 3D Picture controls and I slipped into that error. The spaceship application uses only 1 scene (it is significantly more complicated, that is why I did not make the code available).