Okay, I've done a little planning and I am really quite sure that I need to be able to export matrix animations from the matrix exporter...
In blender, I have an exporter that writes the transformation matrices for all the objects in the scene. These, actually, are used to form special composing models which say more or less, "what goes where" (e.g., they define a ship layout, by showing where wings will be with respect to the body; the wings and body themselves are chosen from a separate pool, and actually may have their own layout schemes)
This probably doesn't make too much sense but anyhow the real reason I write all this crap is so I can read it later. Anyhow I think I need to export matrix animations, but even that is only half the problem, because I also need to be able to import them and play them inside the renderer (will basically require modifying the matobj class to support matrix animations, i think)
This is also a bit of a departure from the way that ships were composed, i guess. Well maybe not. Okay imagine this situation. You have a big fat waddling monster that goes along the ground, sort of like some kind of uh, rhinocerous or something. Hmn. Well anyhow, the body sways a bit left to right as it walks (this is modelled in blender using deformation lattices, probably the only tool i will use for animation besides the matrix animations that I was talking about above). So i get the nice mesh animation (already supported). Then I have the legs attached, each 4 leg points (well I may be end up cheating by xz-symmetry, i don't know, but in that case 2 leg points) which have to wag around as it walks; these will be stubs (little arrow meshes). Then I want to export for the animation not only the mesh animation for the rhino, but also the matrix animations for the stubs. Then, each stub will get a leg object welded to it, with the weld matrix being the matrix animation for the stub, if that makes sense. Or maybe clearer, we weld a leg onto the body at each stub, and the matobj will play the matrix animation back to get the weld points.
Some basic design issues:
1- we should definitely write out the matrix animations as binary data, parsing these as .info will be too time consuming (once upon a time, i even exported meshes as text files, hahahhaahhaha... choke)
2- the matobj class only needs to know how to play uniformly timed, forward-looped-from-start-to-end-frame, matrix animations. this gets rid of a lot of unneccesary details and makes it hopefully fast/simple to implement in the engine.
3- the matrix animation stuff should be patched in more or less where the current static matrix stuff is; i.e., either have a type-path between "static matrix" and "matrix animation", or else just have only matrix animation with the default case being 1 frame played at 1fps.
4- wrt the actual entity modelling tree (i.e., the model generation tree), i guess it means actually a bit more work (or less coverage per work unit, if you prefer) because i haven't separated the layout from the mesh. BUT. I could add an aditional categorization pathway, so for instance, "body" can be split into several body types; one for waddling bodies, one for jumping, what have you, and then each body type will have matrix animations for it.
Garr, i dunnno. This whole thing is a touch bit messier and less orthogonal than the ship generation, which itself worked very nice and easy and gave me *excellent* possibility space coverage per work unit. It's just nice to say, "body here, legs here, head here!" layout and then mix and match parts and layouts like that. It just seems like it will look below the acceptable threshold of badness (which is already pretty bad) for the game.
What about skeletal modelling in-engine? What about it. It isn't hard but I don't have the time, and it doesn't really solve any of the problems that aren't solved with matrix animation.
See, this is probably not even the last post before I actually start implementation of the monster models, and once I do it I will probably have to change.
In the back of my mind, I am thinking, I should perhaps not overanticipate what kind of resulting visual i will get. The ships looked actually better than I thought they would, with more variety, etc. etc. and had really amazingly good coverage (I have only a few dozen units TOTAL and the ships can look very, very difference).
Moreover, mesh animation is working out nicely for me. Touching the engine isn't exactly hard, even though matobj buffers are as low level as it gets (well without touching terrain engine).
If I animate the stubs, well, okay it's nice but then it's work to animate the stubs as well. This is exactly the kind of work that I need to go as fast and as loose as possible.
Okay, I think that I have to either imbed the stubs, animated, into the part meshes, or else do exactly as I did with the ship model generation and don't even use animated stubs. Animated stub-layouts is not really going to work very well, I don't think. Well, maybe with the categorization it would be okay!
ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH! Do you see how the process of design that I have to go through is fundamentally different than you would expect? Okay!