Vertex Animations - Page 4

Vertex Animations

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: Vertex Animations

Post by KDR_11k »

jK wrote:Vertex Animation is an ancient system pre-vertexshader times, when the CPU was responsible for vertex streaming and transformations. It was a hell to code and even more evil to make it work at decent performance.
No one would even think about to use it these days, there is VertexBlending now (with bones etc.) and it ways easier to manage, to code, and it is GPU accelerated.
Hell, skeletal animation started getting popular on the PC with Half-Life, back then 3Dfx was still a quality brand. The N64 cannot do vertex animation.

Probably the only reason people still use vertex animation at all (outside of morph targets inside a mostly skeletal system) is because it's easy to get an MD3 importer running.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Well, that, and it can do stuff you can't do with skeletal.

I'm using it for weapon animations at present, where weapon pieces need to be rescaled or move just a few vertexes of a model over a series of frames. For stuff like that, it's fast and powerful, and because it's arbitrary, it's much less setup.

I guess that counts as a morph target, though- IDK what the distinction is, I thought morph targets were just vertex animations with a base object to average the morphs against.

Vertex animations are the only way to do stuff like scalar changes as well.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Vertex Animations

Post by jK »

Not true, the reason why ppl say you can't use scaling in VertexBlending is because any non-uniform scaling (:= x-,y- & z-scaling are unequal) breaks the normals, it does so for VertexAnimations the same way! Uniform-scaling works always!

And with VB you even have the possibility to recalculate the normals in a geoshader, if you really need something like that (mostly it is just not worth the effort).
KDR_11k wrote:Hell, skeletal animation started getting popular on the PC with Half-Life, back then 3Dfx was still a quality brand. The N64 cannot do vertex animation.
I didn't said that VertexBlending was used because it can be hardware accelerated, I just said that it is the reason why VertexAnimations vanished.

edit: fixed non-uniform scaling definition
Last edited by jK on 27 Sep 2010, 23:45, edited 3 times in total.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Not true, the reason why ppl say you can't use scaling in VertexBlending is because any non-uniform scaling (:= x-,y- & z-scaling are equal) breaks the normals, it does so for VertexAnimations the same way! Uniform-scaling works always!

And with VB you even have the possibility to recalculate the normals in a geoshader, if you really need something like that (mostly it is just not worth the effort).
I'm not really worried about that issue, tbh.

It's just stuff like "gee, I could simply make a copy of this model and move this chunk of the mesh to position 2, or I could make a new bone, make it part of the hierarchy, attach all of that chunk to that bone, then animate the bone".

IOW, vertex animations are a lot easier to make, from the artist's standpoint, for certain types of things.

As another example, if I want to animate a bunch of seaweed tendrils slowly moving in a cyclic but not uniform way, it's a lot easier to do a few frames of vertex animation than to set up a bunch of bones, and it's probably cheaper computationally for the engine to animate it.

Anyhow, I understand I'm not likely to get this, I understand the counter-arguments, and for most use cases, what you said sounds reasonable to me.

@Smoth, please don't derail like that, it's rude.

I've been using both skeletal and vertex and morph-target stuff (facegen faces).

I don't understand how all of it works, but I am getting a pretty good feel for the strengths and weaknesses. None of the techniques is a panacea, and most FPS engines seem to use all three.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Vertex Animations

Post by Pxtl »

One could probably develop a compression system that took a keyframed model and bolted bones on for you - after all, are bones really anything more than a list of vertices and a set of 3x3 matrices for each keyframe?

Thus, look through the animation for vertices that always share the same rotation matrix, and attach them to a bone. Although it would be mathematically tricky for the first part of that sentence.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: Vertex Animations

Post by KDR_11k »

Even before skeletal animation became commonplace in game engines it was used by artists to generate the animation data for the models. Vertex animation is a maintenance nightmare because changing the base geometry in any way fucks all the animations over. I have no idea WTF you're doing with weapons that requires individual vertex movements or rescaling (BTW, skeletal animation usually allows bone scaling as well) but if you're simulating any real mechanical device you can do the animations with bones moving around.

