Physics Simulation Forum

I see... I'll take a look around there again. It seems a bit strange though to have an arbitrary limit at all, or is it for numerical stability, or some such? But thankfully the source is wide open, so it's easy to just change it at will

For sure they did! Unfortunately, bullet's classes and their behaviour aren't what you'd call "well documented".

You were right! The 6000 cap was indeed the culprit. After upping it a bit the suspension parameters started behaving like expected.

EDIT: perhaps that's another thing to note in your document

Now, I've tried my hand at the interpolation you posted. And there must be something wrong with... something. The result was much worse behaviour. Even more bumpy and jittery than before. I couldn't even manage to complete one curve on the track any more.

What I did I was overrode the vehicle raycaster class and also the call result class (to get to the shape part and triangle numbers, which the default implementation just throws away ). After observing the quite horrible behaviour, I traced out all the points and normals I got as input, and noticed that the hit point was actually outside the triangle! No wonder the barycentric and interpolation stuff went haywire...

On the other hand, since the behaviour got that much worse, I guess the resulting normal does play a big part in the behaviour of the suspension

I was thinking also, when overriding these things, it should also be possible to use a normal map and return a normal from that... a bit more math required though. Anyone tried that?

It seems weird that you're getting coordinates outside the triangle. I'm using btBvhTriangleMesh shape, and I get valid positions.



I haven't tried it, but you should be able to work out the UV coordinates and tangent space from the barycentric coordinates, and then transform into world space. The main advantage from modifying the normal is smoothing out the seams between triangle edges, so it'd only help that if your normals were continuous across edges.

It might be useful for an off-road game, or for when you drive outside the optimal parts of the track.

Same here, the collision shape is a btBvhTriangleMeshShape that I feed using a btTriangleIndexVertexArray from a custom source. That same custom source is used for lookup of the triangles in the ray caster.
Hmm.... now that I mention it, when rendering, I have to offset the visible mesh by -4.52 on the y-axis to make it match the collision shape - yup, a real wtf, and something I'll have to resolve, sooner or later. The same probably applies to the ray cast result! Didn't think of that, until now... I'll have to try that Maybe it would be more correct to use the btTriangleIndexVertexArray instead (for positions)...

Yup, that's something I'll have to do correctly as well... not yet complete. However, I was thinking if I add interpolation now when the normals are hard there should at least be no difference in behaviour

Yeah, I realise it's usefulness is quite limited and most probably not worth the effort

Nope. Indeed that class is only a thin wrapper for the arrays supplied in the constructor... Hmmm

Right.
I tried the same tweak on the ray cast result, and voilà: the interpolation works. And it rocks!
The diference is huge, goddamit! Why aren't normals, and their interpolation, supported by Bullet itself? Thanks for dropping the hint

I'm still no closer to the mystery why this offset hack is needed, however... it just shouldn't be...

Turns out that in the beginning of time I had put a +4.5 translation on the Y axis on the generated terrain shape (much later a mesh loaded from file) and then efficiently forgot about it.

Btw, I've the track mesh is now written with smooth normals all over (previously only some of them were), and I'll say it again: it rocks! The difference is considerably not insignificant!

I vote for normal smoothing to be added to Bullet's btRaycastVehicle by default!
(collision shapes need to support normals then also of course).

It's good to hear that it's working!

Adding it by default to Bullet probably requires some quite invasive changes. It's quite a bit of work just for vehicle simulation. I think you'd only want to add it to the 'mesh' shapes: the bvh tri mesh shape, and the heightfield terrain shape.

Yeah, and it's probably only useful for ray cast vehicle-type things.

Btw, I created an enhancement "issue" for having support for normals in the collision shape(s).

I'm trying to create realistic simulations of very large and heavy vehicles - bulldozers, dump trucks, etc. Masses of 35 000 kg or so. I've had to bump up the max suspension force, and I've got a couple questions.
A) are there any repercussion for bumping this limit way higher?
B) are there any other limits I might run into?
thanks.....

How do you determine which vertices to use?
I assume the data must be somewhere in either the btRigidBody or the btVehicleRaycasterResult ?

castRay performs a ray-cast, which returns the triangle index, part id, collision object, and hit position of the end of the ray.

You can use the triangle index to work out which vertices form the hit triangle.

Generally, since the vehicles are heavy & slow-moving, perhaps you'll get better result using rigid body wheels instead of ray cast.
In my own experiments, rigid body wheels have quite big advantages over raycast in terms of being realistic. But since things usually breaks apart physics-wise at high speed (rotations) and require more processing power, raycast usually is better suited for racing-type games... But your choice of vehicles implies that this is not racing