Any one up for OSX work.


#179

Although it’s only useful for compressing animation tables into Panda’s binary bam format, I had to make the following changes for FFTW support.

In my Config.pp:

#define FFTW_IPATH /opt/local/include
#define FFTW_LPATH /opt/local/lib
#define FFTW_LIBS drfftw

In panda/src/mathutil/fftCompressor.cxx I had to change the include from “rfftw.h” to “drfftw.h”.

Again, I’m including the diff for completeness.

--- panda3d-1.5.0/panda/src/mathutil/fftCompressor.cxx	2007-06-22 05:33:47.000000000 -0700
+++ panda3d-1.5.0-patch/panda/src/mathutil/fftCompressor.cxx	2008-03-28 17:58:13.000000000 -0700
@@ -34,7 +34,7 @@
 #ifdef howmany
 #undef howmany
 #endif
-#include "rfftw.h"
+#include "drfftw.h"
 
 // These FFTW support objects can only be defined if we actually have
 // the FFTW library available.

These changes appear to be necessary because the library and include files are named differently when installed from MacPorts.


#180

I have encountered a problem while trying to use ode (libpode).

the problem is that the module is named libpode.dylib/.so, the init function it searches at python import (genPyCode) is _initlibpode:
ImportError: Loaded module does not contain symbol _initlibpode

however it does contain a function which probably could be found using the name _initlibode. Just changing the name from libpode.dylib (and .so) to libode.dylib/.so doesnt help as it’s conflicting the the “real” libode.dylib.

Is there a way to change the panda ode library to be named pode instead of ode (internally), this should solve the problem afaik.

PS: sorry im got a cold and my mind is a bit clouded :wink: I hope you understand me never the less.

<problem solved, see next post>


#181

I have found a way to be able to compile libpode as libode, by changing:

  • the ppremake from pode to ode
  • renaming the files pode_composite(1,2,3).cxx to ode_composite(1,2,3).cxx

however that doesnt solve the lib linking problem, as it’s also causing a “lib conflict”.

I need some way to have all ode things named pode in panda…

Well i really had a clouded mind :slight_smile:

genPyCode works without problems if i genPyCode libpandaode (not libpode)


#182

i downloaded the panda 1.5.4 source and built, more or less according to the instructions at edalytical (thanks!), and was able to genPyCode, etc. however, when i try to import DirectStart, i get the following:

