British Telecom
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.
3D touchscreen interface – new movie
Nice idea.
It’s good to know that there are people on this world who deal with substantial problems and offer solutions to them as well. Thumbs up as far as I’m concerned, because who knows us will understand that we REALLY would have use for such a thing.
Though I must admit that I’m going to wait for the jeweled platinum version.
cebit again - CeBIT08 (Groundhog Day)
“I Got You Babe”
We have returned to Hannover. And what should I say: the weather is crap. It’s cold and the word monotonous is at its climax here. But somehow I like Hannover. God just had to create this city. Its probably the counterpart for all the beautifull places he created as well, to even out the cosmic balance.
We are preparing 2 Ventuz projects right now. First we’re going to top last years appearence of MS at the CeBit. (to remember: Microsoft Cebit 2006) And second we do a quite nice story for British Telecom. (7 workstations and 21 screens and everything is navigated via touchscreen-functions)
Whoever want’s to meet us at the CeBit, we’re probably the one’s with the dark circles around the eyes.
PS:This year’s special guest in our team is (again) Gizmo from “Farbrausch” (Just have a look at it). These guys didn’t invent the expression “realtime art”, but in my opion the made a new definition. Always an inspiration to us.
…and concerning the weather - each city get’s the weather it deserves.
By the way… (part 3)
the new (more secure) secureness - the new Ventuz dongles.
Recently the new Ventuz dongles have arrived. But since the old dongles were content with breaking down while taking them into the hand or putting them on the ground softly (yes and ok, sometimes by falling on the ground), the new Ventuz dongles come with an amazing new feature. The allready break down if you look at them, and respectively if you don’t look at them often enough. Or they just don’t like my face.
Anyway they just break down for no reason. Sometimes only for a few seconds and sometimes forever. Nevertheless the old one’s had to be “touched” in a way for this to happen, the new one’s obviously not. Even installing them inside the pc does not protect them anymore from malfunctioning.
Basically I wouldn’t have a big problem with that, if there wasn’t another new development for safety (probably since version 4.4). Until now it was possible to remove the dongle after a presentation had been started and the presentation was still running perfectly. (This was kind of a safety function, if the dongle should break down during a running show/presentation) So now if you remove the dongle after the presentation was started it will stand still and it can also not be reactivated by inserting the dongle again. You have to wait 15 minutes before you can remove it without any danger. (The comprehendible idea behind this was the fact that so far it was possible to start 30 presentations with only one presenter dongle, which was not what the software producers had in mind. - That’s why this is not so easy any more. To start 30 presentations you would now need 8 hours)
As long as the dongles would function correctly, I wouldn’t have a problem with that - but they don’t. And it’s only a matter of time for such a dongle to malfunction during a running show/presentation.
So before going about any new features this problem should be solved. For the future you better turn away your face while inserting the dongle.
Ventuz Framerate - the second secret.
Here is the official summary on the exact meanings of the Ventuz statistics.
F = Framerate
G = Generation - Time of the value generators. These are movers, interpolating-elements, scroll-text and all the nodes generating new values for each frame.
B = Bindings - Connections and the validations resulting from value changes. This also includes generating resources, if necessary.
A = Stands for Abs-tree-validation. This is kind of a insider. The Abs-tree is the absolute hirachy-tree. That means not the one you see in Ventuz - but the one Ventuz really calculates. Including the setting of the matrixes in the axis and the other DirectX-states (materials,textures,…). For example: lots of spreaders will make this value rise.
V = Video - and live-video decoding (and their transfers).
R = Rendering - the time Ventuz needs for its rendering process.
Thanks to Karol.

