First person camera is sticking to other static objects

[Spankenstein]

I've added an Entity to my camera like so:

Code: Select all

            Entity e = new Box(freeLookCamera.Position, 2, 2, 2, 1);
            e.IsAffectedByGravity = false;

            // Prevent the entity from rotating by setting it inverse inertia tensor to zero
            Matrix m = new Matrix();
            e.LocalInertiaTensorInverse = m;

            freeLookCamera.Entity = e;

            space.Add(freeLookCamera.Entity);

The problem is that the camera will stick to objects and teleport randomly.

I'm updating the velocity for the camera's entity as follows:

Code: Select all

            Vector3 velocity = speed * direction;

            if (entity != null)
            {
                //entity.LinearVelocity = velocity;
                entity.InternalLinearVelocity = velocity;
                position = entity.InternalCenterPosition;
            }

The collision detection is using swept tests:

Code: Select all

space.SimulationSettings.CollisionDetection.CollisionDetectionType = CollisionDetectionType.LinearContinuous;

What is going on?

[Norbo]

What type of object is it colliding against when those issues occur, and how big is it? My first guess, like usual, is numerical issues.Simply setting velocity is a very safe way to move objects around, so you shouldn't be seeing any jumpiness/teleporting/sticking.

Any additional information you could provide about the specific way it moves would help too. Is the sticking preventing you from sliding, or is it keeping you from moving away from the object? Or is it every once in a while 'hitching' momentarily on a mesh edge or other near-collisions? If it's the last one, it's probably related to CCD being on (with entity dimensions being a possible core cause).

[Spankenstein]

I'm colliding against triangle entities created from quadrangle faces:

Code: Select all

                    Matrix worldTransform = rotation;
                    worldTransform.M11 *= scale.X;
                    worldTransform.M12 *= scale.X;
                    worldTransform.M13 *= scale.X;
                    worldTransform.M21 *= scale.Y;
                    worldTransform.M22 *= scale.Y;
                    worldTransform.M23 *= scale.Y;
                    worldTransform.M41 = position.X;
                    worldTransform.M42 = position.Y;
                    worldTransform.M43 = position.Z;

                    Vector3 p0 = Vector3.Transform(corners[0], worldTransform);
                    Vector3 p1 = Vector3.Transform(corners[1], worldTransform);
                    Vector3 p2 = Vector3.Transform(corners[2], worldTransform);
                    Vector3 p3 = Vector3.Transform(corners[3], worldTransform);

                    // CCW Winding
                    triangles[0] = new Triangle(p0, p2, p1);
                    triangles[1] = new Triangle(p1, p2, p3);

                    recreateTriangles = false;

The two triangles form a wall from a quadrangle. Like so:



Each different texture has a quad that defines two triangle entities.

The sticking is preventing me from sliding. I am also 'hitching' momentarily on a mesh edge.

Leaving the collision detection as GJK doesn't stop the problems from occuring.

[Norbo]

Does the sticking happen anywhere but mesh edges (internal or otherwise)?

Those triangles look a little big (relative to what I assume is the box's size), but it should be well within numerically stable limits. If the issue only on mesh edges, this may just be a case of the box hitting the edges of the triangles. You can try setting the mesh's 'use triangle normals within angle' property to something higher, like Pi/2. This will force the system to use the triangle normal as opposed to an edge normal more often (or always). v0.15.0 has some improvements coming to how mesh edges are handled, too.

[Spankenstein]

I've added the following two lines to the triangle creating routine:

Code: Select all

                    triangles[0].TryToUseFaceNormal = true;
                    triangles[0].UseFaceNormalWithinAngle = MathTools.PIOVER2;

                    triangles[1].TryToUseFaceNormal = true;
                    triangles[1].UseFaceNormalWithinAngle = MathTools.PIOVER2;

The unwanted teleporting has been eliminated as far as I can tell.

Does the sticking happen anywhere but mesh edges (internal or otherwise)?

The sticking only occurs at the mesh/triangle edges but it is still occurring even with the added changes.

Any other suggestions?

[Spankenstein]

If I take into account the 'DefaultMargin' when scaling the triangles then that helps:

Code: Select all

                    worldTransform.M11 *= scale.X - 0.05f;
                    worldTransform.M12 *= scale.X - 0.05f;
                    worldTransform.M13 *= scale.X - 0.05f;
                    worldTransform.M21 *= scale.Y - 0.05f;
                    worldTransform.M22 *= scale.Y - 0.05f;
                    worldTransform.M23 *= scale.Y - 0.05f;

but the horrible teleports haven't gone as I previously thought.

[Norbo]

Do both the sticking and teleporting occur under both DiscreteMPRGJK and LinearContinuous collision detection types?

-DiscreteMPRGJK should exhibit absolutely no 'jerks' in motion. Its position is fully determined by forces and velocities. You may still notice bumps on mesh-edge collisions, but they will not cause teleportations.
-LinearContinuous can exhibit 'jerks' occasionally. They take the form of an incomplete frame of motion due to the CCD detecting a collision somewhere in the swept path. If a contact point matching that swept path is not found, then the shape will continue on with the same velocity, creating a sometimes-noticeable 'jig' in the motion. At no point does it teleport backward, but it can appear to since the object fails to move fully in one frame. Mesh-edge collisions are otherwise identical to the DiscreteMPRGJK case.

In either case, there is never an actual teleportation. If you see it moving in a way that isn't according to its (CCD-modified) velocity, then something else is going on. Note that DiscreteGJK (without the MPR), a deprecated collision detection method, DOES perform teleportation occasionally- don't use it

Incorporating the margin like that into the scaling shouldn't do what you want. If the graphics don't already, I'd recommend rendering the collision triangles to see what they look like. You may also want to draw the contact points and their normals whenever you hit a mesh edge to see what they look like, and to see if they explain the motion you're experiencing.

[Spankenstein]

I've solved the teleporting completely now, I promise. It was my fault by not resetting the velocity to 0 each frame when a key wasn't pressed....yes I'm an idiot.

You are absolutely right. The triangles vertices are inset slightly from the quad:


However, the camera will 'hitch'/stick to the triangle edges if they are located in the same place occupied by another triangle edge that is at an angle of 90 degrees. In other words if I don't use the offset/inset then sticking occurs.

Do both the sticking and teleporting occur under both DiscreteMPRGJK and LinearContinuous collision detection types?

The sticking occurs using both DiscreteMPRGJK and LinearContinuous collision detection.

Why would sticking occur if two triangle edges share the exact same location?

[Norbo]

One possibility is that as a box slides along a wall out towards a convex corner, it hits the 'inside' of the perpendicular face behind the wall:

edgehit.jpg (30.58 KiB) Viewed 7855 times

There's no great solution to this issue currently. One option is to fatten up the shape's margin a bit more so that when it inevitably does collide, it has a smoother normal. The 'use triangle normal' feature may actually exacerbate this problem, because it will force normals created against the perpendicular face to oppose the motion directly. You could try tuning the angle until the problem is minimized.

Having the gap 'fixes' this problem too, since it is much more difficult to hit the perpendicular triangle.

v0.15.0 is going to address these problems properly by incorporating one sided triangles, more robust triangle-related tests, and a mesh-edge collision pruner.

[Spankenstein]

v0.15.0 is going to address these problems properly by incorporating one sided triangles, more robust triangle-related tests, and a mesh-edge collision pruner.

Excellent, looking forward to it all the more now

Thanks for the help.