[osg-users] state of CMake build systems for iOS and Android
Just wanted to run a quick poll on that. I am working again on osgART and obviously wanted to get it working on iOS and Android and a few other platforms. Hence, I started to look into the OSG build system. With CMake targeting iOS5 w/ Xcode on GLES2 I had more or less luck as most things are not hard wired, except for the SDK. But I get a working project file and it builds all libs. (except that one thing I sent to osg-submissions). But now with Android the situation seems a bit different. I am a huge fan of the Android NDK standalone toolchain as it allows parallelizing the build and you can use IDEs transparently. But currently the OSG CMake system hardwires a lot of things and uses the Android build system which makes it really annoying to build. Anybody interested in changing that? I am just not interested to code for the bin :) For those of you interested in my CMake toolchain files, please clone them from github (github com seichter CMake-Toolchain-Collection). Can't post the URL as I am categorized as newbie (haha, thats really great) Cheers, Hartmut -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44157#44157 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::GraphicsWindowCarbon with wxWidgets/wxMac
Hi there, I've seen somewhere in the list somebody had some success with using the GraphicsWindowCarbon within bare Carbon. Now I am trying the same with wxWidgets 2.8.10 and it seems not to work as expected (corrupted Window background). Did somebody on the list had some success and can share a code snippet? I got it working with GTK and Win32 (wxGTK and wxMSW respectively). Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Cocoa and wxOSX/Cocoa Application
Thanks Stephan, for the explanation - I will see if I can make this work with wxWidgets trunk. Cheers, H On Thu, 08 Oct 2009 01:06:31 +0200, Stephan Huber ratzf...@digitalmind.de wrote: Hi Hartmut, li...@technotecture.com schrieb: is there a obvious way to tell osgViewer (Cocoa version of recent trunk) to leave the menubar alone? I guess the code is still experimental - so would it be possible to add this functionality? Attached a screenshot that shows the result of combining wxOSX (Cocoa) and a standard osgViewer::Viewer (also Cocoa). This was part of my investigation into updating my application. GUI toolkit is done in wxWidgets, rendering osg - I actually wanted to get the viewer integrated with the GUI again, not separate like in the image attached. A few observations: 1) using wxOSX (2.9 configure flag --with-osx_cocoa) and trunk of osg compiled with Cocoa viewer - method with GraphicsWindowCocoa - I derived from GraphicsWindowCocoa::WindowData and set the NSView to the one retrieved from my underlying control (wxControl derived) - the result is a window ~64x64 in the left top corner, regardless of the constructor flags I set. GraphicsWindowCocoa is the one who creates the NSView. You pass a windowdata with the flags CreateOnlyView to the constructor and after the GraphicsWindowCocoa is constructed you can query the NSView from the WindowData via getCreatedNSView() and add it to your NSWindow / NSView. For this method you'll have to create your window (or load it from a nib-file) yourself. Here's a small snippet: osgViewer::GraphicsWindowCocoa::WindowData* wdata = new osgViewer::GraphicsWindowCocoa::WindowData(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 0; traits-y = 0; traits-width = 800; traits-height = 600; traits-inheritedWindowData = wdata; traits-doubleBuffer = true; traits-sharedContext = 0; traits-vsync = true; // create graphics context osg::ref_ptrosgViewer::GraphicsWindowCocoa gc = dynamic_castosgViewer::GraphicsWindowCocoa*(osg::GraphicsContext::createGraphicsContext(traits.get())); NSView *view = wdata-getCreatedNSView(); // Mainview is the main-view of the window ... [mainview addSubview: view]; // add the view created by GraphicsWindowCocoa to the main-view If you want a NSWindow containing only one NSView, use the GraphicsWindowCocoa with a GraphicsWindowCocoa::WindowData(0), then GraphicsWindowCocoa does not create the app-specific stuff and returns the window only. You can get the NSWindow-reference via GraphicsWindowCocoa::getWindow() To recap the three options: CreateOnlyView: GraphicsWindowCocoa creates only the view (a NSOpenGLView) and store it in the WindowData-class (no window, nada) CheckForEvents: osgViewer queries the system for new events and handles them (mimicking the Cocoa event loop) . If you are using a real cocoa app which installs an event loop, you don't want this. PoseAsStandaloneApp: osgViewer constructs a standard menubar and installs some handler for it and some other stuff. If you are using a real cocoa app which handles the menubar automagically, you don't want this. - method with setUpViewerAsEmbeddedInWindow - the canvas ends up somewhere on the screen whole application gets stuck - I tried to use either timerbased or idleloop based update via _viewer-frame() I have no experience with setUpViewerAsEmbeddedInWindow but to my knowledge you'll have to manage the OpenGLContext (make current, swap, etc) by yourself - method with external viewer: see attached image, the menubar gets unusable see my previous notes about WindowData(0) - method with GraphicsCanvas (derived from osgviewerWX) - mixed bag, I get an occasionally stuck GUI. For instance MenuItems don't highlight but can be selected. You'll have to be careful which thread handles the events. Mac OS X does not like, if you handle events on another thread than the main-thread. Perhaps WindowData(0) is your friend here, too. Hope this helps 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] osgDB plugins with video support?
This might be an edge case for usage but I try to use a video as a
texture loaded from a .osg file (or any other fileformat if that
matters). Fiddeling around with a simple .osg file I get something like
[1] - I get the first frame - great but that's it. It does not run the
video and I couldn't find any reference in the plugins to deal with this
case. Is this just not supported or do I miss an environment variable
etc. pp. - system is OSG 2.8.x from the 2.8 branch on OS X (thus
QuickTime plugin)
Cheers,
Hartmut
1)
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file /Users/seichter/Movies/bowling.avi
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
--
Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] trunk: ffmpeg plugin OS X build error: error: ‘::strcoll’ has not been declared
Maybe this helps, From the CMake 2.6 docs http://www.cmake.org/cmake/help/ctest2.6docs.html under the find_path section: 6. Search the paths specified by the PATHS option or in the short-hand version of the command. These are typically hard-coded guesses. On Darwin or systems supporting OS X Frameworks, the cmake variable CMAKE_FIND_FRAMEWORK can be set to empty or one of the following: FIRST - Try to find frameworks before standard libraries or headers. This is the default on Darwin. LAST - Try to find frameworks after standard libraries or headers. ONLY - Only try to find frameworks. NEVER. - Never try to find frameworks. Cheers, Hartmut On 24/6/09 8:56 PM, Ulrich Hertlein wrote: Hi Robert, On 23/6/09 6:54 PM, Robert Osfield wrote: Thanks for tracking down the issue... sorry about the stdint.h being the cause... hopefully we'll be able to find a solution that works across the board. On Tue, Jun 23, 2009 at 3:41 PM, Ulrich Hertleinu.hertl...@sandbox.de wrote: ... I've removed ~/Library/Frameworks and /Library/Frameworks from 'FindFFmpeg.cmake' and am re-compiling now. Would FFmpeg ever be a framework? Would it be fine just to roll this into svn/trunk? Unfortunately it didn't solve the problem. Even with those gone 'stdint.h' is still found in /System/Library/Frameworks/Kernel.framework even though '/System/Library' isn't even searched (and was not before). Searching in /System/Library/Frameworks is apparently default behaviour for FIND_PATH(). There are ways to tweak that: include NO_DEFAULT_PATH in FIND_PATH(...) or check frameworks last, after the standard libraries. I chose the latter since it's hopefully less likely to break things for anyone else. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgExport
Awsome, seems I have to get more familiar with Mercurial - hg pull didn't do what I expected (using bzr usually) - a fresh cloned repo and now at least my Box is working. I will test a few more things :) Cheers, Hartmut On 21/5/09 9:32 PM, Cedric Pinson wrote: Hi, The error you describe is something that has been fixed two days ago. Could you try again Cheers Cedric On Thu, 2009-05-21 at 10:11 +1200, Hartmut Seichter wrote: Were getting closer, though I am sure its not the Python version at least not on Ubuntu. Attached the console output (from the Ubuntu machine): seems only Jansen.osg could be exported (there is an .osg file and it loads) - the others had the same issue. Btw. the export took ages (as in ~10 min) - on a Quad 2.4 GHz machine. The .log file for Jansen.osg is filled all other .log are empty. Cheers, Hartmut On 21/5/09 4:58 AM, Cedric Pinson wrote: Hi, It makes sense now, your python version used with blender is too old. I dont know about macos soft, but could you check if you can use an up to date version of python ? Cheers, Cedric On Wed, 2009-05-20 at 18:53 +0200, Rafa Gaitan wrote: Hi Cedric, I'm getting also problems with the osgexport, here is my output [ 0%] /Users/rgaitan/Projects/OSG/osgexport/data/robot/robot.blend guessing 'blender' == '/Users/rgaitan/Applications/blender.app/Contents/MacOS/blender' Compiled with Python version 2.3.5. Checking for installed Python... got it! Traceback (most recent call last): File osgExport.py, line 35, in ? import osg File ./osg/__init__.py, line 1, in ? import osgconf File ./osg/osgconf.py, line 25, in ? import osgobject File ./osg/osgobject.py, line 31 CONCAT= lambda s, j=: j.join(str(v) for v in s) ^ SyntaxError: invalid syntax Error executing Python script from command-line: osgExport.py (at line 31). Blender quit For the rest of the models is the same error. Rafa. On Tue, May 19, 2009 at 12:27 PM, Cedric Pinson cedric.pin...@plopbyte.net wrote: Hi, Humm very strange, ok try this: - hg clone http://hg.plopbyte.net/osgexport/ - cd osgexport - mkdir build - cd build - cmake ../ - make it should say something in the console while exporting Can you report the content of the console output ? It works on my ubuntu 9.04 here Cheers, Cedric On Tue, 2009-05-19 at 10:07 +1200, Hartmut Seichter wrote: Thanks, Cedric - I just checked out latest revision. Same result ... On a fresh Ubuntu 9.04 with blender 2.48.1 - install into ~/.blender/scripts (the readme says ~/.blender - this however does not work at all) - open blender with default layout and template (including the unit box) - File Export OpenSceneGraph (.osg) - Leave everything as default - Press Write button - Name file Test.osg (directory is $HOME) - Press Export AnimTK button - No error message (btw. on Mac OSX I get a message about checking on the console which is futile because no error messages are logged) - Check if Test.osg exists ... no - however Test.log exists with 0byte - I tested to add a simple translation animation - also no avail Disclaimer - I poke more or less in the dark with blender however I would suspect the exporter can handle a single box - or is the exporter only capable to export rigged animations, which would raise the question how this exporter can work in conjuntion with the existing osg exporter. Cheers, Hartmut On 19/5/09 1:14 AM, Cedric Pinson wrote: Hi Harmut, I just updated the osgexport repository with some bug fixes if you use this exporter maybe it could help, else i will need a blender file to debug it. Cheers, Cedric On Mon, 2009-05-18 at 11:36 +0200, Cedric Pinson wrote: Hi Hartmut, Can you give more information about the exporter you are using ? i take care of the version on this page http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation If you have problem with it, could you report the blender file and step that result in a empty osg file, without that i can't really help Cheers, Cedric On Mon, 2009-05-18 at 18:05 +1200, Hartmut Seichter wrote: Hi there, I am having a hard time to get the osgexport doing anything - is there a known-to-work revision? Right now with the latest rev I get the GUI but after Write File an empty Filename.log file - so kind of hard to debug. Cheers, Hartmut ___ 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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing
Re: [osg-users] Blender osgExport
Just to make sure I am not missing something obvious. From a quick play around: baked animations from the physics part are not supported? Is that correct? Cheers, Hartmut On 22/5/09 10:43 AM, Hartmut Seichter wrote: Awsome, seems I have to get more familiar with Mercurial - hg pull didn't do what I expected (using bzr usually) - a fresh cloned repo and now at least my Box is working. I will test a few more things :) Cheers, Hartmut On 21/5/09 9:32 PM, Cedric Pinson wrote: Hi, The error you describe is something that has been fixed two days ago. Could you try again Cheers Cedric On Thu, 2009-05-21 at 10:11 +1200, Hartmut Seichter wrote: Were getting closer, though I am sure its not the Python version at least not on Ubuntu. Attached the console output (from the Ubuntu machine): seems only Jansen.osg could be exported (there is an .osg file and it loads) - the others had the same issue. Btw. the export took ages (as in ~10 min) - on a Quad 2.4 GHz machine. The .log file for Jansen.osg is filled all other .log are empty. Cheers, Hartmut On 21/5/09 4:58 AM, Cedric Pinson wrote: Hi, It makes sense now, your python version used with blender is too old. I dont know about macos soft, but could you check if you can use an up to date version of python ? Cheers, Cedric On Wed, 2009-05-20 at 18:53 +0200, Rafa Gaitan wrote: Hi Cedric, I'm getting also problems with the osgexport, here is my output [ 0%] /Users/rgaitan/Projects/OSG/osgexport/data/robot/robot.blend guessing 'blender' == '/Users/rgaitan/Applications/blender.app/Contents/MacOS/blender' Compiled with Python version 2.3.5. Checking for installed Python... got it! Traceback (most recent call last): File osgExport.py, line 35, in ? import osg File ./osg/__init__.py, line 1, in ? import osgconf File ./osg/osgconf.py, line 25, in ? import osgobject File ./osg/osgobject.py, line 31 CONCAT= lambda s, j=: j.join(str(v) for v in s) ^ SyntaxError: invalid syntax Error executing Python script from command-line: osgExport.py (at line 31). Blender quit For the rest of the models is the same error. Rafa. On Tue, May 19, 2009 at 12:27 PM, Cedric Pinson cedric.pin...@plopbyte.net wrote: Hi, Humm very strange, ok try this: - hg clone http://hg.plopbyte.net/osgexport/ - cd osgexport - mkdir build - cd build - cmake ../ - make it should say something in the console while exporting Can you report the content of the console output ? It works on my ubuntu 9.04 here Cheers, Cedric On Tue, 2009-05-19 at 10:07 +1200, Hartmut Seichter wrote: Thanks, Cedric - I just checked out latest revision. Same result ... On a fresh Ubuntu 9.04 with blender 2.48.1 - install into ~/.blender/scripts (the readme says ~/.blender - this however does not work at all) - open blender with default layout and template (including the unit box) - File Export OpenSceneGraph (.osg) - Leave everything as default - Press Write button - Name file Test.osg (directory is $HOME) - Press Export AnimTK button - No error message (btw. on Mac OSX I get a message about checking on the console which is futile because no error messages are logged) - Check if Test.osg exists ... no - however Test.log exists with 0byte - I tested to add a simple translation animation - also no avail Disclaimer - I poke more or less in the dark with blender however I would suspect the exporter can handle a single box - or is the exporter only capable to export rigged animations, which would raise the question how this exporter can work in conjuntion with the existing osg exporter. Cheers, Hartmut On 19/5/09 1:14 AM, Cedric Pinson wrote: Hi Harmut, I just updated the osgexport repository with some bug fixes if you use this exporter maybe it could help, else i will need a blender file to debug it. Cheers, Cedric On Mon, 2009-05-18 at 11:36 +0200, Cedric Pinson wrote: Hi Hartmut, Can you give more information about the exporter you are using ? i take care of the version on this page http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation If you have problem with it, could you report the blender file and step that result in a empty osg file, without that i can't really help Cheers, Cedric On Mon, 2009-05-18 at 18:05 +1200, Hartmut Seichter wrote: Hi there, I am having a hard time to get the osgexport doing anything - is there a known-to-work revision? Right now with the latest rev I get the GUI but after Write File an empty Filename.log file - so kind of hard to debug. Cheers, Hartmut ___ 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
Re: [osg-users] OSG and osgart problem
Daniele, The files you are loading have local lights in the scene. Thus the light from one will effect the other object - this is the correct behaviour. If you want to change the behavior you need to remove the lights from your scene (or switch the export off in osgExp) and add a light manually into the scene. To not get confused with various transformations you should add the light beneath the projection matrix created by osgART::Calibration This problem was also discussed on the osgART forum Cheers, Hartmut On 20/5/09 8:35 AM, daniele argiolas wrote: Hi, I've a problem with osgart 2.0. In a simple example, with 2 marker and 2 osg object with texture made with osgexp from 3ds max, one object changes lights of other. The first marker added can influence other marker. That's the same also using BuildAR software and adding two object. Do you know anything about it? Thanks, Daniele -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12563#12563 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgExport
Were getting closer, though I am sure its not the Python version at least not on Ubuntu. Attached the console output (from the Ubuntu machine): seems only Jansen.osg could be exported (there is an .osg file and it loads) - the others had the same issue. Btw. the export took ages (as in ~10 min) - on a Quad 2.4 GHz machine. The .log file for Jansen.osg is filled all other .log are empty. Cheers, Hartmut On 21/5/09 4:58 AM, Cedric Pinson wrote: Hi, It makes sense now, your python version used with blender is too old. I dont know about macos soft, but could you check if you can use an up to date version of python ? Cheers, Cedric On Wed, 2009-05-20 at 18:53 +0200, Rafa Gaitan wrote: Hi Cedric, I'm getting also problems with the osgexport, here is my output [ 0%] /Users/rgaitan/Projects/OSG/osgexport/data/robot/robot.blend guessing 'blender' == '/Users/rgaitan/Applications/blender.app/Contents/MacOS/blender' Compiled with Python version 2.3.5. Checking for installed Python... got it! Traceback (most recent call last): File osgExport.py, line 35, in ? import osg File ./osg/__init__.py, line 1, in ? import osgconf File ./osg/osgconf.py, line 25, in ? import osgobject File ./osg/osgobject.py, line 31 CONCAT= lambda s, j=: j.join(str(v) for v in s) ^ SyntaxError: invalid syntax Error executing Python script from command-line: osgExport.py (at line 31). Blender quit For the rest of the models is the same error. Rafa. On Tue, May 19, 2009 at 12:27 PM, Cedric Pinson cedric.pin...@plopbyte.net wrote: Hi, Humm very strange, ok try this: - hg clone http://hg.plopbyte.net/osgexport/ - cd osgexport - mkdir build - cd build - cmake ../ - make it should say something in the console while exporting Can you report the content of the console output ? It works on my ubuntu 9.04 here Cheers, Cedric On Tue, 2009-05-19 at 10:07 +1200, Hartmut Seichter wrote: Thanks, Cedric - I just checked out latest revision. Same result ... On a fresh Ubuntu 9.04 with blender 2.48.1 - install into ~/.blender/scripts (the readme says ~/.blender - this however does not work at all) - open blender with default layout and template (including the unit box) - File Export OpenSceneGraph (.osg) - Leave everything as default - Press Write button - Name file Test.osg (directory is $HOME) - Press Export AnimTK button - No error message (btw. on Mac OSX I get a message about checking on the console which is futile because no error messages are logged) - Check if Test.osg exists ... no - however Test.log exists with 0byte - I tested to add a simple translation animation - also no avail Disclaimer - I poke more or less in the dark with blender however I would suspect the exporter can handle a single box - or is the exporter only capable to export rigged animations, which would raise the question how this exporter can work in conjuntion with the existing osg exporter. Cheers, Hartmut On 19/5/09 1:14 AM, Cedric Pinson wrote: Hi Harmut, I just updated the osgexport repository with some bug fixes if you use this exporter maybe it could help, else i will need a blender file to debug it. Cheers, Cedric On Mon, 2009-05-18 at 11:36 +0200, Cedric Pinson wrote: Hi Hartmut, Can you give more information about the exporter you are using ? i take care of the version on this page http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation If you have problem with it, could you report the blender file and step that result in a empty osg file, without that i can't really help Cheers, Cedric On Mon, 2009-05-18 at 18:05 +1200, Hartmut Seichter wrote: Hi there, I am having a hard time to get the osgexport doing anything - is there a known-to-work revision? Right now with the latest rev I get the GUI but after Write File an empty Filename.log file - so kind of hard to debug. Cheers, Hartmut ___ 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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ 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] Blender osgExport
Hi there, I am having a hard time to get the osgexport doing anything - is there a known-to-work revision? Right now with the latest rev I get the GUI but after Write File an empty Filename.log file - so kind of hard to debug. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Blender osgExport
Thanks, Cedric - I just checked out latest revision. Same result ... On a fresh Ubuntu 9.04 with blender 2.48.1 - install into ~/.blender/scripts (the readme says ~/.blender - this however does not work at all) - open blender with default layout and template (including the unit box) - File Export OpenSceneGraph (.osg) - Leave everything as default - Press Write button - Name file Test.osg (directory is $HOME) - Press Export AnimTK button - No error message (btw. on Mac OSX I get a message about checking on the console which is futile because no error messages are logged) - Check if Test.osg exists ... no - however Test.log exists with 0byte - I tested to add a simple translation animation - also no avail Disclaimer - I poke more or less in the dark with blender however I would suspect the exporter can handle a single box - or is the exporter only capable to export rigged animations, which would raise the question how this exporter can work in conjuntion with the existing osg exporter. Cheers, Hartmut On 19/5/09 1:14 AM, Cedric Pinson wrote: Hi Harmut, I just updated the osgexport repository with some bug fixes if you use this exporter maybe it could help, else i will need a blender file to debug it. Cheers, Cedric On Mon, 2009-05-18 at 11:36 +0200, Cedric Pinson wrote: Hi Hartmut, Can you give more information about the exporter you are using ? i take care of the version on this page http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation If you have problem with it, could you report the blender file and step that result in a empty osg file, without that i can't really help Cheers, Cedric On Mon, 2009-05-18 at 18:05 +1200, Hartmut Seichter wrote: Hi there, I am having a hard time to get the osgexport doing anything - is there a known-to-work revision? Right now with the latest rev I get the GUI but after Write File an empty Filename.log file - so kind of hard to debug. Cheers, Hartmut ___ 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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is everyone doing for GUIs?
On 16/5/09 10:21 PM, Simon Hammett wrote: If you want a proper cross platform gui with all the bells and whistles, the three main choices are probably Qt, WxWidgets or Gtk. Qt is probably the most powerful and fully featured, but you have to use that dam MOC thing and the Qt framework. WxWidgets seems to give quite small programs, but it's not very pretty. Well, in defense of wxWidgets - it is as pretty as the native windowing toolkit (Carbon, Cocoa, GTK+, Win32) and as good as you use what wxWidgets provides (*. I think most known wxWidgets examples and applications are not exactly paramount to demonstrate the disguise of a cross-platform application looking native. It comes down to what your target audience expects (is it an engineering application or end-user app) and how much effort you want to put in having the occasional code path here and there to conform with the target platform. My 2ct, Hartmut *) Point in case VLC - they went from shoehorning non-native widgets into wxWidget to shoehorning non-native widgets into Qt -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Dear all, for the sake of completeness some more of my findings (wrapped in a lengthy rant about Windows development) here. - the osgDB::fopen is only the tip of the iceberg - the whole thing is futile if you need to rely on prebuild 3rdparty binaries as chances are high the patch version of VS 2008 and its runtime does not match with what the 3rdparty binaries were build with (try to have a look at the WinSxS and count the variants of VS90_*) - if you are build your own 3rdparty binaries you need to match exactly the same binding settings otherwise VisualStudio 2008 will actually do mixed bindings - thus the one for the actual binary plus the one from the dependencies. You can nicely look at this behaviour using the 3rdparty package kindly provided on the OSG website plus using the _BIND - build the jpeg plugin and look at the osgdb_jpg.intermediate.manifest created in the binary tree - it will have bindings to two different C runtimes. Intermediate manifests are forcibly linked into your binaries. - Microsoft actually also introduced bind redirection with manifests but for all of our sanity this would go to far to explain here now and after all its sounds also more like a workaround. - In relation to the COLLADA 2.2 or 2.2.1 discussion - after being sensitised on that matter with the other problems I had - I can only say the COLLADA 2.2.1 trunk (and the 2.2 package) is the most eclectic mix of binaries and should not be used with VS 2008. There are VS8, VS9 and VS2003SP1 libraries all nicely bundles together. Zlib being linked against the latter 7.1 compiler thus interfering with the dependecy of the libpng provided in the 3rdparty binary. Crossing fingers to run an executable with this is probably not enough. So I resorted finally to the solution Christian was suggesting earlier - shipping the VisualStudio 2008 SP1 redistributable (adding ~4MByte to an normally 5MByte installer) with my application. Its the only way to get all redirected manifests to point to the one and true VC runtime. Oh, and if you do so don't put the redist manifests and DLLs in the binary directory as they will break everything again. So finally Microsoft managed to let us C++ developer feel like C# or Java developers - don't forget that runtime of yours. Cheers, Hartmut Jean-Sébastien Guay wrote: Hi Robert, Hartmut, The changes seem sound, I'd like to see if there are any side effects though, so I'll test the changes in a fresh build linked to a small application tomorrow. I'll let you know what I find out. Change #1 (refer to the original e-mail from Hartmut) is ok, it's a small function that will now be inlined instead of in the DLL, preventing the fopen call being made in a different DLL context than the fclose call. The penalty for such a small function is small, so I don't see a problem. Perhaps a comment could be added explaining why this function is inline while all others are extern... Change #2 is interesting. Trying to be diligent (since /a priori/ I didn't know anything about these settings), I looked up the defines Hartmut added, and found this: http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx It seems that the behavior for resolving the C++ runtime version dependencies changed between VC2005 and VC2008. The defines Hartmut added just bring VC2008's settings back to VC2005 defaults. So in theory, it should have no effect for VC2005 either since the default was already set that way. I wonder what the implication on user applications will be, considering the information on that page. But I guess if the developer ships the VC runtime DLLs (that he compiled the app with) with his application, or the user has that version or newer of the VC runtime installed, it should be ok. That's what happens for VC2005 after all. It's true that perhaps those defines should be optional (I would make them default to on, as it will probably not change anything for most users but those who will have the same problems as Hartmut had will want to turn it on - people who want to turn it on will be few and will know the reasons why). Perhaps that should be added to the patch before final submission. I've compiled OSG and an application I was working on with these changes, and didn't get any adverse change in behavior. Of course, I'm still using VC2005. Perhaps we could wait for someone else using VC2008 to test as well, but as I said, I think the changes are OK even in that context. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bugfix osgDB cross-DLL allocation problem
Dear all,
hunting around for a while with plain VMware images and rebuilding
everything constantly I drilled down to the cause of the problem which I
reported earlier which turns out to be twofold:
1) osgDB::fopen is opening a file (fopen) in the scope of osgDB dll and
various plugins and also osgWidgets close files via the ANSI-C fclose
(in the scope of the plugin) - this works fine for most OSes just not
Windows and OS X. My fix is to inline the proxied version of fopen
because otherwise osgDB needs to provide the whole set of C file
operation functions.
2) Visual Studio 2008 is defaulting to link to the lowest common
denominator of the runtime which is something like 9.0.22*** - however
all known versions of VS 2008 (with or without SP or FeaturePack) ship
with a redistributable with version 9.0.30*** - thus welcome to SxS
hell. The introduced defines should work on both VS 2008 with and
without SP1 (there was a bug ignoring the catch all version _VC_LIBS_) -
it should have only an effect in VS 2005 and 2008 - maybe there should
be an CMake option() around the defines as I could imagine some people
want this exact behaviour.
Please test and comment (the patch is against the 2.8 branch but should
be easy to port into the trunk)
Cheers,
Hartmut
--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 3078
http://www.hitlabnz.org/people/hse25
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 10140)
+++ CMakeLists.txt (working copy)
@@ -186,6 +186,8 @@
# More MSVC specific compilation flags
ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
+ ADD_DEFINITIONS(-D_BIND_TO_CURRENT_CRT_VERSION=1)
+ ADD_DEFINITIONS(-D_BIND_TO_CURRENT_MFC_VERSION=1)
ENDIF(MSVC)
#needed for net plugin
Index: include/osgDB/FileUtils
===
--- include/osgDB/FileUtils (revision 10140)
+++ include/osgDB/FileUtils (working copy)
@@ -14,6 +14,7 @@
#ifndef OSGDB_FILEUTILS
#define OSGDB_FILEUTILS 1
+#include osg/Config
#include osgDB/Registry
#include vector
@@ -38,8 +39,17 @@
// Overload of the standard fopen function. If OSG_USE_UTF8_FILENAME is
defined,
// filename will be expanded from UTF8 to UTF16 and _wfopen will be called.
-extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
+//extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
+inline FILE* fopen(const char* filename, const char* mode)
+{
+#ifdef OSG_USE_UTF8_FILENAME
+ return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
convertUTF8toUTF16(mode).c_str());
+#else
+ return ::fopen(filename, mode);
+#endif
+}
+
// Make a new directory. Returns true if directory exists or was created.
extern OSGDB_EXPORT bool makeDirectory( const std::string directoryPath );
Index: src/osgDB/FileUtils.cpp
===
--- src/osgDB/FileUtils.cpp (revision 10140)
+++ src/osgDB/FileUtils.cpp (working copy)
@@ -98,15 +98,6 @@
#endif
}
-FILE* osgDB::fopen(const char* filename, const char* mode)
-{
-#ifdef OSG_USE_UTF8_FILENAME
-return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
convertUTF8toUTF16(mode).c_str());
-#else
-return ::fopen(filename, mode);
-#endif
-}
-
bool osgDB::makeDirectory( const std::string path )
{
if (path.empty())
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OT: Visual Studio 2008 and deploying an OSG application
Dear OSGlers, as most of you are aware Visual Studio 2008 Microsoft has introduced a few new shudderbars before one can actually get an application deployed on a non-Visual Studio machine. The problem I have: plain OSG 2.8.1 Release build copied over - I added the manifest+DLLs from my VS 2008 installation (Redist). It seems that everything works except if a plugin is been loaded (OSG_NOTIFY reveals that it tries to load it but fails) - and I already copied the files into the plugins directory as well. Did I miss something? Do I really have to bundle everything with the MSI version of the runtime and do a silent install? I already tried to add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the build but also no avail ... (well again - only for the plugin part) Any hints welcome, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Not OT: Visual Studio 2008 and deploying an OSG application
Ok, somehow this all looks too familiar with a problem I had earlier with the MacOS X build of OSG 2.8.x (http://forum.openscenegraph.org/viewtopic.php?p=10151#10151) ... so the output looks like this with the viewer crashing when it tries to load the osgdb_lwo.dll (replicable with any other plugin) I will set up a few VMware images to hunt this down as it prevents any reasonable deployment method. E:\osgosgviewer.exe \SSTT2\sstt2\BO105.lwo GraphicsContext::setWindowingSystemInterface() 092E17C0 003D9198 CullSettings::readEnvironmentalVariables() DatabasePager::addDatabaseThread() HANDLE_NON_HTTP DatabasePager::addDatabaseThread() HANDLE_ONLY_HTTP CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() DriveManipulator::_height set to ==1.5 CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() itr='E:\osg' FindFileInPath() : trying E:\osg\osgPlugins-2.8.1\osgdb_lwo.dll ... FindFileInPath() : USING E:\osg\osgPlugins-2.8.1\osgdb_lwo.dll Opened DynamicLibrary osgPlugins-2.8.1/osgdb_lwo.dll FindFileInPath(\SSTT2\sstt2\BO105.lwo): returning \SSTT2\sstt2\BO105.lwo E:\osgset OSG_LIBRARY_PATH=E:\osg\osgPlugins-2.8.1 E:\osgosgviewer.exe \SSTT2\sstt2\BO105.lwo GraphicsContext::setWindowingSystemInterface() 092E1810 003D9198 CullSettings::readEnvironmentalVariables() DatabasePager::addDatabaseThread() HANDLE_NON_HTTP DatabasePager::addDatabaseThread() HANDLE_ONLY_HTTP CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() DriveManipulator::_height set to ==1.5 CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() itr='E:\osg\osgPlugins-2.8.1' FindFileInPath() : trying E:\osg\E:\osg\osgPlugins-2.8.1\osgPlugins-2.8.1\osgd b_lwo.dll ... itr='E:\osg' FindFileInPath() : trying E:\osg\osgPlugins-2.8.1\osgdb_lwo.dll ... FindFileInPath() : USING E:\osg\osgPlugins-2.8.1\osgdb_lwo.dll Opened DynamicLibrary osgPlugins-2.8.1/osgdb_lwo.dll FindFileInPath(\SSTT2\sstt2\BO105.lwo): returning \SSTT2\sstt2\BO105.lwo Hartmut Seichter wrote: Dear OSGlers, as most of you are aware Visual Studio 2008 Microsoft has introduced a few new shudderbars before one can actually get an application deployed on a non-Visual Studio machine. The problem I have: plain OSG 2.8.1 Release build copied over - I added the manifest+DLLs from my VS 2008 installation (Redist). It seems that everything works except if a plugin is been loaded (OSG_NOTIFY reveals that it tries to load it but fails) - and I already copied the files into the plugins directory as well. Did I miss something? Do I really have to bundle everything with the MSI version of the runtime and do a silent install? I already tried to add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the build but also no avail ... (well again - only for the plugin part) Any hints welcome, Hartmut ___ 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.8.1 release candidate one tagged
Hi there, on OSX (10.5.x in my case) all builds fine, osgviewer works fine as well. Used CMake + Makefiles One strange behaviour - only installed (as in use make install) executables can resolve the plugins correctly or lets say they use the plugins. If I start for instance osgcubemap from the build path it bails out: Hartmuts-Mac:OpenSceneGraph-Data seichter$ ../OpenSceneGraph/build/bin/osgcubemap GraphicsContext::setWindowingSystemInterface() 0xf0aae00x706058 CullSettings::readEnvironmentalVariables() DatabasePager::addDatabaseThread() HANDLE_NON_HTTP DatabasePager::addDatabaseThread() HANDLE_ONLY_HTTP CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() itr='/usr/local/lib' FindFileInPath() : trying /usr/local/lib/osgPlugins-2.8.1/osgdb_osg.so ... FindFileInPath() : USING /usr/local/lib/osgPlugins-2.8.1/osgdb_osg.so CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() Opened DynamicLibrary osgPlugins-2.8.1/osgdb_osg.so Warning: Could not find plugin to read objects from file cessna.osg. Please specify a model filename on the command line. Additionally OSG_FILE_PATH is set and the command above commenced in the root of the data path. Same can be seen for any all other examples (i.e. osganimate only shows the checker board but not the glider+cessna). If I start from /usr/local/share/OpenSceneGraph/bin everything works as expected. I didn't see this behaviour in 2.6.x Cheers, Hartmut On 11/4/09 9:44 AM, Robert Osfield wrote: Hi All, I have just tagged the OpenSceneGraph-2.8.1-rc1, which is a bug/build fix release of OpenSceneGraph-2.8.0 that remains binary compatible with 2.8.0. I've put up a quick attempt and news item for it: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8.1 You can download the source tarball from the OSG download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads Updates between 2.8.1 and 2.8.0 releases include: * Build fixes under FreeBSD and IBM AIX * Crash fixes in osg::State and osg::Geometry * Bug fixes to : o draw instanced support o Optimizer - MergeGeometryVisitor, RemoveLoadedProxyNodesVisitor and SpatializeGroupsVistor o hdr image loader o handling of opacity maps in 3ds loader o dxf loader o frame buffer object o cursor/event handling in windows o windows threading o memory leak in Collada loader o fixes to display lists/vbo creation that prevent crash under ATI drivers o osgconv --formats under OSX I'd appreciate build and runtime testing, fingers crossed everything will go smoothly and we can then get to the task of updating the binaries. Thanks in advance for your help on testing. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg swig build problem
Mhh, I have hunch that SWIG 1.3.29 is too old to expand $self correctly. For the other errors please file an error report Cheers, Hartmut On 18/2/09 10:02 PM, Mathias Franzius wrote: Dear ng, I try to build osgswig on debian etch with either osg 2.4 or osg 2.6, python 2.5, swig 1.3.29, cmake 2.4-patch 5, and a fresh checkout from the osgswig svn. With both versions of osg cmake finishes happily but make stops with the same errors about invalid conversion from 'const char*' to 'char*' and undeclared '$self's (see below). Can somebody give me a hint how to proceed? Thanks! Mathias [...] Scanning dependencies of target _osg cd /home/franzius/osgswig/osgswig-read-only/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/franzius/osgswig/osgswig-read-only /home/franzius/osgswig/osgswig-read-only/src/python /home/franzius/osgswig/osgswig-read-only/build /home/franzius/osgswig/osgswig-read-only/build/src/python /home/franzius/osgswig/osgswig-read-only/build/src/python/CMakeFiles/_osg.dir/DependInfo.cmake make[2]: Leaving directory `/home/franzius/osgswig/osgswig-read-only/build' make -f src/python/CMakeFiles/_osg.dir/build.make src/python/CMakeFiles/_osg.dir/build make[2]: Entering directory `/home/franzius/osgswig/osgswig-read-only/build' /usr/bin/cmake -E cmake_progress_report /home/franzius/osgswig/osgswig-read-only/build/CMakeFiles 1 [ 11%] Building CXX object src/python/CMakeFiles/_osg.dir/osgPYTHON_wrap.o /usr/bin/c++ -D_osg_EXPORTS -fPIC -I/HRI/External/OpenSceneGraph/2.4/include -I/home/franzius/osgswig/osgswig-read-only/include -I/HRI/External/python/2.5/include/python2.5 -o src/python/CMakeFiles/_osg.dir/osgPYTHON_wrap.o -c /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'int SWIG_Python_ConvertFunctionPtr(PyObject*, void**, swig_type_info*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:2052: error: invalid conversion from 'const char*' to 'char*' /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'osg::ImageStream* osg_Image_asImageStream(osg::Image*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:5255: error: '$self' was not declared in this scope /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'double osg_Viewport_getX(osg::Viewport*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:5256: error: '$self' was not declared in this scope /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'double osg_Viewport_getY(osg::Viewport*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:5257: error: '$self' was not declared in this scope /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'double osg_Viewport_getWidth(osg::Viewport*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:5258: error: '$self' was not declared in this scope /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'double osg_Viewport_getHeight(osg::Viewport*)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:5259: error: '$self' was not declared in this scope /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx: In function 'void SWIG_Python_FixMethods(PyMethodDef*, swig_const_info*, swig_type_info**, swig_type_info**)': /home/franzius/osgswig/osgswig-read-only/build/src/python/osgPYTHON_wrap.cxx:310853: error: invalid conversion from 'const char*' to 'char*' make[2]: *** [src/python/CMakeFiles/_osg.dir/osgPYTHON_wrap.o] Error 1 make[2]: Leaving directory `/home/franzius/osgswig/osgswig-read-only/build' make[1]: *** [src/python/CMakeFiles/_osg.dir/all] Error 2 make[1]: Leaving directory `/home/franzius/osgswig/osgswig-read-only/build' make: *** [all] Error 2 ___ Jetzt 1 Monat kostenlos! WEB.DE FreeDSL - Telefonanschluss + DSL für nur 17,95 EURO/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cmake INCLUDE_DIRECTORIES issues
Robert,
I guess this is the same bug in CMake I reported ages ago - the report
also includes a workaround.
http://www.vtk.org/Bug/bug_view_advanced_page.php?bug_id=7407
Cheers,
Hartmut
On 13/1/09 6:57 AM, Robert Osfield wrote:
Hi Cmake experts,
I'm currently working on the OSG's dicom loader, trying to get it
compiling under OSX. I am trying to compile this plugin against the
DCMTK library that has it's headers installed into
/usr/local/include/dcmtk. The Cmake scripts that search for DCMTK
have located the headers in /usr/local/include and the add the extra
path info to this to locate the specific files required. Everything
should just work smoothly... but... the files aren't being found, and
it what it looks like is that CMake's is trying to be clever by by not
including directories that it thinks are redudent. The relevant entry
in the src/osgPlugins/dicom/CMakeList.txt file is:
MESSAGE(DCMTK_ROOT_INCLUDE_DIR: ${DCMTK_ROOT_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${DCMTK_ROOT_INCLUDE_DIR})
When I run the make and cmake confgures itself for the first time it
correctly reports /usr/local/include for DCMTK_ROOT_INCLUDE_DIR, but
when I run make VERBOSE=1 there is no -I/usr/local/include on the
compile line. The weird thing is that if I change the line to:
INCLUDE_DIRECTORIES(${DCMTK_ROOT_INCLUDE_DIR}/../include)
It fools Cmake into including the -I entry. Now this hack isn't a
viable change to check in but it does point to Cmake trying to be too
clever.
Has anyone come across this themselves? Is there a workaround?
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
[osg-users] ANN: osgSWIG/Py available
Dear OSG Community, first of all a late Happy New Year! The osgSWIG team is happy to announce osgSWIG/Py 0.9.1 for Python 2.6 which corresponds to the OpenSceneGraph 2.6.1 version. There is an installer for Win32/Python 2.6 or if you feel funky you can try to compile osgSWIG/Py straight from the source. Please note that on Windows we can only support you with Python 2.6 - hence build with Visual Studio 2008. And another note, we decided to only support stable releases, like 2.6.x or the upcoming 2.8.x releases as the maintenance of the interface files becomes more problematic. Be assured we are looking into some alternative ways to generate them :) For those users looking for an update of the version including osgART (http://www.osgart.org) - please be patient, we are working on the release of osgART 2.x and would like to keep things in sync - there will be an update but not right now. Please give the installer a spin - let us know of your problems in the issue tracker. Now, head over to http://code.google.com/p/osgswig/ Cheers, Hartmut -- Dr Hartmut Seichter, Post-Doctoral Research Fellow, Human Interface Technology Laboratory New Zealand ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDB::DynamicLibrary dlopen flags?
Hi Robert, not sure if you followed my discussion with Jose-Luis regarding osgLua and the problem of stripped RTTI - actually I figured I was barking up the wrong tree. osgIntrospection wrappers will not work on dlopen based systems with gcc 3.x as the osgDB::DynamicLibrary has hardwired the RTLD_LAZY flag in there. Is there a chance that we can get the possibility to set these flags in order to use the introspection. For the time being I need to implement my own loader. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgLua?
Hi Jose-Luis, be assured I seen these messages before and also did the whole patches/linker flags etc. pp. that were suggested there. Still, the RTTI is stripped - so *nix is not going to work. Admittetly, I updated the osgLua sources in an intree version and added my own copy of Lua 5.1.4 into the buildsys (with the patch). Again, I checked that in the whole chain mentioned libs are being compiled with these flags. Its a pitty that this is been ignored by the Lua developers - I can't see why it is so outragous difficult to add this options. I will try to investigate in more depth - after all this is a very specific use-case. Are you still working on osgLua? I can flick you a few patches that might fix a couple of problems. Cheers, Hartmut Jose Luis Hidalgo wrote: Hi Hartmut, The problem is how lua loads libraries, is an issue that comes from time to time, and never is important enough to be solved: http://lua-users.org/lists/lua-l/2007-10/msg00098.html the answer from Luiz was: http://lua-users.org/lists/lua-l/2007-10/msg00120.html Basically that means you can not use osgLua properly from a vanilla lua interpreter+libraries. I tried myself to ask for it on the list: http://lua-users.org/lists/lua-l/2006-11/msg00174.html But... nothing :( Hope it helps. Jose-Luis. On Mon, Dec 15, 2008 at 9:34 PM, Hartmut Seichter li...@technotecture.com wrote: No, not from Lua (or I guess a lua interpreter) itself - I have a wxWidgets application which loads various plugins and one of them is a based around osgLua - thus, lua_open etc pp should happen in that context. On Windows and Mac this whole mechanism works fine - on Linux the RTTI seems to be the showstopper. I added the Linkerflags mentioned somewhere to the whole chain of dependencies: App Plugin Lua Lib Any other ideas? H Jose Luis Hidalgo wrote: Hi Hartmut, How do you try to load osgLua? from lua itself? Cheers, Jose-Lus. On Sun, Dec 14, 2008 at 10:25 PM, Hartmut Seichter li...@technotecture.com wrote: Hi there, I am trying to combine the power of osgLua and osgSWIG in a new project (no I am not mad :)) ... However, I couldn't get osgLua play nicely on Linux - I did all the patching mentioned but no avail. I am on 64bit Ubuntu ... any idea where things go haywire ... seems that RTTI get still stripped - print(osg.Node) returns some mangled reference to osgObject. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ 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] osgLua?
No, not from Lua (or I guess a lua interpreter) itself - I have a wxWidgets application which loads various plugins and one of them is a based around osgLua - thus, lua_open etc pp should happen in that context. On Windows and Mac this whole mechanism works fine - on Linux the RTTI seems to be the showstopper. I added the Linkerflags mentioned somewhere to the whole chain of dependencies: App Plugin Lua Lib Any other ideas? H Jose Luis Hidalgo wrote: Hi Hartmut, How do you try to load osgLua? from lua itself? Cheers, Jose-Lus. On Sun, Dec 14, 2008 at 10:25 PM, Hartmut Seichter li...@technotecture.com wrote: Hi there, I am trying to combine the power of osgLua and osgSWIG in a new project (no I am not mad :)) ... However, I couldn't get osgLua play nicely on Linux - I did all the patching mentioned but no avail. I am on 64bit Ubuntu ... any idea where things go haywire ... seems that RTTI get still stripped - print(osg.Node) returns some mangled reference to osgObject. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgLua?
Hi there, I am trying to combine the power of osgLua and osgSWIG in a new project (no I am not mad :)) ... However, I couldn't get osgLua play nicely on Linux - I did all the patching mentioned but no avail. I am on 64bit Ubuntu ... any idea where things go haywire ... seems that RTTI get still stripped - print(osg.Node) returns some mangled reference to osgObject. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerWX vs. osgPython 2.2.0
Hi Randolph,
seems that was missed out from wrapping ... I guess we have a 2.6.x
release next week out - please be patient :)
Hartmut
--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 2987 Ext. 3078
http://www.hitlabnz.org/people/hse25
Randolph Fritz wrote:
When I try to run this (new) example with this (old) library under IDLE,
I get the following error in line 67:
AttributeError: 'PySwigObject' object has no attribute 'windowResize'
Followed by a crash
Line 67 is:
self.graphicswindow.getEventQueue().windowResize(0, 0, w, h)
Far as I can tell, this is correct. Did windowResize have a different
name in OSG 2.2.0?
Randolph
Platform Windows-XP-5.1.2600
Architecture ('32bit', 'WindowsPE')
Machine --
Python build ('r252:60911', 'Feb 21 2008 13:11:45')
Python compiler MSC v.1310 32 bit (Intel)
--
osg.osgGetLibraryName OpenSceneGraph Library
osg.osgGetVersion 2.2.0
osg.osgGetSOVersion 25
osg Python library location :
C:\Python25\lib\site-packages\osg-2.2.0-msw\osg.pyc
osg Dynamic linked library location : module '_osg' from
'C:\Python25\lib\site-packages\osg-2.2.0-msw\_osg.pyd'
--
osgDB.osgGetLibraryName OpenSceneGraph DB (Data Base)
Library
osgDB.osgGetVersion 2.2.0
osgDB Python library location:
C:\Python25\lib\site-packages\osg-2.2.0-msw\osgDB.pyc
osgDB Dynamic linked library location: module '_osgDB' from
'C:\Python25\lib\site-packages\osg-2.2.0-msw\_osgDB.pyd'
___
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] osgswig and wxPython
Its hard to guess as you don't provide the whole example - all self.Refresh are commented out and its not clear if you use the wxApp OnIdle message pump for updates. The other example (osgviewerWX.py) in the repository might give you some pointers. H R Fritz wrote: I've the beginnings of a simple light-fixture modeling component in wxPython and I am trying to use osgswig (2.2.0.1 version) as a base. I've started out by copying the file loading example which uses osgUtil.SceneView(). The code successfully loads the geometry of a lighting fixture (considering that this is done with readNodeFile that's not terribly surprising). Unfortunately, thereafter I can't maneuver the view with the mouse. Sometimes, I can't even find the fixture model. I suspect I'm doing something dumb. My code--almost the sample code--is attached--any ideas? (Getting a newer version of osgswig would be nice, but as I've written here, I've run into build problems, and I would rather not spend the time chasing them down.) Randolph #!/usr/bin/env python # import wxWidgets stuff import wx import wx.glcanvas # import OpenSceneGraph wrapper import osg import osgUtil import osgDB class OSGLumView(wx.glcanvas.GLCanvas): def __init__(self,parent,id): wx.glcanvas.GLCanvas.__init__(self,parent,id) sv = self.sceneview = osgUtil.SceneView() self.rootnode = osg.MatrixTransformRef(osg.MatrixTransform()) sv.setSceneData(self.rootnode.get()) x,y = self.GetClientSize() self.oldX = 0 self.oldY = 0 sv.setDefaults() self.Bind(wx.EVT_SIZE, self.OnSize) self.Bind(wx.EVT_PAINT, self.OnPaint) self.Bind(wx.EVT_ERASE_BACKGROUND, self.OnEraseBackground) self.Bind(wx.EVT_ENTER_WINDOW, self.OnEnterWindow) self.Bind(wx.EVT_MOUSE_EVENTS, self.OnMouse) sv.init() def AddGeom(self, geom): print AddGeom self.rootnode.addChild(geom) # self.Refresh(False) def OnMouse(self, evt): if ((evt.Dragging() == True) and (evt.LeftIsDown() == True)): x = evt.GetX() - self.oldY y = evt.GetY() - self.oldY self.sceneview.setViewMatrixAsLookAt( osg.Vec3f(0,y,x), osg.Vec3f(0,0,0), osg.Vec3f(0,1,0)) # self.Refresh(False) self.oldX = evt.GetX() self.oldY = evt.GetY() if ((evt.Dragging() == True) and (evt.RightIsDown() == True)) : m = self.rootnode.getMatrix() x,y = self.GetClientSize() rot = osg.Matrixd() rot.makeRotate(self.oldX - evt.GetX(), osg.Vec3f(1,0,0)) m.postMult(rot) # self.Refresh(False) self.oldX = evt.GetX() self.oldY = evt.GetY() def Clear(self): self.rootnode.removeChild(0,self.rootnode.getNumChildren()) # self.Refresh(False) def OnEnterWindow(self, evt): self.SetFocus() def OnEraseBackground(self, evt): pass def OnSize(self, evt): x,y = self.GetClientSize() self.SetCurrent() self.sceneview.setViewport(0,0,x,y) evt.Skip() def OnPaint(self, evt): if (0 == self.GetContext()) : return dc = wx.PaintDC(self) self.SetCurrent() self.sceneview.update() self.sceneview.cull() self.sceneview.draw() self.SwapBuffers() ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig manifest blues
Just to follow up on that - I will add a wiki page on the osgSWIG google code about this. With Python 2.6 the default compiler on Windows is Visual Studio 2008 Cheers, Hartmut http://docs.python.org/whatsnew/2.6.html#build-and-c-api-changes R Fritz wrote: Oh-ho! Yes, that's it. I think we've got a copy of VS 2003 around; I'll take a look. Randolph On Nov 26, 2008, at 2:00 AM, Hartmut Seichter wrote: Mhh, I was just wondering if you are trying to compile osgSWIG / Python with Visual Studio 2005 against a Python 2.5 version? If so - this is unsupported as Python 2.5 is being compiled with Visual Studio 2003 .NET SP1 - in general it shouldn't be a problem because of Pythons C - API - but I guess when a Python script is pulling in different versions of wrapped C++ DLLs the situation becomes more tricky. I have to investigate more closely the new Python 2.6 but from some initial scanning it seems things changed. To come to the core - a proper install script is not existing yet, only my old InnoSetup files which I adapted each time a package. I will investigate if we can add an install target ... Cheers, H Randolph Fritz wrote: OK, now that I've got the files to build, how do I avoid the R6034 (manifest file) error when I move them into site-packages? There doesn't seem to be a cmake generated install script, that would presumably take care of the problem. Randolph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ 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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig: the bigobj problem rears its head again
I have a student working on this problem - to add the flag is good and fixes the problem temporarily but in general osgSWIG needs a more scalable approach. H Randolph Fritz wrote: I'm writing this up so that people who aren't cmake experts have a note about this workaround. For my next trick, I tried building this on Windows using Visual C++. After some blundering around, I found that adding /bigobj flag to CMAKE_CXX_FLAGS (edit the field in the cmake GUI--it is one of the advanced options) makes the build go, but only on Visual Studio 2005 and later. MS acknowledges the problem and recognizes that machine-generated code may trigger it in the page at http://msdn.microsoft.com/en-us/library/ms173499(VS.80).aspx. Reported at http://code.google.com/p/osgswig/issues/detail?id=13. Randolph Fritz design machine group architecture department university of washington [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig manifest blues
Mhh, I was just wondering if you are trying to compile osgSWIG / Python with Visual Studio 2005 against a Python 2.5 version? If so - this is unsupported as Python 2.5 is being compiled with Visual Studio 2003 .NET SP1 - in general it shouldn't be a problem because of Pythons C - API - but I guess when a Python script is pulling in different versions of wrapped C++ DLLs the situation becomes more tricky. I have to investigate more closely the new Python 2.6 but from some initial scanning it seems things changed. To come to the core - a proper install script is not existing yet, only my old InnoSetup files which I adapted each time a package. I will investigate if we can add an install target ... Cheers, H Randolph Fritz wrote: OK, now that I've got the files to build, how do I avoid the R6034 (manifest file) error when I move them into site-packages? There doesn't seem to be a cmake generated install script, that would presumably take care of the problem. Randolph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig confusion
I am not entirely sure if this is a good idea. osgSWIG should be
compiled against an installed release version of the OSG - on Mac you
also need to take care of proper r-paths as multiple versions of a
library could potentially installed and the OSG is not setting the rpath
in its default install via cmake. I have a installable pkg file for
osgPython on Mac 10.5.x which I could upload - its being used by
AccessGrid already
Anyway, thanks for digging into this problem.
H
R Fritz wrote:
Thanks for responding so quickly. I saw you picked up my patches in
issue 18--thanks. But still no joy on 15. I attached my latest
results to the issue there, but the latest result is no result--I
don't think anything changed.
On a different subject, I've made some small changes to FindOSG.cmake
which make the osgswig build happier with linking to OSG library files
in an Xcode build. I'm not sure of the merits of these, so I'm
putting them out here--what do people who know the Mac environment
better than me think?
Randolph
Index: /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake
===
--- /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake
(revision 177)
+++ /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake
(working copy)
@@ -39,11 +39,14 @@
/usr/local/lib
/usr/lib64
/usr/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
+$ENV{OSGDIR}/lib/Release
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
+$ENV{OSG_ROOT}/lib/Release
$ENV{OSG_ROOT}/lib
/sw/lib
/opt/local/lib
@@ -67,10 +70,13 @@
/usr/local/lib
/usr/lib64
/usr/lib
+$ENV{OSG_DIR}/lib/Debug
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
+$ENV{OSGDIR}/lib/Debug
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
+$ENV{OSG_ROOT}/lib/Debug
$ENV{OSG_ROOT}/lib
/sw/lib
/opt/local/lib
Randolph
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig binary release?
Luigi Calori wrote: Hi Gerwin, I subscribed to SWIG list and read that response too, I' ll try to do some test on that because I really want to be able to run my python app code on more recent OSG I' ll let you know if any success, I' m also applying some mod to make the latest svn compile under msvc 7.1. If you have any suggestion, please let me know. Is someone still working on osgSwig? Yes, still working on it :) - I am actually hiring somebody to work on a new build system Cheers, H Thanks Luigi Gerwin de Haan ha scritto: Luigi, As far as the wrapping of osg::MixinVectors goes to support osg 2.6 and on with osgswig, I did get a response from the swig maintainer William Fulton on how to go about on this: ... The easiest is probably to run SWIG -E on std_vector.i and copy paste and change std to osg and vector to MixinVector. You'll see that there is a lot of code developed for some of these target languages and you could provide a much simpler cut down api, something similar to the Java approach, see Lib/java/std_vector.i. I'm not sure I find a timeslot to do this anytime soon. Gerwin On Fri, Nov 14, 2008 at 12:12 PM, Luigi Calori [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Here http://virtualrome.googlecode.com/svn/trunk/py_code/py25_apps/PyPackages/osg.zip you can find an osgSwig (from some month ago, with some patches) I has been built with Visual Stusio 7.1 against OSG 2.5 (included with the zip) It has been tested with python 2.5 win32 binary, you can test by adding the folder where you extract the zip to the PYTHONPATH env variable I'm trying to build osgSwig svn with OSG 2.6 (Viual Studio compiler)buth there is a still unsolved problem, reported in http://code.google.com/p/osgswig/issues/detail?id=12#c3 due to substitution of std::vector with osg::MixinVectors (this low level change prevents wrapper access to functions for building arrays) I also had to make some changes to build as reported in http://code.google.com/p/osgswig/issues/detail?id=13 If interested, let me know Luigi Phan, Linh H ha scritto: Hi, I'm having a real hard time compiling osgswig (gotten from osgswig svn) for OpenSceneGraph 2.3.4 on Windows using MinGW or cygwin. The README said that it has been tested with OpenSceneGraph 2.3.4. http://2.3.4. Does anyone have a pre-built Windows binary for osgswig that they can make available? I would really appreciate it. Thank you, Linh ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig on OSX (python bindings)
the head of osgSWIG svn only compiles with the OSG 2.6.x H Massimo Di Stefano wrote: Hi finally i'm able to build on osx (10.5.5 xcode-3.1): OSG (svn 2.7) OsGis (svn) and VPB (svn 0.9.1) now i'm tring to have osgswig compiled (to have python bindings) i tried to configure the cmake to : www.geofemengineering.it/osgswig_cmake_settings.txt but the make give me these error : www.geofemengineering.it/osgswig_build_log.txt myabe something is wrong in my python libraries or need i to change something in the cmake setting :-/ please, thanks for any help! Massimo Di Stefano. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig compiled (on intrepid, OSG 2.4.0) but examples segfault
/patrick/dev/osgswig-read-only/build/lib/python/_osgGA.so # /home/patrick/dev/osgswig-read-only/build/lib/python/osgViewer.pyc matches /home/patrick/dev/osgswig-read-only/build/lib/python/osgViewer.py import osgViewer # precompiled from /home/patrick/dev/osgswig-read-only/build/lib/python/osgViewer.pyc dlopen(/home/patrick/dev/osgswig-read-only/build/lib/python/_osgViewer.so, 2); Segmentation fault .. any ideas? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and OpenGL ES?
Hi there, last time I asked nobody answered, so I try my luck again: is there anybody working on an OpenGL ES port? Robert, you hinted in an email earlier somebody works on a port - has there been anything substantial been created? I am just not interested reinventing the wheel ... Cheers, Hartmut -- Dr. Hartmut Seichter PhD (HKU), Dipl.-Ing. (BUW) Post-Doctoral Fellow, HIT Lab NZ +64 3 364 2987 Ext. 3078 http://www.hitlabnz.org/people/hse25 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in osgviewer on Linux
Enabling vsync on all cards/screens worked and it runs ok now. I traced the segfault down to the statshandler code or better say the the things it uses. Problem is that valgrind slows down the machine as much so that the race condition does not get triggered. Maybe I wasn't clear xrandr is not needed but it seems without it OSG_WINDOW and OSG_SCREEN environment variables have no effect - windows end up on the second screen of the first card. Cheers, Hartmut Robert Osfield wrote: Hi Hartmut, I have driven four screens from two cards under linux without problems, but haven't recently tried this. I also didn't use Xrandr, and I'm not sure why you say this is needed as running four screens is possible with just straight configuration of xorg.conf. The stack trace you have suggest the crash is in OpenGL, so it could be a driver bug or perhaps an OSG bug, but at this stage not possible to say which. Try different OpenGL versions. Also please enable vsync. Robert. On Mon, Oct 13, 2008 at 9:58 PM, Hartmut Seichter [EMAIL PROTECTED] wrote: Dear osg'ler Following scenario: Quad Core 2 with three NVIDIA 260 GTX - SLI is installed but not used - four screens (final setup will have six), no Xinerama (this performs even worse). OSG is build with Xrandr support so it works as is with the four screens Ubuntu 8.04.1 + latest patches, NVIDIA driver 177.80 compiled for the respective kernel: x86_64 GNU/Linux 2.6.24-19-generic OpenSceneGraph 2.6.1 (HEAD of branch of 2.6) - for sake of completeness OSG 2.4 release shows the same behaviour when running the cow.osg the application crashes a few frames after pulling up the statshandler ... however, even without the stats the performance is rather poor or lets say jumpy between 900 and 90 fps. Changing the threading modes does help at least the SingleThreaded doesn't crash but is rather slow ~200fps. I am trying to triangulate between OSG, nvidia driver and the Xorg config where things go haywire. Attached the backtrace of the crash. Please let me know if you need more information. Goal for us is actually to merge a three screen vis centre to run off one machine rather than on three with removing the need for network sync etc pp. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ (gdb) back #0 0x7f80a070f095 in raise () from /lib/libc.so.6 #1 0x7f80a0710af0 in abort () from /lib/libc.so.6 #2 0x7f80a0749a7b in ?? () from /lib/libc.so.6 #3 0x7f80a075108a in ?? () from /lib/libc.so.6 #4 0x7f80a0754c1c in free () from /lib/libc.so.6 #5 0x7f809f876d5b in ?? () from /usr/lib/libGLcore.so.1 #6 0x7f809f876fab in ?? () from /usr/lib/libGLcore.so.1 #7 0x7f80a3655feb in osg::Drawable::Extensions::glGetQueryObjectiv () from /usr/local/lib64/libosg.so.48 #8 0x7f80a2553012 in osgViewer::OpenGLQuerySupport::checkQuery () from /usr/local/lib64/libosgViewer.so.48 #9 0x7f80a2554410 in osgViewer::Renderer::draw () from /usr/local/lib64/libosgViewer.so.48 #10 0x7f80a254ff39 in osgViewer::Renderer::operator() () from /usr/local/lib64/libosgViewer.so.48 #11 0x7f80a36b828d in osg::GraphicsContext::runOperations () from /usr/local/lib64/libosg.so.48 #12 0x7f80a36c285d in osg::RunOperations::operator() () from /usr/local/lib64/libosg.so.48 #13 0x7f80a36c2ed0 in osg::GraphicsOperation::operator() () from /usr/local/lib64/libosg.so.48 #14 0x7f80a3707ddd in osg::OperationThread::run () from /usr/local/lib64/libosg.so.48 #15 0x7f80a36c2f58 in osg::GraphicsThread::run () from /usr/local/lib64/libosg.so.48 #16 0x7f80a3a9e956 in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib64/libOpenThreads.so.11 #17 0x7f80a1d9a3f7 in start_thread () from /lib/libpthread.so.0 #18 0x7f80a07b4b3d in clone () from /lib/libc.so.6 #19 0x in ?? () ___ 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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] crash in osgviewer on Linux
Dear osg'ler Following scenario: Quad Core 2 with three NVIDIA 260 GTX - SLI is installed but not used - four screens (final setup will have six), no Xinerama (this performs even worse). OSG is build with Xrandr support so it works as is with the four screens Ubuntu 8.04.1 + latest patches, NVIDIA driver 177.80 compiled for the respective kernel: x86_64 GNU/Linux 2.6.24-19-generic OpenSceneGraph 2.6.1 (HEAD of branch of 2.6) - for sake of completeness OSG 2.4 release shows the same behaviour when running the cow.osg the application crashes a few frames after pulling up the statshandler ... however, even without the stats the performance is rather poor or lets say jumpy between 900 and 90 fps. Changing the threading modes does help at least the SingleThreaded doesn't crash but is rather slow ~200fps. I am trying to triangulate between OSG, nvidia driver and the Xorg config where things go haywire. Attached the backtrace of the crash. Please let me know if you need more information. Goal for us is actually to merge a three screen vis centre to run off one machine rather than on three with removing the need for network sync etc pp. Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ (gdb) back #0 0x7f80a070f095 in raise () from /lib/libc.so.6 #1 0x7f80a0710af0 in abort () from /lib/libc.so.6 #2 0x7f80a0749a7b in ?? () from /lib/libc.so.6 #3 0x7f80a075108a in ?? () from /lib/libc.so.6 #4 0x7f80a0754c1c in free () from /lib/libc.so.6 #5 0x7f809f876d5b in ?? () from /usr/lib/libGLcore.so.1 #6 0x7f809f876fab in ?? () from /usr/lib/libGLcore.so.1 #7 0x7f80a3655feb in osg::Drawable::Extensions::glGetQueryObjectiv () from /usr/local/lib64/libosg.so.48 #8 0x7f80a2553012 in osgViewer::OpenGLQuerySupport::checkQuery () from /usr/local/lib64/libosgViewer.so.48 #9 0x7f80a2554410 in osgViewer::Renderer::draw () from /usr/local/lib64/libosgViewer.so.48 #10 0x7f80a254ff39 in osgViewer::Renderer::operator() () from /usr/local/lib64/libosgViewer.so.48 #11 0x7f80a36b828d in osg::GraphicsContext::runOperations () from /usr/local/lib64/libosg.so.48 #12 0x7f80a36c285d in osg::RunOperations::operator() () from /usr/local/lib64/libosg.so.48 #13 0x7f80a36c2ed0 in osg::GraphicsOperation::operator() () from /usr/local/lib64/libosg.so.48 #14 0x7f80a3707ddd in osg::OperationThread::run () from /usr/local/lib64/libosg.so.48 #15 0x7f80a36c2f58 in osg::GraphicsThread::run () from /usr/local/lib64/libosg.so.48 #16 0x7f80a3a9e956 in OpenThreads::ThreadPrivateActions::StartThread () from /usr/local/lib64/libOpenThreads.so.11 #17 0x7f80a1d9a3f7 in start_thread () from /lib/libpthread.so.0 #18 0x7f80a07b4b3d in clone () from /lib/libc.so.6 #19 0x in ?? () ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac OS X 10.5 crash in osgText
::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) + 1009 18 libosgUtil.44.dylib 0x00538da1 osgUtil::SceneView::draw() + 11623 19 libosgViewer.44.dylib 0x00129f6a osgViewer::Renderer::cull_draw() + 1262 20 libosgViewer.44.dylib 0x00128519 osgViewer::Renderer::operator()(osg::GraphicsContext*) + 35 21 libosg.44.dylib 0x008692f3 osg::GraphicsContext::runOperations() + 235 22 libosg.44.dylib 0x00871e69 osg::RunOperations::operator()(osg::GraphicsContext*) + 17 23 libosg.44.dylib 0x008717d3 osg::GraphicsOperation::operator()(osg::Object*) + 117 24 libosg.44.dylib 0x008b88c0 osg::OperationThread::run() + 510 25 libosg.44.dylib 0x00871746 osg::GraphicsThread::run() + 144 26 libOpenThreads.11.dylib 0x0001619c OpenThreads::ThreadPrivateActions::StartThread(void*) + 182 27 libSystem.B.dylib 0x962296f5 _pthread_start + 321 28 libSystem.B.dylib 0x962295b2 thread_start + 34 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ 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 10.5 crash in osgText
Well, sorry I forgot to mention it certainly works with singlethreaded mode. I could try to reproduce it with a simpler example but I think osgviewer is as lean as it gets. If I don't switch on the HUD in osgviewer the problem does not occur - or lets say I can't reproduce it. We have some other applications which could benefit from multi threading but show exactly the same behaviour when using a HUD i.e osgText. H Robert Osfield wrote: Hi Hartmut, The FreeType plugin usage is guarded to prevent thread problems so while FreeType isn't thread safe, this shouldn't affect OSG-2.6, and almost certainly has no barring on the crash you describe. The crash you looks to be CGL issue, whether this is a threading issue or otherwise I cannot say at this stage. Try chnaging the threading models in osgviewer by pressing 'm', or run the app with the command line option --SingleThreaded etc. Robert. On Thu, Sep 11, 2008 at 12:23 PM, Hartmut Seichter [EMAIL PROTECTED] wrote: I seen some other threads mentioning FreeType not being thread save. This is OSG 2.6 branch This is replicable with plain osgviewer on OSX on a MBP 2.4 To replicate: export OSG_WINDOW='20 20 800 600' open osgviewer cow.osg press 's' to show the stats with '' and '' go up and down the window resolutions ... it crashes always at the same point ... see below Is there any solution? If so will it be backported to 2.6? Cheers, Hartmut Process: osgviewer [1487] Path:/usr/local/bin/osgviewer Identifier: osgviewer Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [183] Date/Time: 2008-09-11 20:53:13.980 +1200 OS Version: Mac OS X 10.5.4 (9E17) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x19274010 Crashed Thread: 2 Thread 0: 0 libSystem.B.dylib 0x961f84a6 mach_msg_trap + 10 1 libSystem.B.dylib 0x961ffc9c mach_msg + 72 2 com.apple.CoreGraphics0x94deab4d _CGSRemoveSurface + 133 3 com.apple.agl 0x94d1dc56 aglSetDrawable + 448 4 libosgViewer.44.dylib 0x0017a460 osgViewer::GraphicsWindowCarbon::setWindowDecorationImplementation(bool) + 426 5 libosgViewer.44.dylib 0x00176ed0 osgViewer::GraphicsWindow::setWindowDecoration(bool) + 38 6 libosgViewer.44.dylib 0x00174959 osgViewer::WindowSizeHandler::changeWindowedResolution(osgViewer::GraphicsWindow*, bool) + 1039 7 libosgViewer.44.dylib 0x0017500c osgViewer::WindowSizeHandler::handle(osgGA::GUIEventAdapter const, osgGA::GUIActionAdapter) + 670 8 libosgViewer.44.dylib 0x00126752 osgGA::GUIEventHandler::handle(osgGA::GUIEventAdapter const, osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 38 9 libosgViewer.44.dylib 0x001192d4 osgGA::GUIEventHandler::handleWithCheckAgainstIgnoreHandledEventsMask(osgGA::GUIEventAdapter const, osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 120 10 libosgViewer.44.dylib 0x0016a27c osgViewer::Viewer::eventTraversal() + 4620 11 libosgViewer.44.dylib 0x0016eb21 osgViewer::ViewerBase::frame(double) + 159 12 libosgViewer.44.dylib 0x0016ea65 osgViewer::ViewerBase::run() + 239 13 libosgViewer.44.dylib 0x00161080 osgViewer::Viewer::run() + 182 14 osgviewer 0x865b main + 6241 15 osgviewer 0x6dce start + 54 Thread 1: 0 libSystem.B.dylib 0x961ff68e __semwait_signal + 10 1 libSystem.B.dylib 0x9622a36d pthread_cond_wait$UNIX2003 + 73 2 libGLProgrammability.dylib0x93b92432 glvmDoWork + 162 3 libSystem.B.dylib 0x962296f5 _pthread_start + 321 4 libSystem.B.dylib 0x962295b2 thread_start + 34 Thread 2 Crashed: 0 ??? 0x121ef200 0 + 304017920 1 GLEngine 0x00ed531a gleDrawArraysOrElements_ExecCore + 266 2 GLEngine 0x00ed6278 gleDrawArraysOrElements_IMM_Exec + 1080 3 libGL.dylib 0x96ddd7f1 glDrawArrays + 113 4 libosgText.44.dylib 0x002b4d55 osgText::Text::drawForegroundText(osg::State, osgText::Text::GlyphQuads const, osg::Vec4f const) const + 527 5 libosgText.44.dylib 0x002b5ac0 osgText::Text::renderOnlyForegroundText(osg::State, osg::Vec4f const) const + 118 6 libosgText.44.dylib 0x002b61bb osgText::Text::drawImplementation(osg::State, osg::Vec4f const) const + 1117 7 libosgText.44.dylib 0x002b68f1 osgText::Text::drawImplementation(osg::RenderInfo) const + 107 8 libosgViewer.44.dylib 0x00140e72 osgViewer::TextDrawCallback::drawImplementation(osg::RenderInfo, osg::Drawable const*) const + 548 9 libosgUtil.44.dylib 0x0052082e osg::Drawable::draw(osg::RenderInfo) const + 412 10
[osg-users] Development pathway
Hi there, now there is a new development line coming up I wanted to throw in some thoughts which would be interesting to know for further development of OSG (way beyond 2.7.x) and some of the infrastructure. As you might know I am working on osgSWIG and osgART and a handful other software projects which are used on client systems - so deployment and stability is one of my main concerns. - documentation, there are numerous additions recently and in the past like osgWidgets or osgManipulators which are very interesting but not as interesting to reverse document the code - at least a real API documentation would be sufficient - examples: I am also partly teaching computer graphics and an augmented reality class which heavily rely on OSG. One of the problems I see the students facing is that some of the examples are actually applications and seem to have started simple and went off to show the most convoluted brain-jogging way to achieve something simple - van der Rohe: Less is More On the deployment and integration side: - API additions which change ABI are not documented well: with osgSWIG I am basically poking in the dark, waiting for SWIG to cough up the changes - do I assume right/wrong that API change involves an increment in SOVERSION, it would make backwards compatibility easy And now the more deep down things, which I think would be interesting to look at in a long term plan: - with the Mac OS X 10.4 - 10.5 disaster it should be clear that one can't assume a certain implementation of OpenGL available and relying on it on the front-end - this leads unevitably to OpenGL 3.x and OpenGL ES 2.0 (what happened to the investigation of this?) on the horizon - which hints for hidden backends as with ES there is no certainty of the actual implementation of parts of the API - so you might need to roll your own depending on the hardware detected - bundling math includes in one header to be able to exchange some implementation (ie. floating point emulation) Sorry for the lengthy email. Objective is to get some discussion in the OSG community - so please throw in you 2ct :) Cheers, Hartmut -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test 2.6 branch
Tested with MinGW package bundled with Code::Blocks 8.02 - applications work as expected. However, see attachment for some of the warnings emitted by mingw32-gcc (3.4.5) ... H cid:part1.02030207.01040400@technotecture.com Paul Martz wrote: Hi all -- We've had some build testing of the 2.6 branch on Windows and a Linux box. Since it contains some mingw-specific changes, I'd especially like to see it tested there, as well as build and execution testing on all platforms. http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.6 Please note the URL above is _not_ the SVN head; you'll need to 'svn switch' to the branch or check out a separate tree. (You're right, this is not how OSG releases usually work.) Thanks for helping with this release. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ C:\Development\SDKs\OpenSceneGraph\src\osgDB\FileUtils.cpp|30|warning: F_OK redefined| C:\PROGRA~1\CODEBL~1\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\io.h|196|warning: this is the location of the previous definition| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp||In member function `virtual bool osgViewer::Win32WindowingSystem::setScreenRefreshRate(const osg::GraphicsContext::ScreenIdentifier, double)':| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp|886|warning: converting to `DWORD' from `double'| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp||In member function `virtual void osgViewer::GraphicsWindowWin32::checkEvents()':| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp|1729|warning: passing NULL used for non-pointer converting 3 of `BOOL PeekMessageA(tagMSG*, HWND__*, UINT, UINT, UINT)'| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp|1729|warning: passing NULL used for non-pointer converting 4 of `BOOL PeekMessageA(tagMSG*, HWND__*, UINT, UINT, UINT)'| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp||In member function `virtual void osgViewer::GraphicsWindowWin32::requestWarpPointer(float, float)':| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp|1803|warning: converting to `LONG' from `float'| C:\Development\SDKs\OpenSceneGraph\src\osgViewer\GraphicsWindowWin32.cpp|1804|warning: converting to `LONG' from `float'| C:\Development\SDKs\OpenSceneGraph\src\osgWidget\Window.cpp||In member function `void osgWidget::Window::_removeFromGeode(osgWidget::Widget*)':| C:\Development\SDKs\OpenSceneGraph\src\osgWidget\Window.cpp|413|warning: converting of negative value `-0x1' to `unsigned int'| C:\Development\SDKs\OpenSceneGraph\src\osgWidget\WindowManager.cpp||In member function `virtual void osgWidget::WindowManager::childRemoved(unsigned int, unsigned int)':| C:\Development\SDKs\OpenSceneGraph\src\osgWidget\WindowManager.cpp|275|warning: converting of negative value `-0x1' to `unsigned int'| C:\Development\SDKs\OpenSceneGraph\src\osgPlugins\cfg\CameraConfig.cpp|23|warning: F_OK redefined| C:\PROGRA~1\CODEBL~1\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\include\io.h|196|warning: this is the location of the previous definition| C:\Development\SDKs\OpenSceneGraph\src\osgPlugins\OpenFlight\expPrimaryRecords.cpp||In member function `void flt::FltExportVisitor::writeLightPoint(const osgSim::LightPointNode*)':| C:\Development\SDKs\OpenSceneGraph\src\osgPlugins\OpenFlight\expPrimaryRecords.cpp|710|warning: passing negative value `-0x1' for converting 1 of `void flt::DataOutputStream::writeUInt32(flt::uint32)'| ||=== Build finished: 0 errors, 12 warnings ===| ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Image::update?
Robert Osfield wrote: Hi Hartmut, On Sat, Jul 26, 2008 at 2:02 AM, Hartmut Seichter [EMAIL PROTECTED] wrote: Well, osgART has a number of PlugIns implementing their own osgART::VideoImageStream which implements update slightly different. But I am happy to quickly change things over as we are targeting the latest OSG For 2.6 all original ImageStream implementation - the ones in the Quicktime and Xine plugins are all exactly the same as before, and function in exactly the same way. osgArt::VideoImageStream should be no different - all existing mechanisms will work. The new Image::update(..) method is only called if you attach an update callback to the texture, this is something that is now done automatically for osg::ImageSequence images being assigned to textures, but not for any other Image types. You could add this is you so wished. That was exactly what we did with osgART ... we attached a osgART::ImageUpdateCallback in order to trigger the update. I think I will dive more into ImageStream and ImageSequence to see if we can get rid of our (osgART) additional implementation. Are there any plans to differentiate between open() and play() ... this was the main reason for us to have osgART::VideoImageStream as we need to know in osgART which dimensions and colorspace the imagestream supports I haven't made any other plans for ImageStream. ImageSequence is just a subclass of it at present. The osgDB::ImagePager is a companion to it, which could expand in its role - for instance it could potentially drive the various ImageStream classes, so rather than have their own threads, they'd use the ImagePager's ImageThreads to drive them. This would help when handling many video streams at one time, and also improve the handling of thread cancellation on exit. Yes, that is one area where we have some additional logic in VideoStream to deal with threading issues like locking, or double buffering. As I said before I need to take a deeper look ImageSequence and the ImagePager which might solve a lot of problems for us already. Cheers, Hartmut Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Image::update?
Robert Osfield wrote: Hi Hartmut, On Thu, Jul 24, 2008 at 3:10 AM, Hartmut Seichter [EMAIL PROTECTED] wrote: I just realized the introduction of osg::Image::update(osg::NodeVisitor*) which is awsome (kindof - for now it just breaks the whole thing), What do mean just breaks the whole thing? Could you be very specific. It shouldn't change anything for conventional Texture/Image usage. Well, osgART has a number of PlugIns implementing their own osgART::VideoImageStream which implements update slightly different. But I am happy to quickly change things over as we are targeting the latest OSG especially for osgART (http://osgart.org) ... I was wondering what your plans are with the implementation as the osgimagesequence is probably a work in progress osgimagesequence is currently work in progress, it should be wrapped up today though. I have non paged and paged ImageSequence functionality working, it just API refinement and better control of looping. Robert. Are there any plans to differentiate between open() and play() ... this was the main reason for us to have osgART::VideoImageStream as we need to know in osgART which dimensions and colorspace the imagestream supports Cheers, H ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Image::update?
Hi there, I just realized the introduction of osg::Image::update(osg::NodeVisitor*) which is awsome (kindof - for now it just breaks the whole thing), especially for osgART (http://osgart.org) ... I was wondering what your plans are with the implementation as the osgimagesequence is probably a work in progress H -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Building OSG 2.5.4 on MacOS X w/ CMake
Hi there, maybe I have missed some discussions about this ... - CMake builds seem not to build as frameworks and bundles, is this intentional or is there a CMake option? - Building on 10.5 for a 10.4 target fails due to the offending line seen in the patch. The 10.4u SDK comes with a sys/stat.h why not use it? I suppose pure Darwin builds can use __DARWIN__ ? It probably depends on how far back you want to support. Other than above problems it seems to work quite well. Cheers, Hartmut Index: src/osgDB/FileUtils.cpp === --- src/osgDB/FileUtils.cpp (revision 8575) +++ src/osgDB/FileUtils.cpp (working copy) @@ -35,7 +35,8 @@ #if defined( __APPLE__ ) // I'm not sure how we would handle this in raw Darwin // without the AvailablilityMacros. -#include AvailabilityMacros.h +//#include AvailabilityMacros.h + #include sys/stat.h // 10.5 defines stat64 so we can't use this #define // By default, MAC_OS_X_VERSION_MAX_ALLOWED is set to the latest // system the headers know about. So I will use this as the control ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osgswig
Hi Luigi, thanks for the patch, I will skim through it ASAP. I was just catching up with all my local osgSWIG patches - I will add a cleaner wxWidgets example (the one in the example/python folder was outdated) - based on osgViewer rather than osgUtil::SceneView. I got everything working on Windows XP, Linux (Ubuntu 8.04 x86_64) and Leopard. Can you submit specific problems you have to the osgSWIG issue tracker? Cheers, Hartmut Luigi Calori wrote: Hi Harmut, I did not know you were still working on osgswig, If it can help, I attach some mods we have done to develop some code based on osgswig We have tried to add wrapping to write node visitor derived python I include all our mods, (we have also mod cmake to covert .dll to pyd) It is tested under win XP with osg 2.5 We have also tried it under Linux and it compiles correctly but has some runtime problems We have also integrated osg window with wxpython, it is working under windows but bad performance under linux I attach a patch built with tortoise patch Hope it helps Luigi Hartmut Seichter wrote: Nope we are around and kicking. Unfortunately nothing to show yet: I am working on getting most of the nested classes integrated. Hartmut Gerrick Bivins wrote: Hi all, Does anyone know if osgswig is being maintained anymore? Site on google code doesn’t seem like it’s being updated anymore. Has the project moved or is it just dead? biv ___ 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] Osgswig
Gerrick Bivins wrote:
Any plans for building java binding with Cmake?
Well, in the early days when osgSWIG was osgWrapper/Bindings I had a
Java version running. Being just a far observer of Java I am too
unfamiliar of the Java way of packaging. But in principle the build
should be working.
H
On 6/27/08 8:27 AM, Luigi Calori [EMAIL PROTECTED] wrote:
Hi Harmut, I did not know you were still working on osgswig, If it can
help, I attach some mods we have done to develop some code based on osgswig
We have tried to add wrapping to write node visitor derived python
I include all our mods, (we have also mod cmake to covert .dll to pyd)
It is tested under win XP with osg 2.5
We have also tried it under Linux and it compiles correctly but has some
runtime problems
We have also integrated osg window with wxpython, it is working under
windows but bad performance under linux
I attach a patch built with tortoise patch
Hope it helps
Luigi
Hartmut Seichter wrote:
Nope we are around and kicking. Unfortunately nothing to show yet: I
am working on getting most of the nested classes integrated.
Hartmut
Gerrick Bivins wrote:
Hi all,
Does anyone know if osgswig is being maintained anymore? Site on
google code doesn¹t seem like it¹s being updated anymore.
Has the project moved or is it just dead?
biv
___
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
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 117)
+++ CMakeLists.txt (working copy)
@@ -171,3 +171,11 @@
IMMEDIATE @ONLY)
ADD_CUSTOM_TARGET(uninstall
${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
+
+##to get all the variables of Cmake
+GET_CMAKE_PROPERTY(MYVARS VARIABLES)
+FOREACH(myvar ${MYVARS})
+ FILE(APPEND ${CMAKE_CURRENT_BINARY_DIR}/AllVariables.txt
+ ${myvar} --${${myvar}}-\n
+ )
+ENDFOREACH(myvar)
\ No newline at end of file
Index: CMakeModules/FindOSG.cmake
===
--- CMakeModules/FindOSG.cmake (revision 117)
+++ CMakeModules/FindOSG.cmake (working copy)
@@ -1,16 +1,17 @@
# Locate gdal
# This module defines
# OSG_LIBRARY
-# OSG_FOUND, if false, do not try to link to osg
+# OSG_FOUND, if false, do not try to link to gdal
# OSG_INCLUDE_DIR, where to find the headers
#
# $OSG_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OSG_DIR
#
# Created by Robert Osfield.
-# Edited By R.C.Molenaar to include debug versions
+SET(OSG_DIR CACHE PATH set to base osg install path)
FIND_PATH(OSG_INCLUDE_DIR osg/Node
+${OSG_DIR}/include
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
$ENV{OSGDIR}/include
@@ -24,38 +25,40 @@
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
-/cygdrive/c/Program Files/OpenSceneGraph/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include
)
-
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
-FIND_LIBRARY(${MYLIBRARY}
-NAMES ${MYLIBRARYNAME}
+FIND_LIBRARY(${MYLIBRARY}_DEBUG
+NAMES ${MYLIBRARYNAME}d
PATHS
+${OSG_DIR}/lib/Debug
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/debug
$ENV{OSG_DIR}/lib
-$ENV{OSG_DIR}/bin
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/bin
-/cygdrive/c/Projects/OpenSceneGraph/Build/lib/release
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/lib
/usr/freeware/lib64
)
-FIND_LIBRARY(${MYLIBRARY}_DEBUG
-NAMES ${MYLIBRARYNAME}d
+FIND_LIBRARY(${MYLIBRARY}
+NAMES ${MYLIBRARYNAME}
PATHS
+${OSG_DIR}/lib/Release
+${OSG_DIR}/lib
+$ENV{OSG_DIR}/lib/Release
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
@@ -63,46 +66,84 @@
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
/Library/Frameworks
+/usr/local/lib
+/usr/lib
/sw/lib
/opt/local/lib
/opt/csw/lib
/opt/lib
-/cygdrive/c/Program\ Files/OpenSceneGraph/lib
Re: [osg-users] Osgswig
use some help with the Java and Ruby side of things. On Thu, Jul 3, 2008 at 10:33 AM, Hartmut Seichter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Gerrick Bivins wrote: Any plans for building java binding with Cmake? Well, in the early days when osgSWIG was osgWrapper/Bindings I had a Java version running. Being just a far observer of Java I am too unfamiliar of the Java way of packaging. But in principle the build should be working. H On 6/27/08 8:27 AM, Luigi Calori [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Harmut, I did not know you were still working on osgswig, If it can help, I attach some mods we have done to develop some code based on osgswig We have tried to add wrapping to write node visitor derived python I include all our mods, (we have also mod cmake to covert .dll to pyd) It is tested under win XP with osg 2.5 We have also tried it under Linux and it compiles correctly but has some runtime problems We have also integrated osg window with wxpython, it is working under windows but bad performance under linux I attach a patch built with tortoise patch ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] how osg quicktime plugin handle quicktime message?
Hi there, Julian Looser (see earlier message Internet Streaming with Quicktime Plugin) has a solution for this but until now nobody seems to have answered him in regard to implementation details to let him finish a patch for osg-submission. Short answer, yes it is possible (with the exisiting plugin) but it needs various hacks and tweaks in the core and the pluginloader mechanics. H hui wrote: Hi, I am working on quicktime real time streaming and hope can make it work as the osg plugin. But I cannot find any part that osg qt plugin handle quicktime message. For network streaming, I think quicktime need to contact with windows system to get message. Is that right? Thanks in advance Hui ___ 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] Osgswig
Nope we are around and kicking. Unfortunately nothing to show yet: I am working on getting most of the nested classes integrated. Hartmut Gerrick Bivins wrote: Hi all, Does anyone know if osgswig is being maintained anymore? Site on google code doesn’t seem like it’s being updated anymore. Has the project moved or is it just dead? biv ___ 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] OSG on OpenGL ES Progress?
Hi, Has there been any progress on the OpenGL ES front? I am referring to http://www.openscenegraph.org/projects/osg/wiki/Community/OpenGL-ES H -- Dr. Hartmut Seichter PhD (HKU), Dipl.-Ing. (BUW) Post-Doctoral Fellow, HIT Lab NZ +64 3 364 2987 Ext. 3078 http://www.hitlabnz.org/people/hse25 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgPython (SWIG) 2.2.0
Hi René, I added you to the project. Feel free to add the CMake files etc. pp. As somebody down in the thread suggested I might change the layout to the traditional trunk/branches/tags layout Cheers, Hartmut René Molenaar wrote: I just separated an osgswig cmake project from our larger Library. Tomorrow I can try to build some of your version of the wrappers in this structure. (our version has changed a version of yours here and there). You can add me to the Project members of the google code page? I saw another member on there, I worked with him to create our current version. He makes great use of osgPython in combination with IPython gtk and the rest of our Library. Cheers, René 2008/2/12, Hartmut Seichter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. (http://www.artoolworks.com/) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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] ANN: osgPython (SWIG) 2.2.0
Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. (http://www.artoolworks.com/) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
Hi Cedric, I am the developer of osgSWIG. You can find scripts in src/Languages/Python 1) run wrap.sh 2) run compile.sh I know this is very much suboptimal and might not even work on your distribution. I am working on a CMake based build system which probably solves quite a lot of problems. There is also one big issue I am facing with one of the headers in core OSG. You might stumble upon the same thing, there are three const variables in osg::Vec3f which use the C++ style of declaration and are not supported by SWIG 1.3.30 /H Cedric Pinson wrote: I have found http://code.google.com/p/osgswig/ to bind osg to python, i did not try yet. I would like to know if someone use it on linux. I would like feedback Cedric -- Hartmut Seichter PhD (HKU), Dipl.-Ing. (BUW) www.technotecture.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg python binding
This looks simple enough :) Can I incorporate this into the trunk? I would probably use osg/io_utils for the __str__ wrappers. If you tried the newest trunk and SWIG you certainly stumbled across the osg::Vec3f stuff ... do you have a solution for that? /H megamiller zoid wrote: Dear osgPython users, About the problem with vectors, There is a file in our library, called osgPyExtend, which creates python access to vectors and mat. I have attached it. add %include osgPyExtend.i to osg.i I have more additions, but this one should be an easy to add. _ Jouw nieuws en entertainment, vind je op MSN.nl! http://nl.msn.com/ ___ 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] ode nodekit or the like
Hi Mattias, there are apparently several projects, however very few take care of the newest developments in ODE. We have some code sitting around in our lab called (you guessed it) osgODE. It is particular focused on working together with osgART but also works with plain OSG. I have to pull some strings here in the lab to check if we can release it into the wild. However, a word of caution: after implementing the ODE part we were quite disappointed by the performance of it in terms of dynamic transformations as they happen in Augmented Reality applications. We did some proof-of-concept prototypes with other engines which both performed way better. /Hartmut -- Dr. Hartmut Seichter PhD (HKU), Dipl.-Ing. (BUW) Post-Doctoral Fellow, HIT Lab NZ +64 3 364 2987 Ext. 3143 http://www.hitlabnz.org/people/hse25 Mattias Helsing wrote: I have i vague memory of people working on integrating ode with osg. I'm currently developing sw in that area and could possibly contribute is some way, but wouldn't wanna step on toes or do work that is already done for that matter. LeandroMottaBarros' demo is nice and there are other examples of ode+osg projects. I was thinking that while doing integration of ode in osg nodes i might aswell make the extra effort and create a nodekit or plugin. Am I making any sense at all (OSG wise)? Does anyone have thoughts on how this should be done? Is there sw around that I can build on? Mattias ___ 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] probs running OSG on non-dev system?
The redistributable package should reside: %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86 for x86 ... more details here: http://blogs.msdn.com/astebner/archive/2007/01/24/updated-vc-8-0-runtime-redistributable-packages-are-included-in-visual-studio-2005-sp1.aspx Cheers, Hartmut Mike Weiblen wrote: Pardon the sparse details, had a problem in wee hours this morn... Built a 2.1.10-ish OSG on one system w/ winxppro/vs8, tried to run the resulting osgviewer on a different system w/ winxphome but no VS8 installed. I got entirely unhelpful errormsgs/dialogs along the lines of that application cant be run or trying reinstalling the app. The VS8 runtime libs were present on the non-VS8 system Does this ring any bells? Could the VS8 or Cmake ocnfigs be triggering some OS or binary dependency? Thanks -- mew Mike Weiblen -- Zebra Imaging -- Austin Texas USA -- http://www.zebraimaging.com/ ___ 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] CMake build target INSTALL
Hi there, two things as of SVN rev 7366 using the INSTALL target in combination with Visual Studio 2003: - osgdb_freetype is not being copied (anyway the plugins folder is not as crowded, I have a hunch that more is missing) - applications like osgversion etc are not copied I did clean cache etc with cmake (using version 2.4.7) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
