BEPUphysics

So... I've got 2 questions.

The first: I have a spherical detector volume at the end of my level, when I hit that volume, I want my player (also a sphere) to be tethered to the middle of that volume. Since the volume isn't an entity, I can't do a normal entity-entity DistanceLimit. How difficult would it be to write a SingleEntityConstraint to act as a Entity<->Point max distance constraint? Barring that, I could obviously stick a Kinematic entity in the middle, but then the player would collide with that, so if I went that route, how would I keep the player from colliding with the proxy entity.

The second question: I've mostly finished porting my game over from JigLibX, but one of my last issues is a raycasting problem. I was shooting a ray from my player towards the camera, and dropping the camera in front of anything the camera collided with. JigLibX allowed me to pass a delegate into the raycast so I could ignore the player object. In BEPU I'm having problems with the raycast detecting the player, and dropping the camera inside him. The player is a sphere primitive, so I tried reducing the ray's length to camera distance - radius (and event toyed around with max radius, margins, and an arbitrary padding) and in some cases, such as the ball rolling towards the camera, I would still "catch" the ball in the ray. Is there anyway to ignore the ball while raycasting?
I also tried using the hitEntities raycast, and hitLocations had 3 entries (player sphere, and 2 wall trianglemeshes), but hitEntities had 1 valid entry (player sphere) and dozens of null entries. So I couldn't ignore the player object that way, unless I tested every hit location to see which object it lived in, which seems like a huge performance hit.

Currently I'm using the single hitEntity raycast, and ignoring it if the player is the entity. This isn't perfect however, in that if the player is touching a wall and the camera is between them, it has the potential to detect the player and use the "i'm not colliding with anything" logic.

For the first question, you can use a DistanceLimit with only one entity by passing null in for the other connection. That connects it to a special "world" entity (Constraint.WorldEntity). This is similar to attaching it to a kinematic entity, except the WorldEntity doesn't belong to any space and so cannot collide.

To use a kinematic entity, you could change how it interacts with other entities (disabling collision, for example) by changing its collision rules. Check the collision rules documentation for more information: http://www.bepu-games.com/BEPUphysics/d ... tation.pdf

For the second issue, the demo Camera class has a chase mode that does this. It uses the multi-hit version of the raycast and filters the results. When you use the multi-hit version, be sure you're passing in clean lists. The method will add the results to the lists. The 'null' entries in the entity list occur when a non-entity shape is hit, like the StaticTriangleGroup. There should be an equal number of entries in each list, corresponding to unique hits.

v0.15.0 is going to clean up the method signatures a bit and have a convenience method for filtering as well.

For the First problem, I had tried passing in DistanceLimit.WorldEntity for the second entity, does that differ from passing in null? I was still getting strange behaviour, but if I was doing it properly it might just be a matter of tweaking my parameters.

-- Just tried some new values, realized I had some bogus data going on, does this look right? For the Second problem, it hadn't occurred to me that all I really needed was the hit location, so it didn't matter that I had null entities (once I filter the player entity).
Is the hitLocation list sorted in any particular order?

In that code, the same tether point is supplied for both entities. I assume tetherPoint is the location you want to be in the center of the sphere. If that's the case, then pass in tetherPoint as the location for the 'null' connection, and some location on the other connected entity (maybe center position).

Is the hitLocation list sorted in any particular order?

The only guaranteed ordering is that index Z in the hitLocations list corresponds to index Z in the other lists. Each ray hit entry spread over the current lists is going to be bundled into a single struct in the next version.

I want my player's center point to be tethered to my volume's center point, so for the sake of our argument, would this be more accurate:

Yep, that should do it.