Polyhedron vs. Polyhedron Broken?

Aug 26, 2010 at 7:59 AM
Edited Aug 28, 2010 at 1:12 PM

I was just running the demo and I noticed the Polyhedron vs. Polyhedron collision appears to be broken.

 

Reproduction Steps

1. Run the Holodeck demo.

2. Press "7" to swap to scenes.

3. Change the velocity to something non-zero, 10 is good.

4. Fly the camera over towards the Cone and Cylinder sitting next to the monkey head.

5. Fire at the mid-section of the cone or cylinder and the box will pass through.

 

Collision with the top and the bottom of the cylinder seems to work but not around the sides. Collision works fine for primitives like spheres and capsules but doesn't work for any Polyhedra (small_cube, obelisk, triangle, lblock).

 

I'll look into it myself when I get a chance.

 

UPDATE: I've also started using polyhedrons as temporary cuboid replacement functionality until I get a chance to implement cuboids. However in doing so I have used polyhedra as simple cuboid platforms and dropped smaller cubes (also polyhedrons) onto the platform. Strangely enough friction doesn't work along the Z-axis, so the cubes just keep sliding until they fall off the platform. However if the cubes are knocked along the X-axis friction seems to work perfectly.

I also noticed that collision between a Sphere and a Polyhedron has issues as well. If I try roll a ball along a perfectly flat surface created from a polyhedron (such as the platforms mentioned above) the sphere will bounce (quite high) at random points if the ball picks up too much speed, perhaps the torque is the issue?

Coordinator
Aug 31, 2010 at 1:23 AM

I think this might have been a problem with poly-mesh collisions that I fixed before. Unfortunately, I can't remember now what I did to fix it, and a diff wasn't immediately enlightening. So I put out a release here with my current snapshot:

http://henge3d.codeplex.com/releases/view/51500

Let me know whether this fixes the issue you were seeing with the poly / cone or poly / cylinder collisions. 

I'll try to find some time to look into the other stuff. I haven't worked with XNA much recently.

Aug 31, 2010 at 1:54 PM
Edited Aug 31, 2010 at 1:55 PM

Thanks for that.

I was also confused as to why the diff was not showing any related changes, but I eventually worked out the issue. cone.fbx isn't just a cone model, it also contains the monkey head and the cylinder. So the problem was that the official release had the "Default Shape" parameter incorrectly set to "Polyhedron". I'm guessing at some stage cone.fbx did only consist of a cone and at that point it would have made sense. The version you just made available has the "Default Shape" correctly set to "Mesh". So the issue in the demo wasn't really a bug.

Unfortunately the polyhedron vs. polyhedron friction issue I am seeing still persists. When you have some free time, if you could look into it that would be great.

 

Thanks again.

Coordinator
Sep 1, 2010 at 7:53 PM

Good news; I found the issue with friction along the Z-axis. It turned out to be a simple typo, and I never noticed it because I've always used Z as the gravity axis.

Let me look over the rest of your questions, and I'll try to put out a September release soon.

Coordinator
Sep 1, 2010 at 8:41 PM

I'm still looking into sphere-polyhedron issues. I had run into some glitches there myself when testing the new singularity force against a giant sphere. Debugging collisions is really, really painful.

Coordinator
Sep 2, 2010 at 9:38 PM

Couple quick questions - can you give me a few more details on the Volume property you added? Specifically, how are you computing the volume for the poly and mesh types? Is it similar to the logic in MassProperties.FromTriMesh?

I was thinking about the best way to integrate support for specifying a desired mass instead of a desired density and was thinking about adding more static methods to the MassProperties struct to accomplish that. I'm wondering if that would enable your scenario. I could actually store the volume in the MassProperties struct along with the other stuff, so it wouldn't need to be re-computed later. Unfortunately, that would only give volume at the body level, not the part level, since only the aggregated mass properties are stored.

Oh, also, I'm working on fixing one sphere-poly collision problem now, but I'll probably need to come back and verify whether or not it's the same problem you're seeing. I believe my collision logic was flawed for that scenario so I'll be refactoring it. Were you seeing the strange bouncing behavior with sphere-mesh collisions as well, or just sphere-poly?

 

Sep 3, 2010 at 2:05 AM
nedry wrote:

Couple quick questions - can you give me a few more details on the Volume property you added? Specifically, how are you computing the volume for the poly and mesh types? Is it similar to the logic in MassProperties.FromTriMesh?

