[Kugelfang]

A number of years ago I was interested in porting some of the 3d models I had made into FlightGear. I had originally gotten involved in 3d modeling for the proprietary Virtual Sailor and MicroFlight simulators. So I have a number of ships and planes already modeled. But since every simulator seems have its preferred format, being able to convert from one format to another was a helpful excersise. Interestingly enough, it was my interest in 3d modeling which had led me to create an SVG mapping library for a state agency which I worked for in 2004. I remember thinking that what I really wanted to do was convert my 3d models to card models. Here I am picking up that process again twelve years later using essentially the same tools. What goes around, comes around!

The first step was to find my old conversion script. Luckily, once located, I found that I had been pretty thorough. The Ruby script reads in the entire *.obj file as well as associated *.mtl file which holds definitions for materials applied to the model. All of this is stored in memory and all attributes are accessible from within the code—including the UV coordinates of each and every face in the model. In addition, the model identifies faces in a group and any materials assigned to those groups. Frankly, it only took a couple of hours to write a code module which spits out the UV coordinates as SVG polygons, combined and named by group and assigned the diffuse color of the material of the group as a class style for the SVG polygons. In short, each model group with UV coordinates in the *.obj file is written to an SVG document as an object of polygons with a stroke color matching the material color. For example, in my tank the object 'pilot_house' which is assigned material 'pilot_house' with a diffuse color of green, ends up in the SVG document as a combined group of polygons named 'pilot_house' drawn in green.

But all is not quite rosy. There are some challenges. The first is that of inconsistent coordinate systems. UV coordinates in an *.obj model range from 0.0 to 1.0, up and to the left. So a UV coordinate of 0,0 represents the lower left corner; 0,1 is the lower right corner; 1.0 is the upper left corner; and 1,1 is the upper right corner. Coordinates work differently in SVG. In SVG coordinates extend down and to the left. In addition, SVG uses actual measurements be they inches, pixels, ems or feet. So UV 0,0 would equate to SVG 0,11in (if inches was the defined measurement and you're using a 8x11 sheet of paper). This shift can be compensated for in the layout of the UV coordinates in Wings. See the attached screen shot taken in Wings. Note how the UV coordinates are positioned below the UV area (the area with the checkerboard pattern). This works, but it's a clumsy kludge. But for now….

The second issue is, of course, scale. The tank is modeled in actual size. The model is 24'1” long in Wings3d. But UVs don't care! When UV values are converted directly into SVG, suddenly the model is less than an inch long (if you're using inches in SVG). Woe betide the user who wants to work in pixels in SVG. Then my entire paper model ends up being less than 1 pixel in length. What scale is that, you ask? You'll have to find a real micro-modelor for that answer. You can of course rescale the images in Inkscape. That is, after all, the real benefit to using a vector format rather than a raster format.

So for now I simply multiply my UV coordinates by a factor of 500. I came up with that by trial and error. With the current layout of UV coordinates that gives me something close to an 8.5x11 graphic. Though I would like to be able to feed a scale factor into the script and have it automatically spit out SVG scaled to whatever size I called for. So I could model at 1:1 scale, but print out at 1:72 or 1:33 or whatever. To accomplish that, though, I think I may have to add an object into the model that corresponds to the bounding box of the model, e.g., for my tank it would be 24.1 feet long. Then, assign the object the maximum UV coordinates—so it will always extend from 0 to 1. That should then give me a reference which I could find in the model and scale accordingly. Hmmm… maybe it's too much work and I should just skip it… for now.

Anyhow, running the *.obj file through my script, I opened the resulting *.svg file in Inkscape. I added a layer (named 'exported shapes') and moved all the polygons to that layer. I then rearranged the groups to fit better on a 8.5x11 sheet of paper. I added a second layer (named 'labels') and added the text to identify the groups. A third layer was added (named 'fold lines'). This layer has some white dashed lines which overlay the red lines in the original outlines since I wanted to differentiate between fold lines and cut lines.

This is pretty crude but I'm new to Inkscape. I'm sure I have much to learn. First thing I noticed is that Inkscape *.svg files are not always rendered by other SVG viewers as complete. Whether that's an issue with Inkscape or the other viewers, I'm not quite certain. Consequently, I've uploaded the Inkscape *.pdf file rather than the *.svg file.

Attached are a screen shot showing the A7V UV coordinates as defined in Wings3d and a PDF file showing the final output after the editing in Inkscape.

I would greatly appreciate any feedback or test builds! Photos of how the shape fits together would simply make my day. I'm still without a usable printer for a while. Though I have to admit, I had cataract surgery yesterday and it has not curtailed my activities at all. I thought I'd spend a couple of days without being able to see clearly enough to work on this but that has not been the case at all.


--jeff (now turning down the verbosity mode)