Capsule Character for Collision?

Definitely depends on the game. No point in doing more than what is required, so if a simple capsule is all that the game demands, that's all you need to do.

Many games use a hierarchy of AABBs and/or OBBs if they require region-specific hit detection. IK placement can also be used to make procedural animations... but again, only if you require that level of realism.

So something like

">this (minus all the animation bells and wistles), can be practical for world collision?

I understand using hierarchial characters (don't know the proper name for it) for hit detection but I think I want to expand beyond that to world collision. I want to be able to link a characters hand to a ledge and not have to worry about how the animation lines up or where the giant collision shape is located at the time.

However, I am concerned how much more expensive it is with around 15x more checks to make and the possiblity of a character slipping through a crack of some sort and getting stuck.

Quote:

Original post by AntiGuy ..(minus all the animation bells and wistles)..

It is all about animations :-) A capsule(or 2-3 spheres to approximate a capsule) is often used for two reasons:
1. The collision detection of a capsule is very cheap.
2. The round bottom of a capsulate helps to avoid small obstacles like stones on the ground or stairs.

A "real" character would step over obstacles(!), but in games the capsule just slides over the ground.

Ragdolls are used to animate(!) a character procedurally. So, when a character dies, the game creates a ragdoll-physics representation of the character and let it fall to the ground (or flying away when shoot), but the character is no longer controlled by the player ! This will lead to believable animations because the limbs interact with the world geometry in a believable way.

When a character is not dead, it does not consist of a ragdoll representation. To align animation with the world (i.e. a foot should always touch the the ground), inverse kinematics are used to align the animation with the environment,thought the physical reprensentaiton is still a simple shape.

When you want to move your character using a ragdoll like physical representation you should consider the following issues:
- performance:
ragdoll physics is quite expensive compared to simpler representaitons, be careful if you plan to use many characters/npcs.

- obstacle:
if you plan to create a stable and consistent physics simulation of the character, small obstacle could be an issue. Your character needs to step over them instead of just sliding over them and correcting the animation using IK.

- stucked limbs:
When a limb get stucked (i.e. a arm get stuck in a closing door), the player movement will be blocked which could be very annoying.

Yeah there are probably tons of performance benefits to using a capsule/cylinder but I'm still having trouble seeing how animation does everything.

Picking up a Box
For example... let's say we have a guy completely surrounded by a box. The guy walks up to a ball and wants to pick it up and hold it close. Physically the guy could never do that because the box would be constantly knocking the ball away. So you'd have to disable the ball's collision to do it.
Now let's say the guy want's to drop the ball, if the ball is inside the box at the time it's enabled, it's likely to shoot out somewhere. The only way animation could handle it all is if the animation takes place outside the box.

Grabbing a ledge
This one I'm much more interested in. When grabbing a ledge, let's say you want to link the position of the hand bone to the position of the ledge. The position of the hand bone will be located inside of the player's collision capsule or cause the capsule to hit a wall if moved. The only way I see of handling this, is offseting the model and just putting the capsule whereever until the animation is complete or letting the capsule intersect until the animation puts it in the correct place. It feels more like you're fiddling with the position of the capsule than just letting the animation handle it naturally.

Quote:

When you want to move your character using a ragdoll like physical representation you should consider the following issues: - performance: ragdoll physics is quite expensive compared to simpler representaitons, be careful if you plan to use many characters/npcs.

How many would you say is many? Also wouldn't

">Euphoria require everything to be constantly checked as a ragdoll? I should probably look into a game that uses if so.

