BEPUphysics

I forgot to mention that when you give a list of points to a ConvexHull constructor, Toolbox.getConvexHull is called internally so you don't need to do it before you pass in a point list.

You could try to use the Entity.getExtremePoint function in some arbitrary direction (up?) and compare the extreme point to the center of the hull. The offset can then be used to position your model since you know where the extreme point of the convex hull should be on the model. The missing mirrors...

It looks like the origin of your model is offset from the center of mass of the convex hull. Applying a base transformation that scoots the model down before applying the rotation and translation of the entity should do the trick. It'll require a bit of tweaking since it's not immediately obvious wh...

Does the latest PhysicsThread project I posted behave the same way when you deploy it with no modifications? Currently, all I observe is a pretty regular slowdown during intense interaction (when the box count is around 100) when deployed. Hopefully we can establish a control group of some kind.

A static entity should work exactly as you want. If collision handling is important, you will still have to move the entity with velocities rather than entity.move/moveTo. Since move/moveTo teleports the object, the velocity remains unchanged. Entities respond to collisions based on velocities and t...

Are those .7 outputs from near the shutdown of the program? I noticed some very large numbers near the end during my testing that didn't line up with how the program was running normally. I recommend also setting your thread's processor affinity if you haven't yet. That may help quite a bit. I've at...

I would recommend creating a custom content processor to extract the vertex positions from the model and giving that position list to the ConvexHull. A sample content processor can be found in the picking example on the Creators Club website: http://creators.xna.com/en-US/sample/pickingtriangle. If,...

Changing the name to something besides BEPUPhysics should fix that issue. It seems it is getting confused and looking into your similarly named assembly for BEPUphysics types. I changed it to BEPUPhysicsTest in the assembly name field of the project properties and it works.

The easiest way to constrain the joint in the way you want is to fake it. Applying a corrective force based on the distance of the entity from the desired Z plane would work. Similarly, checking the angle of entities to the starting connection of the joint would give you a way to push things down if...

Everything on the code side looks fine; this is likely caused something in the project set up but I'm not sure what. Posting the test project might help me locate the issue.

Having both XNA GS 3.0 and 2.0 shouldn't pose any problems; I have both currently installed to no ill effect. I don't know of any reasons off the top of my head why it's giving you that error right now, though. One of the StaticTriangleGroup initializeData method takes a Model. The Model can be load...

1) This is on the to-do list. 2) This has been added to the to-do list. 3) This is primarily because the StaticTriangleGroup does not have the same abilities as its Entity-based brethren. I didn't want to establish a link between the expected functionality of a physical entity (or some additional su...

I am unable to replicate the issue using the XNA 2.0 .dll on the website and a XNA 2.0 project. Have you tried upgrading the project to XNA 3.0 and using the XNA 3.0 BEPUphysics.dll?

That is indeed a bug and is fixed in the next version.

The most straightforward solution is to raycast against each individual StaticTriangleGroup and then pick the group with the smallest time of impact. This is essentially what the Space.rayCast does for the one-hit version of the method. I'm not a real big fan of the way I've got the rayCast system s...