BEPUphysics

hi there,
fist of all you have done some awsome work! thank you for that cool peace of software! I'm happy I found it in the web.
Right now I am working on some kind of thirdperson-action-adventure-game (I will post some pics and other stuff here when we are done). And I think it comes along pretty good .
But now I have some problems handling the camera. We need to have an "intelligent" camera that is kind of interactiv. So you can change the distance and hight and stuff like that. But the camera should never be able to break-through any walls or other objects in the scene so you can see it from the inside (I'm sure you know what I mean).
I'm quite sure this is usually handled by casting a ray from the back of the character in the reverse direction. My first guess was to use your methode called testRay. Perhaps I don't handle it right or miss understood it. But it seems to me that I have to check the ray with every object in the scene, but that would really kill our performance. So is there a more performant way to do this? We tried some for our own but they are not getting along to good.
the next question is, whether there is a possibility to check if the character is airborn?
ok that's it so far. thanky alot!

greetz leon

For a third person camera, you can do something similar to the vehicle's camera. A raycast against the entire space (space.rayCast) is accelerated through various methods, so it will actually be pretty quick. An example of this is in the demos camera update method, in the if (isChaseCameraMode) block. As long as the origin of the ray stays within a physics body that doesn't leave your play area, your camera won't leave the play area either. Note that the vehicle's chase camera will sometimes let you see through the ground- this is just because the camera gets shoved up all the way against the triangle without any buffer. Keeping the camera a little bit away from the ray hit will keep the camera from letting you see outside of the map.

You could also use a 'thick' ray by using the Toolbox.areSweptObjectsColliding methods with a sphere or something as the cast shape. Since there isn't a built in space-wide convex cast, this would require collecting all candidates for the test with an intangible or detector object that roughly fits the area where your raycast is. The list of entities colliding with the detector object or entities with controllers with the intangible object is the list you test against. This method would keep the camera from going into insignificant cracks in geometry that could otherwise make your viewing angles awkward.

The character controller has a private field, 'isAirborne.' Making that public or adding an accessor for it would do the trick.

wow! thanks for the quick answer!!!
i will try this right now.
thanks a lot again!

Since there isn't a built in space-wide convex cast, this would require collecting all candidates for the test with an intangible or detector object that roughly fits the area where your raycast is.

Norbo - The Toolbox swept collision test functions require two entities. This is problematic for static geometry (StaticTriangleGroups). What would be the best way to do a swept sphere cast onto static geometry? I think the quoted text addresses this issue, but it's not quite clear - could you elaborate on this?

Since StaticTriangleGroup triangles 'come alive' when entities' bounding boxes approach, you can create and maintain the position of a ghost entity which somehow represents or contains the camera path. A big box would do the job. The now living triangles will be in the controllers list of the ghost entity. Grab the triangles from the controllers (they will be either colliderA or colliderB with the ghost entity as the opposing entity) and test against whatever shape you'd like.

You don't want your ghost entity to actually collide with anything, so you can set the Entity.isTangible to false (if you don't want contacts to be generated, which is probably the case for this ghost entity) or Entity.isDetector to true (if you do want contacts, but just no collision response). Since intangible objects will still generate controllers this setup will work; their controllers just won't be acted upon by the rest of the system.