[SpiROSE] Pizza

Last week was … eventful. After getting turned down again and again by the mechanic, we finally arrived at a design that might work. Simply put, a stack of ROSEace won’t cut it (haha), but a big ol’ plate à la HARP might work. At least the mechanic is okay with it ¯\_(ツ)_/¯


Anyways. I searched for algorithms suitable for the renderer we intend to write. Its job would be double :

  • Voxelize a 3D scene
  • Apply what I will call the Pizza Transform™ from now on


To my surprised, the voxelization is really easy to do, even on a GPU. I found a paper performing real time voxelization (Single-Pass GPU Solid Voxelization for Real-Time Applications by Elmar Eisemann). It is based on OpenGL Xor blending mode. Wonderful, we’ll have a renderer that will work even on complex OpenGL scenes NOT meant to be voxelized. The only constraint is for the scene to be mathematically watertight (along one axis is enough).

Pizza Transform

Now, to the Pizza Transform™. Remember that we have a circular display, where voxels are not square but round-ish rectangles ? It would be better if we could “unroll” the circular image into a nice cartesian matrix. But first, why’d we want this ?

Think about ROSEace. What they did is lay down a square image on their circular display. Think a tablecloth on a round table. Then, for each blade position, they took the pixel just under each LED. This is pretty ineffective, as well as inaccurate : you waste data by not using the corners, and you risk using the same pixel twice for two different voxels.

Even by using a smarter yet harder way, and not refresing all LEDs on the blade at the same time to keep each voxel roughly the same length, you still end up wasting space and reusing pixels.

This is a simulation done using Python and Excel for a 88×88 image. Gray pixels are unused pixels, green are used exactly once, and red are used more than once. On the left is the simple way (ROSEace), right is the more complicated one. Both waste roughly the same amount of pixels (circa 32%), and neither has a perfect 1:1 mapping of a voxel to a texel.

Enter the pizza transform. Its name derives to a simple way of explaining what we want to acheive. Keep in mind we are making a renderer, so output images may not necessarily be cartesian, and we have unlimited resolution on the input.

Take a pizza (we have a 3D model of it). You may want to display it in its glorious 3D :

However, bandwidth is sparse and you don’t want to waste anything, especially not any details by missing stuff and replicating voxels ! Take a knife, cut it along a radius (say, from middle to bottom). Now, stretch it into a rectangle with crust only on one edge :

That’s our transform. Back to the renderer. We only need to do this with our whole OpenGL scene and voxelize it. The first half is kinda done, as I wrote a Pizza Proof of Concept, that generates the cut and transform an OpenGL scene in real time, using a single Geometry Shader.

On the rightmost half of the middle circle, you can see a vertical line. This is our vertical cut that allows us to unwrap the mesh into what we have on the top right. The result may look weird, but it is due to the center of the circle not being at the origin, where the cut happens. Note that the render is in wireframe only to show the cut.


Yes, we are using an FPGA after all. Who would have believed it to be easier ? Anyways, Ethernet and the likes are out of the question.

Wait … We’re doing GPU rendrering … Straight out taking the video output to the FPGA would be perfect ! Oh, any IPs for an HDMI, DisplayPort or the likes would cost an arm, a leg and your cat 🙁 Luckily for us, the RGB protocol is trivial to use on an FPGA (think digital VGA), and event luckier, HDMI <-> RGB bridges ICs do exist, like this one from Ti. One problem solved !


This week, I’ll try to smooth out the renderer PoC and even add voxelization in it.

We will also make a final decision on the components we will use, especially on the SBC and the FPGA. Speaking SBC, T.G. did suggest SoMs from Variscite based on NXP i.MX6 SoCs. Any experience, pros and cons about those ?

We plan on using this dev board from ST (I have one and I know Alexis to have one too) to have an embedded display with touch screen interface to control some aspects of the display. I’ll setup a base graphical project for it using ChibiOS and µGFX.

See you next week ! Or even before, any feedback is welcome !

SpiROSE: how about the mechanics?

This week was full of requirement definitions. How many leds do we put, what bandwidth can we expect between the computer and the display, what technology can we use for [insert stuff here]… Lots of them have been defined, and more than 70 PSSC (Project Specific Success Criteria) have been written. During this time, mechanical drawings have been done to try different mechanical layouts.

The system is based on a main layout : a big squared block makes the fixed part of the system. A big plexiglass© cylinder with a top roof is put
over the block. Inside the fixed cylinder is the rotative part of the display. There have been multiple rotative versions. The idea is to make
something that can infer no occlusion while it’s turning. The induced problems are:
– The PCBs must be fixed without inducing occlusion (when turning)
– The layout of the system where the PCBs are going to be fixed shall not induce occlusion when turning.
– This system must resist without wobbling and have an intertia momentum small enough to respect our security criteria.


Mechanical preview

Example of full design with triangular rotary mechanism


We ended with about 5 designs for the moving part that we’re going to review with the mechanic.
More to be done on next week, as the mechanical drawings should be done at the end of next week!

SpiROSE, a new POV ROSE project

Here we are, at the beginning of our ROSE journey. A tremendous project is waiting for us to engineer it. As usual, we have been looking for a good pun with ROSE for the project name. Eventually we decided to call it “SpiROSE”, a tribute to HARP, RoseAce and video games dragons.

SpiROSE aims at creating a high resolution 3D POV system ( that can be used as easily as a regular screen, so that princess Leïa can send her hologram to Obi-Wan Kenobi without reading a full spec. To achieve this, the LEDs are distributed across several blades that will rotate at high speed. The goal is to use the full extent of the blades to create a whole cylinder, with no hole in the middle.

A 3D video pipeline needs to be created to provide awesome demo showing the potential of our system. We thought about using it as a sprite bumper viewer (see sprite lamp if you don’t know about bump mapping), then exporting models and animation from Blender and finally adding a plugin to Unity. We may only do a very simple video game using voxel directly if we don’t manage to do better with Unity. Heck, even a simple Minecraft map visualizer would do the trick!

The main subjects are :

  • The layout of the LEDs to create a full cylinder without holes
  • How to use it as a “regular” screen, how to send video data from an external source quickly enough
  • How to achieve all this while keeping a high framerate, response time and resolution
  • How to protect ourselves from the Murphy’s law

For now, our main interrogations are focused on the mechanical parts of the project. We are trying to remove the axial part that can be found on HARP or RoseAce, and move to a rotating cylinder style instead. Besides, we are trying to find other layouts for the LEDs, but occlusion is quite a challenge in this quest. We hope that people with more experience and a better physics understanding could explain us more about it, as we are only computer-engineers-to-be.

We also made rough approximations in order to have an idea of the required bandwidth. This confirmed it will be yet another challenge to tackle. We will give more details during the week as soon as we are sure about the results.

We are really thrilled to make this project as we have seen how awesome previous POV project were and we hope everybody will have a good experience during the four following months working on their ROSE project !