![[fr]](/mwf/flags/fr.png "France")
Hello,
Since OpenClonk not work with sprites, you could perhaps change the death animations for the death become ragdolls and not simply Animation.
Since OpenClonk not work with sprites, you could perhaps change the death animations for the death become ragdolls and not simply Animation.
![[ie]](/mwf/flags/ie.png "Ireland")
> Since OpenClonk not work with sprites
OC does work with sprites. Have a look at the rock or the flintstone for example.
/e
Ah, I probably got you wrong there. You mean because the Clonk is no sprite anymore? We do not have any real ragdoll physics (or physics at all). And I wouldn't suppose we would introduce them just for ragdolls. What's the gain anyway?
This adds a little fun to the game, you never laugh at game when you saw a body fall ?
Yes, it may be funny. But as I said, ragdolls need physics, physics do not fall from the sky. Especially clonk has no physics engine whatsoever. Including one is a major task, so don't anticipate this in the near future.Sorry to say so but it's not possible for now.
![[ca]](/mwf/flags/ca.png "Canada")
Well, Randrian was thinking about coding ragdoll physics for the Clonk before. Using helper collision objects and animations for each limb rotating it would be possible, but I don't think it's necessary. A neat visual effect isn't worth the undertaking to make this work.Have a look at how the first Halo game did death animations. Pre-animated falls and collapses worked to great effect there. Scripting a physics engine just for ragdolls would be much harder than making a few nice looking death animations. (Currently I am having lots of trouble exporting the Clonk animation though :[ )
![[de]](/mwf/flags/de.png "Germany")
I was just thinking about implementing ragdolls physics for various purposes, and I remembered this thread. To my surprise nobody really was against implementing ragdolls, everyone just mentioned the effort :)
My first concern would be collision with the landscape. Why do we need helper collision objects? Wouldn't it be possible to create/calculate fake vertices at the joints of the mesh skeleton?
Furthermore, the following comes to mind:
* Blending between animation and ragdoll mode: The animation transformations are applied partially to the skeleton while it works as a ragdoll to prevent the ragdoll from going limp instantly.
* Setting specific bones to ragdoll mode: Would allow for swinging sword scabbards or capes
Also: mega necro post. Happy new year! :D
My first concern would be collision with the landscape. Why do we need helper collision objects? Wouldn't it be possible to create/calculate fake vertices at the joints of the mesh skeleton?
Furthermore, the following comes to mind:
* Blending between animation and ragdoll mode: The animation transformations are applied partially to the skeleton while it works as a ragdoll to prevent the ragdoll from going limp instantly.
* Setting specific bones to ragdoll mode: Would allow for swinging sword scabbards or capes
Also: mega necro post. Happy new year! :D
Hm, actually, perhaps in contrast to the situation 3 years ago, there are so many construction sites in OC that I do really think that it is not a good idea to put any effort into opening a new one. This is not even a really interesting feature as opposed to what we have currently in the pipeline.Also, I don't like the thought of hacking fake vertices etc. into the Clonk physics engine for that.
If we decide to implement this, I would vote for a script implementation rather than hacking this into the engine. Is it currently possible to set bone transformations by script?When I implemented the rope physics with verlet integration, i also red that with verlet integration also ragdoll physics could be implemented easily. But I never hat the time to give it a try.
Yes, I also wanted to do Verlet integration. It works great for fabrics and ragdolls. Script integration would be ok, but it probably does not perform as well as if it were implemented in the engine?
> When I implemented the rope physics with verlet integration, i also red that with verlet integration also ragdoll physics could be implemented easily.
If script-based ragdoll physics would be as efficient as the rope, I'd strongly oppose scripting it. :)
> Is it currently possible to set bone transformations by script?
There is this function available: TransformBone.
In the last few days I gave ragdoll physics a try, the implementation is done in script and not in the engine. It was a little tricky at times, but it might work in the long run! Should I create a bugtracker entry for that?
To be honest, that really sounds slow. And it's not exactly something I'd put ressources into. An engine implementation that runs in another thread would be a different story, of course :)
A ragdoll does not have as many joints/bones as a rope does. I prefer an implementation in the engine, too. However there are some issues: It would work only with meshes that have a skeleton? The mesh/physics engine would somehow have to know where the model collides with the landscape (for example at the joints) and determine that it collides with the landscape?
>The mesh/physics engine would somehow have to know where the model collides with the landscape (for example at the joints) and determine that it collides with the landscape?
That won't work like this as the mesh transformations are not necessarily 100% synchronous. What would work is that the actual position of the mesh does not change, but only the rotation / "position" of the bones adjust to the landscape.
>A ragdoll does not have as many joints/bones as a rope does
If I could choose between allowing two Wipfs more in the landscape or one ragdoll Clonk performance-wise, I'd choose the two Wipfs. It's just not important. And sacrificing performance for a "could possibly be nice to have"-feature is not a good idea, imo.
>What would work is that the actual position of the mesh does not change, but only the rotation / "position" of the bones adjust to the landscape.
I do not quite understand what you mean.
The ingame position (X|Y) of the object can not change based on the bones because the bones' positions are not synchronized.So the ingame position MUST stay the same, but the model can change. So the Clonk will stay at the same position, but the legs and arms will behave like a "ragdoll". The Clonk could of course not fall down a cliff like in soldat, for example.
![[us]](/mwf/flags/us.png "United States")
Ropes are currently the worst performcne-killer we have I think. But I think we could do stuff like casting a ragdoll e.g. for each Clonk that dies. It just shouldn't be something that every object in the landscape is permanently calculating.I'm in favor of an engine solution not just because of performance, but because I'd argue that it's an engine task. You just don't expect low-level physics simulations in script (same with the rope).
If we go that route, then I'd also add stuff such as bouncing objects on vertex contact (similar to the bounce on collision that particles have, since I already implemented something like that in my ragdoll).
Yeah, I guess that would be cool. But make sure that stuff like rocks rolling down slopes and jumping over small ramps still works, because that makes mining more fun.Though I guess rocks/gold/etc. would get rather small elasticity anyway? Or are you not planning to make it a parameter?
At the moment I am doing nothing in the engine. The reception seems good, so I'll make a bugtracker entry and topic for that in the developer's section. Regarding your questions:
We could assign elasticity/bounciness to vertices in the defcore and have all objects have default values, so that they behave the same way before the changed are introduced. Doing this per vertex makes sense for me, because the vertex handles collision already and certain objects may behave differently at certain areas. For example a lorry with tires could have bouncy vertices at the tires, but very stiff vertices at the metal parts.
We could assign elasticity/bounciness to vertices in the defcore and have all objects have default values, so that they behave the same way before the changed are introduced. Doing this per vertex makes sense for me, because the vertex handles collision already and certain objects may behave differently at certain areas. For example a lorry with tires could have bouncy vertices at the tires, but very stiff vertices at the metal parts.
The most important thing that I can think of would be to have a solid line between vertices. So that vehicels and trees don't slide into loambridges anymore.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
