Re: [osg-users] [SOLVED] Deriving my own Effect/Technique class - heap damage error
Hi there, Some weeks ago, I posted my original problem, when deriving my own Effect/Technique class. I'm happy to add that both the heap damage error and the memory leak are solved, now. (In fact, there were some similar errors and I couldn't ignore or workaround them any more.) It was not the mixing of debug and release binaries, but some incompatible compiler settings: My project compiled with /MT and /MTd respectively, while OSG links the C Runtime dynamically (/MD and /MDd respectively). Here are some forum threads which helped me to get the clue and describe in more detail which flags to regard: http://forum.openscenegraph.org/viewtopic.php?t=7753 http://forum.openscenegraph.org/viewtopic.php?t=7644 http://forum.openscenegraph.org/viewtopic.php?t=2436 Hope, this will help others to save time and effort. Cheers, Matthias Schütze, Germany ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flagging shaders with errors
Hi Joel, On Sun, Oct 23, 2011 at 2:22 AM, Joel Graff pair_o_gra...@comcast.net wrote: (However, as a matter of principle, I'd still like to know what I'm missing in regards to what it takes to traverse a scene graph from a post draw or realize callback...) Have a look at the osgUtil::GLObjectsVisitor this traverses a scene graph and compiles the GL objects along the way. See include/osgUtil/GLObjectsVisitor and src/osgUtil/GLObjectsVisitor.cpp. For you own task you'll be able use a much simpler NodeVisitor implementation as you'll be just interested in Program and Uniforms. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Memory leak in osgUtil::Tessellator v3.0.1?
Hi, I've been using v2.8.3 (32bit) on Windows since early this year with no problems, and just this week switched to v3.0.1 and the 64-bit binaries. Now when I call retessellatePolygons in osgUtil::Tessellator the program stops responding and I notice the app memory quickly (!) climbs beyond 5gb, and that for a simple one-function console application I used to reproduce the problem (attached). Is this something I'm doing wrong with the new build? Cheers, Stewart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43513#43513 Attachments: http://forum.openscenegraph.org//files/example_208.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Double precision vertex data problem
Hi Robert Many thanks - your fix to ArrayDispatcher works for me - both with my test data and the original more complex scenegraph that the edge3.osg test case was extracted from. best Mike On 21 October 2011 17:42, Robert Osfield robert.osfi...@gmail.com wrote: Hi Mike, Your comments about ArrayDispatcher and slow paths was most illuminating. I had a look at the ArrayDispatchers.cpp and how it integrates with the GLBeginEndAdapter that is used as a fallback when slow paths have to be used and found that it didn't contain the handling of Vec3d's so I've added this and checked it into svn/trunk. With this change your edges3.osg model works with the vertex data passed in as a Vec3dArray. Could you try out svn/trunk and let me know how you get on. Cheers, Robert. On Fri, Oct 21, 2011 at 1:26 PM, Mike Connell michael.conn...@gmail.com wrote: Hi Filip, Thanks for your comments. It appears the warnings are indeed from the TriangleFunctor which is used by the DriveManipulator TerrainManipulator. As we don't use those pieces of code in this application I don't think they are the problem here. I've dug a little deeper in the rendering code and found a solution. The geometry object which isn't working has PER_PRIMITIVE and OVERALL bindings and so was shunted off the fast path. I now suspect that there is a bug within the ArrayDispatcher code where the Vec3d vertex data is discarded. However, if I update the geometry so that fast paths are used, everything works as expected. I am going to take the easy road and update our code to stay on the fast path route, but in case anyone else has problems with double precision geometry, the non fast path rendering code may be the culprit. best wishes Mike beleive that the problem lies within the ArrayDispatcher code, but On 18 October 2011 17:11, Filip Arlet fili...@seznam.cz wrote: Hi, PolytopeIntersector uses osg::TriangleFunctor T and as you can see in code (TriangleFunctor header). Constructor called with Vec*d does nothing (prints warning). In member function TriangleFunctor::drawArrays OSG is accesing Array, that doesnt exists - and that's where the problem is I think. It looks like it's unfinished. For my app using double I created TriangleFunctorDouble T by replacing every float type variable to double type, but it's more like a workaround than a sollution. Cheers, Filip -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43449#43449 ___ 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] Segfault with Qt
Hi Testing osgviewerQt from osg-3.0.1 on Fedora 16 shows the same segmentation fault. Cheers, Tiziano Am Samstag, den 22.10.2011, 15:09 +0200 schrieb Tiziano Müller: Hi everyone I am using OpenSceneGraph-3.0.1 for a little project together with Qt-4.7.4 and it worked perfectly. After same updates on my system (I can't figure out what exactly changed) I get segfaults when starting either my app or the osgviewerQt demo. Traceback from my app: Program received signal SIGSEGV, Segmentation fault. 0x00841f0f in ?? () (gdb) bt #0 0x00841f0f in ?? () #1 0x7fffe6114f83 in nouveau_fence_update () from /usr/lib64/dri/nouveau_dri.so #2 0x7fffe60d6f9b in nv50_default_flush_notify () from /usr/lib64/dri/nouveau_dri.so #3 0x7fffe5ce861c in nouveau_pushbuf_flush () from /usr/lib64/libdrm_nouveau.so.1 #4 0x7fffe61195eb in st_context_flush () from /usr/lib64/dri/nouveau_dri.so #5 0x7fffe6095c24 in dri_unbind_context () from /usr/lib64/dri/nouveau_dri.so #6 0x7fffe60921b6 in driUnbindContext () from /usr/lib64/dri/nouveau_dri.so #7 0x723d319d in glXMakeCurrentReadSGI () from /usr/lib64/libGL.so.1 #8 0x77b88dd2 in QGLContext::doneCurrent() () from /usr/lib64/qt4/libQtOpenGL.so.4 #9 0x73fb4ed0 in osgQt::GraphicsWindowQt::releaseContextImplementation() () from /usr/lib64/libosgQt.so.80 #10 0x745f986d in osg::GraphicsContext::releaseContext() () from /usr/lib64/libosg.so.80 #11 0x73fb5ae7 in osgQt::GraphicsWindowQt::realizeImplementation() () from /usr/lib64/libosgQt.so.80 #12 0x74209b74 in osgViewer::CompositeViewer::realize() () from /usr/lib64/libosgViewer.so.80 #13 0x74245789 in osgViewer::ViewerBase::frame(double) () from /usr/lib64/libosgViewer.so.80 #14 0x0048edb4 in ViewerWidget::paintEvent (this=0x7fcb70) at /home/tiziano/entwicklung/uni/ba/simulation/gui/viewer_widget.cc:91 #15 0x759728f8 in QWidget::event(QEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #16 0x75922324 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #17 0x759271b1 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #18 0x74ab53ec in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4 #19 0x7596f806 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #20 0x759703e0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #21 0x7596f53c in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #22 0x759703e0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #23 0x759702c0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #24 0x759702c0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #25 0x759702c0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #26 0x759702c0 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QListQObject* const, int, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #27 0x7596f53c in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) () from /usr/lib64/qt4/libQtGui.so.4 #28 0x75b2d8f2 in QWidgetBackingStore::sync() () from /usr/lib64/qt4/libQtGui.so.4 #29 0x75b2dc65 in QWidgetBackingStore::sync(QWidget*, QRegion const) () from /usr/lib64/qt4/libQtGui.so.4 #30 0x7599d595 in QETWidget::translatePaintEvent(_XEvent const*) () from /usr/lib64/qt4/libQtGui.so.4 #31 0x7599e633 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib64/qt4/libQtGui.so.4 #32 0x759c55c2 in x11EventSourceDispatch(_GSource*, int (*)(void*), void*) () from /usr/lib64/qt4/libQtGui.so.4 #33 0x7167969d in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #34 0x71679e98 in g_main_context_iterate.isra.21 () from /usr/lib64/libglib-2.0.so.0 #35 0x7167a069
Re: [osg-users] Segfault with Qt
Hi Tiziano, osgviewerQt is working fine for me. I'm using Kubuntu 11.11 and NVidia drivers. From glxinfo: OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 560 Ti/PCI/SSE2 OpenGL version string: 4.1.0 NVIDIA 280.13 OpenGL shading language version string: 4.10 NVIDIA via Cg compiler From the look of the stack traces the problems you are seeing are driver related. The example runs in mulit-threaded, perhaps this is what introducing problem with the drivers. Try running osgviewerQt --SingleThreaded Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault with Qt
On 10/22/2011 09:09 AM, Tiziano Müller wrote: Hi everyone I am using OpenSceneGraph-3.0.1 for a little project together with Qt-4.7.4 and it worked perfectly. After same updates on my system (I can't figure out what exactly changed) I get segfaults when starting either my app or the osgviewerQt demo. Hi, Tiziano, It looks like you're using the open-source Nouveau drivers that come with Fedora. These drivers are in a constant state of development. From the Nouveau FAQ: nv50 and nvc0 On February 28th, 2011, the original nv50 Gallium3D driver was completely replaced (in git) by the nvc0 Gallium3D driver ported to NV50 family of cards. These drivers are included in *Mesa 7.11*. For nvc0 and the new nv50 drivers, you have to use *at least the 2.6.38 kernel* or you will encounter memory corruption. Bug reports for nv50 and nvc0 can be submitted by following the general reporting guidelines http://nouveau.freedesktop.org/wiki/Bugs. Please, also follow the /About bugs and problems/ section above. If you want things to function reliably, you should probably install the proprietary Nvidia drivers from http://www.nvidia.com. Otherwise, it'll be up to you to deal with the normal issues of unstable open-source software. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [SOLVED] Deriving my own Effect/Technique class - heap damage error
Hi Matthias, Some weeks ago, I posted my original problem, when deriving my own Effect/Technique class. I'm happy to add that both the heap damage error and the memory leak are solved, now. (In fact, there were some similar errors and I couldn't ignore or workaround them any more.) It was not the mixing of debug and release binaries, but some incompatible compiler settings: My project compiled with /MT and /MTd respectively, while OSG links the C Runtime dynamically (/MD and /MDd respectively). Here are some forum threads which helped me to get the clue and describe in more detail which flags to regard: Ah yes, the mixing debug and release argument is often an oversimplification of the actual problem, which is mixing incompatible runtimes. I make that terminology mistake very often... sorry... Good to know you got to the bottom of it. J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] external reference to shader file
Is it possible to embed an external reference to a shader file with any of the osg file formats (.osg, .ive, .osgt, .osgx, etc)? Looking at the plugin code it appears that the only attribute of the shader that gets written is the shader source code, but just wanted to be sure I wasn't missing something. Thanks. Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Left-handed to right-handed
Hi, I am currently working on a pose estimation combined with OpenSceneGraph rendering. It seems that the POSIT algorithm from OpenCv needs modelpoints from a left handed coordinate system. I am working with Sketchup exported Collada files that are right handed. OpenSceneGraph is as OpenGL right handed as well. So I calculate the pose with the POSIT algorithm with left handed input 3D points and get a left handed pose. When I apply a negative scaling along z and change the winding order to osg::FrontFace::CLOCKWISE it is displayed left-handed. For various reasons I'd rather have it displayed right-handed as usual. I was wondering if there is a way to transform a left-handed modelview matrix into a right-handed one? I'd really appreciate any idea. Thank you! Dakota -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43516#43516 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Installation problem with the latest binaries of AlphaPixel
Hi, I'm trying to install OSG 2.8.5 on a Windows 7, 64 bits platform using these tutorials Dwlight Design. 1.The first time, I tried to use: Stable 2.8.5 June 8, 2011 Visual Studio 10 (10.0.30319, 2010) x64 64-bit OpenSceneGraph-2.8.5-VS10.0.30319-x64-release-12493.7z OpenSceneGraph-2.8.5-VS10.0.30319-x64-debug-12493.7z of AlphaPixel. And I got this error: osgd.lib(osg74-osgd.dll) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' 2.Then, I tried with the 32 bits version: OpenSceneGraph-2.8.5-VS10.0.30319-x86-release-12493.7z Everything goes well and I was able to build and execute an example the first time only. After that, I tried again and I got an error message: Fatal error C1083: Cannot open include file: 'osgViewer/Viewer': No such file or directory. I wonder what the reason could be for these two problems ? Thank you! Cheers, VRandria -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43441#43441 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] osgDEM bug?
Hi, ... Thank you! Cheers, baigaichao osgdem -t L:\tex\qiuMerca_t.tif --geocentric --cs epsg:3785 -l 4 -o L:\tex\sky.ive with this command,osgdem can run and no error reported,but nothing generated. why? is the osgdem only run with wgs84? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43416#43416 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Installation problem with the latest binaries of AlphaPixel
On 10/17/2011 11:54 AM, Maia Randria wrote: And I got this error: osgd.lib(osg74-osgd.dll) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' Here, it sounds like you were trying to build an X86 (32-bit) target. Are you familiar with changing the build target in MSVC++? 2.Then, I tried with the 32 bits version: OpenSceneGraph-2.8.5-VS10.0.30319-x86-release-12493.7z Everything goes well and I was able to build and execute an example the first time only. After that, I tried again and I got an error message: Fatal error C1083: Cannot open include file: 'osgViewer/Viewer': No such file or directory. Well, normally VC++ (and CMake, which made the project files VC++ is using) doesn't change settings behind your back. You need to check the CMake settings to make sure that where it thinks the OSG include file are is still ok, and then check in VC++ in the Project Settings for the include paths. I wonder what the reason could be for these two problems ? It's probably not something OSG or AlphaPixel broke -- you'll need to become familiar with checking your compiler settings to isolate the problem. Thank you! Cheers, VRandria -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Installation problem with the latest binaries of AlphaPixel
Hi, Thank you for replying. I resolved the problem by installing the 32 bits binaries (Stable 2.8.5, x86) and it works. I will try again later the complilation from the source codes with your advices. Cheers, Maia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43526#43526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault with Qt
Hi, On Monday 24 October 2011, Jason Daly wrote: If you want things to function reliably, you should probably install the proprietary Nvidia drivers from http://www.nvidia.com. Otherwise, it'll be up to you to deal with the normal issues of unstable open-source software. He reported at the bottom of the original mail that it also fails on nvidias own drivers. So it's probably just nice to see a non obfuscated backtrace on our end, when we get such a backtrace in a bugreport ... But I cant reproduce that either. Probably because of a way older qt here? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
