When loading big meshes with { Polyset keep descend } panda3d seg faults. I get around it by using smaller mesh but then it crashes on windows computers.
Should i go back to trusted raytellers method of collision optimizing?
EDIT: The error pairs some what unrelated:
:loader(debug): Attempt to register loader library pandaegg (egg) when extension is already known.
:loader: loading file type module: p3ptloader
:util(debug): Writing BamCacheIndex object id 1 to bam file
:egg2pg: Reading /p/affcity/data/map/tari/map.egg
:gobj: Loading texture /p/affcity/data/map/tari/tsh.png
:pnmimage(debug): Reading image from /p/affcity/data/map/tari/tsh.png
:pnmimage(debug): By magic number, image file appears to be type PNG.
:pnmimage:png(debug): width = 1024 height = 1024 bit_depth = 8 color_type = 2
:pnmimage:png(debug): PNG_COLOR_TYPE_RGB
:pnmimage(debug): Reading image from /p/affcity/data/map/tari/tsh.png
:pnmimage(debug): By magic number, image file appears to be type PNG.
:pnmimage:png(debug): width = 1024 height = 1024 bit_depth = 8 color_type = 2
:pnmimage:png(debug): PNG_COLOR_TYPE_RGB
:pnmimage:png(debug): Allocating 1024 rows of 3072 bytes each.
:util(debug): Writing BamCacheRecord object id 1 to bam file
:util(debug): Writing Texture object id 2 to bam file
How big is big? We’ve never had troubles loading meshes with thousands of polys.
Of course, your collision performance with such a mesh may be less than spectacular, so you might want to subdivide the mesh anyway. But I don’t know of any crashes related to too many meshes.
Maybe you have a degenerate polygon (like a bowtie or a two-vertex polygon or something) in the mix, and this is causing the crash? (It shouldn’t, of course, but it’s more likely than a crash due to too many polygons.)
Hmm, yes. It’s crashing on a recursive algorithm within the egg library, attempting to analyze the connectivity of the polygons.
Basically, it’s just consuming thousands of stack frames as it processes the polygons. If you have enough stack, it’ll eventually come out the other end, but if you reach some system limit, you’ll crash. Windows has a particularly low stack limit by default.
It’s a bit of a pain to limit a recursive algorithm like this not to go too deep, but I’ll see what I can do.
The algorithm is not strictly tail-recursive, so it really does require a stack. On Windows, you can specify a larger stack size–when you link python.exe. The Windows default, I believe, 1MB, which is puny. I think the default python.exe is set to 2MB, which is also puny.
On Linux, you automatically get an inifinite stack size, up to the available per-process RAM specified in your system parameters. If you’re crashing on Linux, we must really be consuming a lot of stack in this algorithm.