I'm probably making a lot of unnecessary trouble for myself but powered ragdolls seems like the next way to go when it comes to the more interactive games. I really don't like dealing with offsets and disabling collisions : (

Quote:

Grabbing a ledge This one I'm much more interested in. When grabbing a ledge, let's say you want to link the position of the hand bone to the position of the ledge. The position of the hand bone will be located inside of the player's collision capsule or cause the capsule to hit a wall if moved. The only way I see of handling this, is offseting the model and just putting the capsule whereever until the animation is complete or letting the capsule intersect until the animation puts it in the correct place. It feels more like you're fiddling with the position of the capsule than just letting the animation handle it naturally.

Maybe you are just thinking too hard about this. Collision isn't some immutable thing. I've worked on games that defiantly had ledge grab, and defiantly used only two or three shapes per player character. I think the idea you are missing is "flags". Have a single capsule to do collisions with, but dozens of flags to indicate how it should react. The idea is that not all collisions are equal.

You can use bitflags (ie 32flags per int) to do filtering on your collisions. When you enter a ledge grab, your collision box gets the "collide with static geom" flag turned off so he doesn't depenetrate from the wall. Your ball example might be marked as "debris", and while "debris" can collide with static geometry, it can't collide with "players". Bullets might collide with "static geom" and "damageable". Collisions could be one way. Ie, debris can be pushed by player, but player's aren't impeded by debris. Collisions might not have a reaction. Usually called a "Trigger", a no-reaction collision can detect when a player, or item has entered a particular area like a button, level ending, or teleporter.

Lets say you do want the ball to collide with players. You could also filter out specific object. The ball can't collide with "previous owner" unless it has first left its owner's collision shape.

Quote:

I'm still having trouble seeing how animation does everything.

Design. Usually the game worlds are created with specific constraints. All grabable ledges are flaged. All pushable objects are atleast X meters tall. The animators animate with the object in question, and it is always placed the same way thoughout the game so it lines up. You mention "I want to be able to link a characters hand to a ledge and not have to worry about how the animation lines up", but unfortunatly that is the simplest thing to do. You put some markers in the animation, and just poll them to place the character exactly where they need to be in relation to other objects in the animation.

Quote:

Original post by AntiGuy Grabbing a ledge This one I'm much more interested in. When grabbing a ledge, let's say you want to link the position of the hand bone to the position of the ledge. The position of the hand bone will be located inside of the player's collision capsule or cause the capsule to hit a wall if moved. The only way I see of handling this, is offseting the model and just putting the capsule whereever until the animation is complete or letting the capsule intersect until the animation puts it in the correct place. It feels more like you're fiddling with the position of the capsule than just letting the animation handle it naturally.

Take a look at valves publications over here. In "The AI Systems of Left 4 Dead" (2009) ledge grabbing in L4D is explained.

Quote:

Original post by AntiGuy I'm probably making a lot of unnecessary trouble for myself but powered ragdolls seems like the next way to go when it comes to the more interactive games. I really don't like dealing with offsets and disabling collisions : (

I don't know if this is the next big thing. Take a look at movies, almost 100 years of movie history and still everything is just faked for a single shot or take a look at game ai. CPU power has been increased by a major factor the last 15 years, but NPC ai is still "dumb". There're still other parts in which games are years away from a realistic solution and have to use fake techniques (i.e. global illumination).

My credo: KISS, keep it simple and stupid :-) Complexity don't need an invitation and will come over time.

Quote:

Original post by KulSeran You can use bitflags (ie 32flags per int) to do filtering on your collisions. When you enter a ledge grab, your collision box gets the "collide with static geom" flag turned off so he doesn't depenetrate from the wall.

I know how to disable geometry, the problem is I don't want to. If your object is intersecting something at the time you turn the "flag" back on, bad things happen. To ensure you enable the geometry at the right time involves a few checks I'd rather avoid. I do like this idea more than using an offset though which is what I mean't as offseting the model from the collision shape.

Quote:

Original post by Ashaman73 Take a look at valves publications over here. In "The AI Systems of Left 4 Dead" (2009) ledge grabbing in L4D is explained.

Awww that only goes through the AI involved in ledge grabbing. Which I find oddly find to be bit overcomplicated on their part. : )

Quote:

Original post by Ashaman73 I don't know if this is the next big thing. Take a look at movies, almost 100 years of movie history and still everything is just faked for a single shot or take a look at game ai. CPU power has been increased by a major factor the last 15 years, but NPC ai is still "dumb". There're still other parts in which games are years away from a realistic solution and have to use fake techniques (i.e. global illumination). My credo: KISS, keep it simple and stupid :-) Complexity don't need an invitation and will come over time.

I don't see myself as a pioneer or anything close to one, but when something doesn't really sound all that complex and seems like a logical way to go in terms of what you want to do, I think it's fair to give it a try! The less dependent on animations, the better (for what I'm working with at least).

Quote:

Original post by AntiGuy I don't see myself as a pioneer or anything close to one, but when something doesn't really sound all that complex and seems like a logical way to go in terms of what you want to do, I think it's fair to give it a try! The less dependent on animations, the better (for what I'm working with at least).

You should take a look at procedural animation systems too. Chris Hecker talks about the procedural animation systems in spore. The basic idea is to use a simple particle physics simulation to readjust the animation to external targets. I.e. while walking (all feet on ground), you want to grab a box and look at an approaching enemy. With ragdoll phyics all limbs interact with the world, the pure animation approach is to determine few important positions (hand must move to position of box, feet must be at ground level, head must point in direction of enemy) and readjust the skeleton to fit these requirements.

Well I actually tried it (sorta) and I didn't get very far. My first test was trying out 150 capsules (10 characters) out and I also tried checking contacts for 10 capsules 15x. The results where a bit too slow for my uses. Some optimizations come to mind but in the end I wouldn't up up with something much different that that 1 fat capsule itself.

In summary, you've convinced me, it's a bad idea (right now at least). On the other hand if you're doing some sort of Wrestling game.......