Check the logs and the picture to see what spino looks like.
At this point it is still very experimental, we are trying to iterate on the design until we get something good. After that we also plan to build a nice casing for it.
We are based in Taiwan, so most of the components and PCB printing will be done either in Taiwan or China.
We'll try to keep a diary of our progress. Any feedback about our hardware design or cool new features / apps you could think of are welcome!
We've decided to postpone our Kickstarter campaign and to go Open Source.
You want to help us improve our hardware design? develop some apps for Spino? or just get a prototype to play around with? contact us! spino.display@gmail.com
Don't forget to check out this video of our latest software development (code source available on www.spino.tech)
More information about the open source project available here:
http://www.spino.tech/open-source
In this video we are testing a simple demo of space invader on Spino. As you can see the display is spherical which requires to adapt the game accordingly. Instead of using cartesian coordinates we are are using polar coordinates. The pixels, Instead of being arranged along a grid like in a normal display are arranged along concentric circles. This makes designing games much more challenging.
In this case, the test shows us that a shoot them up game is not a good fit for the display as shooting ennemies along circles is a bit awkward. We will modify this game so that the little space shuttle can go all around the circle while having to avoid obstacles which will be much more fun!
Spino is a connected POV LED display. All the data is streamed from a computer to the display through bluetooth. In the final version of the product we will use a smartphone instead of the computer. The smartphone will run the games and will also be used as a controller.
All the data is streamed thought bluetooth from a PC to the display (reaching the right level of compression has been a challenge and we are still considering using WIFI instead of BT)
What you'll find in the video:
- more info about the PCBs
- a few demos of retro games on ouf POV LED screen (some are real games that you can actually play others are just videos that we have ported to the display)
- demos of what we call "holographic animations" (it's just a matter of finding videos that look ok on our display (resolution, colors...), If possible with a black background that will actually be displayed as transparent in the end)
- And a short demo of live streaming from a webcam that we already posted here some time ago
Please feel free to make comments, to tell us how you would like to use this display for and what features you want us to add next.
If you can code in Python and would like to develop some small games or anything else for this display, please contact us.
Doom (the original version), is not only one of the best game ever made, but it's also a great example of C code.
Thanks to id Software decision to release the code as open source in 1999, anybody can have a look and modify it.
I had this project of changing the rendering of doom, to add a border effect to the walls, or cel shading. You can check the video at the end of this post to see why I wanted to do this to start with.
This idea of the cel shading algorithm (as described in the Wikipedia page ) is simple: we apply a Sobel filter to both the depth and normal buffers of the rendered frame, that we then superpose to the colors.
(Image from wikipedia)
I used the excellent chocolate-doom port of Doom, since this is the closest to the original I could find, and it compiles nicely.
My goal is to create my own buffers for depth and normals, and hook a function to fill them inside the rendering code, then just before the final blit, to call an other function to perform the Sobel filter and applying to the final image.
Here is what it will looks like:
-- Before. --
-- After. --
The difficulty when looking at doom source is that most of the functions have side effects modifying global variables. I have to admit it is a bit ugly, and I suspect that this was an optimization to avoid useless copies into the stack.
Neither the less, the code is easy to follow, as there is almost no abstractions and indirections. Clearly, John Carmack is an adept of the New Jersey style of programming.
I came up with this simplified function call tree for the rendering algorithm:
SpinoR_RenderBSPNode
R_Subsector // For each visible subsector
R_FindPlane
R_AddSprites // Fill the vissprites list
R_AddLine // For each wall (front to back)
R_ClipSolidWallSegment
R_StoreWallRange(start, stop)
R_CheckPlane
R_RenderSegLoop
R_DrawColumn // What I am looking for
R_DrawPlanes // Render ceiling and floor.
R_DrawMasked
What they call 'line' is really a wall surface. The reason it is a 'line' is because from a logical point of view, doom walls are just 2d lines extruded vertically (they never have slopes).
As we would expect, the walls are rendered front to back (function
R_AddLine). To prevent rendering on top of previous walls, the code
keeps an array of up to 32 ranges (
struct cliprange) of already rendered
walls. Since the front to back order is guarantied, there is no need for
an actual depth buffer.
In my case, what I am looking for is the function R_DrawColumn, that
ultimately renders a column of pixels from a sprite. It is used for both the
walls and the sprites.
Before the function is called, some global variables are set:
dc_x: x position.
dc_yl: Start y position.
dc_yh: End y position.
dc_iscale: Texture scale (i.e: view distance).
rw_normalangle: Normal of the surface angle.
Those are all I need to maintain the depth and a normal buffers.
In
R_DrawColum, I add a call to my own function spoom_AddColumn, that
fills some pre-allocated buffers:
void spoom_AddColumn(int x, int y1, int y2, int z, int a)
{
double angle = M_PI * a / ANG180;
int y;
for (y = y1; y < y2; y++) {
depthBuffer[y * WIDTH + x] = (double)z / ((uint64_t)1 << 16);
normBuffer[0][y * WIDTH + x] = cos(angle);
normBuffer[1][y * WIDTH + x] = sin(angle);
}
}
(Note that at the time when doom was release, such unoptimized code would kill the performances of the game. Fortunately this is of no concern for my needs).
Now that my buffers are filled, I just need to process them with a Sobel filter at each frame, and use the result to add the borders on top of the color buffer. I do it in a single function:
// Screen point to the color buffer.
void spoom_Apply(byte *screen)
{
int i, k;
gaussianBlur(depthBuffer, tmpBuffers[0]);
sobel(depthBuffer, tmpBuffers);
gaussianBlur(normBuffer[0], tmpBuffers[0]);
sobel(normBuffer[0], tmpBuffers);
gaussianBlur(normBuffer[1], tmpBuffers[0]);
sobel(normBuffer[1], tmpBuffers);
for (i = 0; i <...We made some change for the second prototype:
Some pictures of the new design:
32 LEDs.
64 Leds, by concatenating two 32 LEDs blades together.
For a funny demonstration of the display capacities. We made a software that
can streams a webcam video in real time into the display:
And some rendered images:
Don't hesitate to contact us if you have any question.
Following a question in the comments, here is more information about how we managed to connect the PCB to the power supply (the data being directly sent by bluetooth)
We first started with electromagnetic coils as it's a contactless solution. But we faced some issues: the hall sensor did not get enough power to work properly (the LEDs were ok though).
We ended up going for brushes; which solved the power problem and enabled us to remove some elements from the PCV (AC / DC converter)
ELECTROMAGNETC COILS
We transmit power by the wireless charging module, so for the receiver we use the IC recommended for this module: T3168.
We use the diode in the first part to change AC to high voltage DC, and use IC to control this buck converter to hold the voltage of output.
BRUSHES (hand made...)
Our first prototype was a relative success, but the size of the PCB was too big, and we want to eventually put more LEDs in the display.
For the second iteration we use twelve 74HC595 shift registers to drive the thirty-two RGB LEDs. The PCB arrived from China after a week. There was a minor error in the design, easily fixed by soldering two jumps.
On the left side, we can see the teensy, HC-05 bluetooth modue, and AC/DC converter for the power.
We also started to work on the bluetooth streaming. The idea is to use the display like a screen. It makes for an interesting challenge since the data need to be compressed enough for bluetooth low speed, and yet still need to be easily uncompressed on the teensy.
An other issue we faced was that propagation speed of the data along the shift registers limits the number of time we can blink the LEDs. After some time tweaking the software, we got it working properly.
And here we go for our glorious first video game test:
excellent, excellent, let me join your team
all I know about spinos comes from LED spinos installed for bike wheel
and more advanced gif version
https://awesomestuff365.com/customizable-led-bike-lights/
and alike clones
I developed ambilight for TV than Ambilux, hoping digital RGB LED strip market to develop one day.
Let me know if digital RGB LED strip is fast enough to get real-time Arduino controlled to get such spino display ?
Forgive the (s)pun but this is brilliant! Love it! I bet even my wife would love it! Don't forget to develop a V2.0 that'd be in 3D... Layered blades, as well as using the weird human eye perception of colors (green is "nearer", red is "further away"...)
thanks for your comments, I used to work in the 3D industry... ；）
Hi,
What AC/DC converter do you use? Do you plan to display existing game or game build for SPINO ?
Christophe.
Bonjour Christophe,
We've just added a log with a couple of pictures to answer your question about AC/DC converter.
Regarding the games, we plan to port some classic games to Spino first. But it would obviously make sense to develop games specially designed for the display. The resolution is quite low so it looks better if the graphics are circular. If you are interested in developing games or apps for Spino, please get in touch with us! spino.display@gmail.com
This is really cool, I'd love to know more about it! How do you transfer power to the spinning board? How do you balance that spinning part so that it doesn't wobble? How are you storing frame buffer data? The polar nature of the board makes for an interesting challenge (in my mind anyway).
Hi Mike, thanks for your comments
How do you transfer power to the spinning board?
// We use electromagnetic coils. We wanted to avoid any form of contact to avoid frictions.
How do you balance that spinning part so that it doesn't wobble?
// Right now just with a counterweight: some extra screws located at the very end of the PCB! :)
We also plan to build a prototype with 2 blades of LEDs, one on each side of the teensy. That would make it more balanced and would enable us to decrease the rotation speed.
Eventually, the device will stand vertically to be conveniently used as a display. So you're right, making it stable is something we're concerned about.
How are you storing frame buffer data?
// As a 32x128 bytes buffer, corresponding to the r and θ of polar
coordinates.
The polar nature of the board makes for an interesting challenge (in my
mind anyway).*
// Yes, at this low resolution, you basically have to design your game in
polar coordinates. If we can increase the resolution or the number of
colors, we will be able to render normal looking game as well, but for
the moment all the games we plan to do will have a spherical design.
Koen van Vliet
caBattista
Hunter
Hi,
do you know the theoretical and practical limits on a diameter of such LED spinner ?