At the moment, the process of exporting a level from Blender and then importing it into my game takes quite some time, and keeps the computer rather busy. In the hopes of working on other things while these things happen, I’d like to move the process over to a second computer.
The first part–exporting from Blender–is easy enough. This produces an egg file, which is quite portable, I believe.
It’s the second part that I’m uncertain about: Is it feasible for me to convert the exported egg file to (presumably) bam format on the secondary computer, then copy the result over to the primary one?
As things stand, I’m storing egg files in my project directory. (In sub-directories.) When a level is loaded for the first time, Panda takes some time to do so, presumably in converting the egg-file to a bam file. Subsequent loads are much quicker, presumably because Panda is instead loading the previously-generated bam file. I imagine that these bam files are stored in the cache directory, separate from my project hierarchy.
To do what I intend–if feasible–would I replace the files in the cache? Or perhaps replace my egg level-files with bam versions? And if the latter, does that have any implications if I come to make a distributable build–would I be well-advised to at that point replace the bams with eggs again, and let deploy-ng handle them as it wills?
You can store .bam files and expect them to work between systems, as long as you read them with the same or a more recent version of Panda3D. In fact, Panda3D can still read .bam files produced with Panda3D 1.6.0. For distribution, you can leave them as .bam files.
If you want .bam files produced with Panda3D 1.10 to be compatible with Panda3D 1.9, you need to add this to your Config.prc file:
bam-version 6 37
This tells Panda3D to write .bam files in such a way that they can still be loaded with Panda3D 1.9.x (and up).
See this page for more information on the .bam versions.
An alternative approach is to just create a script that loads the .egg files once, which you run as part of your exporter pipeline, to make sure that there is an up-to-date version in the model cache. You can run python -m direct.directscripts.eggcacher path/to/file.egg (a directory is also accepted) to load an .egg file and write it to the cache (but anything that loads .egg files, including pview, would work for this too).
I think @rdb pretty well covered your original question. I would also like to add that you can go from Blender to BAM using the BAM exporter or BlenderPanda. As for distribution, deploy-ng (and the old p3d/pdeploy system) will automatically convert egg files to BAM.
Hmm… If I’m understanding you correctly, I don’t think that this will work in my case: The idea is to have the work be done on a computer other than the one on which the files are to be loaded, so that the latter can be used for development while the former chews through the files. If I’m understanding correctly, what you’re suggesting would be functionally the same as just loading the files in my game, minus whatever overhead the game incurs.
Interesting! Hmm… But I’m using a slightly-modified version of YABEE, so in my case it might be a little more convenient to just make it a two-step process, and convert to bam after exporting to egg.
That much I’m aware of–and indeed, it’s part of my uncertainty with regards to distribution: if I end up keeping bam files in my project directory during development, will I be missing out on anything when I come to create a distributable?
(And indeed, come to think of it, I might miss out on any bam-related changes that are introduced in versions released after I export a given model to bam.)
Not really. We rarely change the .bam format in a way that affects existing .egg files. Theoretically you could want to re-convert from .egg to .bam with different Config.prc settings.
(That said, thinking about it, I might re-import my level files anyway before creating a distributable build, just to be on the safe side, and to assuage my worries! ^^; )
