Okay, I’ve just updated the Ubuntu package. It now contains ARToolKit support, and the ODE bug is worked around.
As some of you might of noticed I just released naith, which is quite a complex little beast, and in the process of packaging I bumped into quite a few issues (Not surprising, given that this is the first release of the packp3d system!). This seems as good a place as any to report them, so, to start (And apologies for the length of this - I appear to be in a wordy mood.):
-
It doesn’t support upper case letters in .py files. No really (Gives the same error as if you have no init.py).
-
packp3d won’t include xml files. I had to use a multify -r call to add them in! (I generally think that packp3d’s interface is too limited - it needs more options. I understand you can switch to using the pdef system, but I couldn’t figure that out. There does seem to be quite a jump in the complexity of packaging if you pass a fairly low level of complexity in your application however.)
-
The mutify -r command resets the pre-file text string and permissions of the file, so packp3d kicks out a perfectly nice file that you can run under linux as ./my_file.p3d, and then multify breaks it. Easy enough to fix using -P “#! /usr/bin/env panda3d” and a chmod, but thought I would mention it (Can’t decide if I would fix this one myself - probably better to make sure you would never need to use this tool anyway, though you will never get all cases.).
-
The entire imp module doesn’t work when running from a p3d file - I had to rewrite my entire plugin system to use include. (Which is admittedly probably neater, but it took a lot of head scratching to figure out what was happening, and to get there.) (This leads into the whole init requirement - the system currently assumes a simple import hierarchy - when you have a plugin system this assumption starts to impede.)
-
Paths are inconsistent - sometimes you have to prepend base.appRunner.multifileRoot (But only if the program is running in a multifile, and I hate environment dependent code - that you don’t have to do that is one of pandas best features!) For instance, you don’t have to prepend it when loading textures or meshes, but you do when loading shaders or using the standard ‘open’.
-
And, now for the strangest of them all - converting an OdeBody to a string gives an empty string inside a .p3d file, but a unique string if run normally. It took me about 2 hours to work back and figure that was the cause of one of those entirely unhelpful ode error messages. (On the subject of which, the getId() method of OdeBody, which was meant precisely to solve this problem, and is in the api reference, does not actually exist.)
Well, those are the once I can remember, and for a couple of them its debatable if they are worth fixing. I’m also sure there were others that I passed and worked around, but that is plenty to keep you all chugging along with I’m sure;-) (And in case it matters, these all occurred under 64 bit Ubuntu.)
I can actually explain this one. There are #ifndef NDEBUG markers around the code that outputs the OdeBody. In the case of the runtime, a hyper-optimized build of Panda is used that has NDEBUG defined.
Wow, huh. I use mixed-case filenames all the time. Can you tell me more?
Use -e xml on the packp3d command line. Though it’s true that xml is a common enough extension it ought to be automatically included. I can add this to the list.
The multify -r parameter is for rebuilding the multifile. Use multify -u instead, which simply updates the existing file.
Panda does have to play games with the import hooks to support loading Python code from a multifile. We don’t replace the existing import system, though, we only add our own hooks; so I don’t know of anything that would interfere with its proper functioning. Is there something in particular that was causing you trouble?
This bugs me too. I haven’t yet found a satisfactory workaround that suits all cases, though. The shader loader should work as path-free as the model loader, though; it works fine for me.
Hmm, those NDEBUG markers are probably a mistake. I don’t know why we’d want to avoid that code in an optimized build.
David
With regards to the upper case names I’m not so sure now - I attempted to replicate it but couldn’t. It was certainly the case that changing some filenames from containing uppercase to all lower case (And it happened to be all the filenames that had uppercase in.) got me around a problem - I hence assumed that was the issue. Haven’t the foggiest at this point though - can’t revert my code to that state and test it again. I’ld ignore it for now and see if someone else complains (Even though it will probably be me!).
With regards to the imp module its the case that none of the methods provided (I tried to do it several ways.) will allow me to load a python file from inside the multi file. I do note that the module gives a warning that you can’t feed it ‘file equivalents’ - i.e. it requires as input a file object, not an object that provides the same interface. I’m wondering if it in some way hard coded and missing your hooks. That seems kinda crazy however - I had always assumed that the import statement was directly equivalent to the right sequence of calls to that module. Another alternative is, for some reason, its not searching in the right place - I tried the filenames both relative and with base.appRunner.multifileRoot in front of them, and neither worked though. Honestly I’m quite confused by this one.
Thanks for the command line options btw - I missed them:-)
Note that the contents of the p3d are in the virtual file system, so you should pass a file object (from direct.stdpy import * to get a file() equivalent that works with the VFS) rather than a path.
Secondly, by default, the python files in the p3d are compiled as .pyo. There are no raw .py files in there by default.
Right, actually, the import statement is equivalent to a call to the import() function, which is probably a better way to make a dynamic import call than using the low-level functions in the imp module. The imp module exists mainly to provide access to the import hooks; I don’t think the Python developers expect you to use the imp module to actually import modules.
I am a little surprised that imp.find_module() isn’t finding the vfs modules, though; it must be the case that imp.find_module() (and presumably imp.load_module()) are only hooks into Python’s own built-in finder and loader, and do not respect any import hooks that have been added by the imp module itself. I guess that makes some sense, since I believe the purpose of these functions is for import hooks to upcall into the fundamental implementation.
David
FYI, I just removed the NDEBUG markers from the ODE classes.
OK, I finished the manual downloads:
panda3d.org/download/panda3d … python.zip
panda3d.org/download/panda3d … python.chm
panda3d.org/download/panda3d … .0-cxx.zip
panda3d.org/download/panda3d … .0-cxx.chm
Please let me know your thoughts about it. I have yet to tackle the API reference.
this time I see the chm text paragraphs centered instead left-aligned: have been made on purpose?
also: is it possible not to have the pages settled at fixed size but rather to let it wrap to the hosting application?
[size=150]Important notice for OSX users![/size]
I’ve found out that the former 1.7.0 OSX builds can make your system horribly unstable! The installer ran a script that poisoned your environment.plist file. Any OSX users are highly recommended to install the new OSX build from the download page. The updated installer will automatically run an antidote script that carefully sucks the poison out of environment.plist, and it contains a different solution for the problem the previous installer failed to solve.
New installer:
panda3d.org/download/panda3d … -1.7.0.dmg
New sources:
panda3d.org/download/panda3d … mac.tar.gz
Patch for makepanda, if you still use the old source:
panda3d.org/download/panda3d … dote.patch
Masochists can go here to install the old poisonous build:
panda3d.org/download/panda3d … SONOUS.dmg
If you use the buildbot builds, the latest OSX DMG there is depoisoned as well.
Any chance we get a revised installer for Windows? Or maybe 1.7.1 is around the corner and then it’s worth the wait 
Uh… why do you need a revised installer for Windows?
I can’t import pandaai in windows. Is it missing in that version ?
No, it’s supposed to be there.
from panda3d.ai import *I see. I used from libpandaai import * which work only in linux.
Thanks.
I’ve just put up debs for the brand new Ubuntu Maverick Meerkat.
I’ve heard talk of 1.7.1. Is there an expected release?
I’m talking generally, like in a few months or sometime next year?
Thanks,
Frankie
Matter of weeks/months.
Thank you. Thats good news 