EntityMover

[Garold]

Hi,

I am trying to allow the player to buy a weapon from the wall inside a moving helicopter.

My solution is to create a dynamic sphere for each weapon. I then cast a ray and see if there's a collision. I use entitymover to keep the sphere relative to the helicopter body. I use a matrix.createtranslation for the sphere offset which I multiply by the helicopter's worldtransform. This is almost working The spheres are located roughly where they should be; however they drift, depending on how fast the helicopter is moving. Also the cast does not match up with the debug model drawn. As the helicopter slows down the accuracy is improved. I've set the basecorrectivespeed of the servo to a high value and this has "locked" the spheres to the body, but there's still drift and an inaccurate raycast.

I have a small video here where you can see it in action. You'll notice that when the player points at a sphere a message is displayed "Press and hold A for weapon". You'll notice it's displayed when not pointing directly at the sphere, I presume this is where the sphere was at the time of the raycast, and the modeldrawer is lagging behind. You'll also notice as the helicopter slows down to allow the player to disembark, the accuracy improves.

As always any help or suggestions would be greatly appreciated.

http://www.youtube.com/watch?v=EkFA7dzM ... e=youtu.be

[Norbo]

As long as the EntityMover's target is a frame behind, it will drift. To see how this happens, consider the update order:

1) Update EntityMover target. Follower at position a0, target at position b0; set follower's goal to b0.
Space Update
{
2) Update velocity of following object using EntityMover's goal.
3) Update positions of entities according to velocities. Follower achieved goal b0, but target is now at position b1.
}

The faster the target is moving, the larger the displacement will be between b0 and b1.

To avoid this, you could target the position where the target is going to be (b1), rather than where it is now (b0). This only works in cases where the motion is completely predictable, though.

You could also use teleportation to avoid the complexity of EntityMovers, but of course then you import all the complexities associated with teleportation. In addition, you would still have to be careful about velocities to ensure that the bounding box includes the full range of motion so that the ray can still find it in the acceleration structure. If the entity is teleported but the acceleration structure does not match, then the ray cast will fail.

A more physically 'correct' approach would be to use two-body constraints between the helicopter and the object connected to it. Then, you don't have to manage the relative motion at all; it would be handled transparently through the solver.

(Also, the video is private so I cannot view it, but I'm reasonably sure the above covers it )

[Garold]

I have changed the status of the video to "public".

I will investigate your suggestion of using "two body constraints". Is there an example within the demos that I should have a look at?

[Norbo]

Any of the constraint-related demos would be at least tangentially related. Some simple ones include the MultiPendulumDemo, MoreConstraintsTestDemo, and the ActionFigureDemo. More complex options include the SawContraptionDemo, DogbotDemo, and ragdoll demo (separate documentation project). There's quite a few more in there, too.

[Garold]

I've done as you've suggested: adding a joint and an angular motor. This has cured the drift problem, thanks!

Code: Select all

            _sm.Space.Add(new BallSocketJoint(_sm.AIHelicopter.Body, Shape, Shape.Position + new Vector3(0, 0.2f, 0)));
            //Angular motors can be used to simulate friction when their goal velocity is 0.
            angularMotor = new AngularMotor(_sm.AIHelicopter.Body, Shape);
            angularMotor.Settings.MaximumForce = 350; //The maximum force of 'friction' in this joint.
            _sm.Space.Add(angularMotor);

However, I'm still left with the inaccurate ray-cast. Any ideas?

Here's a video showing the latest issue.

http://www.youtube.com/watch?v=K3Y3gUWI ... e=youtu.be

[Peter Prins]

Could it be that the position and direction of the ray you are using are derived from interpolated states, rather than the internal transformations?

[Garold]

I get you. You are saying it may not be the target that is in error but the origin of the ray-cast. I will investigate that, thanks.

[Garold]

I was doing something wrong with my ray-cast, although I am not sure exactly why it's wrong.

I was creating the ray like this, using the camera position.

Code: Select all

                _ray.Position = _sm.Camera.Position;
                _ray.Direction = _sm.Camera.WorldMatrix.Forward;

I changed it to use the worldmatrix translation and now the ray-cast works fine. I presumed that it would contain the same value but obviously it does not.

Code: Select all

                _ray.Position = _sm.Camera.WorldMatrix.Translation;
                _ray.Direction = _sm.Camera.WorldMatrix.Forward;

So thank you.

I'll put up a video of it in action.

[Garold]

Here's a video of it all working.

http://youtu.be/wg8dz7hAjao

I've attached the target boxes to the helicopter using a BallSocketJoint and an AngularMotor for each box, which has cured the drift.
I now build the ray using camera.worldmatrix.translation instead of position, which has cured the ray cast.

Thank you very much for your help!

[Peter Prins]

You're welcome