Collsion with Actor

Scripting Issues
1

This questions seems repeatedly asked many times…but I still can’t confirm why I have this problem.

I have a model created by blender. I add a box with the ObjectType barrier to define the collision geom.

If I load it with loader.loadModel(), the collision detection works fine. But if I load it with Actor interface, the detection is not working anymore.

I saw several examples in the forum attaching a CollisionNode to an Actor. But since the collision geom is already defined in the egg file, it should use it instead.

Do I need any special handling in this case ?

2

The egg loader does not support loading collision geometry from an animated egg file. It is an unfortunate limitation with the egg loader, and it confuses a lot of people; but that’s why it doesn’t work, and that’s why you have to attach collisions separately instead of loading them in directly from the egg file via the Actor interface.

David

3

oic, it would be great if this kind of information can be put in a sticky FAQ.

Thank you.

4

Is this any reason the actor interface not loading the collision information from the egg file ? I know that the collision geom will not be animated with the actor. Other than that, any special reasons behind ?

I load the collision node from the model instead of creating from code. It seems working well. Any comment on this code:

        self.model = Actor(modelfile)
        if self.model:
            reference = loader.loadModel(modelfile)
            np = reference.find("**/CollisionNode")
            np.reparentTo(self.model)
            np.show() # debug

(I name the collision information geom as “CollisionNode” in blender.)

5

Well, the Actor interface just looks for an animatable model, and it throws away everything else it finds, assuming it’s going to be empty nodes or something equally unimportant. I guess it could retain the non-animatable parts of the model and parent it to the same root, which would be correct in your case; but it would be a new behavior on the part of Actor, which risks causing compatibility issues with lots of existing code.

David

6

Does that really matter? Can’t finished projects use the version they were finished on anyway? And in-development projects can update if they need to. If you’re really worried, take a named parameter to the Actor constructor to enable the new behavior.

7

We have ongoing projects that use ongoing Panda development (e.g. Toontown and Pirates), and I’d rather not break these projects willfully. Beyond that, though, it is generally good practice to maintain backward compatibility where reasonable, to minimize the porting effort for people doing Panda3D projects who wish to upgrade to the latest version.

Certainly, it would be possible to make it backward-compatible; and this would be a perfectly reasonable thing to do. There’s always some risk when you touch a part of the system that is used so broadly by everyone, though; and I’m not sure about the cost-to-value ratio there.

David

8

It has been my experience that “fear of breaking things” actually causes more pain and problems, than “actually breaking things.” In fact, if the code is so fragile, and has such poor test coverage, that unpredictable things break where they “shouldn’t,” then the problem is not the changes; it’s the state of the code.
If you’re not at a place where adding an optional keyword argument to Actor is safe, then you’re in real trouble that’s much bigger than that particular change.

9

Point taken.

David

10

So, for my education – do you believe that the Panda3D code is in a state where you should be fearful of breaking things with a change like this?

11

I must say that it’s very easy to break stuff and in the past, all kinds of minor changes have been made which were just slight tweaks in behavior, or accidentally broke backward compatibility, or deliberately.
Result: all those tiny changes build up and 30% of the code that was made four panda versions ago doesn’t run anymore.
This is exactly the reason why code rots and it’s very hard to prevent - that’s why we have to be super-careful with making big changes like this (this change is actually bigger than a small switch somewhere and it’s kinda risky also.)

12

OK, so the answer is “yes” then? Thanks!

13

Well, it’s not so much the Panda3D code itself, but rather all of the many applications that are written using Panda3D. Not all of them limit themselves to using published API’s and responsible calling patterns, and we can’t regression-test them with each change because we don’t own them.

Part of the problem is that we don’t have complete documentation on all of the intended public API’s, of course. Another part of the problem is the nature of Python itself, which tends to encourage loose coding styles due to its late-binding and loosely-typed structure.

In this particular example, we could probably make the proposed change safely. But there are always surprises.

David