Re: [osg-users] imageio problems and possible solutions on loading some PNG images.
I'm betting you hit the same premultiplied alpha problem/limitation reported in SDL_image. http://bugzilla.libsdl.org/show_bug.cgi?id=868 The workaround/solution was to add a block of code at the end of the loader to un-premultiply the alpha (now in the codebase). If that is indeed the problem and the workaround works, I recommend you submit the fix for osgdb_ImageIO. Also, please file a bug report/feature request with Apple. The more reports they get, the better. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL ES-2.0, OpenGL ES-1.1 and OpenGL 3.x support now ready for testing :-)
> > I understand. I just thought calls named "_NSGetEnviron" and > "exc_server" (those are the calls they refer to in the article) sounded > like "get some environment variable" and some threading functions, so I > thought it might be possible that the low-level implementations of some > functions might use them without us being aware of it... > > But if the likeliness of that happening is close to null, that's great. > It will be very explicit whether you are using a "private" API or not. There won't be a header definition and you will get a compile error. If a public API calls a private API behind the scenes, that is perfectly okay. I expect the only areas OSG will have trouble is with the module loading systems (osgDB), but we already expect that. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL ES-2.0, OpenGL ES-1.1 and OpenGL 3.x support now ready for testing :-)
Hello, just passing through again. I thought I would clarify the questions being asked about iPhone. First congrats on the ES support! >> One thing you apparently need to be careful of is that Apple is now more >> careful in its screening of iPhone apps that are submitted for the App >> Store, they apparently got bitten by some apps harvesting phone numbers >> and >> such... I don't know personally, but I read it here: >> >> http://www.develop-online.net/news/33266/Unity-iPhone-games-rejected-by-Apple >> http://forum.unity3d.com/viewtopic.php?t=35744 >> >> Seems some of the calls they rejected apps for seems to be an equivalent >> of >> getenv(), which OSG uses, so it might be interesting to check the actual >> approval rules and see if we can disable things that would cause apps to >> be >> rejected with an iphone-specific define in CMake or something. According to the article, they admittedly used private APIs which is explicitly forbidden in Apple's license terms. I don't believe getenv or any ANSI C function is considered private. Private stuff is usually proprietary Apple APIs hidden away and undocumented which you have to go out of your way to use. I can't imagine OSG would hit any of these either by accident or on purpose. osgDB and static linking: Yes, iPhone license terms forbid dynamic linking and dynamic loading. Pain in the arse. However, I thought we already had a static linking option in the build options, primarily used by Windows users to make distribution easier. I would suggest trying that option to see if that works around the issue. CMake: Officially, I don't think there is CMake support for iPhone yet. However, the rumor mill has it that some large project may already have it working. It might have been Orge3D. >>BTW, on the iPhone what is the scheme for creating windows and >>graphics contexts? Is Cocoa based? Would it be possible to use any >>of the existing osgViewer support for OSX? > Yes IPhone uses cocoa and Objective C which at the momnet I rather suck at > (jump to > c++ at first chance). It does use views and windows although at the mo my > window is > created in the interface editor. I think the cocoa viewer should be a pretty > good start point > for an iphoneViewer. iPhone also uses Cocoa, though the class View hierarchy on iPhone is different than on the desktop so there will need to be a new viewer implementation. The most similar APIs are Core Animation/CALayer which have very few differences, but I don't think the OSG viewer uses Core Animation. But the desktop OpenGL and ES versions of CALayer do have a few differences so there would have to be some #defines. And you would still need to encapsulate the layers in a view class which is where most of the differences really reside. (e.g. mouse input vs multi-touch, etc.) The code flow and design patterns should be almost mirrors of each other though. One other caveat though. The ImageIO backend I wrote for Mac does not work on iPhone because ImageIO wasn't ported to the iPhone, so you will likely want a UIImage backend. I implemented one for SDL_image which was derived from an ImageIO one I wrote for SDL_image, which was ultimately derived from the one I wrote for OSG. So you might look at SDL for inspiration for both the view and image loader in addition to the existing osg Cocoa viewer. (You might also experiment with just using the SDL/OSG viewer since SDL already has preliminary iPhone support.) -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSX 10.6.1 Snow Leopard woes
I am not currently on the OSG track so I'm afraid I can't be much help at the moment. But be aware that in Snow Leopard, the default architecture is 64-bit (assuming you are on a 64-bit machine which almost all Intel Macs are now). All the Carbon stuff in osgViewerCarbon will likely not compile in 64-bit. I thought there was at least a preliminary Cocoa based viewer now, but I haven't been following. It seems like the Cocoa one needs to be made the default for just this problem that people are going to encounter over and over again. (Also, if my ImageIO plugin has not been integrated yet, now is the time do so so as the Quicktime plugin is also not going to work in 64-bit.) Second, I don't know if the Xcode project is maintained anymore. Third for CMake, you'll want to verify which architectures are trying to be built. If you pick the 10.5 SDK and i386 (32-bit), I would think you would have the best chance of it actually getting built as-is. -Eric On 9/15/09, stefan nortd wrote: > Hi, > > I just updated to osx 10.6.1 snow leopard and ran into a couple of > problems. > > (1) My old osg binaries (osg 2.8.2 compiled for the 10.5 sdk) work but I > get a ton of warning (I also needed to update to xcode 3.2). They are all > of the "different visibility" type. > > (2) Osg does not want to compile on osx 10.6. I tried both Xcode and > Makefiles. And for each I tried the 10.5 and 10.6 sdk which does not seem > to change the nature of the compilation error. > > The attached screenshots are the errors I get with xcode. > > The following code snippet is the errors I get with the Makefiles. It gets > 25% into the build and fails with the osgViewer. > > > Code: > > Scanning dependencies of target osgViewer > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/CompositeViewer.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/HelpHandler.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/Renderer.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/Scene.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/ScreenCaptureHandler.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/StatsHandler.cpp.o > [ 25%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/Version.cpp.o > [ 26%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/View.cpp.o > [ 26%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/Viewer.cpp.o > [ 26%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/ViewerBase.cpp.o > [ 26%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/ViewerEventHandlers.cpp.o > [ 26%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowCarbon.cpp.o > In file included from > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:18: > /Users/noema/Downloads/OpenSceneGraph-2.8.2/include/osgViewer/api/Carbon/GraphicsWindowCarbon:122: > warning: ‘AGLDrawable’ is deprecated (declared at > /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) > /Users/noema/Downloads/OpenSceneGraph-2.8.2/include/osgViewer/api/Carbon/GraphicsWindowCarbon:128: > warning: ‘AGLDrawable’ is deprecated (declared at > /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) > /Users/noema/Downloads/OpenSceneGraph-2.8.2/include/osgViewer/api/Carbon/GraphicsWindowCarbon:132: > warning: ‘AGLDrawable’ is deprecated (declared at > /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp: > In function ‘OSStatus GraphicsWindowEventHandler(OpaqueEventHandlerCallRef*, > OpaqueEventRef*, void*)’: > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:75: > error: ‘GetWindowPortBounds’ was not declared in this scope > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:75: > error: ‘InvalWindowRect’ was not declared in this scope > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:76: > error: ‘GetWindowBounds’ was not declared in this scope > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp: > In constructor ‘osgViewer::MenubarController::MenubarController()’: > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:231: > error: ‘DMGetGDeviceByDisplayID’ was not declared in this scope > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:232: > error: ‘GetAvailableWindowPositioningBounds’ was not declared in this scope > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp: > In member function ‘void osgViewer::MenubarController::update()’: > /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgViewer/GraphicsWindowCarbon.cpp:296: > error: ‘GetWindowBounds’ was not declared in this scope > /Users/noema/Downloads/OpenScene
Re: [osg-users] [build] osgdb_freetype build problem on Mac OS/X 10.5.6
I don't know what the specific build issue is as I believe the local FindFreeType.cmake module should be searched for first, but I thought I would share some history. Originally there was no FindFreeType.cmake module in CMake. I wrote the original one for OpenSceneGraph and then submitted it to CMake. Quickly after, the KDE people got mad at me because they had their own FindFreetype.cmake module they were planning to submit which was not completely compatible with ours. Mine was better because it didn't rely on running freetype-config (bad for cross-compiling), and got the capitalization of "FreeType" correct. But because KDE is bigger than OpenSceneGraph, we lost. There was a promise that they would take the better elements of mine (e.g. no dependency on freetype-config) and duplicate variables to allow our stuff to still work, but it could be that those variables have since been removed. (I was told our variables would be considered deprecated.) -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Speeding Up osgText?
> void Text::computePositions()
> {
> unsigned int size =
> osg::maximum(osg::DisplaySettings::instance()->getMaxNumberOfGraphicsCon
> texts(),_autoTransformCache.size());
>
> // FIXME: OPTIMIZE: This would be one of the ideal locations to
> // call computeAverageGlypthWidthAndHeight(). It is out of the
> contextID loop
> // so the value would be computed fewer times. But the code will
> need changes
> // to get the value down to the locations it is needed. (Either pass
> through parameters
> // or member variables, but we would need a system to know if the
> values are stale.)
>
> for(unsigned int i=0;i {
> computePositions(i);
> }
> }
So I am not an expert on the osgText implementation, but I think I am
the one that wrote that comment. I wrote that when I added the
backdrop text and gradient feature to osgText. My strategy was to make
the least amount of structural changes as possible because the
implementation was sufficiently complicated enough, so optimization
wasn't my goal.
I think that above block already existed in some form before my
changes, but as I was refactoring trying to fit in the new features, I
think I took note of that block of code and added that comment
realizing it could be faster. I suggest if you are looking for a way
to speed things up, you could try to do exactly what that comment
says. I honestly don't remember the code at this point, and I never
really profiled how much time was spent in that loop. But I think it
is one of the more staightforward and obvious places that can be
optimized (but probably tedious).
Another thing to note is with the backdrop feature on, it isn't
terribly efficient if I recall, because it needs to repeat for every
direction of the shadow. So if you do outline text, you multiply by 8
or 9 passes. So don't turn on backdrop text if there are performance
problems.
-Eric
___
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
On 9/4/08, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Filip, > > On Thu, Sep 4, 2008 at 11:14 AM, Filip Wänström > <[EMAIL PROTECTED]> wrote: >> 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 > > Hopefully we'll be able to get the XCode generation from CMake working > well enough before OSG-2.8 to enable us to remove all the old hand > maintained XCode and the oddities like the above that go along with > it. > > I have been threatening to retire the old XCode directory to the > deprecated section of the OSG svn repository, perhaps now is the time > to do it... it'd help concentrate our efforts of getting Cmake to work > flawlessly and help avoid errors like the above creeping in unnoticed. > Thoughts OSX users? > > Robert. Sorry, I've been really busy with other things so I haven't been able to work directly on this. I have been trying to coordinate with Eric S. who has been making improvements to the CMake build system. I have independently been testing the final CMake support for framework building. I think we've weeded out all but one remaining bug. I have a demonstration/experimental build script that pushes a lot of the Mac CMake build features for Lua: http://www.assembla.com/wiki/show/lua It also offers a lot of specific GUI options for easy reconfiguration. I envision all the stuff I do there to be transplanted into OSG's build system. (Also, to see some other things I do, you can glance at some connected Lua projects from a superproject/forest I made for LuaDoc here: http://www.assembla.com/wiki/show/luadocsuperforest) I also have a long-lived branch of OSG with some initial framework building support and other Mac things found here: http://www.assembla.com/wiki/show/OpenSceneGraphHg It's quite a bit stale though as I haven't touched it since WWDC. Eric S. and I met at WWDC to discuss/work on the OSG build system and I pointed him to that as a reference. His current changes already submitted I believe already incorporate some of the stuff, though not the framework stuff yet. The Lua example may be easier to read since its much smaller. It is also more up-to-date and more complete (99%). Anyway, if everybody is free to look at my stuff and I'll be happy to help with questions you might have, though I'm still time crunched to find a large block of time to sit down and finish writing the thing. (That's what happened with my branch...I took too long, and it kept getting stale so the cost of resyncing with head starting eating up too much time.) Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer compile problem on OS X?
I figured out the problem. The OSG build system is instructing the process to also build 64-bit as part of the Universal, and of course it doesn't work when it gets to osgViewer because there is no 64-bit Carbon. -Eric On 7/19/08, E. Wing <[EMAIL PROTECTED]> wrote: > Can anybody reproduce this problem? I am trying to build the current > OSG in the SVN trunk with the current CVS head of CMake. > GraphicsWindowCarbon.cpp is complaining it can't find certain Mac > system header files which is odd. > > Thanks, > Eric > > > [ 40%] Building CXX object > src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowCarbon.cpp.o > /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:119: > warning: 'AGLDrawable' is deprecated (declared at > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) > /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:125: > warning: 'AGLDrawable' is deprecated (declared at > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) > /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:129: > warning: 'AGLDrawable' is deprecated (declared at > /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: > In function 'OSStatus > GraphicsWindowEventHandler(OpaqueEventHandlerCallRef*, > OpaqueEventRef*, void*)': > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:75: > error: 'GetWindowPortBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:75: > error: 'InvalWindowRect' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:76: > error: 'GetWindowBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: > In constructor 'osgViewer::MenubarController::MenubarController()': > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:231: > error: 'DMGetGDeviceByDisplayID' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:232: > error: 'GetAvailableWindowPositioningBounds' was not declared in this > scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: > In member function 'void osgViewer::MenubarController::update()': > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:296: > error: 'GetWindowBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: > In constructor > 'osgViewer::OSXCarbonWindowingSystemInterface::OSXCarbonWindowingSystemInterface()': > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:358: > error: 'GetApplicationEventTarget' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:359: > error: invalid conversion from 'OSErr (*)(const AppleEvent*, > AppleEvent*, long int)' to 'OSErr (*)(const AppleEvent*, AppleEvent*, > void*)' > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:359: > error: initializing argument 1 of 'OSErr (* > NewAEEventHandlerUPP(OSErr (*)(const AppleEvent*, AppleEvent*, > void*)))(const AppleEvent*, AppleEvent*, void*)' > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: > In member function 'virtual bool > osgViewer::GraphicsWindowCarbon::setWindowDecorationImplementation(bool)': > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:526: > error: 'GetWindowBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:530: > error: 'ChangeWindowAttributes' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:531: > error: 'SetWindowBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:535: > error: 'ChangeWindowAttributes' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:536: > error: 'SetWindowBounds' was not declared in this scope > /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindo
[osg-users] osgViewer compile problem on OS X?
Can anybody reproduce this problem? I am trying to build the current OSG in the SVN trunk with the current CVS head of CMake. GraphicsWindowCarbon.cpp is complaining it can't find certain Mac system header files which is odd. Thanks, Eric [ 40%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowCarbon.cpp.o /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:119: warning: 'AGLDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:125: warning: 'AGLDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) /Users/ewing/Source/SVN/OpenSceneGraph/include/osgViewer/api/Carbon/GraphicsWindowCarbon:129: warning: 'AGLDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:61) /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In function 'OSStatus GraphicsWindowEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)': /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:75: error: 'GetWindowPortBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:75: error: 'InvalWindowRect' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:76: error: 'GetWindowBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In constructor 'osgViewer::MenubarController::MenubarController()': /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:231: error: 'DMGetGDeviceByDisplayID' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:232: error: 'GetAvailableWindowPositioningBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In member function 'void osgViewer::MenubarController::update()': /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:296: error: 'GetWindowBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In constructor 'osgViewer::OSXCarbonWindowingSystemInterface::OSXCarbonWindowingSystemInterface()': /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:358: error: 'GetApplicationEventTarget' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:359: error: invalid conversion from 'OSErr (*)(const AppleEvent*, AppleEvent*, long int)' to 'OSErr (*)(const AppleEvent*, AppleEvent*, void*)' /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:359: error: initializing argument 1 of 'OSErr (* NewAEEventHandlerUPP(OSErr (*)(const AppleEvent*, AppleEvent*, void*)))(const AppleEvent*, AppleEvent*, void*)' /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In member function 'virtual bool osgViewer::GraphicsWindowCarbon::setWindowDecorationImplementation(bool)': /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:526: error: 'GetWindowBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:530: error: 'ChangeWindowAttributes' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:531: error: 'SetWindowBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:535: error: 'ChangeWindowAttributes' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:536: error: 'SetWindowBounds' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:553: warning: 'aglSetDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:322) /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:553: warning: 'aglSetDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:322) /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:554: warning: 'aglSetDrawable' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/AGL.framework/Headers/agl.h:322) /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp:554: error: 'GetWindowPort' was not declared in this scope /Users/ewing/Source/SVN/OpenSceneGraph/src/osgViewer/GraphicsWindowCarbon.cpp: In member function 'void osgViewer::GraphicsWi
Re: [osg-users] mac -install_name
On 5/27/08, Andy Skinner <[EMAIL PROTECTED]> wrote: > I'll admit to being a little past the limit of my knowledge here ... > > We would like to specify the -install_name arg with which we link the shared > libraries. I think it is because we don't want the paths where these things > were built to be in the files. We're trying to replace the value with > something like: "@load_path/". > > Is there a way to specify the -install_name argument on the Mac? > > I tried setting it in our linker flags, then saw it was in there already, > and I think it is added by the OSG build. > > I have looked at the gmane archive, and found some mention of -install_name, > but nothing I can see how to use. > > thanks > andy > The old, now mostly defunc Xcode project set the install_name via the normal Xcode mechanisms. We set the path to @executable_path/../Frameworks In addition to manually adding the flags to the generic CMake flags, CMake has new direct support for this property. We're adding this to the framework build in CMake. (dylibs are less clear about what the default convention should be.) Also, regardless, CMake also builds with the max path padding so you can use the install_name_tool to redefine the install_name after the fact. I'm struggling with time constraints to finish the CMake/OS X integration. If anybody wants to help, please let me know. I currently have put up a Mercurial repository at: http://www.assembla.com/wiki/show/OpenSceneGraphHg There is an example of the install_name stuff in CMake in CMakeModules/OsgMacroUtils.cmake. (Grep for 'FRAMEWORK'). Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building FreeType plugin on Mac OS X 10.5
On 5/6/08, Paul Martz <[EMAIL PROTECTED]> wrote: > Hi folks -- I'm struggling with building OSG on a new Mac OS X 10.5 system. > I'm using a command-line build, not XCode, so using ccmake and make to > build, > > My current roadblock is the FreeType library, with the following error: > > ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib > collect2: ld returned 1 exit status > > After reading about this on the wiki, I went into ccmake and changed any > paths that used "X11R6" to use "X11" instead. (I've already changed > CMAKE_OSX_SYSROOT to the 10.5 SDK.) However, the same error persists. > > How are others building the FreeType plugin on 10.5? Is anyone using > -dylib_file, and if so, with what params, and how are you configuring it in > ccmake? > I haven't looked at this (yet), but the solution in the Xcode project was to remove unnecessary X11 dependencies. Once that happened, the cycle was avoided entirely. For CMake, I suspect X11 is being exposed somewhere unnecessarily and we should remove it. The other solution is try the work-around I wrote on the wiki for 10.5. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile Errors 2.4 Release Mac OS X
FYI, I think I came across the OSG_GLU_TESS_CALLBACK_TRIPLEDOT issue in my testing too. I think the answer is: In Leopard, you need to flip the value. In prior to Leopard, the value works as is. If I recall, the thing is related to some casting which happens to involve a GLenum. If so, I think the issue is related to the fact that Apple redefined GLenum from long to int in Leopard which brings it in line with most other operating systems, but breaks now because the work-around that was used before didn't work. This is another area I am aware of and think I have already begun to address in the upcoming CMake fixes for OS X. But meanwhile, I think flipping this flag will work. (Also, be aware that if you are under Leopard, you should change to the 10.5 SDK instead of the default 10.4u SDK.) -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OS X / cmake-problems, was: Re: OpenSceneGraph-2.3.10 dev release tagged
Hi, sorry, I've been really busy with other work (day job) which happens to
have no OSG or CMake at the moment so it has been hard for me to finish fixing
everything up. I have some stuff written, but it is incomplete and am still
trying to get over various CMake bugs which requires me to write additional
unit tests for CMake to help the authors isolate things.
I'm thinking I could use some help, particularly in the area of testing. So if
there are any volunteers, please let me know. I've put up a quick/dirty
snapshot things on a Mercurial repo. I probably should have spent more time
making a proper bridge to Subversion so I can also refresh against the OSG SVN
head (so help is welcome there too).
> I can "fix" these warnings when I comment out the line
> "${LIB_PUBLIC_HEADERS}" from the CMakeLists.txt-files (here for osg):
>
> ADD_LIBRARY(${LIB_NAME}
> ${OPENSCENEGRAPH_USER_DEFINED_DYNAMIC_OR_STATIC}
> # ${LIB_PUBLIC_HEADERS}
> AlphaFunc.cpp
> .
> .
> .
>
> I don't know if this change can break other platforms.
Ironically, this will break the the Mac framework support. The CMake proper
thing to do is include the headers as is. I'm not sure why you're seeing those
warnings. We might need to file a CMake bug. It could be the extensionless
headers are confusing things, but I haven't noticed the error myself.
Anyway let me know if you can help out.
Thanks,
Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMakeLists FIND_PACKAGE(OpenGL)
FYI, some of our custom CMake modules have been pushed into the main CMake distribution so at some point in the future, we can remove these modules in our tree. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
On 3/29/08, Robert Osfield <[EMAIL PROTECTED]> wrote: > HI Stephan, > > On Sat, Mar 29, 2008 at 1:44 PM, Stephan Huber <[EMAIL PROTECTED]> > wrote: > > Does CMake support building frameworks on OS X now? IMHO this was the > > missing key feature, stopping us using CMake on OS X. > > I don't know the answer to this, I was hoping that OSX users might know. > The answer is maybe. It is in CMake's CVS. There are still some critical bugs, but the infrastructure is at least there now. (OSG's CMake code must be updated to handle this though.) CMake entered its 2.6.0 beta phase two days ago. I'm hoping to press the issue to finalize the support for the final 2.6 release. > > Can CMake generated XCode projects not support frameworks with just > some settings being changed via the Xcode app? I've always been > perplexed at why this shouldn't be straight forward. No, unfortunately, it doesn't work like that. Frameworks, libraries, applications, command-line tools, bundles, etc. targets in Xcode. Targets in Xcode are non-toggleable. You have to construct targets from the ground up. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OS X Cross-Compile SDKs for 10.4 and 10.5
Yes, I saw your post which reminded me that I needed to get this out. By the way, did you resolve your problem? I don't have much to add at this point, except that I hope you've read over the Leopard notes page on the wiki. http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5 (FYI, I just added a blurb about Doxygen DOCSET support.) Yes, feedback on the cross-compile SDK is welcome. As far as I know, we're one of the first to publicly put something out. There are no conventions in place so it would help to know what works, what doesn't, what could be better, etc. And hopefully when we hit something that works, we can convince others to conform to the same conventions which might improve tool chain support. Thanks, Eric On 1/29/08, Stephen Northcott <[EMAIL PROTECTED]> wrote: > Whoo Hoo.. > > Thanks for that Eric. I am working on a project which apparently needs > just that.. Do you want feedback? > > Have a good holiday Robert. > > Kind regards, > Stephen. > > On Jan 30, 2008, at 8:21 AM, E. Wing wrote: > > > This package will let you cross compile for 10.4 or 10.5 using the SDK > > feature in Xcode 3. This makes it easier to build programs targeting > > 10.4 or 10.5 without having to remove/replace your regular frameworks > > each time. > > > > I've been sitting on this awhile. I've been hoping to clean up the > > documentation, but haven't gotten back to it. So I figured it would be > > better to post it and let people try it. Feedback welcome. > > > > You can find the package at: > > > http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0_CrossCompileSDKs.dmg > > > > It is just the stubs. No runtime is included. If you want to run > > something, you still need the regular frameworks. > > > > Robert, could you add a link to the downloads page with the > > description: > > Mac OS X Cross-Compile SDKs (stubs-only) > > > > Thanks, > > 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 > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac OS X Cross-Compile SDKs for 10.4 and 10.5
This package will let you cross compile for 10.4 or 10.5 using the SDK feature in Xcode 3. This makes it easier to build programs targeting 10.4 or 10.5 without having to remove/replace your regular frameworks each time. I've been sitting on this awhile. I've been hoping to clean up the documentation, but haven't gotten back to it. So I figured it would be better to post it and let people try it. Feedback welcome. You can find the package at: http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0_CrossCompileSDKs.dmg It is just the stubs. No runtime is included. If you want to run something, you still need the regular frameworks. Robert, could you add a link to the downloads page with the description: Mac OS X Cross-Compile SDKs (stubs-only) Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX installation changes
> I installed the 2.2 release, but now I'm looking for the wrappers > (I want to try out osgLua). Are they not included in the OSX install? > > /Andreas Sorry, I don't include the wrappers. I think you might be the first to ask. I'm actually horribly ignorant on how they work and what you're supposed to with them and their relation to osgIntrospection. (If somebody wants to give a summary, I would enjoy it.) We do include osgIntrospection (though it hasn't received much testing). I thought you could build osgLua with just osgIntrospection, though I haven't tried it in awhile. (Btw, osgLua has some bugs in their CMake scripts that will need cleaning up if you plan to build it on OS X.) If you do need the wrappers, building via the CMake system is the way to do it. Sorry. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX installation changes
I only intend to do the dmg/drag-and-drop release. It's extremely well documented and even has screencasts now. Somebody else did the installer but I don't think there are concrete plans to continue it. Newbies should understand the concepts discussed in the screencasts, installer or not. http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips -Eric On 12/31/07, Nicholas Yue <[EMAIL PROTECTED]> wrote: > Hi, > I have the 2.0 and 2.2 OSX *.dmg > > I noticed that the 2.0 DMG has a installable package, which I had > installed a couple of months ago. > > Now I am looking at 2.2 and the *.dmg contains folders which we are > suppose to drag across. > > Is the long term plan to get a use to drag individual folders to various > locations or to use an installable package. > > Personally, as a newbie, I prefer the installable package as I know the > bits will be installed at all the right locations. > > New Year Resolution : Must be fluent in OpenSceneGraph API > > Regards and Happy New Year. > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development-system for Mac-OS
Ugh, that's one of the nasty Leopard bugs documented on the Wiki. We managed to sidestep this in the Xcode project by removing extra/unnecessary link dependencies and by properly adhering to SDK rules. CMake's SDK support is still a bit shaky (something we're trying to work on). But if you're lucky, you might still be able to sidestep it in CMake too by removing any extra/unnecessary link dependencies in building the freetype plugin. Or, you can follow the Wiki solution and add the required link line to the build. -Eric On 12/13/07, Gerrick Bivins <[EMAIL PROTECTED]> wrote: > What is the the suggested method to fix the build(ie avoid linking errors) > on OSX 10.5 with CMake?Our app doesn't use frameworks etc so I run into the > "freetype" linking error during compile. I'm not all that familiar > with CMake so other than setting the couple of freetype path variables in > the ccmake gui, I don't know > where to tweek the build so that it picks up the correct libs. As a side > note, I upgrade from Tiger to Leopard > rather than a new install. I'm running on a fairly new mbp (received in > oct). > > Here is the exact error: > [ 86%] Built target osgdb_qt > Linking CXX shared module ../../../lib/osgPlugins-2.2.0/osgdb_freetype.so > ld: cycle in dylib re-exports with > /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libGL.dylib for architecture i386 > collect2: ld returned 1 exit status > ld: cycle in dylib re-exports with > /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libGL.dylib for architecture ppc > collect2: ld returned 1 exit status > lipo: can't open input file: > /var/folders/m2/m2u1oBxxGAqUxi2h7sbDKTI/-Tmp-//ccWn7pVI.out (No such > file or directory) > make[2]: *** [lib/osgPlugins-2.2.0/osgdb_freetype.so] Error 1 > make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/all] > Error 2 > make: *** [all] Error 2 > [EMAIL PROTECTED]/devEnv/research/APIs/OpenSceneGraph_svn$ > biv > > On Dec 13, 2007 1:01 AM, Andreas Goebel <[EMAIL PROTECTED]> wrote: > > > E. Wing schrieb: > > > In my opinion, you are best off getting Leopard. Apple will not be > > > updating OpenGL drivers for Tiger from this point on. Working OpenGL > > > drivers is by far the most important aspect in my opinion. > > > > > Thank you all, > > > > I summarize: I´d (probably) be best of with: > > - Mac OS 10.5 > > - but use 10.4 sdk to target both 10.4 and 10.5 > > > > right? > > > > I know that the slogan is "think different", so that´s what I´ll have to > > do ... > > > > > > Regards, > > > > Andreas > > > > ___ > > 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] Development-system for Mac-OS
In my opinion, you are best off getting Leopard. Apple will not be updating OpenGL drivers for Tiger from this point on. Working OpenGL drivers is by far the most important aspect in my opinion. I've already added a bunch of documentation to the OSGWiki. On just Leopard issues: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5 However, don't misinterpret this as 'everything works fine on Tiger'. For example, we talk about lack of 64-bit support on Leopard with the current state of Mac/OSG code. We don't discuss it much on Tiger because 64-bit OpenGL wasn't supported at all on the OS. Also, the OSX/OSG Readme we ship with the binary packages attempt to document all the major OS X specific problems we've come across. -Eric On 12/12/07, Andreas Goebel <[EMAIL PROTECTED]> wrote: > Berg, Michael schrieb: > > I don't think the problems weren't just 64-bit. About a month ago (), I > > posted a message with the subject "Undefined Symbols in OSG on Mac OS X" > > > > The OSG binary installer for Mac OS X 10.4 (the 10.4u SDK) *mostly* > > worked, but my applications would not compile if I made calls to > > osg::Image::readPixels() or osg::StateSet::setMode(). > > > > E. Wing replied that: > > = > > Yeah, Apple screwed up and broke binary compatibility between 10.4 and > > 10.5 when using OpenGL and C++. I have notes and binaries coming on > > this, but the short story is you can't use 10.4 built frameworks > > against the 10.5 SDK or you get the linking problems you see. Either > > switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks > > built against the 10.5 SDK. > > = > > > > Anyway, once the Mac OS X 10.5 SDK (32-bit only) was released and I > > upgraded to it (http://www.openscenegraph.org/projects/osg/wiki/Downloads) > > it solved the linking problems I was having. > > > > If you look through the release notes for the 10.5 SDK, it mentions that > > Apple changes some of the types in the OpenGL headers, so OSG had to be > > rebuilt for that. > > > Hi, > > thanks for the info. But does that mean that I would avoid those > problems by simply using Mac OS 10.4 ? > > Regards, > > Andreas > > ___ > 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] Documentation Building Problem
Actually, it's partially implemented, but not working as you can see. If I recall, part of the problem was because OpenThreads and OSG are merged together, there was an ambiguity problem. (I think I had progressed as far as getting the OpenThreads and Producer documentation working if you built them standalone.) Though I think now, the doxyfile for OpenThreads is not even present in the svn externals I'm guessing that if OpenThreads documentation is built, it will have to be as fallout from the main OSG documentation system. The other part of the problem is that I just haven't had time to finish it. More specifically, I think OSG had a more complicated/feature-rich Doxygen configuration. There is kind of a template/pattern I've been following for integrating Doxygen and CMake with deals with a single "doxyfile.cmake" which in turn generates a doxyfile. But OSG seems to not have a single doxyfile, but multiple files. So I haven't figured out how to resolve those differences with the template pattern I've been using. So yes, contributions are welcome. -Eric On 12/7/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > On Dec 6, 2007 6:29 PM, Michele Bosi <[EMAIL PROTECTED]> wrote: > > Hello to all, > > I was trying to build the documentation for OSG 2.2 under WinXP using > > CMake but apparently there is a problem, when I configure the > > makefiles CMake complains that there isn't the file > > "[...]/doc/Doxyfiles/doxyfile.cmake", which in fact does not exist. Is > > that a bug or a "feature"? How can I build the documentation? > > Just wanted to add that I already built and use daily the library > > itself without the documentation and everything went smooth till now. > > Cmake support for building the docs hasn't been added yet, so > contributions of this from the community would be most welcome :-) > > The intructions about building the docs can be found on > openscenegraph.org, just search for doxygen. > > Robert. > ___ > 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] CMake Search Paths ?
>> Is there a simpler way to give cmake user defined search paths? > So, telling people about the shiny world of 'ccmake' and begging for > procedures that are _highly_impractical_ on many people's setup is one > thing, This strikes me as a newbie-like question, not an automation (advanced) question so ccmake is a perfectly reasonable answer. That's the reason for the tool's existence. > If you disallow these people to modify the required flags on the 'cmake' > command line, Nobody disallowed anything. I also gave 3 other perfectly good answers that are geared towards automation and command lines. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake Search Paths ?
There are a bunch of ways to deal with this. You shouldn't modify the CMakeCache directly. And you really shouldn't need to modify the CMakeLists.txt. 1) Use the ccmake instead of cmake. It exists for this very reason and is the easiest, most reliable answer. (I constantly beg people to use this so we don't get these kinds of questions over and over.) 2) Define the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH environmental variables. See the CMake documentation, but essentially: export CMAKE_LIBRARY_PATH=/usr/nekoware/lib 3) Define the OSGDIR environmental variable or OSG_ROOT environmental variable. This is something we put in, though I'm not sure if it is consistently applied everywhere yet. 4) Not recommended, but still better than editing the CMakeCache (but not by much), use the cmake -D := switch to explicitly set values. See the CMake documentation. -Eric On 11/19/07, Paul Pocock <[EMAIL PROTECTED]> wrote: > Hi, This may be an issues with the developers of cmake but I've had a > difficult experience building OSG 2.2 official release on IRIX 6.5 using > the cmake build process. Problems namely with specifying my > own /include /lib paths. > > it seems to want to ignore any arguments I pass to it , I don't think > Cmake even reads the PATH env variable . To solve this I've had to hard > code the paths in CMakeCache and CmakeLists.txt and other areas in > order for OSG to build with the headers and libs I want. Even using the > SET command in CmakeLists.txt doesn't seem to fix the problem. It seems > to me that Cmake has a set of hardcoded directories that it will search. > > Is there a simpler way to give cmake user defined search paths? > > > Other modules I had to alter to make cmake search the directories I > specify: > > In CmakeModules/ for all search paths: > > FIND_LIB /usr/nekoware/lib > > /usr/freeware/lib64 > > FIND_INCLUDE /usr/nekoware/include > > /usr/freeware/include > > /src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir > > added: /usr/nekoware/lib/libjpeg.so > > > I also wonder if cmake builds osg on 64 bit platforms in 64 bit? or does > it build in 32 bit? How can you tell or know what cmake is doing? > > Regards > > Paul > > > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the CRIMES > ACT 1914. If you have received this email in error, you are requested to > contact the sender and delete the email. > > > ___ > 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] 2D Graphs/plots
I worked on a plotting system using OpenSceneGraph not too long ago. Speed was a very important factor for us because we were dealing with real time data. My experience with GNUplot is that it's not very good for this type of situation. OpenGL gave us a lot of power to be able to zoom and manipulate data in real time. There are lots of inexpensive OpenGL operations you can perform such as changing the view frustum (for zoom), using textures for effects on traces, pixel shaders to control color, and vertex shaders for stupidly fast transforms (e.g. change to log scale). But in building our own in OpenGL, there was a lot of detail work to get everything to look just right. Text labels and layout were probably the hardest parts. We implemented the underlying drawing in OpenGL/OSG, and then integrated a native UI layer on top of it in Cocoa so it looked and behaved like a good/seamless Mac OS X application and leveraged all the native widgets available. It was a lot of work though. -Eric On 11/12/07, Anders Backman <[EMAIL PROTECTED]> wrote: > Hi all. > > A while back someone wanted to do 2D plots in an OSG app. > > I was just wondering, is there any one on the list with knowledge about the > best way to create > 2D graphs (gnuplot alike) from an interactive app? > Im looking for a portable solution windows/linux... > > Could be OpenGL rendered inside osg, > could be separate window but with tight integration, but Im not really > looking for a QT/fltk/Wtk widget, I would like to have something with less > dependencies... > > Someone mentioned using gnuplplot through a pipe? How would that work in > windows? > > /Anders > > > -- > > > > Anders Backman Email:[EMAIL PROTECTED] > HPC2N/VRlab Phone:+46 (0)90-786 9936 > Umea university Cellular: +46 (0)70-392 64 67 > S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 > http://www.cs.umu.se/~andersb > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New Mac OS X 10.5 Leopard binaries posted and Leopard specific documentation added to the Wiki
Some things have been updated. First, a new 10.5 oriented binary package has been uploaded to: http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0-10.5SDK.dmg Hopefully, Robert can add the link to the main downloads page soon. The description should be: Mac OS X 10.5 Universal Binaries (10.5 SDK, 32-bit-only) Second, I have updated and added a bunch of documentation. This is included in the OSX_OSG_README.rtf included in the .dmg, but I have also added all this information plus additional information to the Wiki. Leopard Notes: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5 I also made some updates and fixes to some of the other OS X related pages I found on the Wiki. Since the mail archive seems to have been lost, I added my original post on Objective-C/C++ to the Wiki for reference: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Objective-C And as described in the Leopard notes, I hope to add a formal 10.4 and 10.5 cross-compile SDK for OSG soon. Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building osg on release version of leopard
Xcode only in the SVN. We're currently trying to iron out issues within CMake itself wrt to SDKs and also Leopard, so the OSG/CMake system still isn't quite there yet. -Eric On 11/8/07, Mihai Radu <[EMAIL PROTECTED]> wrote: > Thanks for the fix Eric, > > Is this change made to the CMake generated projects, or to the XCode > directory from svn ? > > Mihai > > E. Wing wrote: > > Sorry, the path was going to $(SDKROOT)/usr/X11R6/lib, but I forgot to > > account the change to X.org, so the path needed to be > > $(SDKROOT)/usr/X11/lib. I updated the Xcode project so both paths are > > listed so it should now do the right thing against both the 10.4 and > > 10.5 SDKs. > > > > -Eric > > > > > > On 11/7/07, Radu Mihai <[EMAIL PROTECTED]> wrote: > > > >> Hi > >> > >> To confirm, tis problem is still present when compiling from svn on > >> Leopard. > >> Setting the sdk to 10.5 did not work, but the previously mentioned fix > >> did ( adding specific dylib to the link line ) > >> > >> Here is a more informative description of the fix: > >> http://www.racoonfink.com/mt-rr-trackback.cgi/580 > >> > >> -- > >> Radu Mihai > >> [EMAIL PROTECTED] > >> > >> > >> > >> On 29-Oct-07, at 9:36 AM, Daniel Larimer wrote: > >> > >> > >>> The problem I identified is a fix for building against 10.5 and the > >>> build process would have to be smart enough to test it. It would also > >>> have to be smart enough to know when it is being built for X11 instead > >>> of AGL. I hope Apple fixes the libGL.dylib bug because it has been a > >>> thorn in my side for several of the code bases I maintain. > >>> > >>> Perhaps I didn't understand your solution, I thought your fix required > >>> installing a new version of freetype that linked against Apple's open > >>> gl instead of the X11 open gl. > >>> > >>> Dan > >>> > >>> On Oct 29, 2007, at 3:21 AM, E. Wing wrote: > >>> > >>> > >>>> I haven't tried what you suggested so I could be mistaken. But if > >>>> James's problem is what I think it is, your above suggestion will > >>>> either not work or could potentially cause other > >>>> serious/hard-to-identify problems. > >>>> > >>>> The problem I',m identifying is a binary interface incompatibility > >>>> between 10.4 and 10.5. The fix I checked in (which is actually much > >>>> shorter than your solution because I just add an $(SDKROOT) variable) > >>>> makes sure to look in the correct SDK locations for things. I suspect > >>>> your fix is going to try to always link to the native system > >>>> framework > >>>> (10.5 in this case) which will cause a linking failure if you are > >>>> building against the 10.4u SDK and is generally the wrong thing to > >>>> do. > >>>> > >>>> But again, I could be mis-identifying the problem. I do recall a > >>>> cycle > >>>> problem kind of like what James described many months ago in a much > >>>> older seed, but that problem was supposedly fixed quite awhile ago > >>>> and > >>>> I haven't encountered it since. (I put together a 10.5 OSG binary > >>>> package as a test run against the last seed and I did not encounter > >>>> any build problems as described.) > >>>> > >>>> -Eric > >>>> > >>>> > >>>> On 10/28/07, Daniel Larimer <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> There is a much easier work around to this X11 Open GL bug and that > >>>>> is > >>>>> to add the following to the linking command. I found this on the > >>>>> Fink > >>>>> page documenting changes required for Leopard: > >>>>> > >>>>> > >> > http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug > >> > >>>>> -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/ > >>>>> Versions/ > >>>>> A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ > >>>>> Versions/A/Librarie s/libGL.dylib > >>>>> > >>>>>
Re: [osg-users] building osg on release version of leopard
Sorry, the path was going to $(SDKROOT)/usr/X11R6/lib, but I forgot to account the change to X.org, so the path needed to be $(SDKROOT)/usr/X11/lib. I updated the Xcode project so both paths are listed so it should now do the right thing against both the 10.4 and 10.5 SDKs. -Eric On 11/7/07, Radu Mihai <[EMAIL PROTECTED]> wrote: > Hi > > To confirm, tis problem is still present when compiling from svn on > Leopard. > Setting the sdk to 10.5 did not work, but the previously mentioned fix > did ( adding specific dylib to the link line ) > > Here is a more informative description of the fix: > http://www.racoonfink.com/mt-rr-trackback.cgi/580 > > -- > Radu Mihai > [EMAIL PROTECTED] > > > > On 29-Oct-07, at 9:36 AM, Daniel Larimer wrote: > > > The problem I identified is a fix for building against 10.5 and the > > build process would have to be smart enough to test it. It would also > > have to be smart enough to know when it is being built for X11 instead > > of AGL. I hope Apple fixes the libGL.dylib bug because it has been a > > thorn in my side for several of the code bases I maintain. > > > > Perhaps I didn't understand your solution, I thought your fix required > > installing a new version of freetype that linked against Apple's open > > gl instead of the X11 open gl. > > > > Dan > > > > On Oct 29, 2007, at 3:21 AM, E. Wing wrote: > > > >> I haven't tried what you suggested so I could be mistaken. But if > >> James's problem is what I think it is, your above suggestion will > >> either not work or could potentially cause other > >> serious/hard-to-identify problems. > >> > >> The problem I',m identifying is a binary interface incompatibility > >> between 10.4 and 10.5. The fix I checked in (which is actually much > >> shorter than your solution because I just add an $(SDKROOT) variable) > >> makes sure to look in the correct SDK locations for things. I suspect > >> your fix is going to try to always link to the native system > >> framework > >> (10.5 in this case) which will cause a linking failure if you are > >> building against the 10.4u SDK and is generally the wrong thing to > >> do. > >> > >> But again, I could be mis-identifying the problem. I do recall a > >> cycle > >> problem kind of like what James described many months ago in a much > >> older seed, but that problem was supposedly fixed quite awhile ago > >> and > >> I haven't encountered it since. (I put together a 10.5 OSG binary > >> package as a test run against the last seed and I did not encounter > >> any build problems as described.) > >> > >> -Eric > >> > >> > >> On 10/28/07, Daniel Larimer <[EMAIL PROTECTED]> wrote: > >>> There is a much easier work around to this X11 Open GL bug and that > >>> is > >>> to add the following to the linking command. I found this on the > >>> Fink > >>> page documenting changes required for Leopard: > >>> > http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug > >>> > >>> -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/ > >>> Versions/ > >>> A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ > >>> Versions/A/Librarie s/libGL.dylib > >>> > >>> Dan > >>> > >>> > >>> On Oct 28, 2007, at 10:55 AM, James E.Hopper wrote: > >>> > >>>> the xcode project needs to be fixed. we can no longer use the x11 > >>>> version of libfreetype as it causes a cycle error because it pulls > >>>> in > >>>> the x11 version of opengl. the ossim project has a universal > >>>> libfreetype in their dependencies package. link to that lets > >>>> osgdb_freetype build cleanly. > >>>> > >>>> dependencies package can be downloaded at: > >>>> > >>>> http://ossim.telascience.org/ossimdata/MacOSX/ > >>>> > >>>> best jim > >>>> > >>>> > >>>> > >>>> ___ > >>>> 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 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] Undefined Symbols in OSG on Mac OS X
Yeah, Apple screwed up and broke binary compatibility between 10.4 and 10.5 when using OpenGL and C++. I have notes and binaries coming on this, but the short story is you can't use 10.4 built frameworks against the 10.5 SDK or you get the linking problems you see. Either switch to the 10.4u SDK on Leopard, or use a set of OSG frameworks built against the 10.5 SDK. -Eric On 11/4/07, Berg, Michael <[EMAIL PROTECTED]> wrote: > I have been developing an OSG application on Linux and recently began > making it cross-platform with OS X 10.5 (Leopard). > > Either I'm not doing something correctly for an OS X compile or there is > a bug in the OpenSceneGraph-2.2.0.dmg found at > http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0.dmg. > > I'm using CMake for cross platform builds, and whether I generate a > Makefile or an Xcode build environment, the compile fails on OS X with > this message: > == > Undefined symbols: > "osg::StateSet::setMode(unsigned int, unsigned int)", referenced from: > _main in main.o > _main in main.o > "osg::Image::readPixels(int, int, int, int, unsigned int, unsigned > int)", referenced from: > screenshot(osg::Camera const&) in main.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > == > > > The offending snippets of code are: > == > osg::ref_ptr root = new osg::Group(); > osg::ref_ptr state = root->getOrCreateStateSet(); > state->setMode(GL_LIGHTING, osg::StateAttribute::ON); > state->setMode(GL_LIGHT0, osg::StateAttribute::ON); > == > osg::ref_ptr image = new osg::Image(); > image->readPixels(static_cast(viewport->x()), > static_cast(viewport->y()), > static_cast(viewport->width()), > static_cast(viewport->height()), > GL_RGBA, GL_UNSIGNED_BYTE); > == > > This same code compiles and links without any problem on Linux. > > On OS X, options passed to the compiler include: > -F/Library/Frameworks \ > -framework osg -framework osgDB -framework osgGA \ > -framework osgParticle -framework osgUtil \ > -framework osgText -framework osgViewer > > and I have followed the instructions for installing the OSG frameworks > into /Library/Frameworks. > > If I comment out the code that triggers the linking errors, I can get > the code to compile, link, and run. > "otool -L" shows for following for the resulting executable: > == > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 111.0.0) > @executable_path/../Frameworks/osg.framework/Versions/A/osg > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgDB.framework/Versions/A/osgDB > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgGA.framework/Versions/A/osgGA > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgParticle.framework/Versions/A/osgParticle > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgUtil.framework/Versions/A/osgUtil > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgText.framework/Versions/A/osgText > (compatibility version 0.0.0, current version 1.0.0) > @executable_path/../Frameworks/osgViewer.framework/Versions/A/osgViewer > (compatibility version 0.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) > == > > So executable is linked against the "osg" framework, and the application > runs successfully (with the features that I commented out to get it to > build disabled of course). > > Any ideas? Am I doing something wrong? Or did osg::StateSet::setMode() > and osg::Image::readPixels() not make it into the OS X .dmg file (or not > in a form that can be linked against)? > > - Michael Berg > ___ > 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] building osg on release version of leopard
I haven't tried what you suggested so I could be mistaken. But if James's problem is what I think it is, your above suggestion will either not work or could potentially cause other serious/hard-to-identify problems. The problem I',m identifying is a binary interface incompatibility between 10.4 and 10.5. The fix I checked in (which is actually much shorter than your solution because I just add an $(SDKROOT) variable) makes sure to look in the correct SDK locations for things. I suspect your fix is going to try to always link to the native system framework (10.5 in this case) which will cause a linking failure if you are building against the 10.4u SDK and is generally the wrong thing to do. But again, I could be mis-identifying the problem. I do recall a cycle problem kind of like what James described many months ago in a much older seed, but that problem was supposedly fixed quite awhile ago and I haven't encountered it since. (I put together a 10.5 OSG binary package as a test run against the last seed and I did not encounter any build problems as described.) -Eric On 10/28/07, Daniel Larimer <[EMAIL PROTECTED]> wrote: > There is a much easier work around to this X11 Open GL bug and that is > to add the following to the linking command. I found this on the Fink > page documenting changes required for Leopard: > http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug > > -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/ > A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ > Versions/A/Librarie s/libGL.dylib > > Dan > > > On Oct 28, 2007, at 10:55 AM, James E.Hopper wrote: > > > the xcode project needs to be fixed. we can no longer use the x11 > > version of libfreetype as it causes a cycle error because it pulls in > > the x11 version of opengl. the ossim project has a universal > > libfreetype in their dependencies package. link to that lets > > osgdb_freetype build cleanly. > > > > dependencies package can be downloaded at: > > > > http://ossim.telascience.org/ossimdata/MacOSX/ > > > > best jim > > > > > > > > ___ > > 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] building osg on release version of leopard
Oh, I think I know what happened. Were you compiling in Leopard against the 10.4u SDK and not the 10.5 SDK? It looks like I forgot to check in a minor fix to handle that case which might explain your compile problem. I just checked in my forgotten fix which I hope solves this problem. This is actually a specific instance of a bigger problem though in which I have notes coming. Without going into detail here, Apple screwed up and in very specific cases when using OpenGL with C++ and libraries, Apple accidently broke binary compatibility between things building with 10.5 and OpenGL/C++ things built against 10.4u (or earlier). -Eric On 10/28/07, E. Wing <[EMAIL PROTECTED]> wrote: > I haven't had any problems with compiling or using the freetype plugin > in Leopard though I'm still on the final seed before GM. The > libfreetype that ships with Leopard is already Universal 32/64-bit. > The Xcode project works fine for me under 32-bit. (I haven't done > 64-bit due to osgViewer's Carbon backend and the qt plugin. I just > submitted an ImageIO plugin to osgsubmissions Friday but the build > system isn't yet updated to do anything with it.) > > -Eric > > > > > > > > > > > On 10/28/07, James E. Hopper <[EMAIL PROTECTED]> wrote: > > the xcode project needs to be fixed. we can no longer use the x11 > > version of libfreetype as it causes a cycle error because it pulls in > > the x11 version of opengl. the ossim project has a universal > > libfreetype in their dependencies package. link to that lets > > osgdb_freetype build cleanly. > > > > dependencies package can be downloaded at: > > > > http://ossim.telascience.org/ossimdata/MacOSX/ > > > > best jim > > > > > > > > ___ > > 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] building osg on release version of leopard
I haven't had any problems with compiling or using the freetype plugin in Leopard though I'm still on the final seed before GM. The libfreetype that ships with Leopard is already Universal 32/64-bit. The Xcode project works fine for me under 32-bit. (I haven't done 64-bit due to osgViewer's Carbon backend and the qt plugin. I just submitted an ImageIO plugin to osgsubmissions Friday but the build system isn't yet updated to do anything with it.) -Eric On 10/28/07, James E. Hopper <[EMAIL PROTECTED]> wrote: > the xcode project needs to be fixed. we can no longer use the x11 > version of libfreetype as it causes a cycle error because it pulls in > the x11 version of opengl. the ossim project has a universal > libfreetype in their dependencies package. link to that lets > osgdb_freetype build cleanly. > > dependencies package can be downloaded at: > > http://ossim.telascience.org/ossimdata/MacOSX/ > > best jim > > > > ___ > 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] New binaries
I uploaded the OS X binary last week, but I have been unable to change the downloads page to reflect it. Even with the password Jose setup for me, I am not given the edit button for the downloads page. The binary is located here: http://www.openscenegraph.org/files/OpenSceneGraph-2.2.0/OpenSceneGraph-2.2.0.dmg The description is "Mac OS X 10.4 Universal Binaries (10.4u SDK)" Thanks, Eric On 10/15/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > On 10/10/07, Mike Weiblen <[EMAIL PROTECTED]> wrote: > > Yes, I've tried unsuccessfully to edit the downloads page, but it has a > > separate password for security. > > Hopefully someone cool enough can add links to the available binaries. > > Jose should be able to provide you with a password. > > Once I catch up with things I'll update the pages if they haven't been > done by the time I get to it. > > Cheers. > Robert. > ___ > 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-2.2 stable released
I have a Mac binary package ready to go. Where/how should I upload it? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPlugins and OSX Universal Binaries
Should just work presuming no endian bugs in the underlying code. On 9/17/07, Eric Sokolowsky <[EMAIL PROTECTED]> wrote: > I plan to create an OSG 1.2 based application on Mac OSX which is a > universal binary. Are there any issues that I need to be aware of > regarding the osgPlugins? If I use the Xcode projects with the > distribution to create the various frameworks, copying the generated > osgPlugins to the proper Resources directory within the application > bundle, will it Just Work? Do I need to run lipo separately on the ppc > and i386 .so files? > > 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
Re: [osg-users] Producer on Mac
Hi Eric, By default, the Producer.framework is the same exact framework as Producer_AGL.framework. We gave the Producer_AGL.framework its suffix mainly for private testing when we needed both the AGL and X11 frameworks to exist side-by-side for comparison. Producer.framework is the one we shipped with the OSG 1.2 binary package. I recommend you stick to the defaults and use the Producer.framework which is really just the AGL version. I don't touch the X11 version often on OS X. I think you might actually know more about it than I do. I thought you were one of the unfortunate souls that pushed new/advanced application development under X11 on OS X and hit some devastating X11/OpenGL bugs on the platform which couldn't be worked around. By the way one unfortunate quirks of using Producer with the AGL backend is you have to make sure you compile with a specific #define, something like -DUSE_AGL_IMPLEMENTATION (the exact string is documented in the OSX Readme somewhere and I mention it in the command-line build video tutorial). Producer uses the same headers for AGL and X11 guarded with the #ifdefs. But it assumes X11 by default unless you tell it otherwise. But if you've been using regular Producer.framework , you probably have already been doing this. -Eric On 9/5/07, Eric Sokolowsky <[EMAIL PROTECTED]> wrote: > Eric Wing and other OSX experts, > > I used Xcode to compile OSG for my OSG 1.2 application that uses > osgProducer::Viewer. I just used the regular Producer.framework to > create my application. Is this the best solution, or should I be using > the Producer_X11.framework or Producer_AGL.framework? What are the > differences? I'm not yet ready to move up to the latest OSG. > > 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
Re: [osg-users] Max OS X tutorial videos, broken links (was: RE: Tutorials)
I think delete access may be restricted beyond the default osg login. I couldn't find a delete link. However, if you upload a file, you get a checkbox to replace a file if it already exists. I tried enabling that, but my upload failed saying that the account didn't have the delete privalege. There is one file on the web page that I need to delete (the last one), because the original upload didn't take, and there is only a tiny fraction of the file that made it. Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Max OS X tutorial videos, broken links (was: RE: Tutorials)
I tried 'attaching' one file. It causes the page to create a new section at the bottom of the page called "Attachments" and lists each one. Since this information is redundant to the information at the top (and contains no useful description aside from the filename), I wanted to remove the bottom section. But when I go to edit the page, nothing in the Attachments section appears in the editor. (And interestingly, there doesn't seem to be a way to remove a file.) I would like to clean this page up. Is there a way to do this? On 8/28/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > Hi Eric, > > On 8/28/07, E. Wing <[EMAIL PROTECTED]> wrote: > > I found my copies of the videos if you still need them. I experimented > > with uploading them to YouTube, but YouTube broadcasts in too low of a > > resolution which makes it impossible to read anything, so it's pretty > > much useless except for pointing people to the OSG site for higher > > quality videos. > > Great to hear you've tracked the video down. You could either just > attach them to the page on the wiki, or perhaps get them upload to the > downloads page. > > Hopefully Jose will be reading this and can suggest a good method for > upload big amounts of data to directories like /downloads. > > Robert. > ___ > 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] Max OS X tutorial videos, broken links (was: RE: Tutorials)
I found my copies of the videos if you still need them. I experimented with uploading them to YouTube, but YouTube broadcasts in too low of a resolution which makes it impossible to read anything, so it's pretty much useless except for pointing people to the OSG site for higher quality videos. -Eric On 8/23/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > On 8/23/07, E. Wing <[EMAIL PROTECTED]> wrote: > > D'oh. Are the files lost, or are the links just broken? > > I don't know yet, we've moved server and wiki, the new wiki page has > the same broken links :-| > > > http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips > > The links are into the downloads/movies directory that isn't present > on new server. The downloads directory is there is just doesn't have > the movies directory. > >http://www.openscenegraph.org/downloads/ > > Unfortunately the old server is no more, so we can't just log in a > copy the files across. I guess they might be on backups that Don > might have. There is a chance that I copied them across to the new > server too, but I didn't copy everything across from the old website > as there was quite a bit of old no longer used files there which > didn't need copying across so I didn't just do a total copy. I'll > long in a double check what bits I copied across. > > Robert. > ___ > 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] Max OS X tutorial videos, broken links (was: RE: Tutorials)
D'oh. Are the files lost, or are the links just broken? Thanks, Eric On 8/22/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > Eric Wing has put a few very informative videos on the OSG wiki > > > regarding installing/using OSG on a Mac: > > > http://www.openscenegraph.org/index.php?page=Tutorials.MacOSXTips > > > > Alas, all the videos on that page seem to point to broken > > links. Any chance > > of making them work again? > > Hm, that's unfortunate. They're great videos. > > Posting this with a different subject to raise visibility. >-Paul > > ___ > 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] compiling on Mac OS X Leopard 64 bit
Can't say much about Leopard due to the NDA. But there has been public traffic about Carbon and 64-bit. The summary is that there will be no 64-bit path for Carbon. That means GraphicsWindowCarbon will not work and a Cocoa version of GraphicsWindow is the way to go for 64-bit. (I've warned people that this day would come.) There is currently no Cocoa version. You are free to write it. I did write an example called osgviewerCocoa. Basically, the example needs to be turned inside-out for GraphicsWindowCocoa. This might imply certain things to you about QuickTime (and the plugin). What's not under NDA is that QuickTimeKit (QTKit) in Tiger is a ground up reimplementation of the QuickTime SDK which looks a heck of a lot more 64-bit (and also endian) clean than the old QuickTime SDK. So for now, you want to skip building the QuickTime plugin. You can edit your CMakeLists.txt in the src/osgPlugins directory and remove the entry that handles that plugin. I have been privately discussing with somebody to create two new plugins (one for QTKit, the other for ImageIO). But my employment situation has drastically changed recently so I can't make any promises right now. -Eric On 8/6/07, Andy Skinner <[EMAIL PROTECTED]> wrote: > We have someone trying to build OSG on 64 bit Leopard. He has run into > a couple of things: > > GraphicsWindowCarbon.cpp won't compile. Is anyone doing a Cocoa > version? We aren't looking for one, but would like to not have a build > issue, and may be able to help out. > > The quicktime plugin is conflicting with what is on the machine, if I > understand it correctly. Anybody working on an update to this? > > Here's a summary from the guy working on it: > === > On Leopard 32-bit, all of the APIs are there, but they generate > "deprecated function" compiler warnings. On 64-bit, they generate > compiler errors because they're just plain not available. > === > > Is there a way to not compile the quicktime plugin? If we could specify > to CMake or somewhere either a list of plugins to not compile, or a list > to compile, we could just avoid the quicktime plugin for now. > > thanks > andy > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to screencapture via FBO using osg::Viewer's master camera?
This is kind of a follow up to something awhile back. I'm trying to fix up the screenshot feature in the osgviewerCocoa example which broke when migrating away from SimpleViewer. I was told that instead of manipulating the scene graph nodes to insert my own camera at the top of the scene to setup an FBO to get a screenshot, I could just try using the Master camera that belongs to osg::View. So I'm finally trying that and gutted all my old camera code, but I must be missing something because now I only get a solid black image when I try it. Basically my code is: // Setup camera for FBO osg::Camera* root_camera = theViewer->getCamera(); osg::Camera::RenderOrder old_render_order = root_camera->getRenderOrder(); root_camera->setRenderOrder(osg::Camera::PRE_RENDER); root_camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); root_camera->attach(osg::Camera::COLOR_BUFFER, osg_image.get()); // Render theViewer->frame(); // not sure if I need to flush??? glFlush(); // Restore camera to original settings root_camera->detach(osg::Camera::COLOR_BUFFER); root_camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER); root_camera->setRenderOrder(old_render_order); // Do something with osg_image, but it's currently solid black. Any suggestions on how to fix this? Thanks, Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building virtualplanetbuilder on mac
Hi James, I don't recall any significant problems with the FindGDAL module. Maybe you have a stale CMake cache? In the ccmake menu under advanced options, you can turn on VERBOSE mode. Also under the command line make, you can temporarily set the value like: make VERBOSE=1 -Eric On 7/26/07, James E. Hopper <[EMAIL PROTECTED]> wrote: > Robert, > > if it were a bad path than the static link should fail as well. the > path in CMakeCache.txt is correct (/Library/Frameworks). i will try > to do an update and try again. I am not very clear on how to see > whats going on with cmake. is there a way to turn on a verbose > switch so i can see the actual compile commands? > > best jim > > On Jul 26, 2007, at 4:22 PM, osg-users- > [EMAIL PROTECTED] wrote: > > > Check the CMakeModules/FindGDAL.cmake for the paths it checking for > > GDAL, it could simply be that on your platform the libs are installed > > in a place its not looking. You set custom location by setting > > GDAL_DIR env var then removing the CMakeCache.txt and then re-running > > ./confugure. > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
