CollisionTraverser

General Discussion
1

I have a bit of a problem, could someone please tell me how to fix it? :laughing:

Traceback (most recent call last):
  File "PanIRC.py", line 104, in ?
    gravWalk.initializeCollisions(base.cTrav, lochar, BitMask32.allOn(), BitMask32.
allOn(),100)
  File "c:\panda\direct\src\controls\GravityWalker.py", line 306, in initializeC
ollisions
    self.setCollisionsActive(1)
  File "c:\panda\direct\src\controls\GravityWalker.py", line 346, in setCollisio
nsActive
    self.oneTimeCollide()
  File "c:\panda\direct\src\controls\GravityWalker.py", line 394, in oneTimeColl
ide
    tempCTrav.traverse(render)
  File "CollisionTraverser", line 378, in traverse
AssertionError: has_surface_normal() at line 93 of c:\dev\panda\panda3dsrc\panda
\src\collide\collisionEntry.cxx
:display: Closing wdxGraphicsWindow8

I’m using Panda.egg as my avatar if this helps…

2

The problem isn’t with your avatar egg, but more likely whatever you’re using in your environment. It looks like whatever you’re using is missing some or all of its normals information. Did this happen when you started your program or only after your avatar bumped into something? Assuming you have multiple models loaded in your world, the culprit will likely be something that your avatar was standing over or next to. Once you find the guilty egg, you can try this:

egg-optchar -o newObject.egg -nv 30 object.egg

Then use newObject in place of object in your code.

This will recalculate all of the normals for the object. “30” is the number of degrees within which a seam between two triangles will be smoothed. “0” would leave an object completely faceted, and “180” would smooth every seam, making a cube look a bit strange.

egg-optchar has a lot of handy uses, actually. Try egg-optchar -help to find out more.

3

The information about egg-optchar is very useful information. Also look at egg-trans, which has those options and a few more.

In this particular case, though, the assertion error is a little misleading. It’s not actually complaining about the lack of normals in an egg file; these normals are only used to compute lighting effects, and aren’t involved in collision calculations.

This assertion error is caused when someone asks for the surface normal at the point of a collision, and the intersection test did not compute a normal. Certain kinds of solid-solid collision tests do not bother to calculate a normal. In particular, ray-sphere tests don’t. My guess is you stepped onto a sphere; I think the GravityWalker may be assuming you will only be stepping onto CollisionPolygons.

David

4

How bizarre. I actually had this very problem recently. When I looked at the offending model, I noticed some missing normals. I had the modeler ensure that there were normals defined throughout, and the problem went away.

I suppose it’s possible that there was a sphere declaration in there which coincidentally was removed at the same time as the normals were redefined. Seems awfully strange. I guess I can’t argue with the code, though.