New issue with gContactAddedCallback in Bullet 2.75

[sparkprime]

So you have bits of car that need to fall off? You could use the gimpact partid or an external list to map the triangles to individual pieces. The challenge would seem to be that you need to disable the triangles. I'm not sure whether that's even possible with a gimpact mesh.

I think the manual iteration approach you mention should work though, if you only need to iterate through a few things.


Erwin: using convex hulls is a nice solution but it puts pressure on the artists, no? You really need tools to build these things. Automatic splitting doesn't cut it. How did the GTA4 artists build up the cars? Did they have inhouse tools for it?

Interesting to hear how the GTA4 collisions worked. Deforming triangle meshes sounds like a lot less fun than deforming hulls I admit. How do you deform the hull? Intersect it with a new plane, defined by the collision normal and penetration? Presumably the graphics vertexes can be somehow distorted with the hull, but how?

[Erwin Coumans]

Erwin: using convex hulls is a nice solution but it puts pressure on the artists, no? You really need tools to build these things. Automatic splitting doesn't cut it. How did the GTA4 artists build up the cars? Did they have inhouse tools for it?

It is usually part of a game/movie artist job to create reasonable collision geometry.
As far as I remember they mainly used Maya, and have some plugins to assign collision shapes, supported with a convex decomposition utility (Ratcliff's like Bullet ConvexDecompositionUtility). This is not a big deal at all: there are not that many moving objects in a game that require accurate approximation of the concave surface. There are just a few dozen different vehicles, some even share the same collision bounds and a game is in production for a few years.

The same can be done with off-the-shelf Blender, without any modifications: you can add collision shapes and choose the collision bounds type. If they are in the same hierarchy, they automatically end up in a btCompoundShape. Approximating concave moving objects by compounds of convex shapes (box/sphere/convex hulls) is quite easy and the recommended way, not just for Bullet but for Havok and PhysX as well. The GIMPACT implementation is just not as good as a btCompoundShape with convex hulls.

sparkprime: what modeler/tools are you using? We could help making an easier workflow for you to create convex compounds. The new upcoming build-in Bullet binary file format should make it even more convenient.

Presumably the graphics vertexes can be somehow distorted with the hull, but how?

You simply move the vertices in the btConvexHullShape. Alternatively, use the btMultiSphereShape to approximate parts of your moving concave objects, you can change the radius and local position of each sphere on-the-fly. This is what we did in one of the games for motor bikes: while driving we lift up the spheres around the wheels, to avoid collisions against street curbs. When not driving we animated those spheres back (gradually) for more realistic collisions when falling down. Another benefit from using the btMultiSphereShape is that bigger radius gives a more rounded surface, that makes sliding against 'internal edges' smooth.

Cheers,
Erwin

[sparkprime]

Erwin: using convex hulls is a nice solution but it puts pressure on the artists, no? You really need tools to build these things. Automatic splitting doesn't cut it. How did the GTA4 artists build up the cars? Did they have inhouse tools for it?

It is usually part of a game/movie artist job to create reasonable collision geometry.
As far as I remember they mainly used Maya, and have some plugins to assign collision shapes, supported with a convex decomposition utility (Ratcliff's like Bullet ConvexDecompositionUtility). This is not a big deal at all: there are not that many moving objects in a game that require accurate approximation of the concave surface. There are just a few dozen different vehicles, some even share the same collision bounds and a game is in production for a few years.

I suppose a convex decomposition utility would work well as an offline tool -- something where you could inspect the output, tweak the original triangle mesh to try and avoid it making too much of a hash of it, and maybe even actively guiding the process by suggesting splits.

The same can be done with off-the-shelf Blender, without any modifications: you can add collision shapes and choose the collision bounds type. If they are in the same hierarchy, they automatically end up in a btCompoundShape. Approximating concave moving objects by compounds of convex shapes (box/sphere/convex hulls) is quite easy and the recommended way, not just for Bullet but for Havok and PhysX as well. The GIMPACT implementation is just not as good as a btCompoundShape with convex hulls.

I do actually use blender but not the physics aspects of it, as i have been using it just to create geometry for export. But there are also people using max that have to be considered too.

sparkprime: what modeler/tools are you using? We could help making an easier workflow for you to create convex compounds. The new upcoming build-in Bullet binary file format should make it even more convenient.

Personally I use blender as I'm a linux nut. I export ogre meshes for graphics and I have my own text (text<->binary conversion tools will happen eventually) collision file format that contains a set of primitives at various transforms and an optional triangle mesh. It also has mass and dynamic attributes, and material ids on all the triangles and primitives.

I usually code them either by hand for simple things, or for triangle meshes I export from the modeller in text and have a little script to put them into the right format after that. It's all very hacky. There is someone who has written an exporter from max into this collision format though, and I'd like to pursue that with blender as well. It sounds like blender would be the ideal match as it already contains representations of the bullet shapes so it'd be much easier just to dump them all out in my format.

Presumably the graphics vertexes can be somehow distorted with the hull, but how?

You simply move the vertices in the btConvexHullShape.

So the graphics vertexes are boned to follow the convex hull vertexes...

What if the collision occurs between two vertexes though, do you move them both in? What happens if a hull becomes concave?

edit: and how do you, starting from the information in the manifold, know which vertex(es) to move?

[Erwin Coumans]

Personally I use blender as I'm a linux nut. [...] so it'd be much easier just to dump them all out in my format.

It seems much easier if you simply read the data directly from the .blend file. Our new GameKit project does just that, including examples how to extract triangle meshes, packed texture images, skeletal animation, skinning, Bullet collision shapes, constraints from a .blend file and show them in Ogre and Irrlicht. Its bParse code is small, fast, cross-platform, 32/64bit compatible. Have you checked it?

What if the collision occurs between two vertexes though, do you move them both in? What happens if a hull becomes concave?

Interior vertices don't contribute to the support mapping, so they are effectively not used: the shape stays always convex.

edit: and how do you, starting from the information in the manifold, know which vertex(es) to move?

That is left as an exercise for the reader Seriously, I can ask the Rockstar GTA IV physics developers if they can explain how they did it (I simply forgot it), and give you a follow up later.
Erwin

[sparkprime]

Personally I use blender as I'm a linux nut. [...] so it'd be much easier just to dump them all out in my format.

It seems much easier if you simply read the data directly from the .blend file. Our new GameKit project does just that, including examples how to extract triangle meshes, packed texture images, skeletal animation, skinning, Bullet collision shapes, constraints from a .blend file and show them in Ogre and Irrlicht. Its bParse code is small, fast, cross-platform, 32/64bit compatible. Have you checked it?

No but it seems suprising, they go to a lot of effort to have scriptable plugins in python, is it really better than that?

edit: and how do you, starting from the information in the manifold, know which vertex(es) to move?

That is left as an exercise for the reader Seriously, I can ask the Rockstar GTA IV physics developers if they can explain how they did it (I simply forgot it), and give you a follow up later.
Erwin

That would be very interesting. I can think of a couple of ways of doing it, e.g. one could use the normal and penetration to define a plane and then offset all the vertexes on the wrong side of the plane until they are on the plane. Alternatively just finding and moving the closest vertex might be OK. Also it might be that the depth of the plane is only used for finding vertexes and it is actually the impulse that is used for choosing the deformation depth. I expect it would be necessary to have a maximum offset for damage, to stop models getting too contorted or you might have a vertex coming out the other side. I'm worried there are caveats lurking in this so it'd be good to see what design they converged on.

[Erwin Coumans]

It seems much easier if you simply read the data directly from the .blend file. Our new GameKit project does just that, including examples how to extract triangle meshes, packed texture images, skeletal animation, skinning, Bullet collision shapes, constraints from a .blend file and show them in Ogre and Irrlicht. Its bParse code is small, fast, cross-platform, 32/64bit compatible. Have you checked it?

No but it seems suprising, they go to a lot of effort to have scriptable plugins in python, is it really better than that?

For loading the data into a game engine I think reading the .blend file is better and faster than Python plugins.
We spend a lot of effort in making the .blend file parsing fast and compatible. Python plugins are nice if you want to export/import a particular file format, but I don't see an important reason for an intermediate file format when you deal with your own game engine. Or am I missing something?

If you try out GameKit, I'll email Rockstar, deal?
Thanks,
Erwin

[sparkprime]

I fixed these by adding #include <cstring>

Code: Select all

/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp: In member function ‘void bParse::bBlenderFile::resolvePointersStruct(bParse::bChunkInd&)’:
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:176: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp: In member function ‘virtual void bParse::bBlenderFile::resolvePointers()’:
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:233: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:235: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:238: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:240: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:242: error: ‘strcmp’ was not declared in this scope
/home/spark/gamekit/gamekit-r109/gamekit/bBlenderFile.cpp:244: error: ‘strcmp’ was not declared in this scope

And then it compiled, and I was able to run it and get the race course and the windmill thing. Is there a list of key bindings somewhere? I was able to move around but couldn't work out how to interact. I had a go at the game mode in blender too, it seems you have to set up the links as if it were constraints and then you tick compound to make it a single rigid body instead of several bodies linked with constraints.

There is at least one reason why I'd rather not read .blend files at runtime -- some people prefer max or zmodeller and will be put off if they have to use blender. There is also the usual excuses like having a format optimised for reading fast or for partial reads, e.g. with the graphics mesh, it's nice to have all the rgb ordering correct so you can just mmap the whole thing. For physics data I'm not sure how much performance is really lost though. Probably not much.

Anyway even if I don't want to read the blend files at runtime, reading the blend files with an offline tool is still an option so this is all still quite interesting. I might have to play with physics in blender a bit more.

[Erwin Coumans]

ok, here is a brief overview of the damaging of vehicles in GTA IV:

he physics part of the GTAIV car deformation is complicated mainly by our attempts to get the graphics and physics to match. If someone had lesser graphics requirements, the physics side could probably be simpler.

The way it works is that there is a displacement texture “wrapped” around the car sort of like a sphere map. Azimuth and elevation from the car’s center are mapped to U,V coordinates within this texture. Within this map, R,G,B values represent X,Y,Z displacements. This is warped so that more detail is around the perimeter of the car where most collisions occur. When an impact comes in from the physics, a texture is blended into the image, centered at the U,V coordinates of the impacts as transformed from azimuth and elevation, with a color modulated by the direction of the impact.

This displacement texture is used by the vertex shader for the vehicle, shifting the location of vertices. It is also used to deform the vertices of the physics bound. After each deformation event, all the vertices are updated via this map, but of course only the vertices close to the impact point will move. No attempt is specifically made to ensure that the bound remains convex (in fact many vehicles are concave to start with) and any vertex that gets pushed inward will simply no longer be chosen by the support function. We also don’t do anything about modifying the contact point based on the deformation, so it probably gets discarded on the next refresh.

Some complications: it was discovered that it is necessary to set maximum displacements depending on the position in the texture, to prevent some of the visible geometry from penetrating through other visible geometry. So, there is a min and max displacement texture that limits the R,G,B values in the displacement map. Also, it was necessary to tessellate the geometry more than would otherwise be required, so that there are vertices to create a smooth deformation, e.g. in the wall of a large box shaped truck.

One thing we considered doing that we did not get around to (yet) is integrating the deformation process with the breaking loop of the physics, allowing to re-run the force solver after deformation. The purpose would be to allow the push (position error) solver to take into account the motion of the contact point caused by deformation. So, if you watch carefully at a car hitting a wall in GTAIV, you may notice that although the bumper gets pushed in by some amount, the car stops at the point where the pre-deformed collision occurred.

btConvexHullShape automatically ignores interior vertices, so no need to worry about that. So in short they have a maximum allowed damage distance to avoid car parts from inter-penetration.

Back on-topic: I'm working on a basic solution for filtering out internal edge/vertex collisions, using pre-processed shared edge/vertex information. This should be ready soon, for Bullet 2.76 later this month.

Hope this helps,
Erwin

[sparkprime]

That's an interesting technique that I had not considered at all. It must have some problems with certain shapes of vehicle, I'm not sure it would work too well with a passenger aircraft for instance. However for vaguely spherical shapes like typical cars I can imagine it working quite well. I'm wondering if it would work for gimpact. Highly tesselated shapes are a bad idea with gimpact usually as small triangles can tunnel and get trapped behind static geometry. However with hulls you'd have to make sure there were relatively frequent subdivides too, otherwise you wouldn't get a concave dent. Obviously tesselating the mesh is much more important for graphics than physics so I'm not sure how much you'd have to tesselate e.g. the front of a car.

I'll definitely implement this at some point, and then experiment. It's probably not general purpose enough to be part of bullet though.

I'll also be keeping an eye out for the internal edges thing, it will be good if it does not require any contact added callback stuff, i.e. is implemented internally. Are you going to implement the preprocessing code too?

[Erwin Coumans]

I'll also be keeping an eye out for the internal edges thing, it will be good if it does not require any contact added callback stuff, i.e. is implemented internally. Are you going to implement the preprocessing code too?

My current work-in-progress implementation uses the contact callback, but it can be moved internally. And yes, I have a work-in-progress preprocessing as well, based on btDbvtTriangleMeshShape / btStridingMeshInterface.

I hope to have an initial test soon, before Bullet 2.76 release later this month,
Thanks,
Erwin

[Erwin Coumans]

I'll also be keeping an eye out for the internal edges thing, it will be good if it does not require any contact added callback stuff, i.e. is implemented internally. Are you going to implement the preprocessing code too?

It was a bit more work than expected, but see http://www.bulletphysics.org/Bullet/php ... f=9&t=4603

Please test it and give some feedback in that topic (or issue).
Thanks!
Erwin