I'm currently trying to implement my first ragdoll and its going quite well with some complications...
The technique I use is quite simple, I start off by constructing a ragdoll for a character, looping through all bones in the skeleton and constructing physical objects to represent the bone (I use boxes since spheres seems to roll around to much). During my first attempt I used all bones and uniform boxes but have changed to only include certain bones and using some custom shaped boxes to increase performance. To constrain the ragdoll I use 2 ball socket joints between the parent and the child, this setup appears to create a quite rigid constraint but is far from perfect. Any input here would be helpful, maybe I should use springs instead? Could RotationalAxisConstraint come in handy here?
Once a character is determined dead I calculate the positions for all boxes to match the current animation and insert them into the world. The result is far from perfect but not that bad. The main issues are once the ragdoll activates the character will often 'jump' up in the air or take a very long time before actually starting to fall down. Other issues are once the character is dead on the ground he will twitch and jerk quite alot. Any ideas how to minimize or even better prevent this would be great. I'll try to find some webspace and provide a video so you guys can see for yourselves.
I'm also unsure about certain ideas, currently I'm setting all the physical simulated ragdoll parts' collisionFilter to 100 + index, i.e. box 1 = 101, box 2 = 102 etc, this should result in no internal collision right? However since my projectiles are not BEPU objects and rayCast doesnt seem to provide a way to supply a filter I'm getting collision detection against the ragdoll parts. This is not a big deal since I can always set the tag to something and compare once I detect the collision but could be something to think about for future versions.
Cheers!
Ragdoll
Re: Ragdoll
I'm not sure I understand the setup entirely or the problem encountered, a video/picture would certainly help. Springs can be used though they won't be as rigid. RotationalAxisConstraint could be used to some degree, but its single-body nature won't let it be a complete substitute for proper two-body joint limits (which are in the plan for a future version).
The jump effect could be either due to internal collisions or position correction on the joints. If a joint anchor isn't aligned after the initial transform, the solver will attempt to correct it and add momentum to the system. A slow fall is most likely caused by internal collisions. The jerking/twitching could be due to internal collisions or joint configuration, not sure which at this point.
You can think of the collision filter has 64 groups. If the bit for that group is 1, then the entity can collide with other entities that have a value of 1 for that bit in their collision filters. Basically, if the binary AND between two entities' collisionFilters is nonzero, then they can collide (at least as far as collisionFilters go). Converting 100, 101, 102... to binary gives 1100100 1100101, 1100110... so you can see that they do share bits and will collide. You can use entity.setCollisionFilter to enable specific bits instead of trying to find correct numbers.
For this particular purpose, I would most likely use entity.nonCollidableEntities instead since it is quite a bit easier to understand and use. An entity will not collide with another entity if at least one of the entities has the other in its nonCollidableEntities list.
The jump effect could be either due to internal collisions or position correction on the joints. If a joint anchor isn't aligned after the initial transform, the solver will attempt to correct it and add momentum to the system. A slow fall is most likely caused by internal collisions. The jerking/twitching could be due to internal collisions or joint configuration, not sure which at this point.
You can think of the collision filter has 64 groups. If the bit for that group is 1, then the entity can collide with other entities that have a value of 1 for that bit in their collision filters. Basically, if the binary AND between two entities' collisionFilters is nonzero, then they can collide (at least as far as collisionFilters go). Converting 100, 101, 102... to binary gives 1100100 1100101, 1100110... so you can see that they do share bits and will collide. You can use entity.setCollisionFilter to enable specific bits instead of trying to find correct numbers.
For this particular purpose, I would most likely use entity.nonCollidableEntities instead since it is quite a bit easier to understand and use. An entity will not collide with another entity if at least one of the entities has the other in its nonCollidableEntities list.