The Topographic Apprentice from 3.3 (January/February 2005)

Not the OS variety of control panels, but real ones! If you've ever taken even a brief look at flight or car simulators recently, you've had to notice the amazing control panels and cockpit consoles these programs have. Guess what? They are done using 3D technology! Yes, it's 2D (most of the time), but using 3D has quite a few advantages that regular graphics methods do not. During the process of creating a panel engine prototype for A-OK! Spacecraft Simulation System, now in development, I tried various methods of drawing controls on the screen. The original method used in A-OK! The Wings of Mercury utilized separate canvases. This worked, but only because the drawing involved was simple. There was only one picture for the background and either a drawn black line for a gauge needle or additional graphics for light indicators or switch positions. In A-OK! SSS, the bar has been raised considerably. First, transparency will be mask-based, not the simple white = clear option that is available for images. Second, I wanted to use images for gauge needles instead of simple solid lines. Finally, I needed to support image layers. Most gauges require at least three: a background, a needle image, and a cover plate. Some instruments, like an attitude indicator (the round thing with a little plane and a brown section for land and blue for sky) require four or more images. I dismissed the separate canvas idea right away. Since the panel engine draws its panel items based on information supplied from a definition file, I did not need the convenience of being able to visually layout a panel in the REALbasic IDE. Additionally, I did not like the idea of having to have one of each panel item type in a window because REALbasic cannot create control objects from scratch -- only clone them. I built a prototype that drew directly to a window's background graphics object. That worked very well until I had three or more instruments. At that point, things started to slow down considerably. Even bypassing Quartz by setting UseOldRendering to True didn't help much. Graphics object drawing does not use hardware acceleration at all. All the fancy layering and masking was taking its toll on the cpuCPU. RB3D To The Rescue Way back in issue 1.1 of REALbasic Developer, Joe Strout presented a great overview of three very different techniques of creating sprite animation. One of the ways involved treating each sprite as an Object3D. Besides utilizing hardware acceleration, this method also had the advantage of RB3D's built in scaling and rotation capabilities. The next series of Topographic Apprentice columns will demonstrate a versatile system of defining, drawing, and interacting with a realistic control panel using RB3D. Pictures, stored as Object3Ds, are placed in a specific order, for instance: panel background, gauge background, gauge needle, gauge cover. Each item is only an RB3DSpace unit apart. The camera is set to a small field of view and is placed pretty far away from the control panel Object3Ds. This practically eliminates any perspective. The panel camera can be moved out to view an entire panel (with little detail) or moved in to see a single gauge (getting a very accurate reading). By moving the camera in the x and y axis, the user can pan along a control panel while the detail is relatively high. We will build three panel entities: Indicators, Analog Gauges, and Switches. Let's look at them in detail. Indicators These are status displays that show finite states. It could be as simple as a power-on lamp being on or off, or a system event status indicator that can either be off, green, red, or red and green (simulating a lamp test, for instance). While bulbs and LEDs are commonplace, there are other types like aircraft barber pole indicators. The panel display system will load an image for every state the indicator can have as a shape in the Object3D. If the indicator needs one, a label is drawn as another Object3D, just one unit in front of the indicator state Object3D. Changing the indicator's state is as simple as changing the Object3D.Shape property. Analog Gauges Specifically, we will model round gauges where the needles travel through a 100? degree arc, like a DC voltmeter, or 360? degrees, like an aircraft altimeter. In addition, analog gauges will support the display of multiple values, where each value is assigned its own needle on the gauge. In a clock, for example, there are three types of needles: seconds, minutes, and hours. Since each needle is an Object3D, the value to be displayed has to be scaled and converted into an angular value which rotates the needle to the proper position. Switches Switches are similar to indicators in that each switch position is represented by a separate image, stored as a Shape in an Object3D. There are two very important differences. One, a switch changes its image and waits for a new state value through operator intervention. This means we will use mouse clicks on the switch's Object3D to change the value and therefore change the state image. Secondly, a switch usually has to do something, so we have to provide a way of doing that. We could say that the main program must poll the switch's value and react to any changes, but let's say you had something as complicated as the Mercury spacecraft simulated in A-OK! The Wings of Mercury. With over 60 switches, polling would be a nightmare. How we will handle this is to provide a way to store an RBScript for each state or position of the switch. In most cases, this will simply be a call to a method or changing the value of a known property. The RBScript will be pre-compiled when we build the switch so that there is no delay when a switch is first activated.

Clearance Sale!

Control Panels

Combine Both Libraries

Print:
PDF: