Why Might a Collider not be Colliding...?

Scripting Issues
1

[edit]
Okay, I’ve subsequently discovered that having three solids doesn’t seem to be what does it: I’m having essentially the same problem with just one big solid, save that it’s now clearly losing detection partway through that solid…
[/edit]

So, in my current project I have, managed by a certain class, an into-collider that contains three solids.

(In case it’s relevant, these solids were loaded from models defined in an egg-file–but note that they are not polygonal colliders; they’re CollisionTubes, in this case.)

This is intended to collide with a from-collider whose solid is a single, small sphere. Both colliders have what seem to be appropriate bit-masks.

And indeed, the sphere does collide… with the first of the into-solids. The others it seems to ignore. :/

Now, I’ve checked that all of the solids are present and placed as expected, and that they are indeed all solids of that single node–and as far as I see, they appear to be.

(I’ve even written the whole scene to a bam-file and examined it, seeing the sphere visibly intersecting on of the solids despite the collision system not reporting it, as I recall.)

I’ve also activated collision-visualisation, and it seems that the sphere interacts with the first solid, but not the others.

I’ve tried creating a simple reproduction of the issue… but in simple programs all seems to work as expected, whether using hand-coded solids or model-loaded solids.

I’m… really stuck on what could be going wrong. Does anyone have any ideas as to what the problem might be, or a direction in which I might investigate…?

~

To be a bit more specific about the setup:

  • I’m using the built-in collision system
  • The CollisionCapsule solids are intangible, while the sphere is tangible
  • The capsules exist in the loaded model as simple geometry
    • Specifically, they are three separate models each with a fairly minimal number of vertices
      • Each overlaps, so that their overlapping end-caps result in little to no gap between
      • The two capsules that don’t seem to work (or that maybe partially work; it’s hard to tell, given the overlap) are children of the one that does work
      • Each has “Collide” tags, with “capsule descend intangible” as the tag-values.
      • All of the capsules have that tag, as well as a code-handled tag that sets the mask
  • These collisions are managed by a CollisionHandlerPusher with various collision-events registered

I’ll also note that I’ve used a setup much like this before–albeit using CollisionBoxes–and there it worked. Albeit that I don’t have that scene in the project any more–but I’m tempted to dig it out of my backups to see whether it still works…

2

Are there (non-uniform?) transformations applied to the models? It’s possible that there is a bug in the intersection tests. If transforms are at play, you could take the bam file, flattenLight it and see if it still doesn’t collide properly.

Would you be willing to share the .bam file with me? You could, with a small Python script, remove everything but the two CollisionNodes that are at play.

3

Ah! Prompted by your post, I think that I’ve found the problem! :slight_smile:

Hmm… Doing this in code (operating on an exported bam-file version of the scene), I find that calling “flattenLight” on the scene results in the problem-collider suddenly facing a different direction.

Interestingly, if I load the exported bam-file, search for the two colliders in question, wrtReparent them to a new root-node, and then get rid of the rest of the scene… suddenly they collide properly. o_0

And in my investigating this, I think that I’ve found the source of the problem: several nodes above the into-collider, there’s a node that has a CompassEffect applied.

If I wrtReparentTo the node just below this one, or any further down until I reach the collider itself, I get collisions. Likewise, If I wrtReparentTo the collider to the node just above the one with the CompassEffect, I get collisions. If I wrtReparentTo the node itself, collisions once again don’t work.

Applying this to my main project, it seems that my collisions work again as expected! :smiley:

Thank you so much for your help–I’ve been banging my head against this for a while! ^^;

(I tried to make a small test-program that reproduced the issue with a CompassEffect, but m initial attempts have failed. I’m guessing that there’s something more specific in the setup of my main project that is causing the CompassEffect to be a problem…)

1 Like
4

Ah, makes sense that a CompassEffect could have a funny effect on collisions. Glad you were able to sort it out!

1 Like