Need suggestions for hover craft type functionality...

[BrianL]

I was planning on using Forces for this, but they are currently out of commission. I'm completely new to the BEPU system (which is great by the way). With that being said, I'm currently running tests with Entity.applyImpulse. I'm using a simple cube as the Entity and a custom mesh for a StaticTriangleGroup to represent the hard limits for my "world".

I'm getting too much uncontrolled spinning with the cube. I can dampen that down by setting the angularDamping to something reasonable. I've also played with the UprightConstraint class as well, to try and limit the cube's tendency to want to spin unconrtollably when the force gets too high and to try to keep it "upright". Maybe that's the problem? The rate at which I'm ramping up the force? Maybe a more true to life compound entity that's more representative of a "craft" of "ship" would help?

I guess what I'd really like to be able to do is hard constrain the maximum local limits of rotation. If that's not possible maybe some kind of blunt force? Not sure why the cube wants to spin so badly.

Thanks!

[Norbo]

You could probably still use forces, but they would require removal and re-adding rather than just deactivation, which is a bit of a hassle.

The first version of the vehicle system was very close to a hovercraft, and was built using applyImpulse. With the early versions of the 'wheels,' which at the time were simply raycast suspension with no horizontal friction, the car body would stay afloat and bob around. I consider the suspension a spring with forces based on compression detected by the raycasts. With four of these placed at the corners, the 'car' body was pretty stable and didn't immediately necessitate an upright constraint, though I do use one just to keep things from flipping over too often in the demos.

Creating a more 'hovercrafty' body shape will help with the stability as well, as the shape determines the inertia tensor (though you can modify the tensor separately).

There is no cone constraint at the moment that supports hard limits; the upright constraint just uses the soft position correction boundary without involving the velocity solver as you've probably noticed.

[BrianL]

Thanks for the quick reply. I'll look more closely at the Vehicle class. Is it possible to create and run a vehicle with no wheels? Or is the idea to use "wheels" for physics but just don't visualize or draw them?

[Norbo]

It would be possible to give a vehicle wheels very low friction values (perhaps even zero, relying only upon its suspension) and have a sort of hovercraft, yes. You could then control it arbitrarily with other control impulses for scooting it around. Hiding the wheels would give the effect of a hovercraft.

Alternatively, you could do it directly by implementing a simplified system of raycasting downwards from 'wheels' and finding supporting entities. Then you could just apply the spring compression forces directly without using the vehicle class. This would require keeping track of the 'wheel' locations and raycasting directions.

Either way works, but there'd probably be a bit less work involved in just using the vehicle.

[monty123]

Hello,
I'm also trying to create a hovercraft type vehicle, this is a fictional vehicle similar to the ones from games such as Hioctane and Wipeout. I have stored 4 corner positions and using a raycast have the 4 corresponding hit positions on the staticTriangleGroup. I'm not sure whether I'm using the correct spring formula or applying the resulting force correctly to the box entity, at the moment it behaves in an erratic fashion (http://www.youtube.com/watch?v=rrrrmwqTTno); essentially the 4 springs should act as a pseudo gravity to keep the vehicle a preset distance from the ground , the vehicle will never need to flip over (should only move the ship on the Y axis).

I currently get the distance between the corner point and hit point
minus the presetHoverHeight from this
multiply the resulting value by a constant float value
Then return a minus result of this value (I call this springForce). I then use ship.applyforce(cornerPosition, Vector.down * springForce) for each corner position. At the beginning of the next update i call the clearForces() method and then repeat the above.

Any help will be appreciated, Thanks.

[doggan]

Following the algorithm you supplied, it seems that your impulse direction is opposite.

For example, if your corner point is ABOVE your spring equilibrium point, you would want to apply an impulse downwards to return to equilibrium. You should either apply the force in the Vector3.Up direction, or don't negate your springforce.

[Norbo]

Additionally, it may simplify things a bit if you use impulses. Instead of applyForce, you could use applyImpulse in a similar way. The impulse magnitude would then end up being the springForce * dt and you wouldn't have to deal with clearing out forces later.

[monty123]

Thanks for the suggestions, it was easier to use impulses. It turned out that the problem was caused by passing the wrong hit location to the spring formula for the other 3 corners.