After reading the documentation about CollisionSolid,I still can not understand it. Could someone give me some code examples?
There are three models that I load into the game. I want the animal can not walk through the wall, and when the animal touch the orangeball, the model of the ball disapear. All three models need to create CollisionSolids interactively in program code.
I really need help. Thank you very much.
I believe that there is in fact a full, heavily-commented example a little further on in the manual.
A quick note about the code that you posted: You create an object named “self.animal”–and then go on to attempt to operate on an object named “self.ralph”, without ever creating the latter. Should “self.ralph” not be “self.animal”?
Thank you. That’s an error. But how to avoid the animal to walk through the wall? Because I only see method that add a polygon to the model. How to use the own shape of the model?
Could you help me please.
Where are you looking? At the SDK page for NodePath?
Look again at what the manual says on the “Collision Solids” page. To quote the manual:
First we create a collision solid; then we create a collision node, and attach it to our NodePath; finally, we add the solid to the node (note! Not to the NodePath!).
For that, look to the manual page that covers Collision Handlers, and at the CollisionPusher example given later in the manual.
You want to use the model’s geometry? Ah, that’s a little more complex. For one, I’m not sure of whether it works with animated models (Actors)–at the least I’m pretty confident that it won’t follow the animations of the model. Further than that, however, I’ll defer to others for the most part: I’ve only done this as part of the process of exporting a model (and only successfully with a static–that is, non-animated–model), as far as I recall.
It looks as though the problem is that you’re treating the walls as an “active”/“from” object–and object that should be tested against other objects–rather than as a “static”/“into” object–and object that other objects collide with.
Aside from being potentially inefficient, the Panda collision system only allows collisions from a small sub-set of its solids–just rays, lines, segments and spheres, if I recall correctly–that is, it only allows objects using those shapes as “from”/“active” objects, while allowing any shape as a “static”/“into” object.
In short, add your active object–your cat, I think that you mentioned–to the collision -traverser and -handler, not the walls. (And use a sphere, or some arrangement of rays, segments or lines, (more likely the sphere) for the cat’s collision shape.)
Thank you very much. I add cat to the collision and it does not walk through that model. But I’m not sure about “static”/“into” object. Doesn’t the below code mean “self.wall” is a “static”/“into” type?
No; the code that you posted there just sets the mask to be used when the object is collided with/into.
I was mistaken above when I identified “static” objects with “into” objects and “active” ones with “from” objects–my apologies for this! A better description would be to say that “static” objects can only be “into” objects, while “active” objects may act as both “into” and “from” objects.
For example, a static wall won’t be tested against other objects. An active ball, however, will be tested against all other objects–including the aforementioned wall–as long as the relevant masks match up; this means that if there are two active balls, they may be tested against each other.
In short (and slightly simplified), if I have it correct myself, the objects that you tell the CollisionTraverser to handle are “active” objects, to be tested against all other objects according to their masks; objects not added to a traverser are “static” objects.
As for the masks, if I recall correctly an “active” object is tested against another object (whether “active” or “static”) if the “from” mask of the “active” object being tested matches the “into” mask of the other object–again, regardless of whether the other object is “active” or “static”.
How are you handling gravity and character movement?
That just looks like z-fighting between the standard visible geometry and the representations of the collision geometry; it should go away when you make the collision geometry invisible again.