Hi enn0x,
Well actually I thought that linking with libpandabullet.lib should be enough.
Ok. adding LinearMath.lib fits the bill!!
Nope. Look at the sizes of libpandabullet.dll (1.7mb) and libpandabullet.lib (363kb). The .lib only contains the object code from libpandabullet classes. It does not contain the Bullet object code.
A new release. Nothing breathtaking, just a few updates and cleanup.
http://enn0x.p3dp.com/libpandabullet-r16.zip
New in libpandabullet-r16:
- Using Bullet-r2388 and Panda3D-1.7.1
- Rendering soft body ropes via NURBS curves (see sample 12).
- Replaced abbrevations in softbody cfg & material with full names.
- BulletSoftBodyHelper remove. The soft body factory methods have been moved to BulletSoftBodyNode. All other methods have been moved to BulletHelper.
- .dll is no longer renamed to .pyd, so preloading is required. Preloading can be done the same way as direct.ffi.panda3d does this for all regular Panda3D modules. See ‘test/preload.py’.
- Updated to waf-1.6.3 and added fixed for building under Windows7 (thanks to jean-claude).
that was fast 
Gruss Gott enn0x,
Just to bring to your attention the following link issue with BulletSoftBodyNode::make_rope and BulletSoftBodyNode::link_curve.
error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class PointerTo<class BulletSoftBodyNode> __cdecl BulletSoftBodyNode::make_rope(class BulletSoftBodyWorldInfo &,class LPoint3f const &,class LPoint3f const &,int,int)" (__imp_?make_rope@BulletSoftBodyNode@@SA?AV?$PointerTo@VBulletSoftBodyNode@@@@AAVBulletSoftBodyWorldInfo@@ABVLPoint3f@@1HH@Z) referenced in function "class NodePath __cdecl make(class LVector3f)" (?make@@YA?AVNodePath@@VLVector3f@@@Z)
error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall BulletSoftBodyNode::link_curve(class NurbsCurveEvaluator *)" (__imp_?link_curve@BulletSoftBodyNode@@QAEXPAVNurbsCurveEvaluator@@@Z) referenced in function "class NodePath __cdecl make(class LVector3f)" (?make@@YA?AVNodePath@@VLVector3f@@@Z)Coming from trying to link the properly compiled code
...
PT(BulletSoftBodyNode) bodyNode = BulletSoftBodyNode::make_rope(*p_info, p1, p2, 8, 1);
bodyNode->set_total_mass(50.0);
NodePath bodyNP = worldNP.attach_new_node(bodyNode);
mgr->attach_soft_body(bodyNode);
// Render option: NURBS curve
PT(NurbsCurveEvaluator) curve = new NurbsCurveEvaluator();
curve->reset(10);
bodyNode->link_curve(curve);
...It tend to think that this is related to the “static” definition of make_rope not making it visible…
BTW. As of link libraries I guess I have more than needed, ie
libpandabullet.lib
BulletCollision.lib
BulletDynamics.lib
BulletFileLoader.lib
BulletMultiThreaded.lib
BulletSoftBody.lib
BulletSoftBodySolvers_CPU.lib
BulletSoftBodySolvers_DX11.lib
BulletSoftBodySolvers_OpenCL_Mini.lib
BulletSoftBodySolvers_OpenCL_NVidia.lib
BulletWorldImporter.lib
ConvexDecomposition.lib
GIMPACTUtils.lib
LinearMath.lib
MiniCL.lib
OpenGLSupport.libAny hint on what could be missing (or change to be made in header files?)
Rgds
Jean-Claude
First the more easy one: I think you are linking too much libs. These should be sufficient:
libpandabullet.lib
BulletCollision.lib
BulletDynamics.lib
BulletMultiThreaded.lib
BulletSoftBody.lib
LinearMath.libNow about the missing symbols. I’m actually a bit confused about how you are compiling/linking. My assumption is that you want to build an exe, and link all libs statically to this exe (not only bullet, but also Panda3D libs), or are you linking dynamically to libpandabullet and other Panda3D modules? Can you provide the compiler/linker comand lines? I think this would be helpful in reproducing the problem.
One wild guess would be that you try to link against libpandabullet.lib from r15, but headers from r16. Because both methods ar enew in r16.
Declaring the BulletSoftBodyNode::make_xyz methods static is correct. The CTOR is not published, so I need to have published static factory methods.
Thanks enn0x,
You pin pointed the issue!
I checked and actually, I switched to your new r16 which I regenerated, but in a hurry I forgot to copy the import lib in panda3D/lib and so I was still using the libpandabullet.lib from r15 !!! 
Stupid mistake.
Thanks for your help.
BTW. wrt Compile & Link options: I’m using Intel Optimized compiler (Parallel Studio) so the command lines may sound weird.
On a practical side:
For several (good) reasons my Panda models are all normed based on the convention: 1 panda unit = 1cm.
AFAIK Bullet is using m, kg as basic units system.
So the question is: is it advisable to merely convert the whole unit system simply by scaling it x100. (ie having g=981 cm/s2, and all metric units expressed in cm).
Doing so is there any risk that the Bullet engine experiences stability issue?
Are there some Bullet’s config constants to be modified in order to accept safely this x100 metric rescaling?
jean-claude: Take a look at http://bulletphysics.org/mediawiki-1.5.8/index.php/Scaling_The_World.
Thanks David,
Actually I was just having a look at Bullet doc which states
So it seems that the recommended approach is to scale the Panda world in order to bring the distance values in the range of 0.05 to 10 units. (ie 5cm to 10m).
I’m afraid this is the price to pay to get stable simulations… (too bad)
BTW. I’ll try to use 1/10 of a meter as unit and see what happens…
Well, in theory physicds engines are not tied to one particular set of units. However, there are a few things which limit this:
1.) All physics computation is not solved analytical, but by numerical approaches. Usually the time is split up into small “timesteps”, and forces/velocities/… are assumed to be constant during such a timestep. The smaller the timestep, the better the results. But also the more CPU power is needed.
Some posts above has been a question about setting gravity to 98 (and not 9.8). The result has been strong jitter. Within one timesteps the falling objects have interpenetrated the ground so far that very strong forces had to be applied to keep them out of the the ground. Choosing smaller timesteps has been one solution here.
2.) Computers usually store float numbers as mantissa + exponent. The mantissa has a fixed length, independent of the absolute value of the number. So 12.34 has the same mantissa as 12340000.0. The way float numbers are stored causes big numerical errors when e. g. multiplying a small float number with a large one (when mantissas don’t overlap a lot).
So there is a general rule: Avoid huge differences in size of float numbers
This general problem of numerical computation can’t be solved by making timesteps smaller. It can be solved by choosing “larger” mantissas (4byte float --> 8byte float --> 16byte float).
3.) Most physcis engines have some kind of “skin” or “padding” around a collision shape. This is how much collision shapes are allowed to interpenetrate without causing immediate strong repulsion. So if you want to go the “cm” scale you might want to set larger paddings on all shapes you create.
I would recommend that you first give it a try with the scaling you originally had in mind, and first find out how much trouble this gives you. Maybe you don’t need every bit of performance and can choose smaller timesteps. Maybe the quality of the simulation is still enough for your purposes. If not you can still scale everything in a more recommended way.
So if I get it correctly:
(1) using double versus float should help (in this case this is only a matter of recompiling Bullet)
(2) getting a finer time step (ie for instance getting a 600Hz simulation versus the standard 60Hhz) should help too.
I’ll give a try.
Let me choose different words:
The advice given by whitelynx and the Bullet docs are definitely right. For best results you should follow these advices.
But often you don’t need “best” results. It’s a personal preference perhaps. Sometime, e. g. for small hobby projects, it might be sufficient to start the most easy way, get results quickly, and only when problems arise do it in a better way.
Recompiling Bullet with double precision might give a bit more “correct” results, but I can’t say how much. It might also cost a bit of performance. Again, I can’t say how much.
Right, the default size of substeps used by libpandabullet is 1/60 seconds (60Hz):
void do_physics(float dt, int substeps=10, float stepsize=1.0f/60.0f);I would recommend going do to 1/120 or 1/180 at least. It’s tuning: First set up a working world with all the objects you want, and then play with the timestep size to find optimal settings.
Don’t forget about the “skin”. The Bullet term for skin is “margin”: shape.setMargin(float)/getMargin().
Again a new release:
enn0x.p3dp.com/libpandabullet-r17.zip
New in libpandabullet-r17:
- Using Bullet-r2388
- Using Panda3D-1.7.2
- Optional soft body cloth rendering via NURBS surface and SheetNode. This option is usually slower than Geom rendering, so use with care.
- Renamed BulletManager to BulletWorld (sorry for the inconvenience).
- Python reference in .chm format.
- It is now possible to use setScale on BulletRigidBodyNode, BulletSoftBodyNode and BulletGhostNode. All collision shapes attached to the body will be scaled properly. Please tell me if you get unexpected behaviour now.
- BulletTriangleMeshShape can now be used for dynamic objects too. This has been achived by wrapping both btBvhMeshShape (static) and btGimpactMeshShape (dynamic) inside BulletTriangleMeshShape.
Most of the changes have been done under the hood. For example in a few cases I used to inherit from Bullet classes/structs. These inheritances have been replaced by delegate patterns. And none of the published classes is a nested class anymore.
nice progress
Are you thinking of supporting all the bullet features?
Like .bullet files and liquids?
Well, certainly not every single class/method the Bullet API has to offer. Wouldn’t make sense anyway. But I want to have most of the relevant features. Priority will be on Bullet core features (which are mostly done already), and then features from the Bullet “Extra” directories (most of these features are experimental).
Concerning .bullet files I already has support, before the rewrite around r12 or so. This time I want to do it different, maybe integrate with .bam reader/writers. But I have not made my mind up on this topic. Suggestions are always welcome.
is there a way to build r17 on Mac?
Looking at wscript, it appears that only Windows and Linux are supported currently.
This is right. I don’t expect any specific problems when building on Mac, but I don’t have a Mac at hand, and thus can’t test building on Mac.
I would buy a OSX license (about 30 Euro is a fair price in my opinion) and run OSX in a virtual machine, but the OSX license doesn’t allow this. It is not allowed to install OSX on any other hardware other than Macs. I don’t say that it is not possible, e. g. using a hacked EFI bios, just that it is not allowed.
So you either have to add an OSX section to wscript yourself, or wait until this module is part of the official Panda3D SDK (1.8.0 probably). I suggest building Panda3D from source on your Mac, look at the command lines when building, and then just modify wscript section fot Linux.
How would one go about making an object bounce?
Restitution. It can be set for every object seperately.
I should mention that Bullet combines restitution by multiplying, and that the default value is zero. So you have to set restitution on both objects colliding. Most other engines combine restitution by building the average value. PhysX even allows to choose the way restitution is combined.