54 lines
3.1 KiB
Plaintext
54 lines
3.1 KiB
Plaintext
This document describes how Stereoscopic displays work and how to create software for such displays.
|
|
----------------
|
|
Basic stereoscopy
|
|
----------------
|
|
Stereoscopy functions by creating an illusion of depth by provided each eye with unique positions of a particular scene (hence stereoscopy). This results in an illusion of 3D when the brain combines the two pictures. However, given that this view is a composite of two 2D offsets, the appearance is not one of true 3D, but rather one similar to 2D objects being held at different depths (cut-out puppets, in a way).
|
|
|
|
Traditionally, stereoscopy is provided by using glasses, however modern technology allows for "autostereoscopy" or "glasses-free 3D". Basic autostereoscopy functions by showing different rows or columns of pixels based on viewing angle. This is akin to standard stereoscopy, wherein particular locations are required to achieve the desired effect. In addition to autostereoscopy, there is automultiscopy, which allows for multiple viewing angles to enhance the 3D effect (I guess it would also work for tri-ocular vision and beyond!).
|
|
|
|
----------------
|
|
Autostereoscopic displays
|
|
----------------
|
|
Autostereoscopic displays provide a unique, usually toggleable, mode that allows for either horizontal or vertically-based 3D effect. Enabling this effect sets a rendering mode that takes the pixels from a position of the screen and rendering them at another location relative to a particular eye view.
|
|
|
|
As mentioned, this rendering is horizontal or vertically-based, which means you use either half the height or half the width, in pixels, to display the alternatively rendered scene.
|
|
----------------
|
|
OpenGL/Rendering approaches
|
|
----------------
|
|
To render such a scene, one could choose to:
|
|
* render a scene at particular offsets on the screen
|
|
* render the scene to two unique framebuffers and place those on the screen
|
|
|
|
One should maintain support for regular displays, so create an environment that allows for the rendering of a scene from multiple cameras. One could use a Camera class such as:
|
|
|
|
Camera {
|
|
int render_mode; // MONO, LR, TB
|
|
// usual farz, etc.
|
|
}
|
|
|
|
For the Commander3D, display mode is managed by sending particular byte values to a device file. If you have a terminal on your Android, you can test this out by echoing the appropriate values to the device:
|
|
|
|
echo -n -e '\x40' > /dev/mi3d_tn_ctrl # 64, horizontal rendering
|
|
echo -n -e '\x20' > /dev/mi3d_tn_ctrl # 32, vertical rendering
|
|
echo -n -e '\x10' > /dev/mi3d_tn_ctrl # 16, off
|
|
|
|
Some basic code, in Java, is:
|
|
|
|
short MODE_OFF = 16;
|
|
short MODE_VERTICAL = 32;
|
|
short MODE_HORIZONTAL = 64;
|
|
|
|
FileOutputStream localFileOutputStream = null;
|
|
try {
|
|
localFileOutputStream = new FileOutputStream("/dev/mi3d_tn_ctrl");
|
|
localFileOutputStream.write(MODE_VERTICAL);
|
|
localFileOutputStream.flush();
|
|
} catch (IOException localIOException2) {
|
|
System.out.println("Error writing file to switch 3D mode: " + localIOException2);
|
|
} finally {
|
|
try {
|
|
if (localFileOutputStream != null) localFileOutputStream.close();
|
|
} catch (IOException localIOException4) {
|
|
}
|
|
}
|