I would like to appreciate Alexey Shelyagin's commitment to the project. I had been working with him in a team. GitHub: https://github.com/AlexeysShelyagin
People consume a large amount of various visual information. In most cases, people perceive such information projected onto a plane.
At the same time, humans perceive information better when presented in the form of a three-dimensional image. One way to display three-dimensional images is to use holograms.
Among available solutions, there are simple and cheap ones. Such as using a display and pyramid system. Also, there are more advanced ways, such as projecting holograms onto a sphere.
But these methods have their drawbacks. The main cons are that they either depend on the observer’s position or provide small viewing angles.
The purpose is to create a device that can display a three-dimensional image, perceived without distortion, regardless of the observer’s position. The hypothesis is that the POV effect will allow displaying a three-dimensional image, perceived without distortion, regardless of the observer’s position.
Model of the experimental setup
The device moves the table with a display or matrix. The hardware platform is Raspberry Pi 4B+. Also, we use a stepper motor and an optoisolator. We use the last one to calculate the current position of the table.
Development
While developing the model, Alexey used Autodesk Fusion 360. Then he printed all the parts and built the model.
Mechanism
In the video, you can see how the mechanism turns the rotational movement into translational with the help of rotating rails.
With this mechanism, Alexey eliminates the sine wave during motion conversion, which avoids the display/matrix being in the top and bottom points for a long time.
The displays and matrices
We used an SPI display for the first version of our setup. The second version has an 8 x 8 pixels LED matrix controlled through shift registers.
Displaying the Image
It is clear that there are drivers for outputting an image to the display via the SPI interface, but we encountered a set of problems when using such displays.
Artifacts
We encountered artifacts when displaying the image to the matrix, which arises from the low update rate of the matrix, which leads to writing the data to the display’s frame buffer when reading from it.
Interlayering
To solve this problem, we used our algorithm — interlayered scan.
The essence of the algorithm is that we update the display’s frame buffer with the backlight off to a layer whose output we can guarantee. The driver fills the skipped layers on the reverse pass.
But the image obtained this way is hard to perceive by the human eye.
Using the matrix through shift registers
Accordingly, we decided to use a matrix (8 x 8 pixels) driven by shift registers. It has a significantly lower resolution but large viewing angles, a high refresh rate, and, sequentially, we can output more layers.
Moving from user space to kernel space
We also decided to use kernel modules to control the matrix instead of userspace allowing us to achieve fixed timings between pulses and a higher matrix refresh rate.
For communication between the client and the server, we implemented a protocol based on TCP, which works the following way:
The server transfers information about itself to the client (workspace resolution along the X and Y axes, the maximum number of display/matrix frames);
The client sets the number of layers of the 3D image (Z-axis);
The client transfers images of each layer to the server.
Compression
When transferring the data in the raw format, it usually takes 1.5–2 seconds from starting the transfer to displaying the image in the workspace of the setup. We decided to use compression.
We compared the Deflate algorithm and the H.264 and H.265 codecs (for the first version of the installation). As it turned out, the Deflate algorithm has much less processing time compared to codecs, even with hardware acceleration.
Demonstration (second version)
Analyzing the frequency of the matrix
You can see the graph using which we determined the refresh rate of the matrix. The driver transfers each line at an average frequency of 24 kHz. Given that the matrix has eight lines, the matrix fully updates at the frequency of 3 kHz, which allows us to display about 120 layers in height.
Cons of the software and hardware
We need a faster hardware platform and higher resolution matrices/displays with a lower refresh time
Distortions may occur when using optical elements, such as glasses
The Deflate algorithm is inefficient if there are no patterns in the source file
Sources
Linux Kernel Module: pkasila/matrixdriver
Server: pkasila/matrixvox
Client: pkasila/matrixvox_client
Slicer: AlexeysShelyagin/Matrixvox-slicer
