Information
Gallery
Download
Documentation
Community
FAQ
Search
Register
Login
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.
Panda BulletReturn to Panda Features in Development
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
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. http://www.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:
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.
Nevermind, i thought the a,d keys were fo steering.
As for the jigglebones, wouldn't this work? http://www.panda3d.org/manual/index.php ... to_a_Joint I'm not sure if it's a good idea to attach the NodePath which contains the RigidBodyNode to the joint's NodePath, or in other words move a Bullet node by code. EDIT: BTW, manual mentions debugNode.setVerbose(), but the function is missing in the buildbot versions.
Yes, this is how to expose a joint. I would try to expose the joint directly to the (kinematic) rigid body node:
I don't understand. What do you need these values for? Can't you use the NodePath positions and orientation to compute these values?
Bones are transform matrices. When you expose it, you get a Nodepath with a valid position, but orientation is not the same as the bone's which was constructed by the 3d modeler, because the angle of the transform matrix is not the same as the angle of the bone, by my tests it can be off by 90 or 180 degrees in some angle. So if you want to create a jigglebone from a bone, I don't see how you can get the "tip" of the bone to use for the second rigid body, because there is no "tip" information.
http://i.imgur.com/Lqko9.jpg
What are the red arrows on your image? Visualisations of the x-axis vectors for each exposed NodePath? Please make a new version of your image, where you also show the y-axis and z-axis vectors.
Cleanup on exit
Is there any special cleanup procedure for bulletworlds other than world.removeX, world.clearDebugNode?
Do we have to manually call removeShapes to deconstruct a compound BulletRigidBodyNode shape before it gets garbage collected?
@enn0x, nope it was just a red arrow parented to an exposed joint. But if you want to see the typical red,green, blue arrows, here it is: http://i.imgur.com/kyZmN.jpg
Re: Cleanup on exit
No. Objects are hold in a container which is a private member of their "owner", for example rigid bodies or constraints are owned hold by the world, or shapes are hold by a rigid body. "remove_xyz" removes the object from the owner's collection, and thus allows destruction of the objects (if the last reference of the object is released). It is enough to remove a rigid body node, and then all shapes hold by this node get released too. At least in theory, but there still can be bugs. So if you find any strange behaviour or memory consumption please report it (sample + description). I will try to find out why some objects get not released.
Looks good to me. To absolute positions seem to be ok. The absolute orientations are of no importance to the animation system - just the changes in orientation with time (frame by frame) matter. I still can see a pattern in the orientation. The orientations of the joints are defined by the modeller+exporter. Different modellers+exporters will probably create different results with regard to orientation. If you want to take influence on the orientations this is where you have to look. Anyway, you didn't answer my question why you need the orientations. Did you consider to add new bones to your model within the modeller? For example a "weapon" bone being a child of the "left hand" bone, or a "hat" bone being a child of the "head" bone. No vertices have to be rigged to these bones. They are just for control of, well, hat or weapon. Then you have the "head" NodePath which defines the position of the first rigid body, and the "hat" NodePath which defines the (initial) position of the jiggly hat. And if you still need to you can compute the vector from "head" to "hat".
Well that is what I'm trying to say. It is of importance to us if we want to create a jiggle bone. If a jiggle bone consists of "base" and "tip" rigid bodies, how are we supposed to find out where to position the "tip" rigid body, if we don't even have an actual "real " angle (not to mention a tip position)? If we had an actual angle , all we would need would be to guess the "lenght" from the base to tip, but we don't even have enough data to do that. PS. Hat is part of the animated mesh, rigged with all weight as "1".
I can only repeat what I already have suggested: To define a "tip" position go to your modeller and add an additional bone, then expose it and get it's position. If you already use the name "hat" for a bone then name it "jigglehat" or whatever you like.
You will have to change this. The hat has to be removed from the animated mesh and has to become a separate model. This separate model has to be reparented to the "tip" rigid body in order to have it move with the tip rigid body.
Yes, I heard that suggestion. You said
Which seemed like you wanted an explanation.
I dont think thats a good idea, jigglebones are also used for bones which have weights. From hair and clothes to bellies and breasts. Either way increasing the geom count is a bad idea. As to 'how', im not sure, thats why I ask. Maybe only the rotations of the bones are copied from the jigglebones.
Hi Enn0x,
I could be really really super duper silly, I think this is a typo (it was meant to be Margin instead of Marging?): http://www.panda3d.org/reference/devel/ ... xShape.php the two methods getHalfExtentsWithMarging and getHalfExtentsWithoutMarging.. or otherwise what is Marging? (if it's correct) Also I found that changing BitMasks on two bodies during runtime, has no effect, unless you remove and add back the bodies to the world, is this correct as well? I just thought I would ask in-case they're small things you might have overlooked, they're both non-critical and have no impact other than being a tad bit confusing. Hope this helps, ~powerpup118
I thin I have been too hasty here. It could work without separating the models, if you e. g. EXPOSE the "head" joint as kinematic body and CONTROL the "hat" joint as a dynamic body. You will have to be careful with your vertex weights. Don't forget to post a sample once you are done.
You are right, a typo on my side. I will fix it until next weekend. Thanks for pointing this out.
Hmm, I didn't test this case, but I thought I should work, since I directly access the masks within the filter callback (and not resot to values stored by myself). I will investigate.
The problem is that upon adding a collision object to a world Bullet performs a first collision test. And this collision test may create a persistent manifold point if the newly added object overlaps (bounding boxes!) with some other object. This persistent manifold point doesn't get destroyed just because the PandaNode's collision mask changed. So even if the matching of the masks returns false there is still one manifol point. It should be somehow possible to remove this manifold point from the world's overlapping pair cache, but this means that I have to navigate to the world (in order to access collision dispatcher and broadphase interface). Unfortunately this is not possible without increasing the memory footprint. I will keep this point in mind, but for now I think that removing and adding the body from/to the world AFTER changing the collision mask is the best solution.
eliminate bulletContact
Hi,
I'm new to panda and I scout possibilities of bullet. Here's thing what I try to achieve: - have instance of BulletCharacterControllerNode (call it 'player') - have instance BulletRigidBodyNode (call it 'box') - 'player' perform jump, collides with 'box' which is placed above and is knocked back Now I want to eliminate that knockback. The only thing I'm able to do is to get instance of BulletContact via BulletWorld.contactTestPair(player, box). But I don't know what can I do with it. Can someone give me some hint? Thanks.
Okay, that's totally alright with me then, my next question would be what is the easiest way to remove/add a body returned by BulletWorld.contactTest(..)? Problem I ran into was that BulletWorld.contactTest(..) returns 'const' bodies? and so when trying to remove the body, I get the following error:
Or how else can I remove/add the body? I found a small workaround, by searching the scene graph for a node with a name of the body's name (bodyNode.getName()) however this only works if each bodyNode has a unique name, any other way to work around this? That's actually originally why I wanted to ask about changing objects masks Thank you, ~powerpup118
Re: eliminate bulletContact
Hello, and welcome. I'm afraid there is very little you can do. The Panda3D Bullet module just exposes the "original" Bullet character controller - it does not implement it's own character controller. And the original character controller which comes with Bullet is quite incomplete. In particular the interaction between the character and other collision objects is not implemented. The lack of this feature is what you experience. The physics engine detects an overlap of two objects and just pushes them away from each other, without regard of mass or other physical properties. We do mention this lack of features in the Panda3D manual already: http://www.panda3d.org/manual/index.php/Bullet_Character_Controller What we would need to do is to write our own, better character controller. This is quite a lot of work, and so far I don't feel able to approach this task. A second aproach would be to find some reference implementation of a better character controller (based on Bullet) within some other open source engine, and adapt it to our Bullet wrappers. Right now you hit a limitation of the Panda3D Bullet module. Sorry. Any ideas are welcome.
Return to Panda Features in Development Who is onlineUsers browsing this forum: No registered users and 0 guests Powered by phpBB® Forum Software © phpBB Group | © Carnegie Mellon University 2010 | Full copyright notice | Contact
|
