Physics engine in AssaultCube (ragdoll)

[MykeGregory]

here is what i thought...

Is it possible to make physics using the cube engine, i mean like ragdoll.
cos it would be so cool to have ragdoll in assaultcube, but it would make the filesize huge (i would imagine).

any one have any view on this?

[ärkefiende]

Possible is everything, but remember it´d cost huge amount of time implementing such a feature.

[wolfbr]

about physics, I believe that AC does not need much(simple game, low file size(40-50 MB, run easy in the most systens..).
maybe, enhance the effects of bullets impact(especially when it hits water), improve blood effects, drop shells and other small things.
ragdolls is coll, but, do not know if anyone would encourage programming that.

[eihrul]

The problem is not the engine. The problem is the player models are md2, so have no skeletons by which to animate them with a physics engine.

[MykeGregory]

The problem is not the engine. The problem is the player models are md2, so have no skeletons by which to animate them with a physics engine.

i wish i could make some ragdoll effects, i dont have the knowlege.
would it take much programming? i mean, call me a noob but it seems to me it would be too much, time and money wise.

[Gibstick]

i wish i could make some ragdoll effects, i dont have the knowlege.
would it take much programming? i mean, call me a noob but it seems to me it would be too much, time and money wise.

Yes, I think it would take some time.

[eihrul]

I will repeat. The problem is not the code. I could whip it out in a weekend. The problem is the models! So long as they are not skeletally animated, not ragdoll is possible. No one wants to re-animate the MD2 player models as MD5, so nothing can be done. End of story.

[MykeGregory]

I will repeat. The problem is not the code. I could whip it out in a weekend. The problem is the models! So long as they are not skeletally animated, not ragdoll is possible. No one wants to re-animate the MD2 player models as MD5, so nothing can be done. End of story.

i didnt state anything about the engine, but i see your point. oh well.

[Zarjio]

I will repeat. The problem is not the code. I could whip it out in a weekend. The problem is the models! So long as they are not skeletally animated, not ragdoll is possible. No one wants to re-animate the MD2 player models as MD5, so nothing can be done. End of story.

How exactly are the animations done, for running and such? Is it just a series of models being shown one at a time then?

[wolfbr]

I will repeat. The problem is not the code. I could whip it out in a weekend. The problem is the models! So long as they are not skeletally animated, not ragdoll is possible. No one wants to re-animate the MD2 player models as MD5, so nothing can be done. End of story.

cube2"s and blood frontier's models have ragdolls, perhaps it would be possible to get these and doing other models for AC?
both games are OpenSource, maybe it would be possible to get part of the code of these games.
the same scheme could be useful to add other effects to the AC(better bullet impacts, drop shells, blood...)

[#M|A#Wolf]

I will repeat. The problem is not the code. I could whip it out in a weekend. The problem is the models! So long as they are not skeletally animated, not ragdoll is possible. No one wants to re-animate the MD2 player models as MD5, so nothing can be done. End of story.

both games are OpenSource, maybe it would be possible to get part of the code of these games.

The problem isn't the code. The models themselves would have to be changed from md2 to md5 so if anyone is willing to do so, then...

[tempest]

How exactly are the animations done, for running and such? Is it just a series of models being shown one at a time then?

Yup, that's basically how MD2 and MD3 work. MD5 however uses skeletal animation, which means that the animation just describes how the so-called bones move, and the engine uses that data (and the vertex weight) to move the vertices (i.e. animate the actual model).

[V-Man]

You don't think it was a little overarching to say that nobody would want to make that conversion?

[tempest]

The problem is that it wouldn't be a conversion, but rather completely redoing all animations.

[Mr.Floppy]

Sorry if I confuse something here, but isn't the purpose of ragdolls not to have the models 'manually' animated, but let the engine do all the work?

If this was true, all we needed was a md5 model with proper bones/joints, but NO actual animations, right?

Just asking in order to understand this fully, because if there isn't a model animation needed, well, that would make things a lot easier...

-edit-

On the other hand, if we still needed to animate, then where is the advantage of ragdolls in this case?

[Bukz]

Pretty sure it's up to the ragdoll code that would be put into the physics part of the engine to do all the work. MD5 just has all the requirements which MD2/MD3 will always lack.

[tempest]

@Floppy: Most engines use ragdoll physics mostly to animate correct physical behavior of dead bodies. All actual movement while the player is alive is still done through animations.
(Actually, some modern engines blend animation with ragdoll physics, to some extent, also to fit the the player movement to the environment. I think e.g. Prince of Persia uses such a technique.)

[Matasar]

I would be possible to animate death but it would be boring after you seen it a while.
if not possible to do several animations and make em random.
Not perfect in all situations but still =)

[Revert]

Tbh I don't think the effort and fustration and memory is needed to make ragdoll physics. But, thats in my humble opinion. (:

[FleshyPod]

Sorry if I confuse something here, but isn't the purpose of ragdolls not to have the models 'manually' animated, but let the engine do all the work?

If this was true, all we needed was a md5 model with proper bones/joints, but NO actual animations, right?

Just asking in order to understand this fully, because if there isn't a model animation needed, well, that would make things a lot easier...

-edit-

On the other hand, if we still needed to animate, then where is the advantage of ragdolls in this case?

If you want understand it more, get Sauer game and look into docs. There is one of the models used in game, with all bones and keyframed animation. When player lives, animation is performed. When dies, each bone is affected by gravity, but they are connected each other so you see a ragdoll.

[flowtron]

Indeed. Sauerbraten has been using ragdoll-animations (or rather -physics to not confuse it with _static_ animation-sequences) for quite a while now.
As eihrul has stated (at least twice in this thread) the issue for AC is mainly that we'd need completely new playermodels (MD5 w/ bones) to even make it plausible to start working on a backport of that code.
But, if I'm really honest .. I don't see much use for it in this game.
Also - please keep in mind - AC is geared toward running on low-end machines; if we were so inclined we'd just ditch the entire Cube1-engine and move to Cube2-engine .. it'd provide real 3D enviroments - not just bridge-models that can (pun alert) bridge some gap, but at immense costs to processing power.

[wolfbr]

however, in sauer you can enable and disable effects, thus the game runs well on any machine : ).
ragdolls for me is more for extra realistic gore(exemple: dismembered) and some fun.

