British Telecom
Warning, this text contains inside information. People who are not familiar with Ventuz should not read it. It might damage their health.
Well, what can I say? The CeBIT presentation for British Telecom started out as very smooth and well planed touch screen project. Beside the ordinary madness of last minute changes and the usual problems, which aren’t real problems because you expect them to happen, a really bad thing happened.
A few words to the Setup:
The technical setup consisted of 21 screens and 7 PCs. Each PC delivered content to 3 40 inch Panasonic plasma screens in an overall resolution of 3840 by 1024 pixel. The signal was distributed by the all mighty Matrox TripleHead2Go (analog Version). To add the finishing touch, the presentations were interactively controlled by Panasonic touch screen rims. All of the PCs stood in a tiny spot that was called “Control Room”. In it we also had to put two additional Ventuz-PCs. Since this “room” was too small to fit monitors in it, to actually see what the hell we were doing, we set up a VNC network and controlled them via Ethernet.
The Problem:
The Scene was simply too big. No matter what we did, the scene just wouldn’t load. Due to the setup it was not possible to run from more than one PC. Left alone the fact that they would not have fitted into the control room. Ventuz offers a solution to this sort of problem. You are able to load Scenes into the presentation by using the Scene Reference node. — A fairly boring looking, but yet extremely powerful node.
If you have an extremely interactive scene with hundreds of possibilities though, Ventuz allows you to control the exact number of zero within the master scene. Now let me make this perfectly clear. There is no standard solution where the scene you load into the master scene, can communicate with each other, except for “Hello, I’m here. “
The Solution (and even more problems):
In other projects we have found a workaround to this issue with the OSC node. It is possible to send information from the slave scene to the master scene and vice versa on the same PC, via OSC. Because of our space issue we already had a perfectly working network and this seemed like an easy way let the scenes communicate with each other.
The network itself became a challenge when we realized what should have been obvious from the beginning. One OSC-Node sends to all nodes in a network with the same port, address and IP. Now this can be a nice thing. But of course we wanted the presentations to operate independently, except for one presentation which consisted of 3 PCs showing different parts of the same presentations. This meant to make the presentation find out on what PC it runs. It also had to know if it is a single presentation, or just a part of one, and if so, which part. Besides all these facts we had to be able to run it in some sort of presentation mode, hence at least eight dongle where needed to run the show. One thing was clear: The presenter cannot load scene references. J The only way to even run the whole thing was the Director. Not only that we have never actually used it for a real show before, it also requires the whole project on each machine, and it can only start a scene called default.vzr from the scene root of the Ventuz-Project. This again means you have 7 PC showing different content but having the exact same project structure with all resources and master scenes that have the exact same names. Most of the content arrived very late in the process. And, 4 days before the show was going to start, the last major piece of content arrived, and we discovered that two and half a gigabyte of textures, objects and movies were simply too much, it was clear that we were heading towards a very painful time in our lives. But we had no time to cry, because there still was one little thing left. Due to the late delivery of the content; the client had not seen anything, yet. We had to expect massive changes to the content.
How lucky we were when, after a little testing with the Director, we found out what the plan was. We simply had to build a multi-pc interactive network presentation, which can dynamically load and unload content according to its position and purpose in the installation, and still be able to make massive last minute changes. For the control of the scene we just had to develop and design an interactive menu. It should provide all necessary options plus some additional ones that were not quiet asked for then, should be intuitively to use and not be in the way of the displayed content.
Conclusion and Result
We have made it. All of the changes were implemented.
After some recovery time I will post more.
Here are some pix.
