Sorry your browser is not supported!

Edit: Solution lower down ...

I'm trying to push a character controller with a kinematic object. Here's an idea of what's going on ...



The portion highlighted in blue is a kinematic compound actor made of boxes. When my character cuts the laser beams, the walls come in and crush together. When I drop some cubes in there, they're pushed correctly, but the character controller is not.

I'm assuming this isn't a bug, and is just the nature of character controllers, since they're moved manually with the dynControllerMove() and aren't supposed to be bullied around by physics objects. However, in this situation, I want my character controlled to be squashed to death and meet a sticky end.

He does collide with the kinematic walls. If I run along when they're not moving, he slides correctly. However when they move, they can move though each other.

Trying to think of a good way to resolve this issue. I was thinking about getting the world collision normal, and then projecting the character away along that normal, by the component of the speed of the crusher wall that is in that direction (if that makes sense). Not entirely sure about the maths for that one, or is there perhaps a better solution? I'm guessing there has to be otherwise things like moving platforms etc. would be hard to simulate.

You are correct that this is just a quirk of character controllers, their movement is controlled mainly by you and not the physics world, although their movement can be blocked they can not be pushed around without you defining that movement.

I thought about this a while ago as it would be a common problem with character controllers jumping onto moving platforms or lifts etc

I think one solution would be to collect collisions between controllers and other kinematic actors, I hope that is possible, you may know better than me at this point

If the controller is touching a kinematic actor then you should add any change in position of the kinematic actor to your 'move' function for the controller. I think the controller would then 'stick' to kinematic objects but if they are not moving then nothing would be any different.

At some point I would like to produce an example of a controller on a moving platform, perhaps you will know if it's currently possible before I do If it's not possible then it should be and I will add whatever is necessary.

I'll let you know what I find out tomorrow Matty. Your solution would work fine for a platform that you stand on, for example. However, in my situation, it'd be possible to touch the wall on the opposite side to it's movement (so run behind it as it's moving away), at which point you'd get dragged along behind it which would be a bit weird.

This is what I'd expect to happen with a kinematic actor pushing a character controller:

- Black is the kinematic actor, moving in the direction it's pointing in
- Blue is the character controller
- Red is the normal for the World collision (I hope PhysX will return that as expected)
- Green is the distance the kinematic actor moved
- The blue line is the direction of travel I'd expect the character controller to take



I also just tested this by putting a coin on a glass table and pushing it along with the corner of a coaster. It pretty much moved in this way.

So I think the solution is:
- Check for collision between the character controller and shapes
- If the shape is a kinematic actor (I'm not at my work PC now, but not sure if there is a command for this. Is that available in PhysX?) ...
- Work out how long the blue vector should be for the length of the green vector. I'm guessing there is probably some simple vector maths function for this. e.g. multiply the collision normal (red) by the kinematic movement (green). No idea. Something simple like that. Vector maths isn't my strong point!
- Move the character controller along the blue vector

I'll give that a try tomorrow. If it works, I'll post here.

is it not possible to disable the character controller while it is in contact with the kinematic?

This should allow it to be moved by other simulated objects...

if not, perhaps a feature request for DD ^^

@MrValentine. I don't think you can disable character controllers. They're not the type of object you set up, then switch to character controller mode. Their entire setup is different. You probably could place a dummy object at the same place as the controller, then update the controllers position with it's movements, but that's quite cumbersome.

I've found a solution anyway with works for me:

- The object which is going to push the character controller has to be a normal dynamic actor. In my case, I've attached the moving wall to the route actor (0), which is the static scenery with a sliding joint.

- The wall won't push the character controller by it's own steam. Character controllers defeat all physics! You have to do this manually like so ...

1. Check to see if the controller hit the moving object
2. Get the velocity of the object and the collision normal
3. Find the Dot Product. If this is great than 0, our controller should be pushed
4. Work out the direction and distance to push the object
5. Reposition the character controller




Hopefully that'll be useful to some! (Remove the hyphens from the commands. They're to avoid TGCs language filter!)

