Er, yeah... I got GLSL /fragment shaders confused with vertex shaders. I guess I should read about that at some point, I haven't been able to do anything with shaders yet.
Okay, I'm confused how this sort of system will play with the BOS script - can BOS move around bones instead of parts? Or will it completely supplant the BOS script (except that you have to create a redundant pile of BOS for invisible models or something?)
They're just talking about putting in MD5s and getting them to execute the animations built into MD5 right now, I think.
We might have to build animation instructions entirely in Lua, which means, among other things, that we'll need quite a few new callins, to handle all of the events that BOS currently handles.
With those in place, and some way to pass arguments (run animation sequence X, basically, depending on the context, and a BOS-like logical loop) and working interpolation... well, there ya go- it'd read and act a lot like BOS, only shorter code (for the content-creator end) because it'd just be referring back to pre-built animation. Then they'd just have empty Create() events in COB.
The only problem I have with that is thread control issues. We need a good, solid thread controller for each instance of a given Unit, so that people aren't having to reinvent the wheel on that.
They'd just build their content, set up the various logical events that have animation associated with them and plug it into the thread controller, and voila, it's ready, just like with COB. Stuff like death removing a given Unit from the larger thread needs to be a given, basically, with something like this:
Code: Select all
function gadget:UnitKilled(unitID)
if unitDef[unitID] = blah then
do a cool death animation, which when done returns
UnitIsDeadNow(unitID)
end
end
Where UnitIsDeadNow removes that object from the thread controller, so that it doesn't get clogged up.
Also, there is the issue of making the thread controller wait until it has the pairs unitID,CurrentAnimation for everything that's alive, so that it can sweep through the cycle of interpolation every frame very smoothly, instead of wasting lots and lots of cycles doing internal logic on each one, then returning.
So, basically, we'd run most of this stuff in GameFrame- the current positions of the animations would be arbitrary, and should be ignored by the system- designers should set up the number of frames before something's finished, basically, with interruptions possible due to outside events (i.e., if blah and blah, then we're starting a new animation, interrupt the current one and interpolate).
Lastly... what are the real costs on interpolation, and how would timing be handled dynamically? I mean... if you're in the middle of one animation, and you want to interpolate to another one that's quite extreme... how are we going to get control over the speed at which this occurs? For some things, especially if we're dealing with something large and ponderous... we'll want very slow interpolation... with other stuff, like the death animations of troops in DoW, we'd want really fast interpolation...
<- tears of joy