pxtl: That'd be hell to do. You'd have to check 1k+ vertices against each other using only their transformation data (individual vertices don't contain rotation data) which differs between keyframes only in a linear movement. Probably takes exponential time.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Vertex Animations

Post by SpliFF »

The whole discussion about animation methods is moot until it's established whether this animation is supposed to be synced or unsynced.

The COB method of animation is intrinsically tied to the game state (synced) because it affects aiming, transportability and movement. It can't be moved to unsynced or GPU processing unless the animation system goes through a complex rethink to seperate the parts that are functional from the parts that are merely decorative.

Even if this happens, there are animation events that will always be intrinsically linked to game events and terrain. The question arises then what the engine should do about things like aiming and firing if you go and start bending the turret around with your own vertex manipulations. Does the muzzle remain slaved to the parent node (offset from parent center) or a point on the parent mesh (where the muzzle appears to be at any given moment). This question obviously affects units like the Vulcan cannon where the barrel spins under COB's control. It would definitely affect skeletally animated figures holding weapons.

If you moved the barrel spinning animation into unsynced or vertex shader code it would run faster but you'd often see the shells leave at the wrong spacial position or timing unless you perfectly sync the two systems. That's a task that's much easier said than done. You'd also have to manage conflicts and events like when COB is moving the node but your animation is based on it being still or vice-versa.

You want an animation when your 100-foot giant robot puts it's foot down (unsynced) but you also want it to crush units underneath (synced). What about Spring.GetUnitPieceMatrix() should it return the synced or unsynced vertex positions? (it definitely can't return GPU transforms and if you could what would you do about headless spring).

Synced animations don't have the luxury of running only when the unit is onscreen. They have to run on every PC, on every update, for every unit or feature in the world. If they don't then the game will desync.

And just don't get me started on the technicalities of throwing synced physics simulation into the mix.

You can't just bolt on libraries from other projects to solve these issues. Most projects don't have to deal with sync and other Spring or RTS-specific concepts. All of the libraries discussed so far are primarily aimed at the FPS market. Even then you have to be able to feed these libraries the objects they expect and get back the results Spring expects, bind all that to Lua, make it compile and hope it all runs 8x8 "Epic" or "World" on Joes Athlon and Bobs 6-year old laptop. These things are themselves a massive undertaking.

When you REALLY understand what's involved it's pretty obvious this is a MAJOR project that will probably require mod-breaking changes to ever work sanely. You could probably bolt some of the game-changing stuff to COB extensions and do the fluff in shaders but really I wouldn't expect it to be anything particularly stable or easy to use. I estimate that if somebody with the right skills took it on as a serious 6 - 12 month project it could be done but pretty much anyone who is a current dev has come to the same conclusion at some point and decided not to bother.

So what is the point of this thread exactly? It looks like a wishlist of vaguely specified features that haven't been implemented because nobody who can do it wants to. It isn't like it's a new idea or anything. Might as well wish for an "awesome button" that makes Spring awesome when you press it. You'd pretty much get the same outcome as you'll get from this.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

I think you're really overstating the difficulties here.

Characters can be handled through collision objects, a ground point, and a few points we move / rotate in code. That's all that needs to be synced, and I don't think that's a major problem. A guy with a gun needs just one point defined for a basic simulation, and it probably doesn't need to move at all, because the "shooting" animation will always go to the same relative XYZ.

Stuff like tanks will remain driven through BOS, because that really is the best way to handle things like turrets.

In short, I think it can be done without being super-awful.

Can it be done with Lua/BOS, even? Yeah. We could have a Lua/BOS animated Unit that consisted of empty points, a standard Unit, and the rest of it would be callouts to a skeletal animation system- something like:

Code: Select all

isWalking()
{
  (while !isShooting)
  {
  lua_CallAnimation(characterType,walk_animation,priority);
  } else {
  lua_CallAnimation(characterType,walkshoot_animation,priority);  
  }
}
And that whole animation would be unsynced. Timing would be up to the BOS/Lua script. If you want your gun to fire when the animation does, you'd adjust sleeps to create the illusion of synchronicity.

IOW, the idea that the animations would have to be synced or that they'd have to be a massively new system is largely a chimera, imo.

The only thing that would be a big pain in the ass is if people wanted stuff to be simulation-accurate but use skeletal animation. Then you'd need to do full IK and that would be expensive and a pain in the ass.

Even FPS games rarely do it for more than one bone (usually the bone upwards of the pelvis, to allow torso twists that match sim), and in most cases, we'd want to do zero, because a little bit of mismatch between character animations and gunfire start points is not a big deal- you just don't see that stuff all that much, when things are happening, and most of the character types this kind of animation is good for turn swiftly enough it wouldn't happen that much anyhow. That, and we already have those issues with the current system, because guns need a certain amount of tolerance or they never line up to the required amount of decimal places.