This code will be really useful Fallout, I will try it out when I get some time.

I may be able to generalise it so all dynamic actors can affect the controller, if it works well then having an example included with Dynamix would be pretty useful for people I think.

Thanks Matty. Yes, it surprises me how limited character controllers are. It makes you wonder what the AAA titles have done to get Physx to do what they want it to do. I bet there are some cool ways to get it to behave, but we're just gonna have to find them out as we go.

Yes, I think I agree that they are limited in certain respects.

The PhysX docs say that the controller interactions are left to the programmer as different games will require different things.

I understand this to a point as when I made a puzzle game the characters moved blocks and it was important the blocks were only moved in certain ways which was left for me to define.

That said, I'm not sure if they are using that as an excuse as there are other ways of limiting how things move

Ok, having tested the above solution for a while, I can confirm it doesn't really work. The problem is that once the moving object collides with the character controller, internally it is likely to be stopped, and will never collide again.

E.g.
- Wall is moved with dynSetLinearVelocity() every loop, to ensure it's speed is constant and collisions don't affect it at all.
- When it first hits the character controller a collision is detected. You can then reposition the character controller using the method described above.
- At this point though, the internal system seems to stop the actor (reduce velocity to 0).
- Continuing to set the velocity every loop seems to have no effect. It's as if the engine detects the wall is touching the immovable character controller, and therefore ignores the velocity.

One solution is to set the character controller further away on each collision. This is more reliable, but causes a jumping stuttering effect as the controller jumps away from the moving object. It's still not reliable either. It's still possible for the object to touch the controller and the collision not to be detected and for it's speed to be set to 0, or for the collision to be detected but it's speed to be reported as 0.

It's starting to annoy me really! I would've thought it'd be a really common feature and would therefore be easy to implement with some provided functionality, but apparently not.

The only other solution I can think of is the following:
- Create a capsule object with a radius greater than the character controller
- Freeze all rotations
- Put it in it's own group and turn off collision with every other group, except your moving objects
- Ensure the character controller can't collide with it
- Set up contact reports between this capsule and the moving objects

Then ...
- Every loop, position the capsule on the character controller and set it's velocity to the character's velocity.
- Check for collision flags between the capsule and moving scenery
- If there is a collision, the capsule will have been moved automatically by the physics engine.
- Reset the character controller onto the capsule's position

That's the only solution I have left, and I really don't like it. I think it's horrible and messy.

I'm going to do a bit of googling and see if I can turn up something else and will report back.

I am currently working on something, if I get it finished in the next few hours I will have some time to look at this today.

Have you tried using 'drive' for the wall? I know setting velocities manually is not advisable, it is meant for setting up initial velocity only I think.

Is there any chance you could set up a really simple project with no media reproducing the issue. If not, this is the first thing I will do later so we are both working off the same code.

Googling about Matty, it seems everyone has this problem with PhysX. They're completely unsuitable for any scenario where they have to be moved by external forces. CCs seem to be an accessibility mechanism, to make it easy to get a character running about in a simple game. If you want to do anything complicated, you need to work with normal dynamic objects.

I read a few threads with people trying to use dynamic + cc combinations as I described above, but they all completely dropped the CC in the end and just went with the dynamic object by itself, so I think I'll go down that route.

What I'll do is make a capsule, turn off gravity for it (I think that's possible with a flag right?) and freeze all rotation. Then I can just move it around by setting velocities.

For climbing stairs, I think a good solution would be to hover the capsule above the ground with a raycast. I'll cast a ray downwards from the middle of the capsule and see how far it is away from the ground. By keeping it a minimum distance above the ground, it should avoid the bottom of the capsule getting stuck on stairs and other low obstacles. The hover height will determine how steep the slopes it can climb are.

I'll let you know how it pans out. Gonna have some lunch first.

There is a flag but there is also a command, I think it's dynSetGravity().

I may still give this problem a try later, it is possible that we could succeed where others have failed

If not, the dynamic character sounds useful if stairs can be handled well enough. I think getting it moving about without it feeling sluggish will be a challenge too, good luck