Three Dollar Quill

Okay, let's try to break this down, now that I have somewhat more time, and I've thought about it some.

It makes sense to me to divide things into a "scene" made of one or more "figures" (zero is technically possible, but boring), and a "camera", where for now the relevant variables are the focal length and the camera separation (and the "back face display mode"). The camera processes the scene into a pair of two-dimensional images, subject to the constraint that figures lying entirely within the image plane should render identically to both cameras. (The way I conceptualize this constraint is a holdover from a Minecraft mod that I never released, but I think it makes sense regardless.)

For the double-camera to render a cuboid, the cuboid needs to break itself down into quads; each quad can then break itself down into segments depending on its relative location to the camera, and to the "back face display mode". The segments can then be projected according to the camera's properties, and all of the projected segments for each "eye" can be collected together. At this point, all that remains is negating the y coordinates and doing other SVG niceties. Since my plan at that point is to open in Inkscape and export as PNG (probably this can be automated), I feel comfortable leaving the question of "where should the viewport be in the abstract image plane" to the SVG generation code).

One thing that I'm concluding is that I'd also rather work in centimeters, and convert to pixels as part of the SVG writing step. One thing that I'm not sure of is, projecting a quad requires the camera location for the operation of deriving segments, and of projecting to the image plane... And currently, I am/will be accomplishing this by moving everything but the camera around, leaving it at the origin. This makes dealing with the location of the camera a two-step process: before everything, the scene must be shifted, and after projection, the image must be shifted back. Would I rather have the facing and projection calculations deal with a camera not at the origin? I'm not sure yet. Probably the way to figure out what I want to do here is just to actually try using the code I currently have, and see what feels wrong.

What's missing before I can try that is anything around SVG writing. I need to add that to the two-dimensional segment class, and then I can put together a basic wrapper to use all of the other relevant functionality.

For now, once again, I want to get to bed.

Good night.