Hi Ron, there might be a bug in osg, but I don’t think so, as loading files and displaying them is a core feature, and more people would have stumbled over it. It works perfectly on my end BTW.
I am using currently OS X 10.9 and xcode 5 to build OpenSceneGraph. But I have used everything since 10.4 and the various xcode-versions. Is there a chance that you have an old/multiple installations of OpenSceneGraph anywhere on your computer (in one of your Lirbary folders for example)? Or old release-builds mixed with newer debug-builds? To narrow your problem down I’d start with one of the official examples like osgviewer. If the example can open an osg-file and display it then osg works as expected, so the problem is with your app or because of conflicting build-settings. These are my CMake-settings for OpenSceneGraph: OSG_COMPILE_FRAMEWORKS:BOOL=ON OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR:STRING=@executable_path/../Frameworks OSG_CXX_LANGUAGE_STANDARD:STRING=C++11 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX:STRING=imageio OSG_WINDOWING_SYSTEM:STRING=Cocoa I do usually out-of-source-builds, setting the build-binarys-folder to something different than the source-folder in cMake. When using osg-frameworks and plugins from within my app, I make sure that I use the same standard lib, copy the frameworks and plugins to the correct locations of my bundle and set the following compile-flags for my app: Inline Methods Hidden (GCC_INLINES_ARE_PRIVATE_EXTERN) to 0 Symbols Hidden by Default (GCC_SYMBOLS_PRIVATE_EXTERN) also to 0 To test osgviewer I select the target from the popup, hit "Cmd <" and add an argument to the run-schema, basically the full path to an osgt-file for example. Then I hit run. If the console reports that it can’t find the plugin I’ll check the osgPlugins-folder. (This may be necessary when compiling dylibs) That’s what I did this morning: 1. git clone https://github.com/openscenegraph/osg.git 2. start cmake, chooses xcode, set the variables, use a different build-folder, hit configure multiple times and then generate 3. open xcode-file in xcode hit „Cmd-B“, wait 15 minutes 4. Locate the osgviewer-target in the drop down, select it 5. Hit "Cmd <„ select the „Arguments“-tab, add a new argument and drop an osgt-file into it (or paste the full-path to a osgt-file into it) 6. Hit „Cmd R“ 7. Now I can see the osg-model fullscreen. Note, that this works only for the debug-build. If you switch over to release make sure, that you build the INSTALL-target, as this target sets up the dependencies-paths of the frameworks and plugins. This is mandatory to bundle the osg-frameworks + plugins with your app. cheers, Stephan Am 13.11.2013 um 04:26 schrieb Ronald Aldrich <[email protected]>: > 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 <[email protected]> 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. I >> have no idea why, except that itr.valid must be returning false. >> >> Any ideas? >> >> TIA, >> >> Ron Aldrich >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
