small colision polygons vanishing [SOLVED]

Scripting Issues
1

I think there is a problem with small collision polygons vanishing.

This is one of the problem Thomas found discourse.panda3d.org/viewtopic.php?p=27249#27249

I was using my egg octreefy tool:

This was done generating regular polygons:

This was done with the same code but using eg.addObjectType(‘barrier’) and using ctrl-c to display collision polygons.

I think there is some problem showing them or reading small collision polygons from group.

I have confirmed with collisions - its is not only the display but the reading of large number of collision polygons in large number of groups messes it up!

2

I am still working on this. I have created a program that sends particles at the mesh and yes they pass through the invisible portions. Could there be some limit to nesting of polygons?

3

There is not an intentional limit. It’s possible that some 16-bit index is overflowing, or perhaps the polygons in question are sufficiently small that roundoff error in the vertices is making them look like they have zero area.

I’ll investigate. Still, one is forced to wonder whether it’s really a great idea to have so many thousands of tiny little collision polygons in the first place.

David

4

Well using the octree should make it possible because only log(n) of them needs to be checked

5

Maybe, but the collision system was never designed to create such tiny polygons. There’s probably a threshold check in there somewhere for the polygon’s area being very near zero. Putting this scale in the egg file proves it:

<Group> Mesh {
  <Transform> {
    <Scale> { 0.001 }
  }
  <ObjectType> { barrier }
  <Group> {
    <VertexPool> vpool1 {

With this scale in place, all the polygons load properly. This works because the tiny scale factor forces the egg loader to counter-scale all of the polygons much bigger (and the egg loader does that scaling in double precision).

I can work around this by making a double-precision pathway to create a CollisionPolygon, instead of just the existing single-precision pathway, even though the resulting vertices will ultimately be stored single-precision. The double-precision pathway can have a much smaller threshold check for degenerate polygons.

Still, what you’ve encountered is not precisely a bug; it’s just a design limit on the collision system. Even if your octree is perfect, if the bounding volume of the intersecting volume is large (for instance, a soccer ball hitting the ape in the head), the collision traversal will pass every single bounding-volume test, and it will have to perform an intersection test with all 8,000 polygons. That’s not going to be fast. Especially when you consider that the fundamental shape here could probably be modeled in maybe 10 polygons, which will be 800 times faster to calculate.

So while a good hierarchical subdivision can help, supporting lots of tiny collision polygons has never really been an intended feature of the collision system.

David

6

Thanks drwr! That is a great explanation. I never run into the small polygons collision problem my self because we use special collision meshes i only started to look into it when Thomas said it was a bug in my octree. Thanks problem solved.