I have been using Panda with Softimage and luckily its built in version of Python is the same as Panda (2.6.4). My export script functions properly from within the GUI, however it also has a command line mode which fails to run the script:
# ERROR : Traceback (most recent call last):
# File "<Script Block >", line 16, in <module>
# from panda3d.egg import *
# File "C:\work\sp1\Panda3D\bin\panda3d.py", line 145, in __getattr__
# mod = self.__manager__.libimport(self.__library__)
# File "C:\work\sp1\Panda3D\bin\panda3d.py", line 126, in libimport
# return cls.imp.load_dynamic(name, target)
# ImportError: DLL load failed: Invalid access to memory location.
Seems it cannot import the panda modules.
Any idea why that might happen?
I’m not sure but maybe running the command line version from the applications directory might help.
Tried but it does not make any difference.
It looks like it is finding the modules, it just can’t load them. I tried searching for info on the specific error but there is not much out there.
This sort of error could be caused be anything, though in my experience it usually means you loaded up the wrong dll somewhere. Maybe one of the SoftImage dll’s is shadowing a dll that Panda uses, though since we have named all of our dll’s to start with panda or p3d, this doesn’t seem likely. So maybe it’s something not-quite-right with the python dll’s, in spite of the fact that they have the same version number.
There is an option to use your own version of Python, so I’ll give that a try first with the exact copy that Panda uses. The copy of Python used in the GUI and command line is the exact same though. I guess it could be loading some extra stuff in one version that either makes it work or breaks it.
By playing around with the load order of plugins, I’ve found that it seems to be conflicting with Softimage’s hardware shading DLL, which contains CgFX and HLSL.
Could it be that Softimage is loading its version of one of these and Panda trying to load its own also and they are conflicting? Would that be a naming issue?
Ah, yes. I remember running into this issue with Maya. It’s probably a versioning issue–I bet SoftImage’s copy of these DLL’s are older than the ones Panda uses, or vice-versa.
The solution is to delete or rename the older copy, and let the newer version be loaded. The newer one should be compatible with both systems.
Well that seems to have been a separate problem, copying the newer Cg DLLs from Softimage into Panda did fix the Cg problem. Previously I had to do my Panda imports inside of each function that used Panda to ensure they would load after all of the default Softimage DLLs, now it doesn’t matter anymore.
Panda still will not import in the Softimage command line mode, though.
I suppose I could just mirror Panda’s EGG classes into pure Python which would be a bit slower but more compatible.
That sounds like a lot of work. I bet you can figure out the dll problem with a lot less effort. There’s no reason in principle you shouldn’t be able to load from within SoftImage; it must be just something in the SoftImage environment that you haven’t found yet.
Well that is the very strange thing, is that it does load in Softimage, just not their command-line mode.
I even tried a bare bones build of Panda with everything disabled except for python and pandatool.
The thing is I have no idea where to start with the import problem, but I do know exactly how I would write out the Python code. I do have a bunch of code lying around from a previous version of the exporter that just manually wrote out the EGG files, so it shouldn’t be too much work.
Another benefit is I would be able to run in 64 bit mode, unless it is possible to compile a 64 bit Panda, but if I remember correctly it is not supported. Still, that is a bit of a tangent and not the issue.
Well, I would start by comparing the contents of sys.environ between the working and nonworking environments to see what, if anything, is different there.
For the record, it is certainly possible to compile 64-bit Panda, but it means you also have to compile all of the third-party libraries to use 64-bit too. Since this is a lot of work, no one has bothered to do it yet.
I ended up writing my own EGG classes last night, turns out they even edge out the C++ library in performance by a whisker!
Of course they are only a skeleton supporting the few basic functions that I needed, but the functions that are there are syntax-compatible with Panda’s. I might return to this at a later time for the proper fix.
Here is my module for anyone interested: http://www.novuscom.net/~spacebullet/out/puregg.py
It might be useful in the situation where you need write EGG files but want to be 100% portable. Feel free to do with it what you will.