Previously: RealiMation the Datapath Years, Part 2.
The latter part of this period saw us working on a couple of major projects and the start of what would ultimately be called mantra4D.
Caddet
We worked with Jasmin (a local defence and civil engineering contractor) on a bid for a Close Air Defence trainer for the Army. It was to be based on a projected main view, a magnified view through binoculars and a second magnified view though the eyepiece of the weapon system so that a squad could all train together. There was an extra complication in that the training system had to be portable. Part of the bid involved setting up a demonstration of a mock up of the system with a projected image and a pair of electronic “binoculars” with a tracker taped to them. We did resolution calculations to prove that we could project a high enough resolution image at the required size using the projectors available at that time.
At one point we were considering a twin channel system for the basic portable system as well as for the “top of the line” permanent simulator we would have also had to supply, but we thought that the logistics of setting it up would have proved too onerous. The twin projectors would have to have been correctly and accurately aligned to produce a high quality image. As the join between the images would have been in the centre of the field of view, any misalignment would have been highly visible, even with edge blending. We did some calculations and it turned out we could (just) get enough detail from a single projector, so we dropped this idea. We (or at least our partners in Germany) would come back to this same problem when they developed a portable stereo system. The solution they came up with was to build a portable rack to mount the projectors in – which worked quite well.
The quality of projectors was constantly improving during this period, both in their resolution and brightness, which was both useful and a potential problem for us. One of the key requirements was that the system would work at normal ambient light levels as we would have no control of the rooms it would be set up in, so any increase in image brightness would help. However, we did have to specify the hardware that we would be using, which could have ended up with us supplying an underpowered system – though I think we did try to introduce enough leeway so we could substitute better hardware later.
I also had a trip down to Salisbury to see the actual weapon – a scary piece of hardware, see some of the existing simulators they had, and ask some questions to further our bid. We didn’t get to see the weapon fired – mainly because each one cost several million pounds! We didn’t win the contract – which in hindsight was rather fortunate – apparently for political rather than technical reasons.
Dome Trainer upgrade.
This was a system built using a specialist Datapath graphics card to generate four images. These were then projected onto the inside of a large dome (hence the name) into which a real self-propelled anti-aircraft gun would be driven. The simulation would then proceed. The position of the targets was controlled by hardware; all the software had to do was display the aircraft in the correct orientation and replace it with an explosion if it was “hit”. There were issues with the level of realism in the images, particularly around reflections, but I think they were resolved to everyone’s satisfaction.
RealiMation: The Next Generation
During this period we started talking and thinking about what would eventually become mantra4D. The product went through many names – RealiMation Theatre, RealiMation Enterprise Navigator to name but two – over the next few years, which was always a cause of annoyance to us as it caused, admittedly minor, problems renaming executables etc. The initial idea was to have a system whereby the user picked modules from a list and dropped them into a workspace. These would then be linked together graphically to form the application. The ultimate goal was to have a system where there would be no or minimal coding so that even the non-programmer could develop 3D applications.
An intermediate goal was to widen our potential customer base for the 3D toolkit. If we could develop the tools to such an extent that the average forms programmer (say) could use them then we would have had a vastly increased market to sell into. We had been selling the RealiMation toolkit for quite a few years but the level of mathematical and programming skills needed were really quite high. This was brought home to me quite recently when I was trying to explain how to zoom into an arbitrary point on a 2D image. What I thought was quite straightforward was initially difficult for the other programmer to understand. He’d come from a database & web background so didn’t have the mathematical skills we used as he didn’t need them. However, he soon grasped the concepts and produced the necessary code. These hurdles naturally limited the market for the toolkit.
This ultimate idea never came to fruition as we discovered that each application required the writing of a significant amount of code to “glue” the modules together. However, in hindsight, perhaps this was a failing too. The system that became Enterprise/mantra4D ended up having quite a lot of application functionality in the “glue” layer – whereas this layer should really have only contained user interface code.
Another force driving this change was the acknowledgement that a lot of projects we did were basically the same application with a relatively small amount of custom code unique to solving a specific problem. In other cases only some parts of the standard application were needed. We thought that if we could create a set of modules from the common code we would make our lives a lot easier. When a new project came along we would be able to assemble the required common components and then just write one or two new modules and the specific code or “glue” for that application. Any new modules would then become part of the standard toolkit ready to be reused in the future.
Next time: RealiMation the Datapath Years, Part 4.
© 2009 – 2010, Chris. All rights reserved. If you republish this post can you please link back to the original post.