Canned stuff called from gamecode, though? Not really. We just need a system to render the skeletal stuff and a way to call it that makes sense, and we're in business.
User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Vertex Animations

Post by SpliFF »

Argh wrote:I think you're really overstating the difficulties here.
Says the guy who hasn't read the code, but as I said that depends entirely on what you expect from the results. Animation can be partially disentangled from simulation which is doable but you'll still need your Lua/COB scripts to handle the normal aiming and firing routines which means as a content author you'll need to deal with 2 animation systems instead of one. If you need complex animations the chances are they'll be a complex intermix of decorative static animations and spring's internal proceedural ones meaning a lot of "call animation" happening with no real idea of where your animations timelines and piece transforms are in relation to each other.

You seem to assume synchronizing them will be easy but as someone already familiar with using SendToUnsynced() you should know it's not that simple. It's one thing to send "Hello World" to your widget, it's quite another to maintain frame-accurate timings across hundreds of units on every update.

As far as the "illusion of synchronicity" well that's where reality will kick in and bite you hard. It's not called "unsynced" for nothing and that illusion will probably last about 5 seconds before your units start sticking their weapons through their own heads.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Isn't Sendtounsynced just a Lua issue, though? I don't understand that bottleneck- I thought Unit draw operations were operating directly, and I presumed that this would have to be the same way.

As for timing, etc.- go play any game, and watch closely. Animations are constantly off-time. Shots emerge from guns and the animation for aiming is not quite there or is a little past ideal. It's not a big deal, so long as it's reasonably close. You literally don't see it, unless you're being hyper-critical.

Animations are given a time-to-live for that very reason- to keep it within a fairly close distance from gamecode events. In short, perfection's not attainable; our Units using BOS aren't perfect either (closest you can get is with smoothAnim, which is expensive), and that's OK.

As for two-animations-for-one-thing... that's the norm for most game engines (if they aren't fancy like Unity and allow you connect logical objects to bones), and it really isn't that awful. If you're smart enough to do rigging and animation in the first place, you can handle placing a few points and writing some simple code about when / how they're used. Remember that most of them wouldn't move, and would just get used for shot-points or particle effects or point lights. This would be much, much, much easier than writing BOS/Lua code for people.

Again, you've got to bear in mind that most of the characters you'd want to use skeletal systems for would turn rapidly- there wouldn't be a complex aiming sequence on the code side, just a timer loop and fx. It wouldn't be a lot different than stuff we do now where we give a character a big Tolerance value and don't aim it on either the X or Y axis.

Mainly, I get the impression that you don't have a clue how much smoke-and-mirrors stuff we game developers already have to do, to make stuff look reasonably good. Perfection is only possible at the expense of speed, and given the limitations of the current animation system, there's a lot of stuff we just have to fake entirely, because otherwise it'll be obvious that our "human soldier" is just a collection of boxes or whatever.

That issue- the inability to even fake it well with a lot of character designs, because the animation system can't change geometry- is a much bigger problem than whether or not our guns are perfectly timed and aimed with the synced code aiming sequence, for example (which, as I've said, they aren't and will never be, and it doesn't matter).
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7052
Joined: 16 Nov 2004, 13:08

Re: Vertex Animations

Post by zwzsg »

Have it that way:
- synced move all the bones
- unsynced does the bones->mesh transform

As far as I know, firing, transporting, all other sync relevant action use the piece centers, not vertices, so there's no need to sync the whole meshes, nor even to calculate the meshes for unit outside view. For synced, only the bones matter, and there wouln't more bones than we have pieces at the moment.

I mean, when you think about it, the current Spring model system with the piece hierarchy is a bit like a skeleton where every vertex belongs 100% to one bone(=piece) and 0% to other bones. So just add some info to the s3o to have vertices belongs to several piece(=bone) with weight, and you'd have skeletal animation.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: Vertex Animations

Post by KDR_11k »

Even if you aren't computing all bone positions in synced and let unsynced do that you can still compute specific bones on demand, after all the current animation frame should be deterministic.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Right- it'd just be something that you'd want to avoid unless you really needed it. But yeah, that might be a way to gulf the divide there.
- synced move all the bones
- unsynced does the bones->mesh transform
That'd be second-best. I think that would be equally as slow as the current system (I'd have to go back and look at that code, but I thought that is how relative Piece stuff is working now).

Anyhow... yeah, I think it's doable. ASSIMP already imports characters and skeletal animations into a scenegraph with data nodes (the bones are a separate import, but connecting the two is probably not a major problem).
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Re: Vertex Animations

Post by Tobi »

I think in this case Argh is a bit closer to the point than SpliFF atm: SendToUnsynced is, currently, an instant operation (might change for MT but should remain pretty close to instant because it remains local). There won't be any timing issues.

Unsynced vs synced really only refers to whether data and operations (one implies the other) are identical on all clients or not. From that it is easily seen that synced->unsynced communication is just passing data around on the local system. If you look at the SendToUnsynced code you'll see that it directly calls RecvFromSynced in the unsynced code. Only unsynced->synced involves delays, because for that direction the data really has to be synchronized: it has to be send over the network to all clients before it can be made available to synced.

So to run skeletal animations in unsynced (GPU?) code is not really an extremely hard problem, as long as you, as Argh says, keep doing the normal COB simulation too for the pieces used as firing points and all their parent, grandparent, ..., etc. pieces.

Of course SpliFF is right that it will mean quite a bit of extra work in keeping these things in sync, but there should in principle be no such nasty things as variable lag based on network congestion or cpu usage or so.

Also it would probably be relatively straightforward to allow one to fetch a vertex position in an animation frame in synced manner. It simply means making a separate piece of code that calculates the same animated vertex position on the CPU instead of on the GPU. Then such a vertex could be allowed as firing point of a weapon.

That would get rid of the problems synchronizing two separate animations, though I really wonder if it will be easy to get weapons to behave in a predictable manner if their aiming direction / vertex are based on any frame based animation. Plus if you need aiming in another way than rotating the complete unit you might need parameterized animations, or split up the unit in multiple separately animated pieces (seems to me that might be a good idea anyway, in particular for turreted units). Not sure how that is usually done though.

Personally I think the main reason it isn't done yet is just that it's quite a big amount of work in total, it involves complex matrix/OGL stuff and messing around with many coordinate systems, and there's a little bit of a bootstrap (chicken-egg) problem wrt the code and test data for it. (Of course solvable, but it's a small extra hurdle.) And possibly some/many of the current devs just aren't extremely interested in implementing skeletal animation ;-) Of course I can not speak for others.....

Random other thing:
SmoothAnim in COB is really nothing more than a runtime transformation of all turn now and move nows followed by a sleep between 30 and 300 ms (IIRC) to turn/move with a speed calculated from the sleep duration.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

SmoothAnim in COB is really nothing more than a runtime transformation of all turn now and move nows followed by a sleep between 30 and 300 ms (IIRC) to turn/move with a speed calculated from the sleep duration.
Really?

If that was longer, we could teach animation to nubs in no time flat. Needs to be a second or longer, though.
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Re: Vertex Animations

Post by Tobi »

Realise that it would mean you need a workaround if you really want to do a move/turn now, followed by a sleep. (For recoil, for example.)

I think in that case a better addition would be a turn/move function where the delay is specified instead of the rotation/translation speed.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Yeah, that'd be fine too. The key is that people could just do keyframes and time- velocity would take care of itself. I think that would help new people a lot, and it'd be a lot easier to teach.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Re: Vertex Animations

Post by KDR_11k »

Keyframes should be defined in animation files, not the unit script. There's a ton of powerful tools that help with animations in a modern 3D package, you can e.g. stick an IK solver on the legs, make an animation with a handful of keyframes and then bake the IK before outputting to the game engine to get a walk animation that looks way better than anything you can reasonably make with unit scripts (and much faster than implementing a realtime IK solver).
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Vertex Animations

Post by Argh »

Right. If skeletal animation was available, we could do robots just as effectively as alien sludge-beasts or whatever.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Vertex Animations

Post by Pxtl »

I think the fact is that there are two separate and unrelated features needed to get decent animation into the engine:

1) A way to get skeletal models into the engine, with each bone being treated as a part by unit script

2) A way to import scripted animations into the engine and play them in lieu of manually-coded Lua.

The simpler but less-powerful solution is to abstract bones and animations away into sub-part objects that can't be accessed through lua except just to say "play the animation X frames Y to Z on part Q". Then you break up your models Quake3 style using one part for legs and one part for torso.
Post Reply

Return to “Engine”