Sorry for the delay in response, real life stuff took over there for a few days. On the upshot, now it's Dr. rachil0, so that's something

Here's an outline of how the monsters are built up from a union of nonintersecting, convex polyhedra. The screenshot from post #59 (07-18-2008, 03:34 AM) is a good demonstration - each green square indicates one polyhedron. Dissecting further, polyhedra are just (unordered) collections of polygons, and polygons are ordered sequences of vertices. Vertices wind counterclockwise to define the normal of the polygon, polygons are 1-sided.

I don't mind getting polygon soup. As long as it's pretty clear, by inspection, how the polygons should be collected together to make polyhedra. I think models should be <100 polygons total. That's why I think robots will work so effectively - you expect them to look like they're built out of blocks and pin joints.

Geometrically, the trickiest part is that you can't just throw a hodgepodge of polyhedra together and expect them to z-sort correctly. They have to be partitioned into a bsp, preferably without splitting any polygons. The bsp is constructed by the map editor program, by testing each polygon in the model as a partitioning plane. When a plane is discovered that doesn't split any polygons*, the model is broken into two (hopefully equal) halves, and the partitioning recurses on the halves/submodels. The tail case of the recursion is a single convex polyhedron, which doesn't need to be split any further because it cannot self-occlude. [*If no such plane is found, the bsp process gives up. At that point it's up to the user to split the model by hand along some cutting plane, and try it again. Try to avoid this case, it will cause a dramatic increase in the size of the input to the renderer]

Here's how this partitioning works on a 2D roboman:



This bsp business limits your geometric flexibility. As a monster designer, you should have a good idea of how this bsp process will carve up your model as you're working. Try to make your model such that exactly one partition plane will be found for every subtree, just to avoid unpleasant surprises at runtime (extremely unbalanced trees).

As far as texturing goes, that's a whole other mess. I think that UV pairs are typically defined per-vertex in a modeling program, but this engine stores a complete UV coordinate system on a per-polygon basis. I think it's best that you not bother with trying to import the UV coordinates into the engine, just supply the geometry and the skin (like your color-cure examples) and I can fix it up on my end.

I'd really love to get a skin for roboman - maybe covered with a flames/teeth like a ww2 fighter plane, or a steampunk design with big gearwheels on the joints and brass/chrome fittings. Or camoflage I have no painting/texturing ability whatsoever - that's the #1 aspect that I would like to outsource to a more talented artist. I feel pretty comfortable with making geometry.

There's a link to roboman's geometry in this thread, it's just an xml file:
http://board.flashkit.com/board/showthread.php?t=773035