Spring RTS Engine

Kloot wrote:Programmable vertex shader support has been around since the
GeForce 3 days (you are partially right about it coinciding with the
introduction of DX8).

AFAIK GF3 introduced combiners and GF4 introduced vertex shaders.
But nvidia (in contrast to ati) updated their drivers even for older cards, so even the geforce2 series supports (software?) vertex shaders.

But this support is limited to version1.0 vertex shaders: no fragment shader, no glsl support.

I wised NV would still show such an effort with those new extensions introduced with the GF8 (clamp_color, instancing, bindable uniforms,...)

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:
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...

I managed to get animations working:

http://www.youtube.com/watch?v=JwL67-loGWU



The only thing left now is interpolation, for inbetween animation frames, and also multiple animation sequences I guess. This isn't really necessary to get to a level of basic usability so I might postpone it until later. Then it's a matter of cleaning up and organizing the code into something useful.

For example, loading the files will be a bit tricky since it does take noticable time and I obviously can't preload them. I'm thinking of loading one file and then wait for at least one frame to not freeze up the player too much, maybe with a loading bar for good measure.

For some basic functionality I'm thinking simply a function to call on an animation to have it played, and along with replacing a units model with the md5 rendering, it should be possible to do at least something. For more control there could be a choice of in what frame of the animation to start and end with, how fast to play it back, interrupt animations etc. Then we'd want to put in controlling bones from the outside for things like aiming. It might also be possible to setup a system for someone unfamiliar with LUA to control it all from within the cob with a few simple calls. I could even imagine setting up some kind of system where the bones in the skeleton would follow the pieces in a 3do model, altough I'm not sure if it's really a good idea.

About arghs concerns, interpolation is something that could perhaps be scaled to improve performance, such as skipping it for distant objects (talking about interpolation between animation frames and screen frames). Since I'm using quaternions it should be pretty fast and straightforward to do it, and setting it up so you could control the time between interpolation of multiple animations shouldn't be that hard. It might be possible also to setup for blending more then one animation together by interpolation.

<- tears of joy

W I N.

What's the story if we want to have them running and gunning?

Win!

are there any disadvantages comparing to doing this engine wise?

mainly speed.

I imagine that once the prototype is finished in Lua, it wouldn't be that hard to port it into the engine.

Or at least parts of it like matrix and quaternion operations, keeping the flexibility of having it as a script. Those would also be useful in other scripts as well.

I think loading in Initialize would be best, that's at loadtime. Waiting for the game to run lets the player whose PC loads faster give orders first.

Im working on setting it up for animating actual units. A rather nasty problem seems to be that file input doesn't seem to work in gadgets. Widget would only go so far in using COB, handling synced stuff related to animated joints, etc.

[ 242] Lua LoadCode pcall error = 2, LuaRules/main.lua, error = 2, LuaRules/gadgets.lua, [string "LuaRules/Gadgets/skelanim.lua"]:694: attempt to index global 'io' (a nil value)

use VFS?

Ok, that works fine. Now I just need to deal with the synced-> unsynced barrier and hope it doesn't rot performance while trying to transfer the animation data to the drawer.

On performance, I'm thinking it might be a good idea to precompute all the animations and store them, perhaps even as display lists. This would take some memory I guess but provide pretty awesome performance. No idea what the limits are here tough. Could do interpolation between frames by sending last and new vertice position to the graphics card. This might be the best way to do epic amounts of units, although with some limitations.

Which is more efficient, sending variables to synced by registering as global (gadgetHandler:RegisterGlobal) or using a synced to unsynced function (gadgetHandler:AddSyncAction)?

Er, wait, why do you have to send stuff like that? Can't you just have a table containing the animation states of all units and let the unsynced part draw that?

It depends on whether you want the joint positions to be synced or not. For example if you want to keep track of where to spawn weapons. For now I decided to make it as a widget and keep it all unsynced, which has several advantages. Organic critters usually don't have any spinning turrets and stuff anyway.

How to communicate with the script from COB seems kind of sketchy at the moment, with widgets I don't think you can use call-script, and with gadgets theres the whole luacob->luarules merger to deal with. I found that I need to put my LUA function in the main.lua script which I don't feel comfortable with. I think you can read COB values however in a widget, so the COB could simply set a number that is read by lua corresponding to a numbered animation list.

What I think will work best is to have an animation constantly running and then just switch between which one is running at the moment. Then maybe have another value controlling the speed of animation. You would want to have idle animations running for when the unit is just standing around for example, rather then a still pose (which could be done as a one frame animation).

any updates?

What happened to this? Looked so promising

He never finished it, and like a lot of his other experiments, the source was never released.

Kloot got MD5 all the way into the engine via Lua at one point as well.

hmm, the first post has a bunch of code in it, maybe theres something useful there?