Well it works perfectly. Thank you very much!
Hey, I would like to know if it’s possible to have only a part of a model as softbody and if it’s possible to have a part of an actor as softbody?
No. A body can be either a soft body or a rigid body. You have to create two seperate bodies.
So this effect is not really useful for characters, huh? 
Why?
Well, how can you, say, have an Ogre’s belly as softbody, but have it part of the Ogre Actor? It would be hard, you would need to attach it to a joint, make sure the weights around the belly softbody and the rest have weigts of 1.0 (so that they won’t deform and make holes, as the softbody isn’t affected by weights) and somehow take care of the seams caused by normals where the softbody and the Actor geometry “connect”.
There can only be one who controls an object. Either the actor, that is the animations pre-defined for this object (i. g. walk, idle, …) OR the physics simulation, that is the softbody. If both try to take control you will get a mixed up state at best.
A weight system which distributes influence between the animation system and the physics system could be a solution. But such a system has to be honored by both the underlying animation system and the underlying physics system. Neither do, and so I can put something like this on top of these two legacy systems.
Current state of the art - not related to Panda3D, but 3D games in general - is to have the animation system control the character (i. e. a human character), and “attach” a physics-controlled object to it, usually a cloth of some kind, e. g. a cloak hanging down on the back. But this is a very complex thing, since the softbody simulation has to handle lots of collisions with several kinematic objects (the rigid bodies created for the bones of the animated character).
Attachments are supported by the Panda3D Bullet modules, but only to a limited degree. I doubt that we are already able to create such an effect, and if I fear that performance will not be acceptable. We should bite smaller chunks first, like having kinematic objects for each bone or creating ragdolls for animated characters.
Can I ask why using the old import method doesn’t import Bullet?
from pandac.PandaModules import *but this does?
from panda3d import *
world = bullet.BulletWorld()or
from panda3d.bullet import *
world = BulletWorld()The old import method imports every other 3rd party library just fine. Most of my code relies on the old import method and I’d hate to replace everything now for Bullet, or use both importing methods in the same module for Bullet to get imported. Plus there was a bug which caused the new importing method to take longer than the old one.
So is this a bug? Or done intentionally? If so, please undo it.
This was done intentionally; the old method is deprecated, but you could just use both, like:
from pandac.PandaModules import *
from panda3d.bullet import *There’s no need to switch your other code to the new system if you simply want to use Bullet.
I don’t like that idea at all. Either completely remove the old method, or allow people to use both. Like this you’re just confusing us (how are we supposed to know the old method is not supported by this one wrapper? Why should this wrapper be an exception anyway?) and forcing us to either rewrite the code anyway or write ugly code (import twise just for Bullet).
I don’t agree we should remove the old method. The old method exists so that old code will still be able to run. Pretty much all samples written before the conversion use the old scheme, so we’d stop all of those from working.
People are encouraged to switch to the new system when they can, though. It has many improvements over the old system, and even fixes issues that the old system gives with the plugin system.
This particular wrapper isn’t an exception. Every thirdparty library that has been added since the new system came into place is only available using the new system, including PhysX and the vision module.
Having to “Rewrite the code” or having to “write ugly code” to switch to the new system seems a bit dramatised, don’t you think? I’m sorry if you’re frustrated that you rely on the old system providing the Bullet wrappers, but all that needs to be done to switch is change a few imports at the top of your files; most of the time you can just replace pandac.PandaModules with panda3d.core. It would take only minutes to go through a medium-sized codebase and changing the imports.
And I don’t think it’s necessarily “ugly” to use both import schemes. After all, we already had two separate import schemes, the “pandac” tree and the “direct” tree. Do you consider that equally ugly? I assume you also have other imports to other libraries and the Python standard library that use even different schemes, is that just as ugly to you?
Under the hood, the two import methods do the same thing: load the library, and import the module. If you have already imported a module using one import scheme, the other one will use the module stored in memory, it won’t load it separately.
Of course, if you think there’s something wrong with the new import system, then by all means, let us know and we can resolve any issues you might have.
However, if you’re still opposed to using either system for some reason we can’t resolve, you can create your own import file. PandaModules.py is a very simple python script that you can simply copy and add your own extension modules to.
Then it should be mentioned at least that the old importing method won’t work.
How are people supposed to guess that newer libraries don’t get imported with the old method which is used in the majority of code samples?
The direct tree imports completely different modules, while here you are importing something again differently because a single module doesn’t get imported with the first version. Yes, I think this is ungly and not the same as importing other packages like direct.
I know they do, I don’t complain about speed being an issue or anything. I just think it’s illogical to explicitly prevent the module from being imported the old way. On one hand you keep it for backward campatability, but on the other just cause unnecessary confusion.
EDIT
I’m not sure, is it? What you said seems like completely removing the old method would be the same: it would just take few minutes to port a project to a newer panda version. But you probably wouldn’t agree here, though they seem the same to me.
Note that I don’t want the old method to be removed actually, I’m just saying it’s the same as keeping it but like this.
That’s my opinion.
By the fact that the Bullet manual pages are pretty clear that you’re supposed to import the modules from panda3d.bullet.
That’s not what happens. If you import from PandaModules and then import from panda3d.bullet, nothing gets imported twice. PandaModules doesn’t touch the bullet library, and if you import panda3d.bullet, the modules imported by PandaModules aren’t touched either. So in this sense, it’s exactly the same as with the “direct” tree.
We’re not “preventing” the module from being imported. We just never added a “from libpandabullet import *” to PandaModules.py, because we want to discourage the use of the old system for new modules.
I don’t see how it causes unnecessary confusion. The old system is for old code, all new code should use the new system.
On the other hand, if we added Bullet to the old system, we would only give the impression that we’re still endorsing use of the old system, while we want to encourage everyone to switch to the new system as soon as possible.
Except that old existing samples are usually not actively maintained anymore, whereas new code (by definition) has someone to quickly make the trivial changes.
Also, if changes like these pile up over the course of the major Panda versions, the porting might be a lot more substantial, which is why it’s easier to do ; we’ve on various occasions received complains that we don’t do enough to ensure that old code samples lying around on the forums remain functional. This is why we’ve preferred doing it this way; we don’t break old code, yet we do discourage the use of the old system in any way we can.
I forgot to mention one really strong reason why we wouldn’t add the Bullet and PhysX imports to PandaModules: if we did, then every time someone loaded PandaModules, they’d be loading the heavy Bullet and PhysX libraries into memory, which would be a drain on anyone using PandaModules yet not wanting PhysX and Bullet. Our current system ensures that people don’t need to load those libraries into memory when they don’t want to use it.
It doesn’t say that the old method doesn’t work. Simply because the samples use the new method doesn’t mean it tells us that the old one won’t work. When we get to that page of the manual, all we know is that you can import modules differently in newer versions of Panda.
I don’t think you understood what I meant. I know it doesn’t import bullet, I’m saying it’s assumed to import bullet, like everything else, because you are using “*”. In that sense, you can’t compare a C++ library with direct.
Well OK. Not much difference to me.
I already explained why i think it causes unnecessary confusion (People don’t know the new libraries don’t work with the old importing method).
I don’t think you would.
Sorry, I don’t understand what you mean by this. If someone is porting a project to a newer Panda, doesn’t that mean he is “maintaining” it in a sense?
I’ve heard 2.0 will completely drop the old method. From what I remember of the development speed of Panda, I don’t think so much will be added to actually care.
Well if someone is using the “" to import the modules, he is already importing ODE, OpenAL, FMOD and few others. I’m not sure if it would be that different. Although, he might not use "” anyway.
Anyway, I don’t think I have any more points to raise. It’s all up to you to decide. It’s not a big deal for me, I just want to see Panda improve, that’s all. I might be wrong, but your points didn’t convince me.
redpanda, I think the heart of your argument is that it wasn’t made clear anywhere that “from pandac.PandaModules import *” is now deprecated and no longer recommended for use.
I think this is a valid objection. We don’t really have a way to communicate deprecated features. This has been something of an issue for a long time; developers continue to use long-deprecated features and don’t realize they’re using old interfaces until something breaks. It’s not just the import interface; lots of things have changed in subtle ways over the years, and we’ve never done a good job of telling people about the changes.
But let’s make no mistake: the change from pandac.PandaModules to panda3d.core really is an improvement and a necessary change, for several reasons such as rdb outlines above. Eventually, we will change all of the sample code and internal code to use the new import scheme as well, but it will take a while to get to all of it.
We can’t simply make the old import scheme stop working today, because there is just too much existing code that already uses it. It’s one thing for a developer to change his own project to the new scheme–that would only take a few minutes in most cases–but we can’t make all of the Panda3D developers in the world change all their projects on the same day, which is an insurmountable task. Still, one day (perhaps with the release of 2.0, or perhaps at some other release) it will stop working.
David
Well that wasn’t my main point, but I give up, whatever.
It wasn’t? Did I completely overlook your main point, then? What was your main point?
David
A question: how to make “jigglebones”?
Maybe a hingle/cone twist constraint between a node attached to the bone and another one “at the tip” of the bone? Not really sure how.
youtube.com/watch?v=f7w9N_rEqfA
Also, steering doesn’t work in the car sample snippet.
I just checked in a wrapper for the “multi sphere” shape type. Thank you zhao for pointing me at this interesting shape type. Example of usage:
# MutiSphere
points = [Point3(-1, 0, 0), Point3(0, 0, 0), Point3(1, 0, 0)]
radii = [.4, .8, .6]
shape = BulletMultiSphereShape(points, radii)
np = self.worldNP.attachNewNode(BulletRigidBodyNode('MultiSphere'))
np.node().setMass(1.0)
np.node().addShape(shape)
np.setPos(8, 0, 4)
np.setCollideMask(BitMask32.allOn())
self.world.attachRigidBody(np.node())Hmm… works fine here. What keys do you use for steering?
Tricky. A cone/twist contraint would be the right choice. You also need two rigid bodies, one moving with the parent joint, and one for the jiggly end. The tricky thing would be to make the rigid body at the parent joint move the same way as the joint moves. You could try to make this rigid body kinematic, or keep it in sync by hand. Sorry, but I don’t have any prefabricated solution at hand.
Animated characters and physics are troublesome with the current design of the Panda3D Bullet module. Maybe it has been wrong to integrate the rigid/soft bodies this tight with the scene graph. I’m currently working on PhysX 3.2 code, and here I don’t inherit from PandaNode for rigid bodies, but explore other ways to keep the scene graph and the physics world in sync, e. g. RenderEffects. But it will be a long time before I have solid results, and even longer until the leassons learned will flow back to the Bullet module.