Vertex Animations
Moderator: Moderators
Re: Vertex Animations
oho does this mean i can use all my old quake 2 models :> i wonder if i still have them
Re: Vertex Animations
I think that it's unwise to speculate about the uses or practical limitations of something that general-purpose, personally.Starcraft 2 and Dawn of War II dont have to deal with the unit counts and numbers of unit types we have in our engine
A physics engine wouldn't be doing anything that the engine isn't doing in various places now, it just wouldn't be doing it in dozens of places. If for no other reason than maintenance purposes, it makes a lot of sense to use a physics library.
Re: Vertex Animations
When you are talking about 2-3 orders of magnitude larger counts yes it matters. just one faction in gundam has around the same count as all of starcraft's units. I don't know the count of stacraft II but still there is the fact that you can have 1000s of units on screen on true 3d terrain that is very complex. StarcraftII and dawn of war focuses on simpler maps with 3d geometry creating the illusion of complex terrain. your camera is limited to only a few something like 10-200 units at once and you really are only going to see that much interaction. In spring we can and often do have over 500 units duking it out on screen if you are a fps cam player like me, you see the WHOLE battlefield.
Re: Vertex Animations
A physics library doesn't == slow. It's there to be central and be speedy, after all.
Vertex animations aren't that slow, either. I'm modding an engine where you can watch 200 guys duke it out onscreen at once, something that chokes this engine pretty hardcore.
The main reasons why other engines are keeping tighter reins over stuff like unit counts is probably pathfinding / sub-AI related, frankly.
Vertex animations aren't that slow, either. I'm modding an engine where you can watch 200 guys duke it out onscreen at once, something that chokes this engine pretty hardcore.
The main reasons why other engines are keeping tighter reins over stuff like unit counts is probably pathfinding / sub-AI related, frankly.
Re: Vertex Animations
Of course it doesn't necessarily == slow and of course they had OTHER reasons for low unit counts. but if you are going to tell me ragdoll on 200 units versus 2-5k units is negligible that is silly.
Re: Vertex Animations
Or that a physics library would be totally and mutually exclusive from sub-AI and pathfinding, is completely, and utterly laughable, inane, and naive.
Also comparing engines is comparing apples and pears. Different engines have different ways of calculating things. For example, in spring we have hitboxes or variable shape, width, and size, with 3d particles. In Dawn of War 1, I can see units ignoring 3d weapons ranges and firing at units on ledges above them with the bullets going into and out of ledges, showing no terrain collision detection whatsoever.
To say that an engine can support 100-200 actors onscreen with ragdoll physics is justification that a completely different engine with completely different requirements and simulation architecture, with thousands of units on screen can run ragdoll physics fine is also naive and illogical.
To then go on and say that our engine has issues even running without this more expensive setup, and that this is justification for using it, is even more absurd, naive and illogical.
It is tantamount to saying that I should buy a £3,000 TV because I havent got the money to afford to buy a £500 TV
Also comparing engines is comparing apples and pears. Different engines have different ways of calculating things. For example, in spring we have hitboxes or variable shape, width, and size, with 3d particles. In Dawn of War 1, I can see units ignoring 3d weapons ranges and firing at units on ledges above them with the bullets going into and out of ledges, showing no terrain collision detection whatsoever.
To say that an engine can support 100-200 actors onscreen with ragdoll physics is justification that a completely different engine with completely different requirements and simulation architecture, with thousands of units on screen can run ragdoll physics fine is also naive and illogical.
To then go on and say that our engine has issues even running without this more expensive setup, and that this is justification for using it, is even more absurd, naive and illogical.
It is tantamount to saying that I should buy a £3,000 TV because I havent got the money to afford to buy a £500 TV
Re: Vertex Animations
As usual Argh it would be better if you didn't speculate about the potential effects of code you don't understand. Only an experienced C++ programmer with a high level of familiarity with the code for Spring and the various closed-source engines you're comparing it to could give intelligent answers on these subjects. Not only are you speculating but you are most definitely mistaken about a number of your claims.
As the author of the Epic Legions mod for the original DOW I can tell you categorically and first-hand that the engine was utterly crap at dealing with high unit numbers and path finding in general. It was THE number 1 reason I moved to Spring.
With all of DOW's effects turned down my hardware could still only handle about 1000 units at 20 fps. It became obvious after a while I was fighting a losing battle.
As far as Havok goes, well there's a pretty good reason why Nvidia and ATI were fighting over physics hardware acceleration. It's because the level of physics simulation required to do anything interesting on a larger scale than 10 - 20 models is insanely high. Spring gets around this by cheating. All of these systems you want to merge are deliberately specialised to cheat at one particular thing and do it well. Your assumption that generalising the code more will accelerate it needs data to back it up. My own opinion on the matter is that your theory is unfounded.
If you really want to go comparing Spring to other games why don't you start with Supreme Commander? It's the closest to Spring in every way yet you insist on providing examples of low unit count games to make your points. I spent a lot of time modding Supcom as well and it certainly didn't provide Lua access to vertex animation or Havok. In fact Supcoms animation format was an unintelligible binary blob that makes COB look like a kindergarden storybook. You really have no idea how good you have it.
As the author of the Epic Legions mod for the original DOW I can tell you categorically and first-hand that the engine was utterly crap at dealing with high unit numbers and path finding in general. It was THE number 1 reason I moved to Spring.
With all of DOW's effects turned down my hardware could still only handle about 1000 units at 20 fps. It became obvious after a while I was fighting a losing battle.
As far as Havok goes, well there's a pretty good reason why Nvidia and ATI were fighting over physics hardware acceleration. It's because the level of physics simulation required to do anything interesting on a larger scale than 10 - 20 models is insanely high. Spring gets around this by cheating. All of these systems you want to merge are deliberately specialised to cheat at one particular thing and do it well. Your assumption that generalising the code more will accelerate it needs data to back it up. My own opinion on the matter is that your theory is unfounded.
If you really want to go comparing Spring to other games why don't you start with Supreme Commander? It's the closest to Spring in every way yet you insist on providing examples of low unit count games to make your points. I spent a lot of time modding Supcom as well and it certainly didn't provide Lua access to vertex animation or Havok. In fact Supcoms animation format was an unintelligible binary blob that makes COB look like a kindergarden storybook. You really have no idea how good you have it.
Re: Vertex Animations
OF topic, I was disappoint when the project when silent on moddb >:|SpliFF wrote:As the author of the Epic Legions mod for the original DOW I can tell you categorically and first-hand that the engine was utterly crap at dealing with high unit numbers and path finding in general. It was THE number 1 reason I moved to Spring.
Re: Vertex Animations
What does DoW's pathfinder issues have to do with using Havok?
Please come back when you can at least connect the dots.
AF wins the prize for "wait, wut?" though:
I may not have communicated perfectly, but how you got that out of what I've said is beyond my understanding.
In my wildest fantasies, maybe the aircraft code uses a new sim and is no longer a piece of shit, and FALL isn't the single-most expensive thing you can do, and Lua has the ability to let a physics library carry water for stuff where I want speed and I don't want to have to read a bunch of Wikipedia stuff and reinvent wheels like rigid-body collision stuff. Anything else would just be bonus, and I'm not holding my breath about any of it.
Please come back when you can at least connect the dots.
AF wins the prize for "wait, wut?" though:
What? Do you think I want to make every tank using a suspension simulator?a physics library would be totally and mutually exclusive from sub-AI and pathfinding, is completely, and utterly laughable, inane, and naive
I may not have communicated perfectly, but how you got that out of what I've said is beyond my understanding.
In my wildest fantasies, maybe the aircraft code uses a new sim and is no longer a piece of shit, and FALL isn't the single-most expensive thing you can do, and Lua has the ability to let a physics library carry water for stuff where I want speed and I don't want to have to read a bunch of Wikipedia stuff and reinvent wheels like rigid-body collision stuff. Anything else would just be bonus, and I'm not holding my breath about any of it.
If you don't find the above quote hilarious, then you don't know what ragdoll is.To say that an engine can support 100-200 actors onscreen with ragdoll physics is justification that a completely different engine with completely different requirements and simulation architecture, with thousands of units on screen can run ragdoll physics fine is also naive and illogical.
Re: Vertex Animations
>.< You've obviously never developed using havok, physx, ODE, etc etc beyond seeing the logo and thinking woo! And yes I do understand ragdoll bodies, and it is indeed a hilarious quote, because its showing how ridiculous and contradictory your own points are.
Physics libraries are middleware, they're not performance boosters.
Why are you still posting Argh? The developers have already said that things like IK are desirable, and they'd want it but there are necessary changes first, Zwzsg already has animation scripts running in BOS that have used IK in the past, and its been stated over and over and over again that the engine isn't ready, and that the performance you expect may not be forthcoming, by people who have direct experience in the field that eclipses your own knowledge. Your knowledge only goes so far as that of being an end user modifying things, it is not that of a developer dealing directly with the technology that powers it.
Physics libraries are middleware, they're not performance boosters.
Why are you still posting Argh? The developers have already said that things like IK are desirable, and they'd want it but there are necessary changes first, Zwzsg already has animation scripts running in BOS that have used IK in the past, and its been stated over and over and over again that the engine isn't ready, and that the performance you expect may not be forthcoming, by people who have direct experience in the field that eclipses your own knowledge. Your knowledge only goes so far as that of being an end user modifying things, it is not that of a developer dealing directly with the technology that powers it.
Re: Vertex Animations
Ragdolls are overkill for Spring IMO, there's very little use for them (and in my experience ragdolls can make it hard to tell when a unit dies). Seriously, they're a feature that should be on the bottom of the priority list.
Also note that we want skeletal animation, not vertex animation. The performance hits differ (fewer transformation calculations for skeletal animation), as does the memory footprint (vertex animated models with lots of frames and vertices balloon up to HUGE sizes).
Also note that we want skeletal animation, not vertex animation. The performance hits differ (fewer transformation calculations for skeletal animation), as does the memory footprint (vertex animated models with lots of frames and vertices balloon up to HUGE sizes).
Re: Vertex Animations
Yeah, iirc Quake 2 models were several megabytes in size, and this was the mid-'90s, with polycounts under 500. That would mean gigabyte mods, and all that data has to stay in-memory.
Also, vertex animation takes up too much space to load the whole animation into video card. If you were going to implement vertex-animation, it would almost be worth the effort to develop some kind of lossy compression for it, but you'd have to implement the decompression as a vertex shader for it to really pay off.
That said, vertex animation would work best with Spring's existing model format. Instead of trying to negotiate a relationship between parts and bones, and trying to reconcile animation data vs. animation scripts, you can just animate a Spring part individually at its vertices.
Also, vertex animation takes up too much space to load the whole animation into video card. If you were going to implement vertex-animation, it would almost be worth the effort to develop some kind of lossy compression for it, but you'd have to implement the decompression as a vertex shader for it to really pay off.
That said, vertex animation would work best with Spring's existing model format. Instead of trying to negotiate a relationship between parts and bones, and trying to reconcile animation data vs. animation scripts, you can just animate a Spring part individually at its vertices.
Re: Vertex Animations
if you treat each point as a bone (ending at the next connecting point)which is rigidly bound to said part it would work fine i think pxtl.
Re: Vertex Animations
It might not be ODE in some cases. It could be Ogrenewt.
We could implement a powerful modern physics engine. There are a number of barriers to this, however. We don't really have the developer time to produce something of the sort. Implementing a preexisting physics engine might be possible. ODE and Bullet are the primary options - Newton isn't bad and it is available for non-commercial use, but it is closed source. On the other hand a fully-fledged physics engine like the above (Or Havok/PhysX) is unsuited for the number of active objects in most Spring simulations. In an average team game, let us say 3v3, of 1944 I'm using well over three hundred units alone in the second half of the game - this means that there are more than two thousand units and features on the field... plus so many corpses that as game developers we elected to have infantry corpses removed after a short delay. This is not comparable to a team game in any of the example RTS offered by Argh, and this is just the tip of the iceberg, I've played 6v6 games with well over six thousand units and features active. A physics simulation is intensive, we already have a very resource intensive engine. The social benefits of adding a better physics solution simply aren't there - nobody is going to come to us because we have another shiny. There are other, more useful things to drum up interest in... powerful UI framework, comprehensive professional front end, ASSIMP, etcetera.
Suffice to say, interesting thread, but I think improving the usability of the current options is a better investment of time than advancing a new project in development - particularly one which is so unlikely to prove productive and workable. I'm with Smoth, SpliFF, etc, though we came from different perspectives.
Further personal attacks or other violations of policy will be duly moderated.
We could implement a powerful modern physics engine. There are a number of barriers to this, however. We don't really have the developer time to produce something of the sort. Implementing a preexisting physics engine might be possible. ODE and Bullet are the primary options - Newton isn't bad and it is available for non-commercial use, but it is closed source. On the other hand a fully-fledged physics engine like the above (Or Havok/PhysX) is unsuited for the number of active objects in most Spring simulations. In an average team game, let us say 3v3, of 1944 I'm using well over three hundred units alone in the second half of the game - this means that there are more than two thousand units and features on the field... plus so many corpses that as game developers we elected to have infantry corpses removed after a short delay. This is not comparable to a team game in any of the example RTS offered by Argh, and this is just the tip of the iceberg, I've played 6v6 games with well over six thousand units and features active. A physics simulation is intensive, we already have a very resource intensive engine. The social benefits of adding a better physics solution simply aren't there - nobody is going to come to us because we have another shiny. There are other, more useful things to drum up interest in... powerful UI framework, comprehensive professional front end, ASSIMP, etcetera.
Suffice to say, interesting thread, but I think improving the usability of the current options is a better investment of time than advancing a new project in development - particularly one which is so unlikely to prove productive and workable. I'm with Smoth, SpliFF, etc, though we came from different perspectives.
Further personal attacks or other violations of policy will be duly moderated.
Re: Vertex Animations
In terms of "shiny things to attract interest", physics is well below any animation format that isn't BOS- I wholeheartedly agree with that. I just think it's really silly that people get all hot and bothered about something like this, instead of having a reasonable conversation about use cases and business cases.
As for vertex animations, size, etc., here are my thoughts:
1. Typical Spring model is not a lot worse than a Quake 2 mesh in terms of polycount.
2. Size of vertex animations increases linearly as mesh data increases or animations increase. It's not wise to generalize about the size of things, as it would vary a lot between characters. These days, RAM is not a big issue- games are using well over a gig now, and it's OK to have a feature that may mean that much gets used, if somebody builds a game with a massive number of things all with a lot of animation. Amongst other considerations, animated meshes compress extremely well and ultimately it's not up to the engine to worry about resource use anyhow.
3. Vertex animations are really fast otherwise, and can do stuff skeletal animations can't.
4. Skeletal animation is comparably slower, because it can't just be transformed / interpolated; the character needs to be transformed, then each bone needs to be rotated, the bone's matrix needs to be found and each vertex's weight has to be used to determine the final position.
That's probably not a massive amount cheaper than the process of animating S3O, although it's still cheaper in terms of rendering (one display list call per character).
Moreover, while an engine that mainly deals with humans can do various optimizations for a stock human skeleton, Spring can't make that assumption.
That's pretty much all I've got to say in terms of the technology choices. I think we could have vertex animations as soon as somebody looks at the various source that's available for that, starting with Quake 2 source. I think skeletal stuff will depend on whether the right people want it to happen.
But in either case, compared to the way it works now, where S3Os use multiple display list calls and do a lot of fancy math to handle Piece translation, etc. per render call, it should be considerably faster than anything we've got now. Not slower. There's a lot of stuff going on with unitRendering that is pretty icky.
All that said... I really do not care whether we use something called "noodle animation", so long as it is compatible with a popular format for doing this sort of work,whether that's Collada, SMD, or whatever, so that we're not stuck with an engine that's severely limited visually anymore.
That is what's important to me. Leave off on pointless arguments about physics stuff; if we get some kind of animated format within the next six months, it's exciting and would finally address one of the biggest missing things in the engine that content developers aren't going to be able to fix on their own.
As for vertex animations, size, etc., here are my thoughts:
1. Typical Spring model is not a lot worse than a Quake 2 mesh in terms of polycount.
2. Size of vertex animations increases linearly as mesh data increases or animations increase. It's not wise to generalize about the size of things, as it would vary a lot between characters. These days, RAM is not a big issue- games are using well over a gig now, and it's OK to have a feature that may mean that much gets used, if somebody builds a game with a massive number of things all with a lot of animation. Amongst other considerations, animated meshes compress extremely well and ultimately it's not up to the engine to worry about resource use anyhow.
3. Vertex animations are really fast otherwise, and can do stuff skeletal animations can't.
4. Skeletal animation is comparably slower, because it can't just be transformed / interpolated; the character needs to be transformed, then each bone needs to be rotated, the bone's matrix needs to be found and each vertex's weight has to be used to determine the final position.
That's probably not a massive amount cheaper than the process of animating S3O, although it's still cheaper in terms of rendering (one display list call per character).
Moreover, while an engine that mainly deals with humans can do various optimizations for a stock human skeleton, Spring can't make that assumption.
That's pretty much all I've got to say in terms of the technology choices. I think we could have vertex animations as soon as somebody looks at the various source that's available for that, starting with Quake 2 source. I think skeletal stuff will depend on whether the right people want it to happen.
But in either case, compared to the way it works now, where S3Os use multiple display list calls and do a lot of fancy math to handle Piece translation, etc. per render call, it should be considerably faster than anything we've got now. Not slower. There's a lot of stuff going on with unitRendering that is pretty icky.
All that said... I really do not care whether we use something called "noodle animation", so long as it is compatible with a popular format for doing this sort of work,whether that's Collada, SMD, or whatever, so that we're not stuck with an engine that's severely limited visually anymore.
That is what's important to me. Leave off on pointless arguments about physics stuff; if we get some kind of animated format within the next six months, it's exciting and would finally address one of the biggest missing things in the engine that content developers aren't going to be able to fix on their own.
Re: Vertex Animations
No, IK isn't good or suitable, and isn't wanted in the engine, as an automagic IK solver that can guess how to animate any model is nothing but a dream. See http://springrts.com/phpbb/viewtopic.php?f=9&t=22021The developers have already said that things like IK are desirable, and they'd want it but there are necessary changes first, Zwzsg already has animation scripts running in BOS that have used IK in the past, and its been stated over and over and over again that the engine isn't ready, and that the performance you expect may not be forthcoming
Skeletal animation on the other hand would be very welcome!
Re: Vertex Animations
Skeletal animation is faster than vertex animation. Many early 3D consoles are not capable of vertex animation because it's too costly. There's a massive difference between streaming 3000 vertices per frame or 36 bone matrices.
I've seen Quake 3 models that had ~3000 faces and 300 frames of animation, they took more than 30 MB.
I've seen Quake 3 models that had ~3000 faces and 300 frames of animation, they took more than 30 MB.
Re: Vertex Animations
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.
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.
Re: Vertex Animations
I think the only reason for the enduring popularity of old vertex-animated forms is the simplicity of the data files. It's just an array of frames. Each frame is just a frame number and one position per vertex. That's it.
Meanwhile, boned formats have to store the bone definitions, the relationships of each vertex to each bone, and so on... and because they're newer file-formats, they often have a tonne of more elaborate metadata, some using named animations and whatnot to boot. That's the messy part.
Meanwhile, boned formats have to store the bone definitions, the relationships of each vertex to each bone, and so on... and because they're newer file-formats, they often have a tonne of more elaborate metadata, some using named animations and whatnot to boot. That's the messy part.
Re: Vertex Animations
OK, so vertex shaders make it a no-brainer? Okie doke- I didn't think about passing the matrix along, I guess that does make it pretty simple. Thanks for explaining that.