Re: [osg-users] Framebuffer object fails on mingw
Thanks for you reply, actually we used that site for some help but didn't follow it exactly. Maybe we should try again. Maybe the QT dist of mingw is better. Best /Filip On Fri, Apr 30, 2010 at 2:43 PM, Michael Rohn mr...@gmx.de wrote: Hi Filip, I had the problem to that I was not able to use the FBO with mingw. But on a new PC I set up my environment and build OSG by this howto: http://www.multigesture.net/articles/how-to-compile-openscenegraph-2-x-using-mingw/ http://www.multigesture.net/articles/how-to-upgrade-your-mingw-with-commonly-used-libraries/ After I done this it works. So maybe it is a solution for you too. Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27476#27476 ___ 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] Framebuffer object fails on mingw
More info: If I print the process addresses of some of the extensions like so: osg::FBOExtensions* ext = osg::FBOExtensions::instance(0,1); printf(got ext %p \n, ext); printf(Address of glFramebufferRenderbuffer : %p\n, ext-glFramebufferRenderbuffer); if (ext-isSupported()) printf(FBO is supported!\n); else printf(FBO is NOT supported!\n); I get that the extension is not supported and the address is 0. (On mac and visual studio this reports fbo support as well as a valid address) The weird thing is that OSG as a whole reports that framebuffer extensions are supported when printing debug notifications. /Filip On Fri, Apr 30, 2010 at 10:25 AM, Filip Wänström filip.wanst...@tii.se wrote: Hi, I have a very simple app that uses FBOs to do some post processing of a scene. It works great on Mac OS X and windows 7 using visual studio. When compiling for windows 7 using mingw (codeblocks) however, I get an app that crashes on framebuffer creation. The osg debug info (OSG_NOTIFY_LEVEL=DEBUG) only tells us that we DO have support for the framebuffer extension (both the EXT and the ARB version) but it crashes when trying to set up the fbo. (seems to be related to glFramebufferRenderbuffer). If we use FRAME_BUFFER (not object) as fallback it works but obviously that is not a solution. After this failure we tried to make a simple program on mingw in raw OpenGL and GLFW + GLEW that uses FBOs. It worked fine. So there is no issue with mingw and fbos in general. After this I tried to run the osg example osgprerender but it also crashes with the same problems. The same example, on the same machine built with Visual Studio 2008 (express) runs great. So, as far as I can tell there is some problem with the combination of mingw and osg. I tried to follow the osg code using both debugger and printfsin the osg source but I failed to follow all levels of indirections in the abstraction layers in order to reach a conclusion. It seems like the functions pointers are NOT NULL but erroneous. Does anyone have any idea of where to look? Or even better, a fix? Been on this for many days now and have run out of ideas... /Filip system info: win7 core i3 nvidia gtx 260 with 197 series drivers (tested a few others as well) latest codeblocks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Framebuffer object fails on mingw
Hi Robert, and thanks for your thoughts on the subject. I hoped I messed up the context setup/extension checking code but sadly I didn't, I tested the code successfully on both Windows 7 using Visual studio as well as on Mac OS X using XCode. This problem only happens on mingw when using osg. And since it crashes on the osg supplied example osgprerender I assume It's not about my app at all. The biggest issue is that there are so many parameters that could affect this. win7, the gl headers supplied by mingw (I have tested with the nvidia sdk ones as well as those distributed with mingw) osg versions, how mingw hadles defines etc etc Has anyone successfully built and run osgprerender using mingw? /Filip On Fri, Apr 30, 2010 at 12:02 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Filip, I don't enough about how you are using your code in the wider app, but the extension mechanism requires a graphics context to be able to initialize itself - perhaps this may be affecting your local test for the graphics context support. Beyond this I can't really help as I can't reproduce the problem. The best I can suggest is to try and add to step through The FBOExtensions object initialization to study what is happening w.r.t function pointers and the extension support queries. Robert. On Fri, Apr 30, 2010 at 10:47 AM, Filip Wänström filip.wanst...@tii.se wrote: More info: If I print the process addresses of some of the extensions like so: osg::FBOExtensions* ext = osg::FBOExtensions::instance(0,1); printf(got ext %p \n, ext); printf(Address of glFramebufferRenderbuffer : %p\n, ext-glFramebufferRenderbuffer); if (ext-isSupported()) printf(FBO is supported!\n); else printf(FBO is NOT supported!\n); I get that the extension is not supported and the address is 0. (On mac and visual studio this reports fbo support as well as a valid address) The weird thing is that OSG as a whole reports that framebuffer extensions are supported when printing debug notifications. /Filip On Fri, Apr 30, 2010 at 10:25 AM, Filip Wänström filip.wanst...@tii.se wrote: Hi, I have a very simple app that uses FBOs to do some post processing of a scene. It works great on Mac OS X and windows 7 using visual studio. When compiling for windows 7 using mingw (codeblocks) however, I get an app that crashes on framebuffer creation. The osg debug info (OSG_NOTIFY_LEVEL=DEBUG) only tells us that we DO have support for the framebuffer extension (both the EXT and the ARB version) but it crashes when trying to set up the fbo. (seems to be related to glFramebufferRenderbuffer). If we use FRAME_BUFFER (not object) as fallback it works but obviously that is not a solution. After this failure we tried to make a simple program on mingw in raw OpenGL and GLFW + GLEW that uses FBOs. It worked fine. So there is no issue with mingw and fbos in general. After this I tried to run the osg example osgprerender but it also crashes with the same problems. The same example, on the same machine built with Visual Studio 2008 (express) runs great. So, as far as I can tell there is some problem with the combination of mingw and osg. I tried to follow the osg code using both debugger and printfsin the osg source but I failed to follow all levels of indirections in the abstraction layers in order to reach a conclusion. It seems like the functions pointers are NOT NULL but erroneous. Does anyone have any idea of where to look? Or even better, a fix? Been on this for many days now and have run out of ideas... /Filip system info: win7 core i3 nvidia gtx 260 with 197 series drivers (tested a few others as well) latest codeblocks ___ 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-users-openscenegraph.org
Re: [osg-users] Mac bundle distribution can't use plugin
I Haven't fixed my issues yet so here comes some more info. This is what I get when listing dependencies using otool. I have massaged the libs extensivly using install_name_tool... [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L BasicApp BasicApp: @loader_path/libosgDB.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgUtil.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgGA.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgText.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgViewer.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosg.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0) [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L libOpenThreads.11.dylib libOpenThreads.11.dylib: @loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) [fi...@mpq]:[~/Documents/Code/OSGTests/ Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so: @loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) @loader_path/libosg.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgDB.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/libosgUtil.61.dylib (compatibility version 61.0.0, current version 2.9.6) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.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 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) And the output from the failing loading of the plugin is a before (in first post). Any ideas ? /F On Mon, Nov 23, 2009 at 9:52 AM, Filip Wänström filip.wanst...@gmail.com wrote: Hi, thanks for the answer but I am using CMake/regular makefiles to do all my building and using the OSX Ingest into bundle script that comes with osg. I just presumed it did all magic but maybe I should check out the actual paths in the libs. I'll be back with a report. /Filip On Fri, Nov 20, 2009 at 6:21 PM, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Hi Filip, check your system.log-file -- I am pretty sure the osgdb_obj pluging refers to the osg-dylibs in /usr/lib or similar. You'll have to massage the paths to the libs stored in the plugin via install_name_tool in a post-build-step. Paths to libs are hardcoded in the object-file when linked. You can change them to something better suited like @loader_path.../pipapo. Try googling for install_name_tool and @loader_path to get an idea. If you are using the deprecated XCode-project and embed the osg frameworks into your app and the obj-plugin into plugins it should work out of the box whithout fiddling around with install_name_tool. cheers, Stephan Filip Wänström schrieb: Hi, I have problems with distributing self-contained applications on the mac. I have reduced my issues by building a very simple example that basically only opens a window and loads an .obj file. Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but unrelated) I get the following output: [fi...@mpq]:[~/Documents/Code/OSGTests/]$ ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50 Initiating Constructing BasicApp 1 Listing plugins plugin: /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so Found file: data/models/clogo.obj
Re: [osg-users] Mac bundle distribution can't use plugin
And finally, I have a founf the fix. These are happy times! The plugin loader_path should be pointing to the libs from the path of the plugin. This means that the otool listing should be: $otool -L osgdb_obj.so osgdb_obj.so: @loader_path/../../MacOS/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) @loader_path/../../MacOS/libosg.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/../../MacOS/libosgDB.61.dylib (compatibility version 61.0.0, current version 2.9.6) @loader_path/../../MacOS/libosgUtil.61.dylib (compatibility version 61.0.0, current version 2.9.6) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.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 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) And then it all works. I will make an example of this so that others don't have to spend weeks to support mac deployment! /Filip On Wed, Nov 25, 2009 at 10:46 AM, Filip Wänström filip.wanst...@gmail.com wrote: I Haven't fixed my issues yet so here comes some more info. This is what I get when listing dependencies using otool. I have massaged the libs extensivly using install_name_tool... [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L BasicApp BasicApp: �...@loader_path/libosgDB.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgUtil.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgGA.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgText.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgViewer.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosg.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0) [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L libOpenThreads.11.dylib libOpenThreads.11.dylib: �...@loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) [fi...@mpq]:[~/Documents/Code/OSGTests/ Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$ otool -L ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so: �...@loader_path/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.4.0) �...@loader_path/libosg.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgDB.61.dylib (compatibility version 61.0.0, current version 2.9.6) �...@loader_path/libosgUtil.61.dylib (compatibility version 61.0.0, current version 2.9.6) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.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 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) And the output from the failing loading of the plugin is a before (in first post). Any ideas ? /F On Mon, Nov 23, 2009 at 9:52 AM, Filip Wänström filip.wanst...@gmail.com wrote: Hi, thanks for the answer but I am using CMake/regular makefiles to do all my building and using the OSX Ingest into bundle script that comes with osg. I just presumed it did all magic but maybe I should check out the actual paths in the libs. I'll be back with a report
Re: [osg-users] Mac bundle distribution can't use plugin
Hi, thanks for the answer but I am using CMake/regular makefiles to do all my building and using the OSX Ingest into bundle script that comes with osg. I just presumed it did all magic but maybe I should check out the actual paths in the libs. I'll be back with a report. /Filip On Fri, Nov 20, 2009 at 6:21 PM, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Hi Filip, check your system.log-file -- I am pretty sure the osgdb_obj pluging refers to the osg-dylibs in /usr/lib or similar. You'll have to massage the paths to the libs stored in the plugin via install_name_tool in a post-build-step. Paths to libs are hardcoded in the object-file when linked. You can change them to something better suited like @loader_path.../pipapo. Try googling for install_name_tool and @loader_path to get an idea. If you are using the deprecated XCode-project and embed the osg frameworks into your app and the obj-plugin into plugins it should work out of the box whithout fiddling around with install_name_tool. cheers, Stephan Filip Wänström schrieb: Hi, I have problems with distributing self-contained applications on the mac. I have reduced my issues by building a very simple example that basically only opens a window and loads an .obj file. Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but unrelated) I get the following output: [fi...@mpq]:[~/Documents/Code/OSGTests/]$ ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50 Initiating Constructing BasicApp 1 Listing plugins plugin: /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so Found file: data/models/clogo.obj Opened DynamicLibrary osgPlugins-2.9.6/osgdb_obj.so Warning: Could not find plugin to read objects from file data/models/clogo.obj. Failed to load model This seems self contradictory to me... So as far as I can tell: 1) the bundled osglibs are found correctly and the app starts 2) the file in the Resources directory in the app bundle is found correctly 3) the right plugin is chosen and found in the app bundle PlugIns/osgPlugins-2.9.6 directory 4) The lib is opened ok 5) it fails All .dylibs/.so are copied from my /usr/local/ osg install into the app bundle I tried to see if there were some hidden depencies on osgdb_obj.so using otool but as far as I could tell there were no extra Non-system dependencies I'm at a loss here and tearing my nonexistent hair. Any help would be greatly appreciated. Best /Filip ___ 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-users-openscenegraph.org
[osg-users] Mac bundle distribution can't use plugin
Hi, I have problems with distributing self-contained applications on the mac. I have reduced my issues by building a very simple example that basically only opens a window and loads an .obj file. Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but unrelated) I get the following output: [fi...@mpq]:[~/Documents/Code/OSGTests/]$ ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50 Initiating Constructing BasicApp 1 Listing plugins plugin: /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so Found file: data/models/clogo.obj Opened DynamicLibrary osgPlugins-2.9.6/osgdb_obj.so Warning: Could not find plugin to read objects from file data/models/clogo.obj. Failed to load model This seems self contradictory to me... So as far as I can tell: 1) the bundled osglibs are found correctly and the app starts 2) the file in the Resources directory in the app bundle is found correctly 3) the right plugin is chosen and found in the app bundle PlugIns/osgPlugins-2.9.6 directory 4) The lib is opened ok 5) it fails All .dylibs/.so are copied from my /usr/local/ osg install into the app bundle I tried to see if there were some hidden depencies on osgdb_obj.so using otool but as far as I could tell there were no extra Non-system dependencies I'm at a loss here and tearing my nonexistent hair. Any help would be greatly appreciated. Best /Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] do one have to use prefix?
Does this work? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Can CMake generate mac os frameworks now?
Hello, I just built osg trunk (as of today, 2009-08-24) on the mac successfully after a series of problems with the ffmpeg plugin. I used Cmake to gen. regular makefiles and it works fine. (great even!) Anyway, since I'm a mac person at heart and usually code in Xcode I was curious if osg + xcode is a viable, first rate, option these days so I tested to generate Xcode files from Cmake instead. By the look of it it seems to be working but as I understand it we'll have to do with regular .so libraries for the time being. So, the questions: 1. can I generate an Xcode project file that will build frameworks instead of regular .so dynamic libs? 2. A big reason for this is to get code-completion in Xcode, so if 1) is not an option, are there other ways to get code completion for the osg headers? /Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FFmpeg and osg trunk build issues on mac
Hi all, checked out the latest osg trunk on svn and tried to build on my Mac with OS X 10.5.8. I'm using Cmake to create regular makefiles. I opted for using imageio instead of quicktime for images and switched to Cocoa instead of default Carbon windows Most of the project builds fine but fails in the ffmpeg plugin with linker error messages like: Undefined symbols: _deflateInit2_, referenced from: _encode_frame in libavcodec.a(pngenc.o) _compress, referenced from: _encode_strip in libavcodec.a(tiffenc.o) _uncompress, referenced from: _mov_read_cmov in libavformat.a(mov.o) _decode_frame in libavcodec.a(dxa.o) _svq3_decode_init in libavcodec.a(h264.o) _decode_frame in libavcodec.a(cscd.o) _decode_frame in libavcodec.a(tiff.o) _inflateEnd, referenced from: _matroska_decode_buffer in libavformat.a(matroskadec.o) _decode_frame in libavcodec.a(pngdec.o) _decode_end in libavcodec.a(lcldec.o) _decode_end in libavcodec.a(zmbv.o) _flashsv_decode_end in libavcodec.a(flashsv.o) _decode_end in libavcodec.a(tscc.o) _inflateInit_, referenced from: _matroska_decode_buffer in libavformat.a(matroskadec.o) _decode_frame in libavcodec.a(pngdec.o) _decode_init in libavcodec.a(lcldec.o) _decode_init in libavcodec.a(zmbv.o) _flashsv_decode_init in libavcodec.a(flashsv.o) _decode_init in libavcodec.a(tscc.o) etc. Does anyone know what might be wrong? I get the feeling that the the linker can't find the libs needed for the actual encoding/decoding of the formats (pngenc.o looks for _deflateInit2_ which I presume resides in some libpng... But since I use imageio for image in/out I won't actually be using libpng.a right? Or do I need libpng just for ffmpeg to work? I also tried to switch back to using quicktime instead of imageio but still gets the same errors. (in this case quicktime takes care of for example pngs so libpng won't be used here either) Any tips for moving forward? Disabling ffmpeg would be an ok interim solution for me even though its not preferable. /Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FFmpeg and osg trunk build issues on mac
As I see it this is an issue with not finding symbols that should be in the zlib and bz2lib. If I had my own project I would have tried to add -lz -lbz2 to the linker flags but as it is now I don't know where to put such a thing... ideas? On Wed, Aug 19, 2009 at 10:55 AM, Filip Wänströmfilip.wanst...@tii.se wrote: Hi all, checked out the latest osg trunk on svn and tried to build on my Mac with OS X 10.5.8. I'm using Cmake to create regular makefiles. I opted for using imageio instead of quicktime for images and switched to Cocoa instead of default Carbon windows Most of the project builds fine but fails in the ffmpeg plugin with linker error messages like: Undefined symbols: _deflateInit2_, referenced from: _encode_frame in libavcodec.a(pngenc.o) _compress, referenced from: _encode_strip in libavcodec.a(tiffenc.o) _uncompress, referenced from: _mov_read_cmov in libavformat.a(mov.o) _decode_frame in libavcodec.a(dxa.o) _svq3_decode_init in libavcodec.a(h264.o) _decode_frame in libavcodec.a(cscd.o) _decode_frame in libavcodec.a(tiff.o) _inflateEnd, referenced from: _matroska_decode_buffer in libavformat.a(matroskadec.o) _decode_frame in libavcodec.a(pngdec.o) _decode_end in libavcodec.a(lcldec.o) _decode_end in libavcodec.a(zmbv.o) _flashsv_decode_end in libavcodec.a(flashsv.o) _decode_end in libavcodec.a(tscc.o) _inflateInit_, referenced from: _matroska_decode_buffer in libavformat.a(matroskadec.o) _decode_frame in libavcodec.a(pngdec.o) _decode_init in libavcodec.a(lcldec.o) _decode_init in libavcodec.a(zmbv.o) _flashsv_decode_init in libavcodec.a(flashsv.o) _decode_init in libavcodec.a(tscc.o) etc. Does anyone know what might be wrong? I get the feeling that the the linker can't find the libs needed for the actual encoding/decoding of the formats (pngenc.o looks for _deflateInit2_ which I presume resides in some libpng... But since I use imageio for image in/out I won't actually be using libpng.a right? Or do I need libpng just for ffmpeg to work? I also tried to switch back to using quicktime instead of imageio but still gets the same errors. (in this case quicktime takes care of for example pngs so libpng won't be used here either) Any tips for moving forward? Disabling ffmpeg would be an ok interim solution for me even though its not preferable. /Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] fish eye projection
Hi, I need to output to a single channel fish eye projection lens .
(Elumenati system) Is there a simple way to achieve this?
Basically I believe there are 3 paths to chose from:
1. doing the fisheye projection yourself (similar to osgdistortion)
2. using the elumentai api, omnimap (only windows so I'm not to keen on
this)
3. configuring osgViewer in some way?
1 and 2 is obvious but requires some work. I am hoping for 3 since I found
files called *.view in the {$OSG_FILE_PATH}/Configuration folder. I have not
found documentation on how to create or use those files so if someone has a
pointer for me to start reading it would be great :)
/Filip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] fish eye projection
Ok, I searched and tested a little bit more. Using -c congfigfile.view
should have been the first thing to try out. Sorry about that. But anyway,
Is there some documentation of how the rendering is set up etc?
Complications etc? Would be nice to understand and be able to change
depending on the needs that occurs.
/Filip
On Thu, Sep 11, 2008 at 1:46 PM, Filip Wänström [EMAIL PROTECTED]wrote:
Hi, I need to output to a single channel fish eye projection lens .
(Elumenati system) Is there a simple way to achieve this?
Basically I believe there are 3 paths to chose from:
1. doing the fisheye projection yourself (similar to osgdistortion)
2. using the elumentai api, omnimap (only windows so I'm not to keen on
this)
3. configuring osgViewer in some way?
1 and 2 is obvious but requires some work. I am hoping for 3 since I found
files called *.view in the {$OSG_FILE_PATH}/Configuration folder. I have not
found documentation on how to create or use those files so if someone has a
pointer for me to start reading it would be great :)
/Filip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] fish eye projection
Robert,
thanks for clearing that out. I'll experiment and see what I come up with.
I would also prefer not to use/integrate 3rd party libs.
/Filip
On Thu, Sep 11, 2008 at 2:02 PM, Robert Osfield [EMAIL PROTECTED]wrote:
Hi Flilip,
The .view format is still in a very early stage of development, so
only supports a select range of convenience methods that are provided
in the osgViewer::View::setUpView*() methods. The OSG also has
Producer .cfg plugin which allows you to use Producer configuration
files, these are more feature rich that the present .view in terms of
controlling windows, viewports, projections and view matrices and
their offsets, but doesn't support any distortion correction so won't
be of use to you.
The dome distortion correction that is provided .view and
VIew::setUpView*() methods are just for full spherical projection. If
you need another type of dome correction then you'll need to roll you
own setup. The View::setUp*() methods and the distortion examples
should provide a useful guide.
Diving into 3rd party libs for setting up the rendering I'd personally
avoid as they'll just complicate your application, and will limit the
threading options you have in your viewer.
Robert.
On Thu, Sep 11, 2008 at 12:46 PM, Filip Wänström
[EMAIL PROTECTED] wrote:
Hi, I need to output to a single channel fish eye projection lens .
(Elumenati system) Is there a simple way to achieve this?
Basically I believe there are 3 paths to chose from:
1. doing the fisheye projection yourself (similar to osgdistortion)
2. using the elumentai api, omnimap (only windows so I'm not to keen on
this)
3. configuring osgViewer in some way?
1 and 2 is obvious but requires some work. I am hoping for 3 since I
found
files called *.view in the {$OSG_FILE_PATH}/Configuration folder. I have
not
found documentation on how to create or use those files so if someone has
a
pointer for me to start reading it would be great :)
/Filip
___
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-users-openscenegraph.org
Re: [osg-users] fish eye projection
Nice to hear! I don't have access to the actual inflatable dome at this time but I am trying to do a quick-and-dirty app to help me display media and models for testing purposes. By using 3DSphericalDisplayTopProjector.view with the projector matrix set to identity I think I have something close to what I need. At least it's a great starting point:) /F On Thu, Sep 11, 2008 at 3:40 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Filip, Robert, Diving into 3rd party libs for setting up the rendering I'd personally avoid as they'll just complicate your application, and will limit the threading options you have in your viewer. Personally I have integrated our rendering backend here at work with both OmniMap and EasyBlend (still based on OSG 2.2, but moving to 2.6 soon). * OmniMap does only fisheye correction * EasyBlend does correction for a variety of display geometries (dome, cylinder, etc) and edge blending for any number of projectors. Though the initial integration needed some care, we now have a setup that is not limited in terms of threading. We can use any threading mode that OSG supports with both integrations. And in both cases the actual integration needed just a simple class of about 150-200 lines, nothing really complicated. Yes, they are Win32 only though. But they were pretty straightforward to integrate, and the automatic calibration done by EasyBlend (it uses a digital camera and analyzes the resulting images to calibrate itself) saves us a lot of time in the field. Just sharing my experiences. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] Cannot get apps to find plugins
Hi again, I have tried to find the reason for my issues and it seems that I have got it to work. The bad thing is that I have tested so many different ways that I'm not completely sure what I have done ;) Default on mac doesn't have /usr/local/lib in the PATH so it can/could/should) be added to DYLD_LIBRARY_PATH. A problem with this is that Xcode and finder doesn't use env vars when launching .apps so in that case you want to add DYLD_LIBRARY_PATH as an env var in the ~/.MacOSX/environment.plist. (When you start an app from the finder it uses something called laucnh services) However, that doesn't seem to solve all issues with Xcode so the easiest thing to do is probably to install in the /Library/Application Support/OpenSceneGraph/PLugIns/ directory. The right thing to do here is obviously(?) to enhance the support for buildning frameworks and have a install build phase in Xcode. In the meantime I will put my plugins in my /Library/Application Support/OpenSceneGraph/PlugIns/osgPlugins-2.6.0/ dir. It is found both when running from terminal and when launching from xcode or finder. btw: I built osg 2 times, one time from regular Makefiles and one time from the xcode project. I get the impression that these two versions are not compatible? Maybe the Makefiles built using 10.4 SDK and the Xcode project using the 10.5 ? Haven't researched this completely, just wanted to add my final thoughts /Filip On Fri, Sep 5, 2008 at 9:49 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Filip, Could you try other and model image formats, such as osgviewer cow.osg And see what happens. Robert. On Fri, Sep 5, 2008 at 6:33 PM, Filip Wänström [EMAIL PROTECTED] wrote: Thank you Robert, but the wierd thing is that this is in the output: FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so ... FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so Opened DynamicLibrary osgPlugins-2.6.0/osgdb_qt.so Warning: Could not find plugin to read objects from file wood.png. wood.png'. I'll have to dig more on this and report back. I've tried so many different ways now that It might be a better route to uninstall and install anew... /Filip On Fri, Sep 5, 2008 at 5:28 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Filip, If you have installed the OSG then there should be no need to set the path to the plugins, as the OSG should search the standard lib paths for the presence of the osgPlugins-2.x.x directory. A good way to check where the the OSG is searching for files and plugins is to enable verbose debug messages, on the command line do: setenv OSG_NOTIFY_LEVEL DEBUG osgviewer cow.osg Then look back up through the output till you can see it search for the osgdb_osg plugin. If your system doesn't have the /usr/local/lib on its library path then you could add this, for instance via DYLD_LIBRARY_PATH. I'm no OSX expert though so just recalling stuff from when I've tinkered with Mac's. Robert. On Fri, Sep 5, 2008 at 4:11 PM, Filip Wänström [EMAIL PROTECTED] wrote: Hi again, I have problems to get my apps to find the plugins. Or rather, there seems to be some issue with the executable. I'm loosing my mind over this today so if someone have some insights I would be more than happy! So I'm on a Mac with Leopard(10.5.4) I tested to build using CMake to generate a Xcode project. I built for 10.5 deployment from Xcode and ran the install scripts using sudo in the terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0 so those would be found. I also set the OSG_FILE_PATH to where I put those files. The examples that installed in /usr/local/share/OpenSceneGraph/bin worked fine from the command line. So far, so fine. Then I proceeded to create a xcode project for a simple OSG app that reads a png file from the resource bundle. But it can't seem to find the plugins... I can't find the source to this issue so I would be glad if someone could tell me in the right direction. - Is it really so that the plugin can't be found? How is that possible? The examples had no problems? - Can there be some binary incompability? Should I turn on some switch in xcode? /Filip ___ 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-users-openscenegraph.org
[osg-users] Reading shader source on Mac
More merry mac musings...
I get the impression (from the osg source) that when a shader is read from
the file it uses raw c++ IO. This means that shaders source that I have put
in my Resources directory in my App bundle (e.g.
OsgTest.app/Contents/Resources/data/shaders/simple.vert) won't read.
I remedied this by using the following snippet of mac code:
// Function
void SetCWDToMainBundle()
{
CFBundleRef mainBundle = CFBundleGetMainBundle();
CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
char path[PATH_MAX];
if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path,
PATH_MAX))
{
// Error
}
CFRelease(resourcesURL);
chdir(path);
}
// In use:
void SetCWDToMainBundle()
v-loadShaderSourceFromFile( data/shaders/simple.vert );
f-loadShaderSourceFromFile( data/shaders/simple.frag );
Obviously something like that happens in the image and model loading code so
I guess it's easy to fix If you have access (and understanding of!) to the
source code
/Filip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading shader source on Mac
That worked fine.
I think it would be a good idea to have similar behavior when loading files
independent of their types. Can someone change the shaders loading code so
that it uses findDataFile instead of the raw c++ IO ?
/Filip
On Mon, Sep 8, 2008 at 10:20 AM, Stephan Maximilian Huber
[EMAIL PROTECTED] wrote:
Filip Wänström schrieb:
More merry mac musings...
I get the impression (from the osg source) that when a shader is read from
the file it uses raw c++ IO. This means that shaders source that I have
put
in my Resources directory in my App bundle (e.g.
OsgTest.app/Contents/Resources/data/shaders/simple.vert) won't read.
does
std::string filename = osgDB::findDataFile(data/shaders/simple.vert);
if (!filename.empy()) {
}
work? findDataFile should find your files in the resource-path of your app
bundle automagically. IMHO findDataFile is called by the Registry when
loading models / images, perhaps this call is missing when loading shaders.
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
[osg-users] Cannot get apps to find plugins
Hi again, I have problems to get my apps to find the plugins. Or rather, there seems to be some issue with the executable. I'm loosing my mind over this today so if someone have some insights I would be more than happy! So I'm on a Mac with Leopard(10.5.4) I tested to build using CMake to generate a Xcode project. I built for 10.5 deployment from Xcode and ran the install scripts using sudo in the terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0 so those would be found. I also set the OSG_FILE_PATH to where I put those files. The examples that installed in /usr/local/share/OpenSceneGraph/bin worked fine from the command line. So far, so fine. Then I proceeded to create a xcode project for a simple OSG app that reads a png file from the resource bundle. But it can't seem to find the plugins... I can't find the source to this issue so I would be glad if someone could tell me in the right direction. - Is it really so that the plugin can't be found? How is that possible? The examples had no problems? - Can there be some binary incompability? Should I turn on some switch in xcode? /Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cannot get apps to find plugins
Thank you Robert, but the wierd thing is that this is in the output: FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so ... FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so Opened DynamicLibrary osgPlugins-2.6.0/osgdb_qt.so Warning: Could not find plugin to read objects from file wood.png. wood.png'. I'll have to dig more on this and report back. I've tried so many different ways now that It might be a better route to uninstall and install anew... /Filip On Fri, Sep 5, 2008 at 5:28 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Filip, If you have installed the OSG then there should be no need to set the path to the plugins, as the OSG should search the standard lib paths for the presence of the osgPlugins-2.x.x directory. A good way to check where the the OSG is searching for files and plugins is to enable verbose debug messages, on the command line do: setenv OSG_NOTIFY_LEVEL DEBUG osgviewer cow.osg Then look back up through the output till you can see it search for the osgdb_osg plugin. If your system doesn't have the /usr/local/lib on its library path then you could add this, for instance via DYLD_LIBRARY_PATH. I'm no OSX expert though so just recalling stuff from when I've tinkered with Mac's. Robert. On Fri, Sep 5, 2008 at 4:11 PM, Filip Wänström [EMAIL PROTECTED] wrote: Hi again, I have problems to get my apps to find the plugins. Or rather, there seems to be some issue with the executable. I'm loosing my mind over this today so if someone have some insights I would be more than happy! So I'm on a Mac with Leopard(10.5.4) I tested to build using CMake to generate a Xcode project. I built for 10.5 deployment from Xcode and ran the install scripts using sudo in the terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0 so those would be found. I also set the OSG_FILE_PATH to where I put those files. The examples that installed in /usr/local/share/OpenSceneGraph/bin worked fine from the command line. So far, so fine. Then I proceeded to create a xcode project for a simple OSG app that reads a png file from the resource bundle. But it can't seem to find the plugins... I can't find the source to this issue so I would be glad if someone could tell me in the right direction. - Is it really so that the plugin can't be found? How is that possible? The examples had no problems? - Can there be some binary incompability? Should I turn on some switch in xcode? /Filip ___ 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-users-openscenegraph.org
[osg-users] 2.6 Mac OS X issues and some solutions
Hi there! I tried out to run the 2.6 source release on my MacBook Pro (Leopard 10.5.4) And run into some issues but it seems that I resolved them in the process and I want to share my experience in order to help others in a similar situation. First: 1. The provided Xcode project is out of date/doesn't work. I didn't bother further with that after the initial failure to get it to work. 2. There seems to be no updated info on what to do with the Mac version except that its seems hard, its not supported and Apple has broken binary compatibility going from Tiger to Leopard. Scary stuff. I would have stopped here if it wasn't for that I badly want Mac to be a viable development environment for me. Maybe some old info could be removed and replaced with a simple 1.2.3 list of what to do now. Anyway, I decided to go the CMake route even though it's not exactly well documented anywhere (neither osg site or CMake homepage talks much about the current status of Mac) In short it worked, but not completely flawlessly. I found the following issues: 1. There is not much documentation (The biggest problem is that a lot of documentation is contradictory or just to old). So it's trial and error (and patience). 2. The install script doesn't work since you have to run as root/su to install in /usr/local 3. After install. You need to set OSG_LIBRARY_PATH to the plugin install dir 3b. Since this is very far from common practice when it comes to mac I think It can be good to provide an example: Recommended: 1. Download source (from svn or zipped, I use OpenSceneGraph-2.6.0 as the example here) 2. Extract 3. Open terminal and go to your newly created directory (something like ~/tmp/OpenSceneGraph-2.6.0) 4. Create a place for building the project (like: ~/tmp/osgbuild) 5. Enter that dir 5. run cmake with the flag -GXcode (cmake -GXcode ../OpenSceneGraph-2.6.0) 6. start ccmake to configure further (you probably want to build the examples) (ccmake ../OpenSceneGraph-2.6.0) 7. In the text-gui of ccmake. make changes like turn on the examples build. then configure and generate project (c, g) 8. Start the xcodeproject and build ( 9. run the installscript from the command line with su privileges ( or login as root user for this task) 10. in order to test examples and make sure that plugins work: set the environment variables: Create a file called .profile in you root. export OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0/ export OSG_FILE_PATH=/path/to_where/you_put/OpenSceneGraph-Data-2.6.0/ Hope this help some other to shorten the time to get it working on the mac. Best regards /Filip Wänström Creative Engineer - Visualization The Interactive Institute Norrköping, Sweden ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6 Mac OS X issues and some solutions
Hi again, wanted to add that the template xcode OSG Application needs to be updated. (and changed if you want it to work right now) Since I tried the CMake route that creates regular .so files and headers in /usr/local instead of creating mac os frameworks the template need to be changed by removing all the framework linkings. In addition, some of the headers in the precompiled header file is out of date it seems. Introspection and osgSim/OpenFlightOptimizer I willl change the template so it works with libs and am of course willing to share if anyone want it. I'm not saying that the template should be changed to using regular libs instead of frameworks in the long run but for the time being that is the easiest way for me to start developing on the mac (and get a homey linux feeling as well..) I'm not sure what the status is for generating frameworks from the xcode project that CMake creates. Hopeully this is remedied in a not to far future. For now, I'm glad that I can use xcode to create osg projects that works fine. /Filip On Thu, Sep 4, 2008 at 11:24 AM, Filip Wänström [EMAIL PROTECTED]wrote: Hi there! I tried out to run the 2.6 source release on my MacBook Pro (Leopard 10.5.4) And run into some issues but it seems that I resolved them in the process and I want to share my experience in order to help others in a similar situation. First: 1. The provided Xcode project is out of date/doesn't work. I didn't bother further with that after the initial failure to get it to work. 2. There seems to be no updated info on what to do with the Mac version except that its seems hard, its not supported and Apple has broken binary compatibility going from Tiger to Leopard. Scary stuff. I would have stopped here if it wasn't for that I badly want Mac to be a viable development environment for me. Maybe some old info could be removed and replaced with a simple 1.2.3 list of what to do now. Anyway, I decided to go the CMake route even though it's not exactly well documented anywhere (neither osg site or CMake homepage talks much about the current status of Mac) In short it worked, but not completely flawlessly. I found the following issues: 1. There is not much documentation (The biggest problem is that a lot of documentation is contradictory or just to old). So it's trial and error (and patience). 2. The install script doesn't work since you have to run as root/su to install in /usr/local 3. After install. You need to set OSG_LIBRARY_PATH to the plugin install dir 3b. Since this is very far from common practice when it comes to mac I think It can be good to provide an example: Recommended: 1. Download source (from svn or zipped, I use OpenSceneGraph-2.6.0 as the example here) 2. Extract 3. Open terminal and go to your newly created directory (something like ~/tmp/OpenSceneGraph-2.6.0) 4. Create a place for building the project (like: ~/tmp/osgbuild) 5. Enter that dir 5. run cmake with the flag -GXcode (cmake -GXcode ../OpenSceneGraph-2.6.0) 6. start ccmake to configure further (you probably want to build the examples) (ccmake ../OpenSceneGraph-2.6.0) 7. In the text-gui of ccmake. make changes like turn on the examples build. then configure and generate project (c, g) 8. Start the xcodeproject and build ( 9. run the installscript from the command line with su privileges ( or login as root user for this task) 10. in order to test examples and make sure that plugins work: set the environment variables: Create a file called .profile in you root. export OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0/ export OSG_FILE_PATH=/path/to_where/you_put/OpenSceneGraph-Data-2.6.0/ Hope this help some other to shorten the time to get it working on the mac. Best regards /Filip Wänström Creative Engineer - Visualization The Interactive Institute Norrköping, Sweden ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6 Mac OS X issues and some solutions
Thanks for your reply Robert! I know of the issues of the Mac and understand the situation. That is one of the reasons I write to this list: To share my experiences and hopefully help some other people. In general I find the Mac environment to be great for my productivity so I prefer to develop apps there as well. I will probably have to deliver on Windows and perhaps on linux but I view cross-platform-development as a good help to find hidden and nasty code :) Anyway, I hope that the Mac can be a viable platform for Mac OS X and that Apple fixes some of their more glaring problems soon. I hope I will be able to contribute in the future. /Filip On Thu, Sep 4, 2008 at 11:50 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Filip, I'm afraid the OSX side is still a bit in flux, do to a range of reasons - not all under our control. Apple themselves have thrown a couple of spanners in the works when moving from 10.4.x to 10.5.x, Xcode have provided not be forward/backwards compatible so the Xcode projects can't break quite easily if you don't use the same version that the maintainer used and Apple SDK versions also a bit sensitive. Cmake is in flux as, and we are also migrating to use Cmake under OSX. I just so happened to be on OSX 10.5 box yesterday and compiling the SVN trunk version of the OSG and encountered problems too. The initial show stopper was that I CMake 2.6.0 hung when running the initial cmake or ccmake command. Moving to Cmake 2.6.1 fixed this CMake bug and got the GNUmakefiles built. The OSG and Present3D then built without problems. I didn't on this occasion test the Xcode project build form CMake though. Since the OSX platform is so much in flux it does require active maintenance to keep things working, in facts it probably the platform that requires the highest effort maintenance wise, even more than windows, yet has a much smaller user base, so for good support it does require OSX user to be particularly proactive in helping maintain the platform - this includes documentation as much as coding. This applies to the CMake community as well as the OSG community - proactive OSX users/maintainers are gold dust! Robert. On Thu, Sep 4, 2008 at 10:24 AM, Filip Wänström [EMAIL PROTECTED] wrote: Hi there! I tried out to run the 2.6 source release on my MacBook Pro (Leopard 10.5.4) And run into some issues but it seems that I resolved them in the process and I want to share my experience in order to help others in a similar situation. First: 1. The provided Xcode project is out of date/doesn't work. I didn't bother further with that after the initial failure to get it to work. 2. There seems to be no updated info on what to do with the Mac version except that its seems hard, its not supported and Apple has broken binary compatibility going from Tiger to Leopard. Scary stuff. I would have stopped here if it wasn't for that I badly want Mac to be a viable development environment for me. Maybe some old info could be removed and replaced with a simple 1.2.3 list of what to do now. Anyway, I decided to go the CMake route even though it's not exactly well documented anywhere (neither osg site or CMake homepage talks much about the current status of Mac) In short it worked, but not completely flawlessly. I found the following issues: 1. There is not much documentation (The biggest problem is that a lot of documentation is contradictory or just to old). So it's trial and error (and patience). 2. The install script doesn't work since you have to run as root/su to install in /usr/local 3. After install. You need to set OSG_LIBRARY_PATH to the plugin install dir 3b. Since this is very far from common practice when it comes to mac I think It can be good to provide an example: Recommended: 1. Download source (from svn or zipped, I use OpenSceneGraph-2.6.0 as the example here) 2. Extract 3. Open terminal and go to your newly created directory (something like ~/tmp/OpenSceneGraph-2.6.0) 4. Create a place for building the project (like: ~/tmp/osgbuild) 5. Enter that dir 5. run cmake with the flag -GXcode (cmake -GXcode ../OpenSceneGraph-2.6.0) 6. start ccmake to configure further (you probably want to build the examples) (ccmake ../OpenSceneGraph-2.6.0) 7. In the text-gui of ccmake. make changes like turn on the examples build. then configure and generate project (c, g) 8. Start the xcodeproject and build ( 9. run the installscript from the command line with su privileges ( or login as root user for this task) 10. in order to test examples and make sure that plugins work: set the environment variables: Create a file called .profile in you root. export OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0/ export OSG_FILE_PATH=/path/to_where/you_put/OpenSceneGraph-Data-2.6.0/ Hope this help some other to shorten the time to get it working on the mac
Re: [osg-users] 2.6 Mac OS X issues and some solutions
Stephan, I'm absolutely not in to here to point fingers etc. I just wanted to share my experience when trying to build on the Mac for the first time in a long long time (last time I tried all mac was X11 and the osg version was 0.9 or so). I'm not interested so much in explanations (even though they can be enlightening) as I am in solutions. I personally need to know if I can use the Mac as a development platform for real time 3D applications today. Can I use OSG to help me from reinventing the wheel? Do I have to abandon the Mac in favor for Windows? These are the questions I need to get answered. By myself and with the help from others. Like this eminent list. Obviously, things like what you describe can happen and can be easy to fix. But when you are evaluating a platform or and API, all friction works against it. Issues like that should be sorted out in the pre-rc state in a best case scenario. As its stands, one (me!) gets discouraged and tends to think that these issues reflect the general state of things... In any case, I think it would be good to make one single, clear, general and working path for the Mac OS X build. If one download code, one should be able to follow a tutorial along and get the stuff working. I hope no-one is offended by this as I fully understand that no one gets payed for making sure everything works fine etc etc. I have written down my experience, hopefully this can be used to change some of the documentation on the web. I can not change it myself (or can I?) Otherwise I could have made the changes on the Wiki/Trac. And, since I'm kind of new to this game (this time around) I thought it would be better to air my thoughts on this list. I have changed the xcode template on my system so that it uses libs instead. I could upload that somewhere if I knew how alongside information on how to do use it. (and for review, obviously) Anyway, I hope this might lead to further, and fruitful, discussion on the state of the Mac. Best regards /Filip On Thu, Sep 4, 2008 at 1:20 PM, Stephan Maximilian Huber [EMAIL PROTECTED] wrote: Filip Wänström schrieb: 1. There is not much documentation (The biggest problem is that a lot of documentation is contradictory or just to old). So it's trial and error (and patience). I am sorry, that the xcode-project didn't work for you -- I am maintaining it in my spare time. Unfortunatley I cannot donate as much time as I want to to keep the xcode project running. Maintaining the hand-crafted Xcode-project files is error-prone and tedious to do. But your problem is easy fixable. Just select the group osgWidget in OpenSceneGraph/src and reselect the source-folder. Unfortunately XCode stored an absolute path to the osgWidget folder. This worked for me, but not for you :) Regarding moving the XCode-folder to the deprecated section: As long as most OS X users do their stuff with libraries I am not against the move. Even better would be a cMake solution building frameworks natively. But I am not an cMake-guru and can't say anything about that route and if it works. 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] 2.6 Mac OS X issues and some solutions
Great, then I know that I have a working path and in the future it gets even better. :) Since I haven't used OSG for a few years (1.2 was the last thing I tried in 2006 I think) I have some catching up to do. And at that time I had to use Windows. This time around I hope I can use a Mac instead. If this works out I hope I will be able to contribute in some way. /Filip - back to coding... On Thu, Sep 4, 2008 at 2:34 PM, Eric Sokolowsky [EMAIL PROTECTED] wrote: Filip Wänström wrote: Hi again, wanted to add that the template xcode OSG Application needs to be updated. (and changed if you want it to work right now) Since I tried the CMake route that creates regular .so files and headers in /usr/local instead of creating mac os frameworks the template need to be changed by removing all the framework linkings. In addition, some of the headers in the precompiled header file is out of date it seems. Introspection and osgSim/OpenFlightOptimizer I willl change the template so it works with libs and am of course willing to share if anyone want it. I'm not saying that the template should be changed to using regular libs instead of frameworks in the long run but for the time being that is the easiest way for me to start developing on the mac (and get a homey linux feeling as well..) I'm not sure what the status is for generating frameworks from the xcode project that CMake creates. Hopeully this is remedied in a not to far future. For now, I'm glad that I can use xcode to create osg projects that works fine. Yes, for now, the cmake project does not create OSG frameworks. We're working on this. Creating dylibs works fine. These dylibs can be installed on a developer's system or embedded into an application. Since most of the example programs require command-line arguments to run properly, it's not too much of a burden to set environment variables. Once we get frameworks built with cmake the environment variables should not be necessary. -Eric ___ 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