I was thinking about the best way to integrate support for specifying a desired mass instead of a desired density and was thinking about adding more static methods to the MassProperties struct to accomplish that. I'm wondering if that would enable your scenario. I could actually store the volume in the MassProperties struct along with the other stuff, so it wouldn't need to be re-computed later. Unfortunately, that would only give volume at the body level, not the part level, since only the aggregated mass properties are stored.

 For consistency I calculated the volume the same way as it's done by the static MassProperties methods.

 

Adding the ability to update the mass via the MassProperties struct would work perfectly for my situation.

nedry wrote:

Oh, also, I'm working on fixing one sphere-poly collision problem now, but I'll probably need to come back and verify whether or not it's the same problem you're seeing. I believe my collision logic was flawed for that scenario so I'll be refactoring it. Were you seeing the strange bouncing behavior with sphere-mesh collisions as well, or just sphere-poly?

I didn't have a completely flat mesh to test on so I tried with a tube. It didn't appear to be happening but it wasn't the most scientific test ever

I'm not sure that the issue is explicitly collision related because it seems to happen when I apply torque to a ball. The more torque I apply the higher the ball jumps into the air. It's as if instead of skidding (rotating on the spot) the solver is conserving the energy and applying an upwards force instead. The upwards force is actually quite large and a torque of 10 * mass will send the ball a couple metres straight up in the air and the ball will only move a couple of centimetres horizontally.

Coordinator
Sep 14, 2010 at 6:31 PM

Any chance you can set up a quick repro for me that I can paste into Holodeck.cs? If it's not collision-related, I'm wondering if we'll get the same effect with a ball on a simple plane.

 

Sep 19, 2010 at 9:47 AM

Sorry I've been away for the last few days. I'm back now so I'll try get a reproduction case to you sometime tomorrow.

Sep 20, 2010 at 3:14 AM
Edited Sep 20, 2010 at 3:15 AM

It was a bit difficult to reproduce exactly what am seeing without making a lot of changes to the Holodeck demo. However, I was able to partially reproduce the behaviour I'm seeing and whilst I was doing it I've definitely come across some sort of sphere polyhedra collision issue. Replace one of the cases in Holodeck.CreateScene(int sceneNumber) with the following:

 

						var plank = new SolidThing(this, obeliskModel);
						plank.SetWorld(new Vector3(0.0f, 0.0f, 4.0f),
							Quaternion.CreateFromAxisAngle(Vector3.UnitY, MathHelper.ToRadians(15f)));
						MassProperties immovableMassProperties = new MassProperties(float.PositiveInfinity, Matrix.Identity);
						plank.MassProperties = immovableMassProperties;
						_physics.Add(plank);

						var sphere = new SolidThing(this, sphereModel);
						sphere.SetWorld(new Vector3(-4.9f, 0.0f, 9.0f), Quaternion.Identity);
						_physics.Add(sphere);

 

For this to work you also need to make a few minor changes to the Holodeck content project.

oblisk.fbx:

Elasticity = 0.5

Scale = 4

 

sphere.fbx:

Scale = 2

 

 

Looking at this the problem seems to be specifically related to the way in which elasticity is being handled. You can noticeably see that the sphere collides with an invisible portion of the obelisk. However, when you return the obelisk's elasticity back to 0 not only do the small vibrations disappear when rolling, the sphere begins colliding with the obelisk correctly (not hitting an invisible region).

 

I keep meaning to ask, as far as I can tell most physics libraries allow you to specify a coefficient for both static friction and kinetic friction of a material. Henge3D only has the one roughness, is there a particular reason why you have chosen this approach?

Coordinator
Sep 23, 2010 at 2:17 AM

Thanks, I'll check it out. Might be a little while since Civ5 came out...

I've also noticed some problems with spehre-poly collisions, which I think may be fixed in my test branch. I'll get those changes out to github soon.

I had originally tried for static vs. dynamic friction but I found it fairly difficult to integrate it properly with the accumulated impulses approach. It's been too long to remember exactly what the difficulties were. I just ended up falling back on the same approach as box2d (a simplified friction model). I'd be open to changing it if someone is able to tackle the math.

Coordinator
Oct 2, 2010 at 6:14 PM

I think the recent changes I made to sphere-poly collision may have corrected the issue you're seeing. At least, the repro you posted above seems to behave as I would expect now. 

I'm uploading a new release in a few minutes with that change and some of the other things you suggested. Let me know if you are still seeing the problem.