The answer is - right now, there’s nobody at ETC working on an OSX port. We just don’t have the manpower right now. Besides, we don’t have any macs. I also believe there’s nobody at Disney working on an OSX port.
I don’t know whether or not this would be a very hard thing to do. Who knows… it already runs under Linux, SGI, and Windows, so it must already contain most of the code you need.
Looking forward to an OSX port… even if its just an X11 port for now. What happened? Earlier, there was talk of an OS X port. Did it all kinda fizzle? Did the guy doing it graduate?
Good work in trying to bring together lots of VR tools. Hope it helps unify the field.
At Disney, we do still have plans to finish the OSX port eventually, but the effort has been temporarily postponed while our engineers work on more immediate issues.
Since OSX is derived from BSD, which is very similar to Linux, one would think that an OSX port would be pretty simple. In practice, it appears that many fundamental things have been changed in the OSX implementation, such as the mechanism by which third-party libraries are linked in, the way static initialization is performed, and other silly fiddly little things that make the port a bit harder than you’d expect.
A couple of people, outside of CMU or Disney, have offered to contribute from time to time, and seemed to make some progress, but then they went away without contributing anything, so we don’t really know what happened.
I spent a bit of time on this this evening. Due to the custom build system, the port is likely to be somewhat painful. I haven’t even got around to figuring out how Panda3D opens a window yet, which is likely to be the other tricky bit…
In thirdparty/linux-libs-a, there are these files that are required:
libfftw.a
librfftw.a
libfmod-3.74.so
libpandanspr4.so
libpandaplc4.so
libpandaplds4.so
libCg.so
libCgGL.so
libquat.a
libvrpn.a
I know what fmod, Cg and CgGL are, and obtaining them for the Mac is not a problem. For the rest, I have no idea. Can anyone help me out?
Furthermore, please realize that Panda can be built without any of the thirdparty libraries. They all just provide support for optional features, such as compressed animation files. (Some of these features some might not consider “optional”, such as Python scripting, or even OpenGL rendering, but the fact is that Panda can compile without them and can still do useful work.)
In any porting effort, it would make sense to get core Panda working first, without any of this add-on stuff.
using makepanda.py --nothing I’ve got a bit further.
Now it says
Cannot find source file fdisplay_composite1.cxx
Sure enough, that file doesn’t exist. Should it? Its name seems to be hardcoded into makepanda.py, and it’s only mentioned in one place in that file, suggesting it’s not supposed to be a product of another build step.
This really doesn’t seem worth the effort. Panda3d really is the biggest bloated mess of dubious C++ code, and my computer is barely usable as it chugs away at the compilation
Anyway, in case someone else can benefit from what I’ve done, I’ve put a patch for the 1.0.3 tarball here: onesadcookie.com/~keith/panda3d-1.0.3.patch
which gets you as far as reported in my last message.
Good luck to anyone in their future efforts to port this…
Where you have replaced the occurrence of “glxdisplay_composite1.cxx” with “fdisplay_composite1.cxx”. Perhaps this is an unintentional typo? It probably explains your error above.
The compilation time is just absurd and annoying. C++ files shouldn’t need 600+ MB of RAM to compile. The quality of code is as judged by the number of warnings spewed out during the build.
I’ve put the fixed patch up at the same URL. It doesn’t get much further – barfs trying to parse glext.h. I’ve tried defining various things for interrogate, but nothing seems to help, and the error message is totally uninformative.
Do you mean, interrogate fails trying to parse glext.h, or do you mean the compiler fails? If it is interrogate, that’s strange, since interrogate isn’t supposed to run on any of the OpenGL code (and you probably should start out with interrogate disabled anyway, and even OpenGL for that matter, until you’ve got the core code ported). If it is the compiler, that’s a different problem, and glext.h isn’t even part of our code anyway–it was downloaded from opengl.org.
I agree that it would be nice if compilers didn’t consume many megabytes of ram and vast numbers of CPU cycles. And it would certainly be nice if they gave useful and informative error messages. But C++ is a big, complicated language, and Panda3D contains a lot of code.
I don’t know what you’re talking about when you complain about warnings. Every different version of a compiler has its own set of pet peeves it issues warnings about; we make an effort to keep compiler warnings to a minimum (zero) on the compilers we use every day. Nothing I can do about warnings on a compiler I’ve never used before.