[Zarjio]

You can't use both static animations and "skeleton" animations - or at least I can't see any way of doing it. That would be extremely difficult to code.

[Mr.Floppy]

however, in sauer you can enable and disable effects, thus the game runs well on any machine : ).
[...]

That doesn't apply for any machine actually. I can disable all and everything, but Sauerbraten won't get beyond 30 FPS at all. ;)

Thanks to everyone giving hints and help on that issue. I meanwhile understand a little more about the possibilities having models with skeletons, but as FlowTron mentioned, I doubt the expected benefit would cover the costs, so to say.

[LtDan]

You could make two AC packages. One for old comps - without all the fancy new rag-doll stuff, and one for BEAST comps (like mine) - that has all the cool animation/rag-doll junk. It would be a lot of work, but I'm just sayin that it is possible.

[wolfbr]

however, in sauer you can enable and disable effects, thus the game runs well on any machine : ).
[...]

That doesn't apply for any machine actually. I can disable all and everything, but Sauerbraten won't get beyond 30 FPS at all. ;)

Thanks to everyone giving hints and help on that issue. I meanwhile understand a little more about the possibilities having models with skeletons, but as FlowTron mentioned, I doubt the expected benefit would cover the costs, so to say.

http://cube.wikispaces.com/Beginners+Guide
Typically, to run Sauerbraten at playable speeds on minimum settings, you'll need at least:
1GHz or higher CPU, 256MB RAM and a GeForce 4 MX or equivalent GPU.

For maximum settings, you'll need at least:
2GHz or higher CPU, 512MB RAM and a GeForce 6600 or equivalent shader model 2.0 GPU.

---
I do not think it is very, run in a P3, AC has some cool effects, which do not weigh much in the game(lights,shadows,water..), I just think that some effects can be improved without much grief in the game, and can be configured for most of the machines. i like to see more effects(exemple, rain, snow, realistic gibs..)

exemple;
water: bullet hit water(water splash), configure amount of blood(like gibs), body walk in the water(water trail), underwater bubbles under water(for players and bullets trails).

bullets coliders> improve bullets hits, body and walls(improves the game because you can better see where the bullets hit, especially good for long distance)

weapons drop shells> more realism and fun

weather effects> rain, fog, snow..

improve players anims>

and others small thinGs : ) < FIXED : D (flood trol XD)

[LtDan]

and others small thinks : )

things* LOLZ!

[flowtron]

LtDan: no way, it's either one or the other. I've repeatedly asked (on IRC) whether or not people would like us to go "AssaultBraten" with the project .. and there's just too many people still relying on AssaultCube being one of the few fps-games they can play on their low-end machines - that's the niche AC lives in.
Suggesting what you did seems to indicate you have neither an inkling of how much time & sweat it'd take to completely rewrite AC into a Cube2-engine-based game and how much exponential growth to time & sweat it'd cause were we to try to keep a Cube1/Cube2 engine compatible with each other .. it's just not feasible, not even a highly funded game-forging company would ever attempt it I'd wager - certainly not a handful of enthusiasts that work on this project in their spare time and get no money for it, the odd cheer and lot's and lot's of bad blood, bad language and bad people (read: cheaters & cheat providing lame-o's) for their efforts.

[tempest]

May I add that keeping a Cube1-AC and a Cube2-AC compatible would also mean that the main advantage of Cube 2, the octree world structure, could not be used.

[FleshyPod]

Also porting all code to cube2 may cause setup file >300megs. But opposite to that, maps can be more realistic, not that square as there are now. Maybe later some maniacs could migrate code for us :>