Re: [osg-users] OpenSceneGraph and Mac OS X
Stephan,
I think I've found the issue - it seems that the AvailableReaderWriterIterator
isn't being used safely.
In ReaderWriter::ReadResult Registry::read(const ReadFunctor& readFunctor)
you'll find:
> // first attempt to load the file from existing ReaderWriter's
> AvailableReaderWriterIterator itr(_rwList, _pluginMutex);
> for(;itr.valid();++itr)
> {
> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr);
> if (readFunctor.isValid(rr)) return rr;
> else results.push_back(rr);
> }
and later on…
> // now look for a plug-in to load the file.
> std::string libraryName = createLibraryNameForFile(readFunctor._filename);
> if (loadLibrary(libraryName)!=NOT_LOADED)
> {
> for(;itr.valid();++itr)
> {
> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr);
> if (readFunctor.isValid(rr)) return rr;
> else results.push_back(rr);
> }
> }
The first loop runs through the iterator until itr.valid() returns false.
The second loop never runs because itr.valid() immediately returns false, or
because a compiler optimization assumed that it would return false.
I suspect that when loadLibrary is called, the library is inserted into
_rwList, which would cause itr.valid() to return true, but it appears that the
second call (and the loop it's in) were optimized away.
The following code
> // now look for a plug-in to load the file.
> std::string libraryName = createLibraryNameForFile(readFunctor._filename);
> if (loadLibrary(libraryName)!=NOT_LOADED)
> {
> AvailableReaderWriterIterator itr(_rwList, _pluginMutex);
> for(;itr.valid();++itr)
> {
> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr);
> if (readFunctor.isValid(rr)) return rr;
> else results.push_back(rr);
> }
> }
appears to fix the issue.
There's probably a way to tell the compiler that it can't optimize that call
away (careful placement of a volatile keyword?) but someone more familiar with
that aspect of C++ would have to do it.
This all begs the question: How does one submit a bug report for openscenegraph?
- Ron
On Nov 12, 2013, at 1:01 PM, Ronald Aldrich wrote:
> Stephan,
>
> I've re-organized my application to match your layout as best I can. It
> appears that I've built a debug build, rather than a release build. I
> haven't been able to figure out how to make a release build using XCode 5
> (This begs the question: What version of XCode and MacOS X are you using?).
>
> One issue I'm running into is that I cannot step and trace anything within
> the OSG library. I'm pretty sure that it's because the modification dates
> between the library as built, and as copied into my application bundle are
> different.
>
> As far as I can tell both the OSG framework and the plugins are loading
> correctly - Still, reading a .OSG file doesn't work.
>
> I think the error messages are a bit of a red herring - I added trail of
> bread crumbs (printf statements) so I could see what's happening.
>
>> FindFileInPath() : USING
>> /Users/raldrich/Documents/fu/osgviewercocoa/DerivedData/osgviewercocoa/Build/Products/Debug/osgviewercocoa.app/Contents/PlugIns/osgdb_osgd.so
>> Opened DynamicLibrary osgPlugins-3.2.0/osgdb_osgd.so
>> LOADED
>> LOADED
>> Warning: Could not find plugin to read objects from file
>> "/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg".
>> 2013-11-12 12:33:43.629 osgviewercocoa[85734:303] File:
>> /Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg
>> failed to load
>
> The log entry "Opened DynamicLibrary…" comes from
> DynamicLibrary::DynamicLibrary(name, handle), which shouldn't be reachable if
> the library doesn't load.
> The first "LOADED" log entry comes from Registry::loadLibrary(filename), and
> changes to "PREVIOUSLY_LOADED" the second time I try to load a file.
> The second "LOADED" log entry comes from Registry::read(readfunctor)
>
>> // now look for a plug-in to load the file.
>> std::string libraryName =
>> createLibraryNameForFile(readFunctor._filename);
>> if (loadLibrary(libraryName)!=NOT_LOADED)
>> {
>> printf("LOADED\r");
>>for(;itr.valid();++itr)
>> {
>> printf("loop, reading\r");
>> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr);
>> if (readFunctor.isValid(rr)) return rr;
>> else results.push_back(rr);
>> }
>> }
>> else
>> {
>> printf("NOT_LOADED\r");
>> }
>
>
> The "Warning: Could not find plugin…" is a misnomer - The warning is
> generated if the model couldn't be read, regardless of why.
>
> Here's the interesting bit though - you'll notice that I added "printf("
> loop, reading\r");" inside the read loop, and it's never being reached.
Re: [osg-users] OpenSceneGraph and Mac OS X
Stephan,
I've re-organized my application to match your layout as best I can. It
appears that I've built a debug build, rather than a release build. I haven't
been able to figure out how to make a release build using XCode 5 (This begs
the question: What version of XCode and MacOS X are you using?).
One issue I'm running into is that I cannot step and trace anything within the
OSG library. I'm pretty sure that it's because the modification dates between
the library as built, and as copied into my application bundle are different.
As far as I can tell both the OSG framework and the plugins are loading
correctly - Still, reading a .OSG file doesn't work.
I think the error messages are a bit of a red herring - I added trail of bread
crumbs (printf statements) so I could see what's happening.
> FindFileInPath() : USING
> /Users/raldrich/Documents/fu/osgviewercocoa/DerivedData/osgviewercocoa/Build/Products/Debug/osgviewercocoa.app/Contents/PlugIns/osgdb_osgd.so
> Opened DynamicLibrary osgPlugins-3.2.0/osgdb_osgd.so
> LOADED
> LOADED
> Warning: Could not find plugin to read objects from file
> "/Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg".
> 2013-11-12 12:33:43.629 osgviewercocoa[85734:303] File:
> /Users/raldrich/Documents/fu/OpenSceneGraph/OpenSceneGraph-Data-3.0.0/cessna.osg
> failed to load
The log entry "Opened DynamicLibrary…" comes from
DynamicLibrary::DynamicLibrary(name, handle), which shouldn't be reachable if
the library doesn't load.
The first "LOADED" log entry comes from Registry::loadLibrary(filename), and
changes to "PREVIOUSLY_LOADED" the second time I try to load a file.
The second "LOADED" log entry comes from Registry::read(readfunctor)
> // now look for a plug-in to load the file.
> std::string libraryName = createLibraryNameForFile(readFunctor._filename);
> if (loadLibrary(libraryName)!=NOT_LOADED)
> {
> printf("LOADED\r");
>for(;itr.valid();++itr)
> {
> printf("loop, reading\r");
> ReaderWriter::ReadResult rr = readFunctor.doRead(*itr);
> if (readFunctor.isValid(rr)) return rr;
> else results.push_back(rr);
> }
> }
> else
> {
> printf("NOT_LOADED\r");
> }
The "Warning: Could not find plugin…" is a misnomer - The warning is generated
if the model couldn't be read, regardless of why.
Here's the interesting bit though - you'll notice that I added "printf("
loop, reading\r");" inside the read loop, and it's never being reached. I have
no idea why, except that itr.valid must be returning false.
Any ideas?
TIA,
Ron Aldrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting breakpoints when using osg as library
Bram, My experience is from Mac OS, but it might be relevant. I'm finding that when XCode copies files from one location to another, it doesn't always maintain the file's modification date, which the dynamic loader uses to check the validity of the debugging info. As a result, I can't trace into a library unless I leave it where it was built, or add a post process to set the modification date. - Ron On Nov 12, 2013, at 1:24 AM, Bram Vaessen wrote: > Hi Sebastian, > > Yes I built OSG from source myself, using CMake and VC++ 2010 Express (I just > followed the tutorial on this). The strange thing is: when I press f11 during > debug in a call to OSG for example viewer->someFunction(), it first goes into > the ref_ptr overloaded operator code, then back to the original line, and > then if I press F11 one more time, it just jumps to the next line, without > jumping to the osg function code or asking me to find the PDB. > > Any idea why that is? Is there something broken in my VC++? > > Anyway, the Debug->Windows->Modules tab is something that I was looking for: > information on what is loaded and the possibility to manually load PDB's. > Maybe that works, or at least it will give some error when it fails. I'll try > it! > > > > > Thank you! > > Cheers, > Bram > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=57192#57192 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Texture2DMultisample
Its in osgUtil/RenderStage.cpp. Just search for glBlitFramebuffer.
Cheers,
Wojtek
2013/11/12 Sebastian Messerschmidt
> Hi Wojciech,
>
>
> Thank you for the very extensive explanation and tests.
> It seems it is either a driver problem or I solved the problem
> accidentally. Tests on my office PC worked with setting up multisampled
> textures bound to a non-multisampled FBO. I'm able to "resolve" them
> manually in the shader via texelFetch.
> So if I get it correctly there is no implict blit if FBO is 0/0
> multisamples and bound texture is multisampled.
> Btw: Can you point me to the line where the implicit blitting is done, so
> I can debug it?
>
> cheers
> Sebastian
>
> Hi,
>
> Ok. I used verb copy to avoid verb resolve, not being sure how advanced
> you are... But yes that 'copy' is a resolve operation using
> glBlitFramebuffer internally.
>
> I have not tried multisampled textures as multirender targets so I guess
> your case is bit more complex and I guess its the reason why your results
> vary. My observations described earlier, come from experiment with single
> color and single depth multisampled textures attached as COLOR and DEPTH
> attachments. Attaching them with samples / color samples = 0 was creating
> single FBO and rendered directly to these textures. Attaching with samples
> / color samples = 8 was internally creating render and resolve FBOs. First
> render FBO was rendering to Renderbuffer with 8 samples. And attachment
> multisample textures were bound to second resolve FBO. So final
> glBlitFarmebuffer was 'copying' contents from Renderbuffer to my
> multisampled textures. With first case (samples/color samples = 0) I was
> still able to use the textures as input to some other shaders by declaring
> them as sampler2DMS uniforms. Below is my shader I used to 'resolve' the
> textures myself in input phase.
>
> #version 150
> #extension GL_ARB_texture_multisample : enable
> uniform sampler2DMS colorTex;
> uniform sampler2DMS depthTex;
>
> const int NUM_SAMPLES = 8;
> const float NUM_SAMPLES_INV = 1. / float( NUM_SAMPLES );
>
> void main( void )
> {
>ivec2 itc = ivec2( gl_FragCoord.xy );
>float depth = 0.;
>vec4 color = vec4(0.);
>for ( int i=0; i depth += texelFetch( depthTex, itc, i ).x;
> color += texelFetch( colorTex, itc, i );
>}
>gl_FragDepth = depth * NUM_SAMPLES_INV;
>gl_FragColor = color * NUM_SAMPLES_INV;
> }
>
> Cheers,
> Wojtek
>
>
>
>
> 2013/11/12 Sebastian Messerschmidt
>
>> Am 11.11.2013 22:44, schrieb Wojciech Lewandowski:
>>
>> Hi,
>>
>> I guess answer to main question would be go ahead and add this.
>>
>> Okay, I just wanted to make sure they are not left out intentionally.
>>
>> But I just want to write about something else here. If you attach
>> Texture2DMultisample to Camera you would want to leave the number of
>> samples and color samples at 0. Thats because these params are used to set
>> up rendering to multisampled Renderbuffer objects and in post step that
>> Renderbuffer is copied to attached texture. If you set Texture2DMultisample
>> and additionaly set numbers of samples in attach it will do rendering to
>> Renderbuffer and then will copy the result to your Texture2DMultisample
>> attachment. I guess its not what you are after.
>>
>> That is strange. In this case I need some explanation. I want to render
>> several multisampled color attachments and resolve them in later passes. In
>> this case I create a multisampled color texture and attach it to the
>> camera. In consecutive passes I rebind those textures as input and resolve
>> them there. If I leave the colorsamples and sample count at the FBO I get a
>> FRAMEBUFFER_ATTACHMENT_INCOMPLETE error for the first pass. Setting them
>> solved the problem and I got a correct rendering.
>> So what is the correct thing to do here?
>>
>> You mentioned a copy. I always thought binding a texture to a FBO and
>> reusing it later in another FBO will not copy it, so I'm quite puzzled. Am
>> I'm doing something fundamentally wrong here?
>>
>> cheers
>> Sebastian
>>
>>
>> Cheers,
>> Wojtek Lewandowski.
>>
>>
>> 2013/11/11 Sebastian Messerschmidt
>>
>>> Hi,
>>>
>>> maybe this seems like s stupid question but why does
>>> osg::Texture2DMultisample does not have a getNumSamples() function?
>>> This might come in handy if, like in my case, a texture is passed around
>>> for MRT binding (camera->attach), to determine the number of samples for
>>> the attach function.
>>> Would it be okay to add the get function?
>>>
>>> cheers
>>> Sebastian
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>>
>> ___
>> osg-users mailing
>> listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>> ___
Re: [osg-users] composite viewer: fixed view size on resize event
Hi All, I would add that, even if someone like the view resizing inside a compsite viewer, it does not properly work. In fact its content is resized resizing the window vertically, but resizing the window horizontally its content is not resized at all. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57195#57195 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Texture2DMultisample
Hi Wojciech,
Thank you for the very extensive explanation and tests.
It seems it is either a driver problem or I solved the problem
accidentally. Tests on my office PC worked with setting up multisampled
textures bound to a non-multisampled FBO. I'm able to "resolve" them
manually in the shader via texelFetch.
So if I get it correctly there is no implict blit if FBO is 0/0
multisamples and bound texture is multisampled.
Btw: Can you point me to the line where the implicit blitting is done,
so I can debug it?
cheers
Sebastian
Hi,
Ok. I used verb copy to avoid verb resolve, not being sure how
advanced you are... But yes that 'copy' is a resolve operation using
glBlitFramebuffer internally.
I have not tried multisampled textures as multirender targets so I
guess your case is bit more complex and I guess its the reason why
your results vary. My observations described earlier, come from
experiment with single color and single depth multisampled textures
attached as COLOR and DEPTH attachments. Attaching them with samples /
color samples = 0 was creating single FBO and rendered directly to
these textures. Attaching with samples / color samples = 8 was
internally creating render and resolve FBOs. First render FBO was
rendering to Renderbuffer with 8 samples. And attachment multisample
textures were bound to second resolve FBO. So final glBlitFarmebuffer
was 'copying' contents from Renderbuffer to my multisampled textures.
With first case (samples/color samples = 0) I was still able to use
the textures as input to some other shaders by declaring them as
sampler2DMS uniforms. Below is my shader I used to 'resolve' the
textures myself in input phase.
#version 150
#extension GL_ARB_texture_multisample : enable
uniform sampler2DMS colorTex;
uniform sampler2DMS depthTex;
const int NUM_SAMPLES = 8;
const float NUM_SAMPLES_INV = 1. / float( NUM_SAMPLES );
void main( void )
{
ivec2 itc = ivec2( gl_FragCoord.xy );
float depth = 0.;
vec4 color = vec4(0.);
for ( int i=0; i2013/11/12 Sebastian Messerschmidt >
Am 11.11.2013 22:44, schrieb Wojciech Lewandowski:
Hi,
I guess answer to main question would be go ahead and add this.
Okay, I just wanted to make sure they are not left out intentionally.
But I just want to write about something else here. If you attach
Texture2DMultisample to Camera you would want to leave the number
of samples and color samples at 0. Thats because these params are
used to set up rendering to multisampled Renderbuffer objects and
in post step that Renderbuffer is copied to attached texture. If
you set Texture2DMultisample and additionaly set numbers of
samples in attach it will do rendering to Renderbuffer and then
will copy the result to your Texture2DMultisample attachment. I
guess its not what you are after.
That is strange. In this case I need some explanation. I want to
render several multisampled color attachments and resolve them in
later passes. In this case I create a multisampled color texture
and attach it to the camera. In consecutive passes I rebind those
textures as input and resolve them there. If I leave the
colorsamples and sample count at the FBO I get a
FRAMEBUFFER_ATTACHMENT_INCOMPLETE error for the first pass.
Setting them solved the problem and I got a correct rendering.
So what is the correct thing to do here?
You mentioned a copy. I always thought binding a texture to a FBO
and reusing it later in another FBO will not copy it, so I'm quite
puzzled. Am I'm doing something fundamentally wrong here?
cheers
Sebastian
Cheers,
Wojtek Lewandowski.
2013/11/11 Sebastian Messerschmidt
mailto:sebastian.messerschm...@gmx.de>>
Hi,
maybe this seems like s stupid question but why does
osg::Texture2DMultisample does not have a getNumSamples()
function?
This might come in handy if, like in my case, a texture is
passed around for MRT binding (camera->attach), to determine
the number of samples for the attach function.
Would it be okay to add the get function?
cheers
Sebastian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-
Re: [osg-users] osg::Texture2DMultisample
Hi,
Ok. I used verb copy to avoid verb resolve, not being sure how advanced you
are... But yes that 'copy' is a resolve operation using glBlitFramebuffer
internally.
I have not tried multisampled textures as multirender targets so I guess
your case is bit more complex and I guess its the reason why your results
vary. My observations described earlier, come from experiment with single
color and single depth multisampled textures attached as COLOR and DEPTH
attachments. Attaching them with samples / color samples = 0 was creating
single FBO and rendered directly to these textures. Attaching with samples
/ color samples = 8 was internally creating render and resolve FBOs. First
render FBO was rendering to Renderbuffer with 8 samples. And attachment
multisample textures were bound to second resolve FBO. So final
glBlitFarmebuffer was 'copying' contents from Renderbuffer to my
multisampled textures. With first case (samples/color samples = 0) I was
still able to use the textures as input to some other shaders by declaring
them as sampler2DMS uniforms. Below is my shader I used to 'resolve' the
textures myself in input phase.
#version 150
#extension GL_ARB_texture_multisample : enable
uniform sampler2DMS colorTex;
uniform sampler2DMS depthTex;
const int NUM_SAMPLES = 8;
const float NUM_SAMPLES_INV = 1. / float( NUM_SAMPLES );
void main( void )
{
ivec2 itc = ivec2( gl_FragCoord.xy );
float depth = 0.;
vec4 color = vec4(0.);
for ( int i=0; i
> Am 11.11.2013 22:44, schrieb Wojciech Lewandowski:
>
> Hi,
>
> I guess answer to main question would be go ahead and add this.
>
> Okay, I just wanted to make sure they are not left out intentionally.
>
> But I just want to write about something else here. If you attach
> Texture2DMultisample to Camera you would want to leave the number of
> samples and color samples at 0. Thats because these params are used to set
> up rendering to multisampled Renderbuffer objects and in post step that
> Renderbuffer is copied to attached texture. If you set Texture2DMultisample
> and additionaly set numbers of samples in attach it will do rendering to
> Renderbuffer and then will copy the result to your Texture2DMultisample
> attachment. I guess its not what you are after.
>
> That is strange. In this case I need some explanation. I want to render
> several multisampled color attachments and resolve them in later passes. In
> this case I create a multisampled color texture and attach it to the
> camera. In consecutive passes I rebind those textures as input and resolve
> them there. If I leave the colorsamples and sample count at the FBO I get a
> FRAMEBUFFER_ATTACHMENT_INCOMPLETE error for the first pass. Setting them
> solved the problem and I got a correct rendering.
> So what is the correct thing to do here?
>
> You mentioned a copy. I always thought binding a texture to a FBO and
> reusing it later in another FBO will not copy it, so I'm quite puzzled. Am
> I'm doing something fundamentally wrong here?
>
> cheers
> Sebastian
>
>
> Cheers,
> Wojtek Lewandowski.
>
>
> 2013/11/11 Sebastian Messerschmidt
>
>> Hi,
>>
>> maybe this seems like s stupid question but why does
>> osg::Texture2DMultisample does not have a getNumSamples() function?
>> This might come in handy if, like in my case, a texture is passed around
>> for MRT binding (camera->attach), to determine the number of samples for
>> the attach function.
>> Would it be okay to add the get function?
>>
>> cheers
>> Sebastian
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> ___
> osg-users mailing
> listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting breakpoints when using osg as library
Hi Sebastian, Yes I built OSG from source myself, using CMake and VC++ 2010 Express (I just followed the tutorial on this). The strange thing is: when I press f11 during debug in a call to OSG for example viewer->someFunction(), it first goes into the ref_ptr overloaded operator code, then back to the original line, and then if I press F11 one more time, it just jumps to the next line, without jumping to the osg function code or asking me to find the PDB. Any idea why that is? Is there something broken in my VC++? Anyway, the Debug->Windows->Modules tab is something that I was looking for: information on what is loaded and the possibility to manually load PDB's. Maybe that works, or at least it will give some error when it fails. I'll try it! Thank you! Cheers, Bram -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57192#57192 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph and Mac OS X
I've tried putting them directly into Plugins/, but couldn't get the loader to look there. Perhaps there's some bit of magic to tell OSG to stop appending osgPlugins-3.x.x to the library path? - Ron On Nov 12, 2013, at 12:25 AM, Stephan Maximilian Huber wrote: > HI, > > Am 12.11.2013 um 09:00 schrieb Stephan Maximilian Huber > : > >> I am using a similar bundle-layout as yours, I usually don’t use the >> osgPlugins-3.x-folder at all. All plugins are sitting in Plugins/ > > as a followup: here’s a screenshot of the bundle-layout of a working app: > > http://scrups.cefix.org//cr/thxi3jv74sc40.png > > cheers, > > Stephan > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph and Mac OS X
HI, Am 12.11.2013 um 09:00 schrieb Stephan Maximilian Huber : > I am using a similar bundle-layout as yours, I usually don’t use the > osgPlugins-3.x-folder at all. All plugins are sitting in Plugins/ as a followup: here’s a screenshot of the bundle-layout of a working app: http://scrups.cefix.org//cr/thxi3jv74sc40.png cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph and Mac OS X
Hi Ronald,
Am 12.11.2013 um 08:52 schrieb Ronald Aldrich :
> I gave up on static linking of OSG - while it worked for the main libraries,
> it didn't help with loading plugins.
static linking needs some manual work on your code side. See the
osgstaticviewer-example. Basically the linker strips all plugins out of the
product when not taking some precautions.
I am using a similar bundle-layout as yours, I usually don’t use the
osgPlugins-3.x-folder at all. All plugins are sitting in Plugins/
This is working w/o problems.
cheers,
Stephan
> So, I poked around in dyld a bit.
>
> OSG wants to find its plugins in:
> .../OSG_Viewer.app/Contents/PlugIns/osgplugins-3.2.0/
>
> Using OTool to inspect an OSG framework resulted in:
>
> otool -L
> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/Frameworks/osg.framework/osg
>
> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/Frameworks/osg.framework/osg:
> @executable_path/../Frameworks/osg.framework/Versions/100/osg
> (compatibility version 100.0.0, current version 3.2.0)
>
> @executable_path/../Frameworks/OpenThreads.framework/Versions/13/OpenThreads
> (compatibility version 13.0.0, current version 3.2.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 169.3.0)
> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 56.0.0)
>
> Using OTool to inspect a plugin resulted in:
>
> otool -L
> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgPlugins-3.2.0/osgdb_3dcd.so
>
> /Users/raldrich/Documents/fu/OSG_Viewer/DerivedData/OSG_Viewer/Build/Products/Debug/OSG_Viewer.app/Contents/PlugIns/osgPlugins-3.2.0/osgdb_3dcd.so:
>
> @executable_path/../Frameworks/OpenThreads.framework/Versions/13/OpenThreads
> (compatibility version 13.0.0, current version 3.2.0)
> @executable_path/../Frameworks/osg.framework/Versions/100/osg
> (compatibility version 100.0.0, current version 3.2.0)
> @executable_path/../Frameworks/osgDB.framework/Versions/100/osgDB
> (compatibility version 100.0.0, current version 3.2.0)
> @executable_path/../Frameworks/osgUtil.framework/Versions/100/osgUtil
> (compatibility version 100.0.0, current version 3.2.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 169.3.0)
> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 155.0.0)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
> 1.2.5)
> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 56.0.0)
>
> And the application is laid out as:
>
> OSG_Viewer.app
> Contents
> Frameworks
> {OpenSceneGraph Frameworks}
> MacOS
> OSG_Viewer
> Plugins
> osgPlugins-3.2.0
> {OpenSceneGraph Plugins}
> Resources
> {Application resources}
>
> The documentation for dyld indicates that @executable_path "is replaced with
> the path to the directory containing the main executable for the
> process.", which should be .../OSG_Viewer.app/Contents/MacOS, so to my eye,
> the linkages reported by OTool appear to be correct, but either the library
> doesn't load, or doesn't work when it is loaded.
>
> If anyone has a suggestion on how to resolve this, I'd greatly appreciate it.
>
> - Ron
>
>
> On Nov 11, 2013, at 6:16 PM, Ronald Aldrich wrote:
>
>> I tried setting OSG_BUILD_APPLICATION_BUNDLES, but couldn't see that it was
>> doing anything. At any rate, I find that XCode is better behaved (and
>> faster) when it is allowed to use its own build environment (It'll compile
>> multiple sources at once, where make is a one-at-a-time process).
>>
>> I've gotten my variant of osgViewerCocoa to compile, link, run, and display
>> the "Drag and drop here" message. The latest issue comes when I try to drag
>> an OSG document onto it (cessna.osg).
>>
>>> 2013-11-11 14:56:03.444 OSG_Viewer[53523:303] -[ViewerCocoa
>>> draggingEntered:]
>>> 2013-11-11 14:56:04.048 OSG_Viewer[53523:303] -[ViewerCocoa
>>> prepareForDragOperation:]
>>> 2013-11-11 14:56:04.049 OSG_Viewer[53523:303] -[ViewerCocoa
>>> performDragOperation:]
>>> osg::Node *osgDB::readNodeFile(const std::string &, const osgDB::Options
>>> *)(/Users/raldrich/Documents/fu/OpenSceneGraph/Op
