Here are some misc suggestions from someone who is just learning the engine. I don’t know how feasible these are, but just putting them out there for what they may, or may not be worth = )
*) The issue with not being able to store python derived classes directly onthe scene graph seems like a bit of a pain. It can be worked around, but would be nice if this could be automated. Maybe like having a spot on nodes (and maybe node paths? Not certain yet) where you could store a python object. ie:
node.setPyData( pyObj )
So that the data will be there automatically, and you could avoid the logic mentioned in:
Of course this is just a work around for the limitation mentioned above. The ideal solution would be to have the python derived classes come in and out of the scene graph/c calls unscathed
*) Seems like there is a good possibility for a disconnect in applying forces to a body. Since you have to two independent operations on a force that you are going to apply to a body. (ie, adding to the scene graph and applying to the body, as detailed in:
If you forget to do either one of those two (Most likely the adding to the screne graph?) you will get an error/it won’t work. So a way of enforcing that connection would be to instead of taking the force directly in the ‘addLinearForce’ call, instead take a NodePath that has a force node attached to it.
*) More a umm… label issue. But I know that I have written down that CollisionNode.setIntoCollideMask really means CollisionNode.setContents. (I find the setIntoCollideMask to hurt my brain to try and figure out if something is colliding into it, or it is colliding into someting, etc…) I haven’t found a good name in my head for CollisionNode.setFromCollideMask, but something along the lines of setCollideMask usually goes through there.
THese definitely could be thoughts that are due to me just being new to Panda 3D, and over time I’ll think them silly. But here they are anyway.
There have been a few proposed solutions for the Python object loss problem in the past. It is difficult to provide a general solution, though. Not least of which is the problem that even in C++, you don’t get back the same NodePath object that you put in–it might reference the same PandaNode, but the NodePath object itself is a completely different object. This is not a problem unless you’ve modified the NodePath by hanging some data on it.
But a special case solution is perfectly doable; we can, for instance, fairly easily extend setTag() so that you can hang a Python object on a node (in addition to just a string). Although note that with Python’s pickle module, this is almost solved even as it is–but it is still clumsy.
I agree that the physics library is clumsy to use. I don’t like that the Force object is different from the ForceNode object–they really should be the same thing. There are a few other weaknesses in the library. We hope to rework this library one of these days; or maybe we will just integrate with a more full-featured third-party library like ODE.
It took me a minute to understand the concept you meant to imply by setContents, but now that I have digested it, I agree that it is less ambiguous (and certainly less of a mouthful) than setIntoCollideMask. Let me know if you come up with a good replacement for setFromCollideMask.
ODE works pretty nicely, at least as far as the dynamics part goes (and Panda handles collisions anyway I think?).
Advantages of using ODE is that its becoming ubiquitous, and that say you have a multiplayer usergame, you can easily run the same physics engine (ode) on the server as on the clients; although I guess one could just run Panda on server too perhaps?
That would be nice. = ) Would help cut down duplicate code that everyone would have using the hash method you had mentioned.
Yeah… Kinda. Seems less ideal in that you are now storing the whole data of the object instead of just a pointer. And if you modify the object after you ‘set’ it on the node, you won’t get the modified object/data out. (So more data is stored, now with less usefulness = )
That would be slick. = )
The closest I’ve come to is setClipMask. ie, this is the mask of stuff that you clip into.
As always, Thanks for the reply David,
setFromCollideMask -> setColliderMask
setIntoCollideMask -> setCollideeMask
or something along those lines. You want to be clear which one you call on the object doing the colliding and which one you call on the object being collided into.
The current “From” and “Into” definitely hurt my brain, too.
Heh. The more I think about it, the more I’ve come to like the contents thing. Contents are what you are. It is when hitting/colliding/running into other things, that seems like when you want to ‘mask’. The mask determines what you want to run into, or what contents you run up against. Having them both be called a mask doesn’t fit as well with my brain currently. (Then again, it could just be my brain = ) So something like:
setContents( Constants.WATER )
setCollisionMask( Contents.FIRE | Contents.GROUND )
Humm. but then again, maybe setClipMask? or setCollideMask?
Just my .005,
After I thought about it some more, I realized that a big part of this confusion is likely the Panda3D manual, which did such a poor job of explaining the difference between setIntoCollideMask and setFromCollideMask (and even gets it backward in the end).
It also didn’t give any explanation of the etymology of the method names: throughout the rest of the collision system, the nodes are referred to as “from nodes” and “into nodes”. For instance, CollisionEntry has methods called getFromNodePath() and getIntoNodePath(), and the CollisionTraverser passes around variables named into_node and from_node.
So the idea of the method names is that setIntoCollideMask sets the mask as an “into node”–something to be collided into–while setFromCollideMask sets the mask as a “from node”–something to be collided from.
setColliderMask and setCollideeMask are ok, too, although the word “collidee” seems so awkward.
With this observation, and a repair of the damage in the manual, do you suppose I can justify keeping the old names for a while longer?
<Laugh!> I certainly say that the lead developer perhaps has a better handle of the overall view of things, so what the heck.