>>> import direct.directbase.DirectStart
DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
:display: loading display module: libpandagl.dylib
:display: Unable to load: dlopen(libmkl_def.dylib, 1): image not found
Known pipe types:
(all display modules loaded.)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/panda/lib/direct/directbase/DirectStart.py", line 4, in ?
    ShowBase.ShowBase()
  File "/usr/local/panda/lib/direct/showbase/ShowBase.py", line 241, in __init__
    self.openDefaultWindow(startDirect = False, props=props)
  File "/usr/local/panda/lib/direct/showbase/ShowBase.py", line 679, in openDefaultWindow
    self.openMainWindow(*args, **kw)
  File "/usr/local/panda/lib/direct/showbase/ShowBase.py", line 754, in openMainWindow
    self.openWindow(*args, **kw)
  File "/usr/local/panda/lib/direct/showbase/ShowBase.py", line 521, in openWindow
    self.makeDefaultPipe()
  File "/usr/local/panda/lib/direct/showbase/ShowBase.py", line 463, in makeDefaultPipe
    self.notify.error(
  File "/usr/local/panda/lib/direct/directnotify/Notifier.py", line 130, in error
    raise exception(errorString)
StandardError: No graphics pipe is available!
Your Config.prc file must name at least one valid panda display
library via load-display or aux-display.
>>> 

does anyone know what libmkl_def is or how that name might be generated? doesn’t sound like a display pipe to me.

jeremy


#183

Never heard of it. It’s certainly not part of Panda; maybe it’s part of your system or your OpenGL drivers?

David


#184

no such file exists on my machine.

the error is coming from GraphicsPipeSelection::load_named_module(), but i’m not sure how the const string& name parameter is getting set to mkl_def for synthesis.

i know there is significant magic involved in the loading of prc files. as i recall, it involves looking in ./etc and then tracing the path up to the root directory, looking in etc at each step along the way. after that fails, $INSTALL_DIR/etc is checked or something like that…? what is the specific magic on OSX?

i checked the loaded config object (though i don’t know which file it was loaded from), and

>>> config.GetString('load-display')
'pandagl'
>>>

so i’m a bit confused. i feel like i must be way off track.


#185

The loading of prc files is not that magical. It looks in various directories, but doesn’t make up a completely new filename. The loading of the display modules is even less magic–it doesn’t even look in various directories for that one.

So, that filename isn’t being requested by any Panda code. It must be loaded indirectly by the dylibs that libpandagl pulls in, which is to say, by your OpenGL drivers. You can test this by calling dlopen(‘libpandagl.dylib’) or even dlopen(‘libGL.dylib’) (or whatever your OpenGL library is called) in a sample program.

David


#186

:slight_smile:

even so, i’d like to know which prc file is being loaded. is there an introspective way to get the path? otherwise, could you confirm or deny my algorithm for finding the file, so i can inspect the prc and make sure there’s no funny business going on?

i thought it was unlikely that panda would create a string with such a bizarre name, but i thought it more unlikely that the opengl rigging distributed by apple would reference an unloadable library. other opengl stuff is currently working on my machine.

jeremy


#187
print cpMgr

will print a list of all prc files loaded and where they came from. (These are the “implicit pages”, as opposed to the “explicit pages” which are loaded by explicit calls you make at runtime.)

If you can’t get DirectStart imported enough to get the cpMgr builtin, then do:

from pandac.PandaModules import *
cpMgr = ConfigPageManager.getGlobalPtr()
print cpMgr

You can also see which file specifically defined load-display with:

print ConfigVariableString('load-display')

David


#188

i’ve been working on this and am confused thusly:

in python, loading libpandagl fails, complaining about libmkl_def.dylib:

>>> selection = GraphicsPipeSelection.getGlobalPtr()
>>> selection.printPipeTypes()
:display: loading display module: libpandagl.dylib
:display: Unable to load: dlopen(libmkl_def.dylib, 1): image not found
Known pipe types:
(all display modules loaded.)
>>> 

in c this code

	void * x = dlopen("/usr/local/panda/lib/libpandagl.dylib",1);

	printf("%i\n",x);

	if (x == (void *)NULL){
		printf("fail\n");
		printf("%s\n",dlerror());
	}
	else printf("pass\n");

loading fails with a different message:

% ./libtest
0
fail
dlopen(/usr/local/panda/lib/libpandagl.dylib, 1): Symbol not found: _PyObject_Free
  Referenced from: /usr/local/panda/lib/libinterrogatedb.dylib
  Expected in: dynamic lookup

for completeness, opengl loads fine (no surprise, since other opengl programs have been running):

	void *  = dlopen("/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib",1);

	printf("%i\n",x);

	if (x == (void *)NULL){
		printf("fail\n");
		printf("%s\n",dlerror());
	}
	else printf("pass\n");

yeilds

% ./libtest
1049136
pass

so libpandagl fails in two different ways. the problem in the c instance seems to be some sort of library path problem, but i haven’t explored that fully.

let me also mention that i’ve successfully built and run a 1.4.x panda from CVS in the past. i can’t be certain of the exact version – it was about 15 months ago. the main differences between that (working) time and this are: building with support for opencv and nvidia cg. i also upgraded the cg framework on this machine, but since it wasn’t incorporated in the last build, i wouldn’t imagine that has much to do with it.

jeremy


#189

Hmm, wait, you mean this build–the first build that doesn’t work–is also the first build that links with Cg? That sounds highly suspicious to me. Try making a build without Cg, to see if that one works.

David


#190

success.

i rebuilt w/o cg support and ran into the problem described in this thread:

discourse.panda3d.org/viewtopic.php?t=5036

after setting up my PRC_PATH and adding the plugin-path directive to the Config.prc, everything worked fine.

so i went back and built with cg and i’m now able to open a window. ironically, i can’t really test functionality of the cg bits because i have an ati card.

incidentally, where can i find more information on this plugin-path change?

jeremy


#191

Even though Cg is an NVidia product, it does work fine on ATI cards, at least those ATI cards that support shaders at all. That’s one of the selling points of Cg: it’s platform-independent, and works on all shader-capable cards, on OpenGL and on DirectX.

What do you want to know about the plugin-path change?

David


#192

By default, the plugin-path is set to /lib (or something like that) but doesn’t seem to work quite well on OSX. I thought I fixed that, but apparently I didn’t.
Normally you wouldn’t need to set it, but only on OSX, for this reason.


#193

i’ve heard this, too. but my experience, and those of people i’ve worked with, is that ati’s cg support is fairly poor.

on the other hand, i just assumed that was the problem when the toon shader example failed. when running the (basic) demo, i get a blank screen with this error at the bottom of the window:

"Toon Shader: Video card not powerful enough to do image postprocessing"

maybe the bamboo stuff is failing in some other way, but CommonFilters.filters.setCartoonInk() returned false.

the advanced demo, on the other hand, failed in a different way:

:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (16) : warning C7011: implicit cast from "float4" to "float3"
:gobj(error): /usr/local/src/panda3d-1.5.4/samples/Cartoon-Shader/lightingGen.sha: (29) : fatal error C9999: *** exception during compilation ***
Segmentation fault

many other programs involving shaders fail in various ways. those that explictly load .sha shader files (as opposed to using the new-fangled auto generated ones) pause/load for a long time before posting any of the above errors, and then again before finally segfaulting. there’s no such thing as a software implementation of cg to my knowledge, so i’m not sure what the hangs could be about.

the card is plenty capable (assuming that ati is not the barrier) – its r520 architecture is on par with nvidia’s g70, supporting shader model 3.0, etc. in particular, it’s the x1800 mobile part.

jeremy


#194

this is resolved. i did have another version of the cg framework installed somewhere.

however, i still haven’t been able to get CommonFilters-related code to function as expected.


#195

I think the problem is that ppremake doesn’t copy the .sha files on a “make install” from the direct/src/filter dir to the panda_install_dir/lib/direct/filter/ dir. You need to copy them manually.

Also, about the “not powerful enough” bug, this will be fixed in the upcoming 1.6.0 release.


#196

@pro-rsoft: regarding the Feb.23rd bundle you made available of 1.6.0-pre, I can attest to that the “Not powerful enough” bug is there (I have a Mac Pro with nVidia 8800/512).

Also, if I enable setShaderAuto(), my project crashes (no sensible messages tho :neutral_face:)

But thanks for your efforts :slight_smile: Without you I’d be stuck using an old PC :stuck_out_tongue:


#197

I’ve only very recently checked in those changes. I only tested them on linux. I just noticed that in the source, the buffer code in make_output is mainly uncommented. That won’t get us very far.
I have no idea how the buffer code is supposed to work on OSX.

If I only had a Mac with a graphical display I would have been able to debug and fix this. :frowning:


#198

Oh, I’ve just updated the DMG, it should contain the FBO fixes now, in case you want to try it.