Article Preview

FEATURE

A-OK! The Wings of Mercury

Programming the Right Stuff, Part Two

Issue: 2.5 (May/June 2004)
Author: Joe Nastasi
Author Bio: Joe Nastasi is the president of Pyramid Design, a software development firm and the developers of A-OK! The Wings of Mercury and FTP Suite.
Article Description: No description available.
Article Length (in bytes): 29,215
Starting Page Number: 12
Article Number: 2509
Related Link(s): None

Excerpt of article text...

More 3D Woes

Boy, if I could turn back the hands of time! One of the big issues I faced was the lack of collision detection. Even something as simple as knowing when the spacecraft hit the water during splashdown became a mini-nightmare. While I was certainly keeping track of the altitude, all my calculations were based on the center point of the current spacecraft model. So when I had to test to see if the water (or land) model had reached the spacecraft (remember, I am moving the world around the spacecraft to prevent math errors), I always had to factor in an offset depending on what configuration the spacecraft was in (possibly the entire launch stack is crashing into the ocean) and what orientation it was in. All this to determine when we have hit the ocean.

As per the theme of this product's development, I labored over the collision issue, essentially solved the problem (though not very well), and a couple of months later an RB3D API update produced the Bounds3D class which solved all these problems!

Bounds3D solved another problem a bit too late as well. In the early days of spaceflight nothing was known about a pilot's ability to control spacecraft attitude. The Mercury program had quite a few experiments designed to evaluate the ability to track other object's in space. These included tracking the spent booster as it drifted away, tracking balloons, and a flashing beacon. A-OK! WoM simulated the booster and beacon tracking experiments.

While not really a game, A-OK! WoM does keep track of the astronaut's performance and issues a complete multi-page HTML report at the end of a simulation. Part of the evaluation is how well the booster and beacon package were tracked. I had to know if these objects were in the spacecraft window, which was an RB3DSpace control. Since there was no Bounds3D, which provides a very simple Boolean answer, I had to use the FindObject method. The problem was that it can only test one point at a time. I created a Thread that checked every Nth point for the Object3D being tracked. This technique worked but was complicated, time-consuming, and prone to error. When the Object3D was very far away it was possible to miss it in the point scan, which corrupted the ability to properly score the experiment. In order to overcome this (without decreasing the space between the point scans and slowing up the Thread), I created a large, invisible sphere and included it in any model that had to be detected within the RB3DSpace. Bounds3D came too late to help eliminate the work and needless complexity.

At this point, one could rightfully ask why I did not use direct Quesa calls to implement some of the deficiencies in the RB3D API. There were two main reasons. First, the last thing I needed to do was to spend time learning Quesa and translating the calls into REALbasic Declares. I just did not have the time and, as it turns out, in most cases it would have been wasted energy because almost all of the missing features were added to the API eventually. Second, I had a vested interest in improving the RB3D API. Since it was really a minor feature in the grand scheme of what REALbasic was about, I knew it was a matter of applying reasonable pressure to REAL Software's management to improve the API. One of the best ways of doing this was to deliver a product that used the API exclusively.

...End of Excerpt. Please purchase the magazine to read the full article.