How to build good collision objectsPreamble: in M&B, the most common kind of collision objects is the "
manifold" (closed meshes of quads and tris, which usually are the simplified/poly-reduced versions of the tri meshes used for rendering). They are the most flexible kind, as any shape can be approximated with one. However they are quite heavy to test, and in the game a lot of testing happens for collision detection. Better primitives (better = lighter to store and to test) are
cylinders (called "capsules") and
spheres. Unlike manyfolds, cylinder / sphere is not specified by hundreds of points and faces: a few parameters like center, axis and radius will do.
In M&B a collision object is a collection of manifolds, spheres, and cylinders.
So, if you can, try to specify collision objects for your custom stuff in terms of a few spheres and cylinders. It will be more efficient to test. For example, see the screenshot with the collision object for the catapult in the first page (taken from a native collision object)...
PS: there is also a forth, simplest kind: the "face", a single flat polygon.
How to do that? an Obj file can contain several subparts, each with its own "name". When one obj is imported in OpenBrf as a collision object, all parts that have a name starting with "cylinder" (or "capsule") will be interpreted as a cylinder, and a "capsule" object will be created for it with the right position/orientation/size (by a fitting algorithm). Similarly, object with a name starting with "sphere" and "polygon" (or "face") will produce a "sphere" and a "face" collision object respectively.
(Obj files produced by OpenBrf by exporting a collision object will comply with the above naming rule, so if you reimport en exported off all the various subparts should be kept).
Yes but how do I specify these names in my Obj file? The answer varies with the program you use to produce the obj file.
In Wings3D, for example, you must look at the geometry graph. Also, if you add a new "cylinder" or "sphere" object, Wings 3D will produce an object named "cylinderX" or "sphereX" (X being a number), so that's just perfect.
EXAMPLE:In wings 3D, I created an vaguely erotic abstract art with two cylinders, two spheres, a cube and a torus (note the geometry graph, displaying names of the objects -- they are the default ones)...

After importing, OpenBrf understood and separated the spheres and cylinders as separate objects...

(the scene is flipped, as usual -- in the game, it will look like in OpenBrf).
Update: not anymore. Now obj exported by OpenBrf will look with the same orientation in Wings3D etc.The torus and the cube, as well as anything
not named "sphere*" or "cylinder*", were merged in a single "manifold" object, but the spheres and the cylinders are listed as separated objects, each defined by a few parameters and ready to be tested for collision (during the game) in a wink .
What if I didn't read any of the above and don't feel like doing so?Nothing bad, friend. If your obj file is not spit in objects named "sphere" "cylinder" etc, then the collision object you obtain by importing it will just be composed by a single manifold. It will still work in M&B. (only, it may be a little less efficient in game).