Re: [osg-users] altitude terrain shading...
HI Gerwin, I've done a little bit of point cloud vis, using small scale laser scanner data rather large scale terrain. One technique I never tried, but did think about, was rendering the pointer cloud to a texture to generate a height texture, which is then used as a source for a vertex program that deforms a regular mesh to the alloted positions. The rendering to the height texture you'd need to splat the point with a an weight decreasing weight as you go out form the center of the point. Robert. On Sun, Jan 18, 2009 at 10:33 AM, Gerwin de Haan gerwindeh...@gmail.com wrote: Hi Gordon, We have many different point-cloud datasets from both terrestial and aerial LiDAR scans, most of them in the range of ~20M points (some with intensity values and/or with rgb values), but some sets total over 2B points divided in tiles. I now build either a quad- or oct tree datastructure with LODs that take a subset from each tile. The results are promising and really have a different feel than 2.5D terrains. I was surprised even a lot of people in the remote-sensing field have never explored full 3D point clouds interactively (thanks OSG!). We're still in a prototyping stage though (python and osgswig help :-), and I am now experimenting with balancing point rendering size, LOD levels and subsampling from pointsets in order to get just enough points on-screen for a solid visual impression with a high frame rate. Real framerates are difficult to give at this point, as they are now really card and view dependent. Currently, a scan of the whole of the Netherlands is in progress with a minimum sampling of 10 xyz points per square meter (a 5 year project). I am using a small subset of this now for experiments, but hope to be able to provide smooth interactive exploration for the whole of this scan. If you like we can discuss more detailed aspects off the list. What is your application / data for? Gerwin On Sat, Jan 17, 2009 at 4:33 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: HI Gerwin Interesting screen shot Being noisy now ;-) what sort of numbers in points are you using/getting with you point clouds We are doing similar work it seems Gordon ___ 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] map/set iterator not dereferencable
Sorry for the new thread.My mistake. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AnimationPathManipulator MFC Time control
Hi osg-users, I'm developping an application under MFC and I started from the MFC sample to begin with but with a little difference in thread management. My rendering thread isn't create with _beginthread but with CreateThread wich launch a CWinThread derived class with a message pump, I want it to be a UI thread and not a worker thread. So I don't know if I'm clear but my problem is that when I play a path and I press 'p' key to pause, the camera isn't at the correct position. In fact I decided to derive osgGA::AnimationPathManipulator class and to replace all ea.getTime() by fTimeSec ( double fTimeSec = osg::Timer::instance()-time_s();) in function handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter us); With this method it works perfectly, so I assume that when creating a rendering thread responsible to call viewer::frame() with CreateThread the ea.getTime() isn't the correct time... Can someone explain me why we use ea.getTime() and not osg::Timer::instance()-time_s() ? -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] map/set iterator not dereferencable
Malcom Poiter wrote: Well I'm still stuck here. My goal is to display the camera coordinates on screen using A HUD. I Start with osgHUD example. everything went fine , the error occur when I'm changing the text, after several frame it just crash. I tried updating the osgText in the DrawableUpdateCallback, tried in the --- while (!viewer.done()) loop, and yet the same error. Did you set DYNAMIC datavariance on the text drawable you're changing? See e.g. the thread with subject osgText crash, dated 8 oct 2008, for what might be going on here... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] AnimationPathManipulator MFC Time control
Hi Alexandre, I haven't dug in deeply in your problem, but I guess it stems from the following remark from the CreateThread() documentation: A thread that uses functions from the C run-time libraries should use the beginthread and endthread C run-time functions for thread management rather than CreateThread and ExitThread. Failure to do so results in small memory leaks when ExitThread is called. This in fact means you cannot reliably use any function in your thread which might call a c run time lib function. Try to rewrite your thread initialization to use _beginthread instead. regards Ralph Alexandre Amalric schrieb: Hi osg-users, I'm developping an application under MFC and I started from the MFC sample to begin with but with a little difference in thread management. My rendering thread isn't create with _beginthread but with CreateThread wich launch a CWinThread derived class with a message pump, I want it to be a UI thread and not a worker thread. So I don't know if I'm clear but my problem is that when I play a path and I press 'p' key to pause, the camera isn't at the correct position. In fact I decided to derive osgGA::AnimationPathManipulator class and to replace all ea.getTime() by fTimeSec ( double fTimeSec = osg::Timer::instance()-time_s();) in function handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter us); With this method it works perfectly, so I assume that when creating a rendering thread responsible to call viewer::frame() with CreateThread the ea.getTime() isn't the correct time... Can someone explain me why we use ea.getTime() and not osg::Timer::instance()-time_s() ? -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] map/set iterator not dereferencable
Yep I think it solved the problemMissed it along the way. Do I need to set the DYNAMIC for everything I have in my scene that is changing?? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] map/set iterator not dereferencable
oren david wrote: Yep I think it solved the problem Missed it along the way. Do I need to set the DYNAMIC for everything I have in my scene that is changing?? Well, it depends on a number of factors. The reason you were getting a crash was that certain optimizations were performed that assumed the text drawables were not being changed. See the thread I mentioned for details, as this only happens for certain multithreaded OSG modes. Setting the datavariance on nodes should in general only have an effect on the behaviour of the optimizer (i.e. osgUtil::Optimizer), but others might know more about that. Regards, Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Qt and OSG
Hi guys! I try to integrate qt dialogs into osg application and have some troubles in creating borderless window I try to modify osgviewerQT example but in in QOSGWidget.cpp already have traits-windowDecoration = false; but on vista with qt4.4.3 I have window decoration. In example there are two types of qt integration via OSG/GL and via QT/GL. Cold you please tell me which is fastest? Thanx in advance Bye ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt and OSG
Try the Qt demo where you can set all the window flags. I've tried in on Windows XP, Linux, and Mac OS X, and many of the flags don't really do much, and it's system dependent. I was unable to find a set of flags that would create a borderless window either. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4744#4744 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt and OSG
Me too! I try to setup like this viewerWindow-setWindowFlags(Qt::FramelessWindowHint); but have some message that can't create ogl context on vista nvidia 181.20 on qt 4.4.3 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Guthrie Sent: Monday, January 19, 2009 3:44 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Qt and OSG Try the Qt demo where you can set all the window flags. I've tried in on Windows XP, Linux, and Mac OS X, and many of the flags don't really do much, and it's system dependent. I was unable to find a set of flags that would create a borderless window either. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4744#4744 ___ 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] Problem with deletion of DrawableDrawWithDepthShadowComparisonOffCallback
Has anyone else come across this problem. When the debugging features of osgShadow are activated by calling setDebugDraw(true). I get a crash when cleaning up my scene. This crash occurs when the destructor of DrawableDrawWithDepthShadowComparisonOffCallback is called. It appears that the 'this' pointer is off by a few (16) bytes by the time the compiler generated destructor is called. I suspect this is a compiler issue with Microsoft VC8.1. Tracing shows that the this pointer starts off OK and the right things are being done to handle the virtual destructor but when the chain of destructor calls gets thunked across into the osgShadow DLL the wrong offset is applied to get from the base virtual destructor this pointer (~osg::Referenced) to the correct derived class this pointer at this point. So has anyone else come across this, or got any ideas whether it is fixable. This might finally force me to move to VC9, a task I am not looking forward to. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] AnimationPathManipulator MFC Time control
Hi Ralph, I took the time to convert my program to call beginthreadex instead of CreateThread, but the bug stay the same. I think it's because of my PeekMessage loop because it's the only difference between the MFC sample and my corresponding part of code. I think I'm gonna keep my derived class from AnimationPathManipulator calling osg::Timer::instance()-time_s() instead of ea.getTime(), because I don't see any other solution. 2009/1/19 Ralph Kern usene...@rk-se.de Hi Alexandre, I haven't dug in deeply in your problem, but I guess it stems from the following remark from the CreateThread() documentation: A thread that uses functions from the C run-time libraries should use the beginthread and endthread C run-time functions for thread management rather than CreateThread and ExitThread. Failure to do so results in small memory leaks when ExitThread is called. This in fact means you cannot reliably use any function in your thread which might call a c run time lib function. Try to rewrite your thread initialization to use _beginthread instead. regards Ralph Alexandre Amalric schrieb: Hi osg-users, I'm developping an application under MFC and I started from the MFC sample to begin with but with a little difference in thread management. My rendering thread isn't create with _beginthread but with CreateThread wich launch a CWinThread derived class with a message pump, I want it to be a UI thread and not a worker thread. So I don't know if I'm clear but my problem is that when I play a path and I press 'p' key to pause, the camera isn't at the correct position. In fact I decided to derive osgGA::AnimationPathManipulator class and to replace all ea.getTime() by fTimeSec ( double fTimeSec = osg::Timer::instance()-time_s();) in function handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter us); With this method it works perfectly, so I assume that when creating a rendering thread responsible to call viewer::frame() with CreateThread the ea.getTime() isn't the correct time... Can someone explain me why we use ea.getTime() and not osg::Timer::instance()-time_s() ? -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] AnimationPathManipulator MFC Time control
Hi osg-users, For those who are interested I find the solution, before calling for the first time osgViewer::CompositeViewer::frame() I call osgViewer::CompositeViewer::setReferenceTime() like : pCompoViewer-setReferenceTime(osg::Timer::instance()-time_s()); So I can now use the AnimationPathManipulator, no more need to derive this class. 2009/1/19 Alexandre Amalric alex.pix...@gmail.com Hi Ralph, I took the time to convert my program to call beginthreadex instead of CreateThread, but the bug stay the same. I think it's because of my PeekMessage loop because it's the only difference between the MFC sample and my corresponding part of code. I think I'm gonna keep my derived class from AnimationPathManipulator calling osg::Timer::instance()-time_s() instead of ea.getTime(), because I don't see any other solution. 2009/1/19 Ralph Kern usene...@rk-se.de Hi Alexandre, I haven't dug in deeply in your problem, but I guess it stems from the following remark from the CreateThread() documentation: A thread that uses functions from the C run-time libraries should use the beginthread and endthread C run-time functions for thread management rather than CreateThread and ExitThread. Failure to do so results in small memory leaks when ExitThread is called. This in fact means you cannot reliably use any function in your thread which might call a c run time lib function. Try to rewrite your thread initialization to use _beginthread instead. regards Ralph Alexandre Amalric schrieb: Hi osg-users, I'm developping an application under MFC and I started from the MFC sample to begin with but with a little difference in thread management. My rendering thread isn't create with _beginthread but with CreateThread wich launch a CWinThread derived class with a message pump, I want it to be a UI thread and not a worker thread. So I don't know if I'm clear but my problem is that when I play a path and I press 'p' key to pause, the camera isn't at the correct position. In fact I decided to derive osgGA::AnimationPathManipulator class and to replace all ea.getTime() by fTimeSec ( double fTimeSec = osg::Timer::instance()-time_s();) in function handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter us); With this method it works perfectly, so I assume that when creating a rendering thread responsible to call viewer::frame() with CreateThread the ea.getTime() isn't the correct time... Can someone explain me why we use ea.getTime() and not osg::Timer::instance()-time_s() ? -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] AnimationPathManipulator MFC Time control
Hi-osg-users, Last post because sometimes I write too much ;-) The ideal solution was for me to not forget to call osgViewer::CompositeViewer::realize() after adding a new view... Sorry to bother you. 2009/1/19 Alexandre Amalric alex.pix...@gmail.com Hi osg-users, For those who are interested I find the solution, before calling for the first time osgViewer::CompositeViewer::frame() I call osgViewer::CompositeViewer::setReferenceTime() like : pCompoViewer-setReferenceTime(osg::Timer::instance()-time_s()); So I can now use the AnimationPathManipulator, no more need to derive this class. 2009/1/19 Alexandre Amalric alex.pix...@gmail.com Hi Ralph, I took the time to convert my program to call beginthreadex instead of CreateThread, but the bug stay the same. I think it's because of my PeekMessage loop because it's the only difference between the MFC sample and my corresponding part of code. I think I'm gonna keep my derived class from AnimationPathManipulator calling osg::Timer::instance()-time_s() instead of ea.getTime(), because I don't see any other solution. 2009/1/19 Ralph Kern usene...@rk-se.de Hi Alexandre, I haven't dug in deeply in your problem, but I guess it stems from the following remark from the CreateThread() documentation: A thread that uses functions from the C run-time libraries should use the beginthread and endthread C run-time functions for thread management rather than CreateThread and ExitThread. Failure to do so results in small memory leaks when ExitThread is called. This in fact means you cannot reliably use any function in your thread which might call a c run time lib function. Try to rewrite your thread initialization to use _beginthread instead. regards Ralph Alexandre Amalric schrieb: Hi osg-users, I'm developping an application under MFC and I started from the MFC sample to begin with but with a little difference in thread management. My rendering thread isn't create with _beginthread but with CreateThread wich launch a CWinThread derived class with a message pump, I want it to be a UI thread and not a worker thread. So I don't know if I'm clear but my problem is that when I play a path and I press 'p' key to pause, the camera isn't at the correct position. In fact I decided to derive osgGA::AnimationPathManipulator class and to replace all ea.getTime() by fTimeSec ( double fTimeSec = osg::Timer::instance()-time_s();) in function handle(const osgGA::GUIEventAdapter ea, osgGA::GUIActionAdapter us); With this method it works perfectly, so I assume that when creating a rendering thread responsible to call viewer::frame() with CreateThread the ea.getTime() isn't the correct time... Can someone explain me why we use ea.getTime() and not osg::Timer::instance()-time_s() ? -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] prob with osgviewerQT
Hi, I am unable to compile osgviewerQT example .. i am getting the following error.. CMake Error at CMakeLists.txt:17 (SETUP_EXAMPLE): Unknown CMake command SETUP_EXAMPLE. CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.6) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run cmake --help-policy CMP. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done I tried to discard it and continued with make osgviewerQT .. It gave another error .. /tmp/ccJqhYMB.o: In function `main': osgviewerQT.cpp:(.text+0x92): undefined reference to `QApplication::QApplication(int, char**, int)' osgviewerQT.cpp:(.text+0xfc): undefined reference to `osg::ArgumentParser::ArgumentParser(int*, char**)' osgviewerQT.cpp:(.text+0x133): undefined reference to `osg::ArgumentParser::read(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' osgviewerQT.cpp:(.text+0x1b2): undefined reference to `mainQOSGWidget(QApplication, osg::ArgumentParser)' osgviewerQT.cpp:(.text+0x1c9): undefined reference to `mainAdapterWidget(QApplication, osg::ArgumentParser)' osgviewerQT.cpp:(.text+0x211): undefined reference to `QApplication::~QApplication()' osgviewerQT.cpp:(.text+0x22d): undefined reference to `QApplication::~QApplication()' /tmp/ccJqhYMB.o: In function `osg::Referenced::unref() const': osgviewerQT.cpp:(.text._ZNK3osg10Referenced5unrefEv[osg::Referenced::unref() const]+0x77): undefined reference to `osg::Referenced::getDeleteHandler()' osgviewerQT.cpp:(.text._ZNK3osg10Referenced5unrefEv[osg::Referenced::unref() const]+0x8b): undefined reference to `osg::Referenced::deleteUsingDeleteHandler() const' collect2: ld returned 1 exit status make: *** [osgviewerQT] Error 1 ... Then I wrote my own makefile including all the files .. then I got a very long list of errors .. I did try googlin it but cudnt solve the prob :( .. someone plzz help me out .. tnx in advance, pavan On Mon, Jan 19, 2009 at 11:03 PM, dasari pavan kumar dasaripa...@gmail.comwrote: Hi, I am unable to compile osgviewerQT example .. i am getting the following error.. CMake Error at CMakeLists.txt:17 (SETUP_EXAMPLE): Unknown CMake command SETUP_EXAMPLE. CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.6) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run cmake --help-policy CMP. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done I tried to discard it and continued with make osgviewerQT .. It gave another error .. /tmp/ccJqhYMB.o: In function `main': osgviewerQT.cpp:(.text+0x92): undefined reference to `QApplication::QApplication(int, char**, int)' osgviewerQT.cpp:(.text+0xfc): undefined reference to `osg::ArgumentParser::ArgumentParser(int*, char**)' osgviewerQT.cpp:(.text+0x133): undefined reference to `osg::ArgumentParser::read(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' osgviewerQT.cpp:(.text+0x1b2): undefined reference to `mainQOSGWidget(QApplication, osg::ArgumentParser)' osgviewerQT.cpp:(.text+0x1c9): undefined reference to `mainAdapterWidget(QApplication, osg::ArgumentParser)' osgviewerQT.cpp:(.text+0x211): undefined reference to `QApplication::~QApplication()' osgviewerQT.cpp:(.text+0x22d): undefined reference to `QApplication::~QApplication()' /tmp/ccJqhYMB.o: In function `osg::Referenced::unref() const': osgviewerQT.cpp:(.text._ZNK3osg10Referenced5unrefEv[osg::Referenced::unref() const]+0x77): undefined reference to `osg::Referenced::getDeleteHandler()' osgviewerQT.cpp:(.text._ZNK3osg10Referenced5unrefEv[osg::Referenced::unref() const]+0x8b): undefined reference to `osg::Referenced::deleteUsingDeleteHandler() const' collect2: ld returned 1 exit status make: *** [osgviewerQT] Error 1 ... Then I wrote my own makefile including all the files .. then I got a very long list of errors .. I did try googlin it but cudnt solve the prob :( .. someone plzz help me out .. tnx in advance, pavan -- ./Pavan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compilation of OSG with /MT option.
Hi Vincent, I know a pack exist but it is a 2.6 Mo file to add, and ask for user to install it is sufficient, but It is a 3rd pack (first is the .exe, second the OSG dll) and we would be able to free user of some pack to install. You can just include the DLLs in your application's zip/installer. There's no real reason to have more than one thing to install. The zip/installer can include all dependencies: OSG itself, OSG's dependencies, and the VC++ runtime. In fact, if you check out the 3rd party binaries package that Mike Weiblen distributes: https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1/bin/ you'll see that the VC++ runtime is included (note that this is for vc80sp1 (VC++ 2005 sp1)). You can do the same thing, for your specific version of VC++ if it's not the same. I guess I just think you're trying to complicate things for yourself (perhaps unknowingly). It's really quite simple: include all the DLLs you app needs and which are not system-default as private DLLs (in the same directory as your app's exe) and you should be fine, as long as the licensing terms for those DLLs allow that (and generally they do). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link error for osgdb_ive plugin on Mac OS x 10.5
alessandro terenzi schrieb: I'm trying to build OSG 2.6.1 on Mac OS X 10.5 but I get a link error when building osgdb_ive plugin. The error is shown in the attached screen capture. Every other plugins build successfully. I missed the release of 2.6.1, so the xcode-project is outdated for this version. (Current svn should compile, though) The problem is, that some new ive-files are not part of the project, You can try to add the missing files to the ive-plugin, and try a recompile. I'll try to submit a fixed XCode-project the next days. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with deletion ofDrawableDrawWithDepthShadowComparisonOffCallback
Roger, Any chance you are mixing debug and release dlls? This is a typical debug/release memory management problem, when memory allocated by one dll (using say debug memory management) is deallocated by another dll (built with release memory management). The only solution (and it sort of feels right anyhow) is always let the dll that allocates memory also be responsible for deallocating the memory. That way, there is never a conflict with memory management - mind you other issues might then arise, so probably best to ensure that dlls (and the .exe) are built to the same debug or release state. PhilT -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org]on Behalf Of Roger James Sent: 19 January 2009 16:03 To: OpenSceneGraph Users Subject: [osg-users] Problem with deletion ofDrawableDrawWithDepthShadowComparisonOffCallback Has anyone else come across this problem. When the debugging features of osgShadow are activated by calling setDebugDraw(true). I get a crash when cleaning up my scene. This crash occurs when the destructor of DrawableDrawWithDepthShadowComparisonOffCallback is called. It appears that the 'this' pointer is off by a few (16) bytes by the time the compiler generated destructor is called. I suspect this is a compiler issue with Microsoft VC8.1. Tracing shows that the this pointer starts off OK and the right things are being done to handle the virtual destructor but when the chain of destructor calls gets thunked across into the osgShadow DLL the wrong offset is applied to get from the base virtual destructor this pointer (~osg::Referenced) to the correct derived class this pointer at this point. So has anyone else come across this, or got any ideas whether it is fixable. This might finally force me to move to VC9, a task I am not looking forward to. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
