A brief overview on how we overcome some of the more interesting
challenges on the MoMu
Featuring some insights on the look and feel,hardware, multiscreen
rendering & video playback.
Look and feel
It was pretty clear that it wasn't possible to capture the look and
feel in a series of photoshop/illustrator files. Therefore we
worked with a irritative design process. The designer would provide
us design elements which were integrated into a working prototype.
The client provided regular feedback on the look and feel of the
prototype. Working with irritative process demands a great amount
of trust from the client side. Clients are used to see the complete
design before the development starts. It was nice to work with a
client like MoMu who gave us this trust.
All collision, movement and repulsion is done with box2D.
As seen below every item has a velocity (yellow lines) and a
different gravity point (red dots). The attraction or gravity is
set by a perlin noise flow.
One of the first challenges was the touch hardware. At this scale
optical solutions are very common because they scale well.
But since the wall is placed outside it wasn't an option for us.
From previous setups we knew that dust and sunlight would have a
bad impact on the optical sensors specially in the long run. So
capacitive touch was the best option left. We used 4 capacitive
foils which where electrical isolated to reduce the interference
between them. Each foil is connected to the workstation where we
merge all the data into a global coördinate system.
We have nice experiences with multi-screen projects running of one
Eyefinity card. Unfortunately there are no cards available with 8
For this setup we used two AMD FIREPRO W7000 cards and a S400
module to keep the refresh rate in sync on all the screens.
Current setup runs day and night so we made sure all components
where workstation quality. So far running non-stop for 6 months and
On top of our priority list was the 8xHD rendering at 60fps.
- network setup with OSC which was lagging with fast
- glShareLists didn't work out
Finally we discovered that we could simply use two fullscreen
Cinder windows, one window per videocard. Previously the framerate
dropped dramatically when a window was placed on two screens which
were connected to different GPU's. So we grouped the left side (2x2
physical screens) and connected them to them same graphic card and
grouped them as one desktop in the ATI configurator and did the
same for the other side.
Little side effect, we needed to upload our textures per
Other improvements we did to maximise performance:
- prerender all text and graphics with Phantom.js on the backend
- used DXT for video playback
- used threading for all I/O operations
Image prerendering and DXT video took some disk space and resulted
in a very large number of files. But it gave us a really big
performance boost compared to the relative cheap diskspace. We are
confident that we could easily upscale this way of working to even
more screens without a big performance hit. Only disadvantage or
prerending would be that we have to process the whole cms again in
multiple languages if we change something in the text layout.
Currently this takes 30 minutes for 10.000 images.
Text-render from the wysiwig editor to a png image.
We managed to get a almost perfect transition from the wysiwyg
editor to the image output.
On the left the CMS and on the right the rendered image for the
The path from text to the screen.
Video render is a common problem in a lot of OpenGL frameworks like
Cinder & openFramework setups. We tried many solutions but a
lot of them where to slow or unstable with multiple instances
We consulted our genius friend Diederick Huijbers
worked on video encoding and decoding for a while. He wrote a
platform independent DXT encoder and decoder. Which we converted to
The benefits of using DXT.
- the codebase is rather small and readable compared to other
- our implementation is fully open so no crashes in closed
- we could do all heavy lifting in a thread and then upload the
pixels per GPU
The disadvantages of using DXT.
- conversion takes a while
- takes really a lot of disk space