Or, at least a few seconds into the past…
Major steps ‘forward’ on my time machine simulator today. Seeing the beauty of classes to really keep your code clean & efficient. My main draw loop now looks like this:
void testApp::draw() {ofTranslate(fullWindowWidth/2,fullWindowHeight/2);
ofViewport(0, ofGetWindowHeight()/2, ofGetWindowWidth(), ofGetWindowHeight()/2);
myMesh->updateMesh(smoothPZ, smoothDiffX, smoothDiffY, transZ);
ofViewport(0, 0, ofGetWindowWidth(), ofGetWindowHeight()/2);
myMesh->updateMesh(smoothPZ, smoothDiffX+eyeDistance, smoothDiffY, transZ);}
Everything else happens under the hood. Since I’m building a layered, installation-oriented, theatrical application, one can easily imagine expanding the graphics processing to incorporate playful 2D visuals layered in a “heads-up-display” style. Relying on a class that is external to my main draw loop allows me to clearly see and see the order in which I draw my graphics.
Once I figured out ofViewport (thanks, again, to Kyle McDonald) incorporating 3D has been surprisingly easy. Rotating right eye’s perspective 7.5 degrees from the perspective of the left eye did the trick. I was expecting more complex stereoscopic subtleties to pose significant problems; convergence and other 3D-specific parameters often provide significant challenges to the live-action 3D cinematographer (as my 3D simulcast gig next week may demonstrate).
One bug: sometimes when I connect the sony HMD (think video goggles) I’m using, the top and bottom image sections are offset by about 1/4 of the screen height. It’s not a bug in my coding, since I observe this discordance outside of openFrameworks. I can’t seem to reliably repeat the problem, and only a long restart fixes it (and even then, only some of the time). The order with which I connect the components (the goggles, their control box, the DVI to HDMI adapter) may have something to do with it. The best thing, here, would probably be to look into a proper graphics card that provides true HD 3D output. As it stands, I’m squashing two images into a single 1280×720 output — that’s about 640×360 per eye, significantly less resolution than the 1280×720 pixels the sony HMD is able of displaying per eye — and relying on the HMD to “unsquish” each image into discrete left and right images, a process of encoding 3D that is colloquially referred to as “over-under”. It’s somewhere in this last process, I think, that things are going awry, since the 2D mode seems fine. Since the HMD also supports a “side-by-side” mode, that’ll be the next thing to try.
Recent Comments