Has the Bullet wrapper for Panda any analogs of following parameters from Blender?
Hi Ninth,
Lock Translation, Lock Rotation:
You can use BulletRigidBodyNode.setLinearFactor and setAngularFactor. Here is a link to the original Bullet documentation which explains how to use these methods: bulletphysics.org/mediawiki-1.5. … e_Snippets
Force Fields:
Bullet does not have force fields out of the box. Blender added their own implementation. We don’t have our own implementation. Basically it’s not that difficult: register all bodies which enter the force field volume and apply forces to them each frame. The difficult part is how to handle objects which are only partially immersed in the force field, e. i. buoyancy.
Ok, thanks, I’l try it.
As for the force field - think it’s not very important part currently. Perhaps I’ll try reimplement it later
I am again
Blender has “Linked Collision” option
Has the Bullet wrapper analogs?
Even with a bit of googeling I have not been able to find out what the BGE “Linked Constraint” actually is. My best guess is that it means to disable the collision between linked objects (linked with a constraint/joint). Here is why I believe so:
blender.org/api/blender_pyth … aints.html
blender.stackexchange.com/questi … in-the-bge
In this case the underlyingBullet (not BGE) method would be: BtDynamicsWorld::addConstraint (btTypedConstraint *constraint, bool disableCollisionsBetweenLinkedBodies=false).
We have not exposed this flag in BulletWorld::attach_contraint (and I wonder why… perhaps there is also a way to set this later?), but it would be easy to add it (at the cost of un-deprecating this method, which is ok in my opinion).
Ah, sorry I forget to say that this option relates to the constraints, so you right - it disable the collision between linked objects.
Another two question:
Method setLimit ( int index, float value ) is not affect on the my cone twist constrain, however setLimit (float swing1, float swing2, float twist) works as expected. Do I understand correctly that setLimit ( int index, float value ) should affect on the angles separately? Or it work by another way?
I use Rigid Body without mass and BulletTriangleMeshShape with dynamic=False to implement Blender “STATIC” collision mesh. Unfortunately on the large mesh (for example - plane with 5 subdivisions) this method drops my FPS up to 15-20, however in Blender the same mesh works quite fast. Is there more fast solution to implement static mesh?
Exposed the flag in Bulletworld.attach_contraint.
The Bullet docs say themself that it “may be a bit tricky to set up cone twist constraints” ( bulletphysics.org/mediawiki-1.5. … onstraints ). I think it is tricky to set up any Bullet constraint. However, the docs recommend using the set_limits method with three spans, i. e. the one you got to work.
Here is a snippet from th eBullet header file for the cone twist constraint. You can see what values to use for “index” in order to get the desired effect:
165 void setLimit(int limitIndex,btScalar limitValue)
166 {
167 switch (limitIndex)
168 {
169 case 3:
170 {
171 m_twistSpan = limitValue;
172 break;
173 }
174 case 4:
175 {
176 m_swingSpan2 = limitValue;
177 break;
178 }
179 case 5:
180 {
181 m_swingSpan1 = limitValue;
182 break;
183 }
184 default:
185 {
186 }
187 };
188 }By the way, here are a few comment lines from the same header file regarding the other setLimits function. Might be useful too:
190 // setLimit(), a few notes:
191 // _softness:
192 // 0->1, recommend ~0.8->1.
193 // describes % of limits where movement is free.
194 // beyond this softness %, the limit is gradually enforced until the "hard" (1.0) limit is reached.
195 // _biasFactor:
196 // 0->1?, recommend 0.3 +/-0.3 or so.
197 // strength with which constraint resists zeroth order (angular, not angular velocity) limit violation.
198 // __relaxationFactor:
199 // 0->1, recommend to stay near 1.
200 // the lower the value, the less the constraint will fight velocities which violate the angular limits.This is not the expected performance. Can you use the Panda3D profiler to find out what actually eats the performance? You have turned off the debug renderer, right? (The debug rendering is slow)
O, thanks! I tried 0-2 values for axis index, but actualy it should be 3-5.
Oops, I forget about low performans of debug rendering, sorry for this mistake 
Another problem - I have strange behaviour on Win 7 x86, however the same scene on Ubuntu x64 works well. Here video youtu.be/QFJ7yOGpin4
Panda 1.9 builded from GIT >makepanda\makepanda.bat --everything --installer --no-eigen
EDIT: 3 issue is again my mistake - it result of setting inertia, though in Ubuntu seems that it not affected, or perhaps I again miss something, in any case third issue now is not actual.
Does Bullet wrapper support (multi)materials?
There is no “material” concept in Bullet. You set friction/restitution etc. per body.
Also, the default friction modle does not distinuish between static and dynamic friction. However, it is possible to write and use you own custom friction model on the C++ level.
Blender stores the friction and elasticity parameters in the own Material and seems can apply different materials to the same mesh.
Also I found this, though I not sure that it was completed:
bulletphysics.org/Bullet/phpBB3/ … f=9&t=2088
continuousphysics.com/Bullet … Shape.html
continuousphysics.com/Bullet … rties.html
continuousphysics.com/Bullet … erial.html
Hmm… I very remotely remember having seen this specialized shape class before. Mind you, only the bt
If I remmeber right I decided not to support it for several reasons: (1) btMultimaterialTriangleMeshShape is the only shape which supports these materials, and it is a specialization usable for static methes only AFAIK. (2) there has been no simple way to configure the tringle/material mapping.
I still don’t see a good way of how to expose such a feature, without breaking existing code or impairing performance for all users who don’t need this feature. Feel free to suggest something, and I will reflect your thoughs. Perhaps together we find a way to go.
Right now I think I would start with writing a new class for triangle meshes with per-triangle-materials, e. g. BulletMultiMaterialTriangleMesh. Perhaps it makes sense to have both this new class and BulletTriangleMesh inherit from a shared base class. The BulletTriangleMeshShape CTOR would be able to handle both classes as arguments, and construct the proper Bullet shape class internal. This more or less leaves the challenge to design an API for this new class.
A few thoughts here: collision meshes are more restrictive than render meshes. For example you can have four adjacent triangles, and each of the triangles has it’s own vertex. The four vertrexes would be very close together, or even have the same coordinates. This is no problem when rendering. But for collision detection the nearby vertices must be merged into a single vertex (aka “welding”). Also very long and thin triangles should be removed. So the “final” collision mesh looks different from the original rendering mesh. This makes the mapping a bit tricky.
I am not so familiar with c++ and Bullet, but if you say that it works only for static bodies, then I think there no problem to split one static body to the several with different friction settings, and there really no need to implement btMultimaterialTriangleMeshShape. I am just thought that materials affected on rigid body too. Thanks for explanation!
I think it would be good to support multi-material meshes. There are use cases, for example a static terrain with different surfaces (slippery, mud, pavement, …). Splitting one mesh into several meshes each with one friction/restitution value is not a good solution. Besides performance there will be problems with those regions where one mesh ends and the other starts. Objects won’t slide perfectly smooth over such edges, no matter how good the vertices are alligned.
This means: yes, we have a missing feature here, and we should fill the gap - somehow.
For the static/dynamic triangle meshes: here is a link to the Bullet docs for the base class of all collision shapes. It shows the inheritance tree. for dynamic triangle meshes we use the btGImpactMeshShape, and for static meshes we use the btBvhTriangleMeshShape. The later has one derived class, the btMultimaterialTriangleMeshShape, which is the only one using btMaterials. No problem here. The only thing I am worried about is how to define the material/triangle mapping on the user interface side.
EDIT: forgot the link: continuousphysics.com/Bullet … Shape.html
Bach when I wrote the Bullet wrappers I though it would be clever to provide a low-level interface for creating collision meshes (via BulletTriangleMesh.add_triangle) and a high level convenience method (just pass a Geom, and I try to iterate over all triangles inside and add them automatically). The high level interface has been intended as a quick-and-dirty way for rapid prototyping. For real content the collision mesh should be less detailed than the render mesh.
This sooner or later boild down to content pipeline questions. And this is where you have done great work for Panda3D by writing your Blender exporter.
Currently I think that all physics modules should have a common way to provide content to them. Otherwise we would end up with exporter modules for Blender/Max/Maya… which need to implement different code for different physics engines (not clever). And there is already a standard for defining collision geometry in Panda3D, which is somehow controlable from EGG files. After importing an EGG file with collisions in Panda3D we have CollisionSolids in our scene graph. So currently I think Bullet should start here, with CollisionSolids, and convert them to it’s own collision geometry.
So here is the question to you: how would you export the material properties from Blender using the current EGG syntax?
If we can find a way here I’m sure we can find ways to define other physics properties too, like mass of an object. And once Bullet can pick up there information we would have a much better physics module.
For what it’s worth, if someone were to make a good proposal for a change to the .egg specification, I’d be happy to implement the extensions.
Unfortunately I am not using EGG for define physics parameters. Initially I planned to use EGG collision solids, but encountered with issues which I can not resolve (related post: Blender 4 Panda).
For recognition and linking Panda objects (nodes) I use names of NodePath and material attributes.
As for EGG, I have two variants: