Questions about hovering on a mesh

[krwhite]

Hi. I'm a new user to the forum. I'm incredibly impressed with this engine! Most of the documentation seems very clear and understandable. This is very new to me though, and I'm having trouble trying to figure out how to do 'exactly' what I want..

Let me explain my problem. I basically have a large triangle mesh that my objects ride on top of. The problem I'm having is that I would rather not interact physically with this mesh, but more or less be constrained to it while other objects on the mesh can perform collisions and such.

I don't want to do anything against physics engine karma or anything and manipulate object positions per frame (as the wiki suggests). It would seem wrong of me to have bullet not to be aware of this surface as well. I would think some internal class variables would end up messing up upon simply 'snapping' to coordinates.

Ideally, I would like riding object's up vector to be pretty much like the current mesh triangle's up vector without getting struck down by any physics gods.

Any recommendations? Thanks for reading, and keep up the great work. This is an unbelievable library.

Kyle White

[devmelon]

We solved a similar problem like this through a simple raytest. The object that should levitate cast one (or several) rays downward to see if it intersects with the level. If it does, it calculates the distance and applies a force relative to that distance to give it a "hovery" feeling. This raytest is actually a test with a finite ray, a line with start and end points.

I doubt you'll find built-in mechanics for such features in physics engines as your (and our) problems are quite specific.

Another solution you could do is wrap your object inside a bigger, non-colliding, extruded shape. If the ground intersects with it, apply neccessary forces to the wrapped object to keep it hovering.

Tip:
Don't get tied up NOT coding just because functionality x isn't natively supported. If you do that, you'll never complete anything. Refactor your old code when/if you find a better solution.

[Oscar Civit Flores]

Definitely, manipulating object positions directly sounds dangerous. You can easily end up adding energy to the system and make thinks jitter or explode.

From a theoretical prespective, what you are trying to do, if I understand it correctly, is adding an "ObjectOnSurface" constraint to all objects. In order to work seamlessly with Bullet or any other impulse-based physics engine, this new constraint should be solved together with collisions and joints. The constraint error stabilization factor (Baumagarte) would act as the "raycast plus penalty force" solution that devmelon suggests, but with the advantage that the velocity correction step (collision+joints) would be aware of the constraint and give an overall better solution.

I'm not very familiar with Bullet's source but a glimpse at the code architecture shows that adding a new constraint type is a "local" change, and, thus, should not be very difficult to integrate. Maybe you can give it a try

As far as I understand, the ObjectOnSurface constraint would be quite similar to the existing btContactConstraint but acting as an equality constraint, so displacements away from the surface are are forbidden in both directions, Normal and -Normal. In addition, you'd need a way to compute the surface Normal at each point of an object that you want to constrain to the surface. You can raycast and use the face-normals of your mesh or interpolate them across edges/vertices when the point is near them to ensure a smoother behaviour.

Well... this was just my speculations... Good luck if you try