I noticed how there were no paper models of the Frontier Elite ships. I'm a big fan of the Amiga version, and most of the paper models I've seen are made from the old Elite games and maybe not to scale. I'm planning to do most of the ships, but it has been a bit tricky to get the folding process right, and I don't want to release... trouble.
Update: jul 19, 2006
No update, I kind of got deterred by the scale problem. The Viper on the 'Work in Progress' sheet below has the wrong size (It should be closer to the size of the Viper on the Viper sheets), and I still need to do all the add-ons (landing gear rescaling etc.).
Update: may 2, 2006
Quick recap. There's no problem figuring out the sizes of the ships in the game.
The problem is that the sizes of the game is misrepresentave of the cargo capacity of the ships.
Since the cargo is generic and all ships can be made into trading ships
there's no reason for a Gecko to be able to fit a cargo unit in 2 cubic meters
whilst the Tiger Trader needs 14.6 cubic meters per cargo unit (see chart at the bottom).
What I'm doing atm. is trying to scale the ships after their cargo capacity. I know there's a 3D program plug-in that can measure the volume of 3D models, but I don't have the ships as models, or a 3D program, or that plugin. My solution is to use clay to approximate the volumes. Not very accurate but better than wild guesses, and certainly more reasonable than Braben's scales.
Unfortunately this mean I'll have to go 'un-canon', not only with the hulls, but also with the add-ons (landing gears, missiles, etc). I think in the end it will look better with the add-on scales shared consistantly between the ships.
Progress
Viper Defence Craft - 1:220 - game scale
Reference: Many ship screenshots
You'll need Inkscape to work with the SVG file. Firefox 1.5 should be able to display the SVG file, but it will pixelate it and make it fuzzy if you're trying to print it. These sheets are A4 by the way, and the scale is relative to that. I won't upload any highres bitmaps atm. The quality and size of the SVG files is superior anyways. I suppose I could use 'cloning' a bit to avoid redundant data and get filesize down further.
Feel free to give me feedback on this project, if you can solve the little rebus thingy.
(hint: it's diglett - my favorite pokémon!).
I wrote my own program because 3D programs didn't do what I want, and they have unintuitive and constipated GUIs. Writing my own program was the easiest.
So, here's what my program does. It loads the ship points (vertices, but I'll call them points) from the firstenc.dat file. Actually it doesn't. It uses the vertice data from a data extractor program Theun over at Jongware wrote (he also provided the font). I reformat it so BlitzMax can read it as data a'la Basic style.
The program reads in this data as x-y-z coordinates and flips them to make the ship symetrical and stuff. There's quite a bit of data for a ship, but only the first part has the ship geometry so my program can be set to ignore the rest of it.
I don't actually know any 3D programming, but I've toyed around a bit with Sodaplay and I had this idea of writing an unwrapper with just sticks that try to be a certain length. I get the length by running a 3D pythagora between the 3D points. It works. This spared me the agony of doing 'trig' stuff.
The program also scales the ships properly and 'saves' the data as SVG that can be read by a free vector illustrator program called Inkscape. Before saving it takes a look at the 'sticks' and tries to figure out where to put triangles. I also made a little thing that allow me to make male and female tabs.
Huge thanks to Jongware Theun for the work he had done reverse engineering the Frontier data. I was really lucky to be able to get the data (without having to hex around in files) and the neat Bezier font. Stumbling upon InkScape helped a lot too. SVG was perfect for this kind of thing since it's just XML text.
What's left then is coloring, rotating and moving stuff into suitable positions. Adding the ship gear like antennas, landing wheels, reg-id etc. There are a couple of different color schemes for each ship, and I've tried to mimic what color palettes Frontier uses, there's often a saturated and dull version of each color.
I'm using screenshots or my program to eyeball the placements of things on the hull. I could actually use the data from the program here but so far I have no function for aligning those points along with the hull. If I add them into the geometry I might distort the hull shape since the points might not be placed exactly along the hull surface (I'd get a bump which would flatten and thus produce the distortion). In any case eyeballing is sufficiently precise here.
After having assembled a couple of ships it seemed to me like Braben grossly miscalculated the scales of the ships. Maybe it was because he only has a signed char/byte for the geometry, and then left bit shifted that value to scale the ships. This might have made it hard to control the scale of the ships.
I'm considering doing my own scales based on tonnage. I can just assume that since tonnage (weight) is already defined, I have no responsibility to keep weight down. I can see how surface area is important in a combat situation, so the ships are probably pretty dense fully laden, maybe 5cu.m per ton (200kg/cu.m). I made a little cute table below to illustrate what's going on. My values here are 'Cube ratio' and 'Ton length'. I get the cube value by making a clay cube, then making a ruler based on the length of a cube side. Then I make a ship of the clay and measure it against the ruler. This gives me a 'density' of sorts. Although the results are inprecise, it's still obvious that the ship scales are bad.
| Ship | Cube ratio | Ton | Volume (cu.m) | Volume/ton | Game Length (m) | Ton Length (m) | Length Difference |
| EscapeCapsule | 2.30 | 5.00 | 0.97 | 0.19 | 2.27 | 6.73 | 0.34 |
| Shuttle | 2.00 | 8.00 | 9.16 | 1.15 | 4.19 | 6.84 | 0.61 |
| Eagle | 2.70 | 27.00 | 19.40 | 0.72 | 7.25 | 13.85 | 0.52 |
| Sidewinder | 1.40 | 33.00 | 71.24 | 2.16 | 5.80 | 7.68 | 0.76 |
| Gecko | 1.90 | 45.00 | 88.97 | 1.98 | 8.48 | 11.56 | 0.73 |
| Adder | 2.40 | 55.00 | 182.61 | 3.32 | 13.62 | 15.61 | 0.87 |
| Viper | 2.30 | 65.00 | 468.01 | 7.20 | 17.86 | 15.81 | 1.13 |
| Moray | 2.00 | 87.00 | 364.43 | 4.19 | 14.29 | 15.15 | 0.94 |
| Cobra1 | 1.65 | 75.00 | 183.43 | 2.45 | 9.37 | 11.90 | 0.79 |
| Cobra3 | 1.40 | 100.00 | 345.25 | 3.45 | 9.82 | 11.11 | 0.88 |
| Constrictor | 2.45 | 120.00 | 3335.79 | 27.80 | 36.61 | 20.66 | 1.77 |
| Asp | 2.00 | 150.00 | 1082.53 | 7.22 | 20.54 | 18.17 | 1.13 |
| Transporter | 2.10 | 200.00 | 1512.79 | 7.56 | 24.11 | 21.00 | 1.15 |
| Tiger | 1.60 | 400.00 | 5431.47 | 13.58 | 28.12 | 20.16 | 1.40 |
| Python | 2.90 | 500.00 | 7297.49 | 14.59 | 56.25 | 39.36 | 1.43 |
Although one might argue that nothing is known about the densities of the ships, I think sizes based on tonnage seem a lot more reasonable since they reflect actual performance.
Right now I've been playing Frontier on winUAE with the JIT CPU boost and I get a really nice and smooth framerate, and the whole game behaves more precise. I get a steady 50fps everywhere in the game, no 1-2fps stuttering in police crowds or cities. Since the external camera movement seem to be framerate based it's possible to get much better angles with JIT on. My scale is based on the '////50 METERS////' sign over the docking bay. It's 114 688 units wide with left bit shift applied. I use this value to make a scale constant which I then use with the ship vertices to come up with some sort of scale. It seems to work, I've measured the dimensions of a few ships as they fly out of the docking bay, and also with the external camera ship switch trick. My program seems to be doing the scaling correct.