Ah!  I've implemented the dot product check for the normals, and it does help.  It also seems like it may be speeding things up, which suggests that my sorting code, later in the comparison function, may slow down as the sort list grows in length.

So far the checking of base geometry normals doesn't seem to make any obvious difference in my tests.  I'm weighing the potential value of the option.

Spanki, if you're still reading out there, I am wondering about one particular .pyd function.  I know that mesh.GetWorldNormals() can return a divide-by-zero crash error if it encounters a stray vertex with no associated polygons.  I'm using the older PolyVertexNormals() approach, so I can get base geometry as well as worldspace normals, if need be.  Do you happen to remember whether PolyVertexNormals() has divide-by-zero protection?  I'm not sure I have a testing mesh with any stray verts, to try to find out in a whaddayacall hueristic manner.  :unsure:

EnglishBob and others: My apologies.  I didn't get started on a web page today.  Doctor Who and the Dot Products distracted me.  :lol:  It looks like I can start on web design tomorrow.  

With my above speculation about the possible speed gains of Numeric.dot(), I forgot that Spanki had already speed tested the function against various other approaches, quite some time ago.  The Numeric version is actually slower than performing the calculation directly within a function.  Sorry, Spanki.  I forgot about that.

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking.  He apologizes for this.  He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below.  His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.