|
yeah, it could be done all in code for sure. i mean, blender does tht kind of thing when you request a torus. which it seems is called "add_mesh_torus.py" in the scripts directory. i'd guess it's allot like that but figuring out where to not generate vertexes on the inner doughnut*.
most i've done with building meshes in code is getting a heightmap mesh from a gray-scale image. and once me and a friend built a non-smooth sub-divide routine that worked on a quad. both of these were pretty grisly to work on, but ultimately rewarding.
doing the texture coordinates sounds more complicated than doing the geometry, but it shouldn't be that bad.
i was trying to think of some ways to do a rim system where you'd get to select your visual style and then select how many spokes you wanted and then rim diameter. and while it's all do-able the only way i could think to do it *right* would want the mesh exporter recognizing vertex groups so certain patches around the hub (like the lug-nuts) wouldn't be scaled when you went from 13" to 18". also welding together the hub vertexes of spokes doesn't sound fun, and i don't think it could be done in such a way that scaling the spoke count wouldn't create bulges or kinks where the vertexes were welded.
yeah, change-able wheels would be sweet. if you do the tire idea i can try to re-make all the other car's wheels to just have the non-tire part. of course if the original .blend files are around that would be nicest.
and speaking of tedium! i did all the driver re-positioning a while back. but then began the discussion of the coordinate system inconsistencies. and then came the re-factoring of top level code. then i made the dudes head bigger to be more realistic, meaning i'll have to do re-check the positioning for each vehicle.
and i'm wondering: should wait to re-check driver positioning until the coordinate systems are all consistent (which i'm guessing will happen in the re-factor branch)?
|
