DirectRadioButton-boxImage problem

Hi guys.

In my project I use
loadPrcFileData("", “default-model-extension .bam”) so I can you use the bam models in the project without writing the extension.
Yesterday when I used DirectRadioButton it gave me error:
IOError: Could not load model file(s): [‘models/gui/radio_button_gui’]
I guess the reason is because in the the boxImage is written as
“(‘boxImage’, loader.loadModel(‘models/gui/radio_button_gui’), None),” - with no extension of the file, so it can work with samples, where you do not change the “default-model-extension”
When I change it to
“(‘boxImage’, loader.loadModel(‘models/gui/radio_button_gui.egg.pz’), None),” it’s OK.
So I’m wondering is this left on purpose with no extension ?
If so - then changing the default model extension to bam - which would be the case when you are looking for optimizations - could lead to problem here and only editing the standard Panda3D file fix the issue.

PS. I’ve seen “IOError: Could not load model file(s): [‘models/gui/radio_button_gui’]” was discussed in some threads, but it was connected with packing the project not with changed model extension.

Indeed, the DirectRadioButton (and other builtin objects) are intentionally left with no extension, so that they can load files either from the SDK, which are egg files, or so they can run in the packaged p3d environment, in which case all of these models become bam files automatically.

This is the primary reason for the default-model-extension variable. If you wish to set it to .bam yourself, you can do so; but in this case it’s probably a good idea to bamify the standard models in the SDK so that DirectRadioButton can also work with this setting. (Or you can specify boxImage = ‘my/model’ to the DirectRadioButton constructor, so that it loads your own custom file instead of the standard one).

Note that with the model-cache, there’s not usually a reason to load bam files during development. The model-cache does a pretty good job of speeding up the load time of egg files.


This is true, but you must have standard model in your models path. If you don`t - loader.loadModel will raise an exception. This is because loader.loadModel is executed no matter what and before boxImage=‘my/model’.

Hmm, you’re right. That seems like an oversight easily corrected.