Well, I have a bug in the animation system. Before, I thought I actually had the opposite bug, but it was because I had what the "mode" flag in the viewer does confused.
@p
Basically, vex has a bunch of layers for abstracting what an object is. Anyhow, one of the lower levels is something called "gobject", this is a generic object class with methods like render(), update(), what have you. However, this isn't fast enough for rendering lots of objects like a city, so there is a function which basically amounts to compile() that takes that object and compiles it into a simplified data structure which only supports certain things (basically, this means meshes; gobjects can be something a lot more complex, for instance the entire impostoring system that lays down trees on the planets is just a single gobject class)
@p
Anyhow, the compile() function seems to be mishandling some of the animation data; I'm not sure what though, so I have to hunt that bug down. It's not too major, but I need to use optimized models for rendering (and especially, for caching them to disk so they can load quickly as you fly around).
@p
Want to know why it is great to be a garage developer? Here is how you end up with an enemy model in vex (and this is of course release simplified):
@p
1- meta data; this is stuff like, wing models, beaks, textures, colors, material properties, etc; a lot of work but generally pretty loose that feeds into...
@p
2- umake layer; this layer itself has about 3 or 4 levels of abstraction which basically groks the meta-data and spits out...
@p
3- more meta data; this is largely .info files which reference the meta-data in 1, and it feeds into...
@p
4- object generation layer (vex engine) which takes that data in the .info files and produces structures which are capable of producing...
@p
5- generalized object layer these are the gobjects mentioned above, we can actually render these and they look fine but they aren't fast enough so we grok them down to...
@p
6- mesh-material format, this is a simplified data structure taken from the above, it contains basically mesh/material/animation and actually some physics data (oh yes, did we mention there is physics also being generated all along these stages) which we then take and process to produce...
@p
7- optimized display structure, imagine if you can the steps neccesary to render an object, it consists of a bunch of gl calls and other calls to set up material properties and stuff (they aren't all gl calls), so what this does is sequence them in what is somewhat of an optimal structure, anyhow these also are renderable but they STILL arne't good enough because otherwise everytime we want an object we have to do steps 4-7 which doesn't grok very well realtime, so what we do is spit out...
@p
8- multi-cache! we take some of those optimized display structures and write them to disk for loading later by a...
@p
9- generalized gobject! HAHA didn't think we'd end up back here did you? Well it's of course not that the gobject class itself is inefficient, just that it sort of needs to get compiled down. At this layer, it is just serving as a wrapper for the multi cache object.
@p
Well. Just try getting this kind of design past your project lead. This is not some kind of fabrication, it's just what the actual design is. You may wonder, how can it possibly work? But it does work. It's just that, it's not a design that arises when you sit down and figure out what you want. It's what happens as you continually build upon what you've done before, and when what you've done before is (mostly) pretty solid. The design works very, very well, much better than you would think. It just happens to be a bit insane.
@p
So, to elucidate, what happens is that somewhere between 5 and 9, the animation data for certain types of animations is not getting managed properly. It's not actually too major, but I will definitely need to hunt it down.
2004-03-30