1.4.1 freezes up


I’ve been studying Panda and Python for some time now. I tried installing 1.4.0, but the installer froze up near the end; there was a box listing models and what I guess was the completion of their installation. Models had completion percentages from 0-21%. Later, when 1.4.1. came along, I tried to install that also. Same problem.

I’ve downloaded and reinstalled 1.3.2 and everything works great. Any idea what the problem may be? I use an Inspiron 2200 with Windows XP.

How long does it freeze up? There’s a very big model at 22% which takes a long time to process.

I’ve actually assumed it was a bug and stopped it, but the part with the percentages would always last longer than 15 mins. The 1.3.2 installation never behaved that was; is this normal behavior? Should I just let it go on?

15 minutes seems excessive, on mine, it takes maybe 2-3 minutes. But mine is a fast computer… how much RAM do you have? Maybe it’s thrashing because it doesn’t have enough RAM to load the model.

BTW, starting with version 1.4.0, I no longer ship BAM files - instead, I generate them during installation. That’s what’s different.

Update: I’ve noticed that it takes 300 MB to load that egg file. I’m guessing your computer only has 512 MB? That could explain it.

Yeah, that’s probably it.

Well, that’s unfortunate. I’ll see if I can fix it, but it’s not going to be a quick process.

Update: I’ve looked at the code. I can’t fix it, the egg data structures are too complex for me to tighten them up right now.

The problem is this: panda has two model file formats: “egg”, which is a format designed exclusively for game developers, and “bam” format, which is an optimized format intended for shipping to end-users. The latter format is very efficient, but the code than handles egg files is a memory hog. This has generally not been a big problem, because most game developers have plenty of RAM. Unfortunately, as panda gains popularity, more and more users with small RAM sizes are trying to use panda, and they are discovering that they can’t manipulate big egg files. The problem is exacerbated by the fact that in 1.4.0, I added a little script that runs at install time that pre-caches the egg files - and there are a few big egg files in the panda distribution. As a result, you can’t even install panda if you don’t have enough memory to manipulate big egg files.

I’m not entirely sure what to do about this.

I use 512 MB mem too, but I never have such thing. I can’t remember if there was thrashing here, the installation was as fast as before, the caching was fast.
If you got thrashing, the thing that makes it worse is your hard drive interface. If you’re still using parallel interface, that would be horribly slow. I use SATA1 here, so I may simply didn’t realize the trashing, if there was one.
To use SATA interface, you could permanently replace your MoBo, or simply use a cheaper, a lot cheaper way : SATA2USB external HD interface, it’s around $30. And of course you must use SATA HD.

I doubt that the problem is that his hard disk is slow — I suspect that the problem is that he has a little less RAM than you. For example, maybe he has 512MB and integrated video, and maybe the integrated video is using up 128MB of his RAM. Or, maybe he was running photoshop when he installed panda. :slight_smile:

If the problem file in particular is SuperCity.egg, that model file is just broken. It’s broken because it has a entry, which means the model should be loaded as an animated character, even though it has no joints and no animations. (Clearly it was converted to egg with the wrong options.)

But anyway. The animated-character loader wants to load the whole thing as one big triangle mesh, which when you’re talking about millions of triangles, takes a while, since triangle meshing is fundamentally an n^2 operation.

Try removing that entry. I bet it will load much faster if it’s allowed to mesh each component individually.

There might be other models that have similar mistakes. In general, it shouldn’t be taking minutes, or hundreds of megabytes, to load any one particular egg file.


The model in question is “forest.egg,” which is a 125,000 polygon model in one of the sample programs. It’s a big model, admittedly, but these days a level that size isn’t outrageous.

It does, in fact, contain a “Dart”. However, removing the “Dart” doesn’t affect the memory consumption — either way, egg2bam takes 320MB, and pview takes something similar.

I assume the “Dart” doesn’t really come into play until after the EggData is loaded? I suspect it’s the EggData itself which is taking up all the memory.