Re: [osg-users] CPU usage
Greate news (or bad news) that means we have not a windows issue. what happens when you switch to singelthreaded ? /adrian 2009/2/1 Simon Loic simon1l...@gmail.com Hi, in my case when I am runing osgviewer on a ubuntu distribution with 4 cores I get 25% of cpu, which means that one of my cores is over used. One of my colleagues have exactly the same behavior. Thus I don't think this is windows related only. On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron gwald...@gmail.com wrote: Adrian, I have observed an intermittent problem on Windows in which osgviewer starts up using a high CPU %, but then cycling through the threading modes with 'm' makes the problem go away - even when you return to the mode in which you started. I never did figure out why. Just a data point... Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Sun, Feb 1, 2009 at 7:45 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi Cory, I am working with Windows Vista dual core system. I get 50% CPU usage when i am running osgviewer cow.osg if i start osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i have about 0.5-3% CPU usage ! i am very busy at the moment, but may tomorrow i will debug the OSG core, may there is a bug inside or a thread running at max. or robert has some idea,where i can start with debugging. may it's a windows vista bug adrian 2009/2/1 Robert Osfield robert.osfi...@gmail.com Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Robert. On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell c...@codeware.com wrote: I'm not sure about vysync. I'll look that up and check it. I thought about the possibility of it being a debug build and I don't think that's it. In my bin directory I have osgviewer.exe at 25,600 bytes and osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU pegging behavior (as observed by SysInternals Process Explorer). My command line is osgviewer.exe --window 100 100 200 200 cessna.osg. My video card is an ATI FireGL V7700 and the drivers are up to date. Ah- I just noticed something-- an error message: Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found, trying GDI. Reason: The specified procedure could not be found. I'm running over remote desktop right now, so perhaps that's related. I don't recall seeing this error message before. Cory On Sat, Jan 31, 2009 at 3:54 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Cory, It's not normal to have this high level of CPU usage for this model, the expceptions to this would be: You have vysync switched off, so the app is racing as fast it can to dispatch frames You've compiled the OSG with debug build. Robert. On Fri, Jan 30, 2009 at 8:36 PM, Cory Riddell c...@codeware.com wrote: When I run the osg viewer app and load just about any osg file (like cesna.osg), my CPU usage is a constant 23% - 30%. This is with no interaction, it is basically using an entire CPU core. Fortunatelly I have a 4 core machine, so it hasn't been a problem so far, but I'm wondering what this means for single core machines (which most of our customers have). Is this typical? Cory ___ 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 -- Adrian Egli ___ 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 -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Histroy Buffer Implementation / Suggestion
Hello all You should use lispsm or pssm shadow : even for terrain this gives nice looking shadows (with pssm you can limit the max far distance, use this say 250m, and you will get nice shadows) but once we have the latest idea implemented, the shadow quality gets much better, this would be of sure true, but may the performance will be very bad. so i am looking for high performance and robust technic. I don't really like to implement this with osgPPU, because of the problem robert told (see submission discussion) not tha osgPPU is bad, but it would better be nicely integrated into osg and osgShadow, not only for osgShadow and its quality the histroy buffer could have high impact, also for others shaders. Then for the default shader in openscenegraph may we should think to redesign them, because actually we have shaders in shadow, ... , but each of the re-writes the very basics, may we could think about of GLSL shader modules, code modules then we can put them together, this would be greate. i have some idea how this could be solved. but i have to think about more of this idea. /adrian 2009/2/1 Simon Loic simon1l...@gmail.com It would be very interested to see the resulting shadows of this method in osg. I'am currently using the basic shadow technic and the rendering is so aliased! Maybe I'am not using it in the right way. On Fri, Jan 30, 2009 at 4:44 PM, Art Tevs stud_in...@yahoo.de wrote: Hi Adrian, for all 2D effects there exists already a pipeline with couple of examples (gauss blurr, depth of field, hdr and so on), however you maybe have heard about it already. Take a look into osgPPU. I took a small look into the paper and saw that the main method is just to combine N previous images in some sense together to achieve nice results. As you said, using the history buffer. Using pure osg components, one could for example setup N cameras with corresponding textures and switch them framewise. Then current rendering camera use the input of other N-1 cameras to produce its new output. Using osgPPU, I would suggest to implement new class UnitHistoryBuffer, which will do this trick, by collecting the inputs in some buffer, e.g. 3D texture or 2D texture array. Output of this unit can then be combined with current rendering camera in the way as described in the paper. This shouldn't be a big trick, yeah, maybe I can do this for the upcoming v0.4 release ;) I am wonder if one could use this technique for some sreen space effects, not only for motionblur, but also for optical flow detection or something similar ??? Maybe for something like hybrid ray tracing approach, where some kind of heuristic function could use this information to retrace only neccessary rays. cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5545#5545 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shutting down OSG
Did the code help ?
/adrian
2009/1/30 Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com
Hi Robert, Cory,
I implement some weeks before a memory leak detector for VS 2005 and
cleaned up the code that all of my objects get right removed from memory
now, espacially i had some bad behaviour before
cleaning up my webbased rendering plugin, after removing all memory leak
even quicktime get closed without any crashes. so it's really important that
all allocated memory gets
fine removed. the plugin don't have some leaks coming through the OSG core,
and believe me: our application is much more complex than just use some
geometry nodes.
and i can say that the osg core should be free of any memory leak, i
suggest using in all user application the ref_ptr concept which robert is
using in the core of osglib then you don't get some leaks.
I also believe that there is also many false positives...
Here is the code you should use :
// memory leak check ...
---
MEM_LEAK_BASE.h
---
---
Just include this in each CPP file
#ifdef MEM_LEAK_CHK
#include DbgMemoryImpl.h
#endif
---
i hope this works also
/adrian
2009/1/30 Robert Osfield robert.osfi...@gmail.com
Hi Cory,
I believe the are bugs in the memory tracking support in VS,
especially when using MFC, that produce many false positives. You'll
need to get more info about this from VS experts though, the last time
I used VS was in the last Century!
Robert.
On Fri, Jan 30, 2009 at 3:32 PM, Cory Riddell c...@codeware.com wrote:
After my (MFC) app ends, the output window in Visual Studio fills with a
bunch of this:
Detected memory leaks!
Dumping objects -{164} normal block at 0x02A54248, 128 bytes long.
Data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
{163} normal block at 0x02A541A8, 96 bytes long.
Data: c F8 87 63 01 00 00 00 00 01 00 00 00 00 00 00
00
{161} normal block at 0x02A54068, 64 bytes long.
Data: OpenThread v1.2p 4F 70 65 6E 54 68 72 65 61 64 20 76 31 2E 32
70
I'm just getting started with OSG. I'm using it to render geometry from
Granite (the geometry kernel from the Pro/ENGINEER people, just getting
started with this too). Both libraries have their own reference counted
pointer types and they function a bit differently so I'm probably just
abusing one or the other.
Normally I can just pick one of the allocation numbers from the dump
(161,
163, and 164 above) and tell the debugger to stop there, but for some
reason
that isn't working. If I have time later today, I'm going to instrument
everything with BoundsChecker and run it again.
Cory
On Fri, Jan 30, 2009 at 9:08 AM, Robert Osfield
robert.osfi...@gmail.com
wrote:
Hi Cory,
The OSG users ref counting, so if all external references to the scene
and viewer are removed then all the associated resources should be
deleted automatically. If you app keeps any references to this data
then it'll stay around until these references are removed.
If you've enabled caching in the osgDB::Registry then it can keep
around a reference for loaded objects in its cache, so clearing this
would be required. Also if you app loads OSG plugins as part of
loading your data then one could see this as items you might want to
unload.
BTW, what makes you think that things aren't being released?
Robert.
On Fri, Jan 30, 2009 at 2:57 PM, Cory Riddell c...@codeware.com
wrote:
Is there a correct way to stop OSG and free all the resources that
have
been
acquired by without stopping the application? I thought that when my
osgViewer::Viewer instance went out of scope, everything would be
released,
but that doesn't seem to be the case.
cory
___
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] What about User-Meeting in Europe - osgInEurope?
No problem for Paris ! :) The show at Brussels seems interesting too, and it's a center place in Europe. On Sun, Feb 1, 2009 at 1:53 PM, Cedric Pinson morni...@plopbyte.net wrote: Hi, I will happy to meet osg users in Europe like the last time in Paris :) Cheers, Cedric Adrian Egli OpenSceneGraph (3D) wrote: Hi all i am also interested in EuropOSG meeting, switzerland can be a nice option (luzern my home country (canton) :-) ) but we have no osgEarth to get the country and cities ,,, brussel / holland :-) ? adrian 2009/2/1 Art Tevs stud_in...@yahoo.de mailto:stud_in...@yahoo.de Hi Robbert, oh, true Brussel is not in the Netherlands ;) Sorry, my fault! Aha, a military conference?! Of course we could do that, however it is already in around 3 months, hence I am not sure if this time is enough to organize a small osg-meeting/conference. Cheers, art Robbert wrote: osgHi, I did not know Brussels was located in the Netherlands [Shocked] Now i mention Brussels How about a user meeting at the ITEC conference (http://www.itec.co.uk/) in Brussels 12-14 may? There will be alot of OSG user around at that event. Robbert -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5603#5603 ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +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 -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Cedric, I did make some changes to CMakeLists.txt to fix build problems under FreeBSD that related the Xrandr functionality. Could you check the Cmake variable that have been picked up for X11_Xrandr_LIB, mine points to .usr/lib/libXrandr.so. Robert. On Sun, Feb 1, 2009 at 5:08 PM, Cedric Pinson morni...@plopbyte.net wrote: Hi Robert and all I get the trunk this afternoon, and get a compile issue ./configure make ... Linking CXX executable ../../bin/osgviewer /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRQueryVersion' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRConfigRates' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRQueryExtension' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRConfigRotations' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRRates' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRFreeScreenConfigInfo' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRGetScreenInfo' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRConfigSizes' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRSizes' /home/mornifle/dev/osg-trunk/release/lib/libosgViewer.so: undefined reference to `XRRSetScreenConfigAndRate' Anybody get this error ? Cheers, Cedric Robert Osfield wrote: Hi All, I would like to finish this week with a 2.7.9 dev release, could users do a check out of svn/trunk and let know if your build succeeds/or where it fails. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +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@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, Thanks for the explanation. Actually I was wondering: If anyone can easily and freely have 2.6+ without any drawback (which is false, Cedric told me), why should users stay to 2.4?. This is why I asked. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 14:51:54 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, I apply a pain vs gain to this type of decision. How much pain is it to maintain 2.4.x support vs how much pain it would be to those who'd have to upgrade, and also against how much we have to gain in streamlining our own maintenance work. Right now for Cmake 2.4.x it doesn't seem too difficult to retain support. A similar situation occurred back when we wanted to migrate from supporting VS 6.0 and to now when we've officially dropped support. VS 6.0 became almost impossible to maintain as there wasn't enough active users using VS 6.0 to be able to keep the build running, and given the small numbers of VS 6.0 the pain of removing this support got less over time. At OSG 2.0 we may the decision to officially drop support for VS 6.0. CMake 2.4.x is still quite a long way from this point though. Robert. On Mon, Feb 2, 2009 at 12:38 PM, Sukender suky0...@free.fr wrote: Hi Robert, hi Cédric, Please don't take offense of this question, but why don't we simply drop the support for older versions of CMake? As far as I know, 2.6 introduced many improvements. Are there platforms where 2.6+ isn't available? Or is there something I don't know (which may be the most probable answer!)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 12:40:06 +0100, Cedric Pinson morni...@plopbyte.net a écrit: Hi Robert, I use cmake version 2.4-patch 8 Cheers, Cedric Robert Osfield wrote: Hi Cedric, Which version of Cmake are you using? Here's my equivalent of your grep of CMaekCache.txt. Note the entry for X11_Xrandr_LIB. Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB to XRANDR_LIBRARIES would be appropriate. Robert. grep -i xran CMakeCache.txt //Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so X11_Xrandr_INCLUDE_PATH:PATH=/usr/include X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;; GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0 GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0 POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp //Advanced flag for variable: QT_XRANDR_LIBRARY QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL=
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, STOP Experimental build launched on rev. 9622 (trunk) STOP Using VC8sp1 STOP See results on dashboard when available (Machine's name is SUKENDER1) STOP Should be finished in... err... when it's done! :) STOP Sukender STOP PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ STOP Le Mon, 02 Feb 2009 16:01:55 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Robert Osfield wrote: Hi Sukender, I apply a pain vs gain to this type of decision. How much pain is it to maintain 2.4.x support vs how much pain it would be to those who'd have to upgrade, and also against how much we have to gain in streamlining our own maintenance work. Right now for Cmake 2.4.x it doesn't seem too difficult to retain support. One reason I like CMake 2.6 more than 2.4 is that it seems to have worked around the stupid and time-consuming relink step that it did when doing make install. When I call make and it finishes I expect to have a fully built set of libraries and executables, not something that isn't directly installable by simply copying files to a destination directory. I'm on a system where only CMake 2.4 is available, btw, but it's hardly any pain to compile and install 2.6 by hand. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. OSX CMake/Make Intel builds. Kubuntu 8.10, 64 bit builds. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
Hi J-S i am working with NVidia GPU, and i have same behaviour. So there should be another problem than the busy wait. Of course can VSync give some problem in performance or at least we get a smaller FPS displayed. But here we have some strang behavior of our osgViewer (renderer). My there is a bug inside the synchronisation. But what i guess is: When we are running under --SingleThreaded : bool GraphicsWindowWin32::realizeImplementation() wglMakeCurrent SwapBuffers all are called in the same thread. if we are working without singlethreaded option, then the realize get call in the master thread and in the others wgl based method call get called in a second thread. may the operating system (driver) understand, that there must be more than one thread in the world and starts an extra synchronisation which cause the CPU overload. /adrian 2009/2/2 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Well, using Remote Desktop adds a variable into the mix for sure, so eliminating this and running the app locally would eliminate one possible thing. About one core being pegged, some video drivers implement vsync as a busy wait, which means that the CPU is not really pegged, it just looks like that. If you were to actually run real code on that core, along with OSG, you would see that that code would run at a normal speed because the vsync busy wait would relinquish the CPU while it's waiting for the next frame to start. So my guess is that your ATI drivers are doing this, and what you're seeing is just the idle time between frames being counted as active time by Process Explorer because it's implemented as a busy wait. Of course, I'm speculating here, you'll have to run a real app (not just osgviewer) to see for yourself. Note also that ATI's OpenGL drivers have never been the best... Though they say they're getting better, they have a long way to go. So there might be some of that here. Hope this helps, 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Morne, On Mon, Feb 2, 2009 at 3:39 PM, Morné Pistorius mpistorius@googlemail.com wrote: I successfully built the current trunk on Windows, VS8. Attached are more warnings if you are interested (about 71), they look to be mostly benign. Thanks, I'll do a review of the warnings and look to get the fixed (or suppressed if we have to) before OSG-2.8.0 goes out. In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 20, Issue 5
Hi Davide, You'll need to be a lot more specific about the tests and results you are getting for others to be able to help dig any deeper into the issue. Items like testing in debug mode is something that can sometime throw people - debug builds are far far slower, much more than one might expect. Secondly vsynv/sync off makes a huge difference. As a point of reference, I'm an occasional OSX users and haven't observed any 15-20x speed reduction under OSX related to Linux, and Linux certainly isn't a slouch relative to Windows. So this suggests there is some combination of usage at your end that is causing the difference or something amiss in how you are interpreting the results. Robert. On Mon, Feb 2, 2009 at 3:48 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi Robert, thanks for the quick answer. What I feel strange is the different behavior that the standard osgviewer class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms. If I check the osgviewerGLUT example, the behavior looks almost identical in both osx and win32. Is there a way to disable the vsync check in a plain osgviewer application? I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG architecture yet... :) thanks again, Davide Date: Mon, 2 Feb 2009 14:47:28 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] OSX issue with the osgviewer class To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902020647k51a2b4bdndf37ebaafae43...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 HI Davide, In what way is this a problem? It's quite normal for a viewer to wait on barriers, as when you have vsync on the graphics thread will be gated by the refresh of the monitor, with the OpenGL driver just putting the calling thread to sleep while it waits for the next frame. If you switch off vysnc you'll find much high CPU utilization as you then see the frame loop throwing many for frames of data quickly at the OpenGL fifo. Robert. On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet __ ___ 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] OSX issue with the osgviewer class
Hi Robert, thanks for the quick answer. What I feel strange is the different behavior that the standard osgviewer class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms. If I check the osgviewerGLUT example, the behavior looks almost identical in both osx and win32. Is there a way to disable the vsync check in a plain osgviewer application? I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG architecture yet... :) thanks again, Davide (I reposted this mail using the correct subject, sorry) HI Davide, In what way is this a problem? It's quite normal for a viewer to wait on barriers, as when you have vsync on the graphics thread will be gated by the refresh of the monitor, with the OpenGL driver just putting the calling thread to sleep while it waits for the next frame. If you switch off vysnc you'll find much high CPU utilization as you then see the frame loop throwing many for frames of data quickly at the OpenGL fifo. Robert. On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi all, Here everything build fines under WinXP, VS8 SP1. But I have a little question, when I call : osviewer.exe --window 100 100 800 600 cow.osg Then I try to display the stats, nothing appears before several hits on the s button, and I just see some parts of the stats, is it normal ? On Mon, Feb 2, 2009 at 5:03 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? osgviewerQT --QOSGWidget cow.osg Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Yup, I have the clearmask enabled for the viewer and it works fine as long as at least one view is still present. But as soon as the last camera is removed, the entire viewer stops working, even if adding new views afterwards. I am trying to reproduce that now in a small example, will send it in a bit. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
I'm running locally now and am seeing the same behavior. Running with --SingleThreaded makes no difference. Cory On Mon, Feb 2, 2009 at 9:53 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi J-S i am working with NVidia GPU, and i have same behaviour. So there should be another problem than the busy wait. Of course can VSync give some problem in performance or at least we get a smaller FPS displayed. But here we have some strang behavior of our osgViewer (renderer). My there is a bug inside the synchronisation. But what i guess is: When we are running under --SingleThreaded : bool GraphicsWindowWin32::realizeImplementation() wglMakeCurrent SwapBuffers all are called in the same thread. if we are working without singlethreaded option, then the realize get call in the master thread and in the others wgl based method call get called in a second thread. may the operating system (driver) understand, that there must be more than one thread in the world and starts an extra synchronisation which cause the CPU overload. /adrian 2009/2/2 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Well, using Remote Desktop adds a variable into the mix for sure, so eliminating this and running the app locally would eliminate one possible thing. About one core being pegged, some video drivers implement vsync as a busy wait, which means that the CPU is not really pegged, it just looks like that. If you were to actually run real code on that core, along with OSG, you would see that that code would run at a normal speed because the vsync busy wait would relinquish the CPU while it's waiting for the next frame to start. So my guess is that your ATI drivers are doing this, and what you're seeing is just the idle time between frames being counted as active time by Process Explorer because it's implemented as a busy wait. Of course, I'm speculating here, you'll have to run a real app (not just osgviewer) to see for yourself. Note also that ATI's OpenGL drivers have never been the best... Though they say they're getting better, they have a long way to go. So there might be some of that here. Hope this helps, 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 -- Adrian Egli ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:20 +0100, Sukender wrote: Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I have two machines: a laptop (Dell M90 with Core2Duo 1.6Ghz) and a desktop (QuadCore 2.6Ghz). It takes about 20 minutes to build from scratch on my laptop (no including the introspection stuff) and about 5 minutes on my desktop. The laptop runs Fedora 10 and the desktop Vista 64. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... 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 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, Could you please capture the warnings you are getting now. They are almost certainly be the same set as the original warnings you sent as I have fixed hundreds and hundreds and hundreds of warnings, having spent well over a week of my life dedicated to just aggressive warnings level. Please also could specify the compiler options as well - are they different from the standard options used by the OSG? (I only see warnings with 3rd party libs that we can do no thing about on my builds). Robert. On Mon, Feb 2, 2009 at 3:56 PM, Jeremy Moles jer...@emperorlinux.com wrote: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi J-S, Hem... I *do* use osgGA wrapper... And yes, I saw they cost much in compile time. :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:36:49 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:44 +0100, Sukender wrote: Hi J-S, Hem... I *do* use osgGA wrapper... And yes, I saw they cost much in compile time. :) Yeah, I don't compile the introspection stuff because it makes it take about 40 minutes here, too. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:36:49 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? If you don't use the wrappers, disable those. That will likely cut your compile time in half if not more. The wrappers really take a long time to compile. J-S ___ 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] Views 1 frame out-of-sync
Hi John, It sounds like you have gen lock that locks the swap buffers of the graphics cards, but you don't have a swap ready implemented for your cluster. Swap ready is a synchronization prior to the dispatch of the call to swap buffers, this sync prevents an application from advancing to the next frame without all the machines/cards having got to a point where they are all ready to swap. Robert. On Mon, Feb 2, 2009 at 4:54 PM, John Aughey j...@aughey.com wrote: I have a problem with 2 independent view windows getting out of sync in a multi-channel system. Bear with me while I explain the configuration. My current test system is one machine with 2 nVidia Quadro FX 4600 graphics cards. These cards are genlocked with the GSync2 option card. Each video card renders one half of a video frame which is then combined in the display hardware. My test scene is nothing but a spinning cube with 5 black faces and 1 white face. Each frame the cube is rotated 90 degrees showing 3 frames of black and 1 frame of white. GL is synced to VBLANK with the __GL_SYNC_TO_VBLANK environment variable. The behavior I'm seeing is when the program first starts the top and bottom half are in perfect sync. What is displayed is 3 frames of black and 1 frame of white producing a seizure-enducing strobe effect. However, after a short period of time (5-10 seconds), the bottom half (second video card) is 1 frame behind the top half. Visually you see the top half strobe slightly before the bottom half (verified with light sensors and a scope). The CPU load is very low (extremely simple scene). I am running in SIngleThreaded mode, and the threading mode doesn't seem to effect the problem. I have had this same problem where the two graphics cards were split across two different machines (2 computers, 2 graphics cards, genlocked with gsync2). In the scene, you will see the two halves looking as they should then after a while you'll see the two halves torn by 1 frame, then after a while they appear to re-sync back up (somewhat dependent on scene content). But while they are split, the system still runs at 60Hz so it is not in a constant overload condition. I believe the problem may lie in the rendering pipeline on the graphics card, and I need to figure out how to keep multiple pipelines in sync with each other. Has anyone else had this problem or knows what I can do to address this synchronization problem? Thank you John ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Serge, On Mon, Feb 2, 2009 at 4:32 PM, Robert Osfield robert.osfi...@gmail.com wrote: Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. I've now improved the handling of the scaling the stats projection matrix, this ensures that the osgviewer cow.osg --window 100 100 800 500 works fine, as well as the usage case that was previously broken. This change is now checked into svn/trunk. Could you please test svn/trunk to see if this problem is solved at your end as well. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Thanks Robert, I'll only be able to test tomorrow morning but i'll let you know. On Mon, Feb 2, 2009 at 6:13 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Serge, On Mon, Feb 2, 2009 at 4:32 PM, Robert Osfield robert.osfi...@gmail.com wrote: Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. I've now improved the handling of the scaling the stats projection matrix, this ensures that the osgviewer cow.osg --window 100 100 800 500 works fine, as well as the usage case that was previously broken. This change is now checked into svn/trunk. Could you please test svn/trunk to see if this problem is solved at your end as well. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 16:23 +, Robert Osfield wrote: Hi Jeremy, Could you please capture the warnings you are getting now. They are almost certainly be the same set as the original warnings you sent as I have fixed hundreds and hundreds and hundreds of warnings, having spent well over a week of my life dedicated to just aggressive warnings level. Please also could specify the compiler options as well - are they different from the standard options used by the OSG? (I only see warnings with 3rd party libs that we can do no thing about on my builds). The only MAJOR one I'm getting anymore is this: In copy constructor ‘osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)’: /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osg::Object’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘class osgGA::GUIEventHandler’ should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class ‘struct osg::Drawable::CullCallback’ should be explicitly initialized in the copy constructor I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) Robert. On Mon, Feb 2, 2009 at 3:56 PM, Jeremy Moles jer...@emperorlinux.com wrote: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... 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 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash errors/warnings
Hi John, Ar this is slow progress... fix one, break the other... So the resolution of this problem now looks to be telling CMake about the directory that the lib is in, I don't know off hand what the CMake scheme for this is, but should be able to hunt it down. Robert. On Mon, Feb 2, 2009 at 5:24 PM, Shue, John A john.s...@mantech.com wrote: Robert, I haven't read all the messages on the other thread with Cedric, but I tried this new CMakeLists.txt and it fails like the original one: Linking CXX shared library ../../lib/libosgViewer.so cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer /usr/local/bin/cmake -E cmake_link_script CMakeFiles/osgViewer.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -fpermissive -O3 -DNDEBUG -shared -Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9 CMakeFiles/osgViewer.dir/CompositeViewer.o CMakeFiles/osgViewer.dir/HelpHandler.o CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o CMakeFiles/osgViewer.dir/StatsHandler.o CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o CMakeFiles/osgViewer.dir/Viewer.o CMakeFiles/osgViewer.dir/ViewerBase.o CMakeFiles/osgViewer.dir/ViewerEventHandlers.o CMakeFiles/osgViewer.dir/GraphicsWindowX11.o CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9 ../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9 ../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9 ../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm /usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread -Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us r/X11R6/lib /usr/bin/ld: cannot find -lXrandr gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1 My libXrandr.so is in /usr/local/lib. I don't see a -L option for /usr/local/lib in the commandline above. Also the end of that commandline doesn't look right to me, namely -Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u sr/X11R6/lib. If I add -L/usr/local/lib to the end of the above commandline, it links. -john -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, February 02, 2009 7:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] CDash errors/warnings Hi John, On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com wrote: That did the trick. Compiled all the way to the end of the build without errors. Turns out that this fix that works for you and me using CMake 2.6.x, breaks the build with Cmake 2.4.8 so we'll need to try out another iteration, instead of using the X11_xrand_LIB we'll need to try XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt. Thanks, Robert. This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. I agree entirely, and it would be nice to strike osgCairo off my list of software dependencies (especially for osgPango, which I'm making incredible progress on and which now works pleasantly well in Windows). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. OSX CMake/Make Intel builds. Kubuntu 8.10, 64 bit builds. Also Mandriva 2009, 32 bit builds OK and seems to work. BTW, OSG package in Mandriva is being updated right now, the packager is waiting for 2.8 to be out. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJhzG8n11XseNj94gRAlO1AKCK6zLxI6dhHb0/r9CyMOAiSHzZkQCeMxzJ BQ7h9Lag3KX0uFhmxT6wPOo= =UUVf -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, On Mon, Feb 2, 2009 at 7:11 PM, Jeremy Moles jer...@emperorlinux.com wrote: The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. This class doesn't directly inherit from osg::Object, I added all the initializers that should be required. Could it be one of the parent classes need the explicit initializer? Could you look into this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash errors/warnings
Robert,
The INCLUDE_DIRECTORIES() line didn't fix the error. It added
-I/usr/local/lib to the command lines used to compile the cpp files,
but didn't add the requried -L/usr/local/lib.
Looking at the output of grep Xrandr CMakeCache.txt, I see the
following:
XRANDR_LDFLAGS:INTERNAL=-L/usr/local/lib;-lXrandr
which has both the -L and -l options we need to pass to the linker.
Question is, how does this get added to the linker commandline? Looking
through osgViewer's CmakeLists.txt file, I don't see any obvious place.
I got it to link with the following change:
#SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LDFLAGS} ${LIB_EXTRA_LIBS})
I have no idea if this is correct usage.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, February 02, 2009 12:47 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
Could you try the attached src/osgViewer/CMakeLists.txt. This adds a :
INCLUDE_DIRECTORIES(${XRANDR_LIBDIR})
Robert.
On Mon, Feb 2, 2009 at 5:24 PM, Shue, John A john.s...@mantech.com
wrote:
Robert,
I haven't read all the messages on the other thread with Cedric, but I
tried this new CMakeLists.txt and it fails like the original one:
Linking CXX shared library ../../lib/libosgViewer.so
cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/osgViewer.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long
-Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas
-Wunused -fpermissive -O3 -DNDEBUG -shared
-Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9
CMakeFiles/osgViewer.dir/CompositeViewer.o
CMakeFiles/osgViewer.dir/HelpHandler.o
CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o
CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o
CMakeFiles/osgViewer.dir/StatsHandler.o
CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o
CMakeFiles/osgViewer.dir/Viewer.o
CMakeFiles/osgViewer.dir/ViewerBase.o
CMakeFiles/osgViewer.dir/ViewerEventHandlers.o
CMakeFiles/osgViewer.dir/GraphicsWindowX11.o
CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9
../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9
../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9
../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so
/usr/local/lib/libICE.so
/usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us
r/X11R6/lib
/usr/bin/ld: cannot find -lXrandr
gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1
My libXrandr.so is in /usr/local/lib. I don't see a -L option for
/usr/local/lib in the commandline above. Also the end of that
commandline doesn't look right to me, namely
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u
sr/X11R6/lib.
If I add -L/usr/local/lib to the end of the above commandline, it
links.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Robert
Osfield
Sent: Monday, February 02, 2009 7:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com
wrote:
That did the trick. Compiled all the way to the end of the build
without
errors.
Turns out that this fix that works for you and me using CMake 2.6.x,
breaks the build with Cmake 2.4.8 so we'll need to try out another
iteration, instead of using the X11_xrand_LIB we'll need to try
XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt.
Thanks,
Robert.
This communication, along with any attachments, is covered by federal
and state law governing electronic communications and may contain
company proprietary and legally privileged information.
If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution, use or copying of
this message is strictly prohibited.
If you have received this in error, please reply immediately to the
sender and delete this message. Thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
This communication, along with any attachments, is covered by federal and state
law governing electronic communications and may contain company proprietary and
legally privileged information.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution, use or
Re: [osg-users] CDash errors/warnings
Hi John,
I'm a bit surpised it didn't work, similar code elsewhere in the OSG
works for other libs, so I can only guess the that directory env var
for XRANDR isn't being set.
To try a fix it I've changed the code to be:
IF (X11_Xrandr_LIB)
SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
ELSE(X11_Xrandr_LIB)
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
ENDIF(X11_Xrandr_LIB)
The first branch is what was compiling on your machine before I
applied my patch to fix CMake 2.4.8 build, the second branch should
now be picked up for 2.4.8 support.
Could you let me know if this works.
Cheers,
Robert.
On Mon, Feb 2, 2009 at 7:49 PM, Shue, John A john.s...@mantech.com wrote:
Robert,
The INCLUDE_DIRECTORIES() line didn't fix the error. It added
-I/usr/local/lib to the command lines used to compile the cpp files,
but didn't add the requried -L/usr/local/lib.
Looking at the output of grep Xrandr CMakeCache.txt, I see the
following:
XRANDR_LDFLAGS:INTERNAL=-L/usr/local/lib;-lXrandr
which has both the -L and -l options we need to pass to the linker.
Question is, how does this get added to the linker commandline? Looking
through osgViewer's CmakeLists.txt file, I don't see any obvious place.
I got it to link with the following change:
#SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LDFLAGS} ${LIB_EXTRA_LIBS})
I have no idea if this is correct usage.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, February 02, 2009 12:47 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
Could you try the attached src/osgViewer/CMakeLists.txt. This adds a :
INCLUDE_DIRECTORIES(${XRANDR_LIBDIR})
Robert.
On Mon, Feb 2, 2009 at 5:24 PM, Shue, John A john.s...@mantech.com
wrote:
Robert,
I haven't read all the messages on the other thread with Cedric, but I
tried this new CMakeLists.txt and it fails like the original one:
Linking CXX shared library ../../lib/libosgViewer.so
cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/osgViewer.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long
-Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas
-Wunused -fpermissive -O3 -DNDEBUG -shared
-Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9
CMakeFiles/osgViewer.dir/CompositeViewer.o
CMakeFiles/osgViewer.dir/HelpHandler.o
CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o
CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o
CMakeFiles/osgViewer.dir/StatsHandler.o
CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o
CMakeFiles/osgViewer.dir/Viewer.o
CMakeFiles/osgViewer.dir/ViewerBase.o
CMakeFiles/osgViewer.dir/ViewerEventHandlers.o
CMakeFiles/osgViewer.dir/GraphicsWindowX11.o
CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9
../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9
../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9
../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so
/usr/local/lib/libICE.so
/usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us
r/X11R6/lib
/usr/bin/ld: cannot find -lXrandr
gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1
My libXrandr.so is in /usr/local/lib. I don't see a -L option for
/usr/local/lib in the commandline above. Also the end of that
commandline doesn't look right to me, namely
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u
sr/X11R6/lib.
If I add -L/usr/local/lib to the end of the above commandline, it
links.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Robert
Osfield
Sent: Monday, February 02, 2009 7:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com
wrote:
That did the trick. Compiled all the way to the end of the build
without
errors.
Turns out that this fix that works for you and me using CMake 2.6.x,
breaks the build with Cmake 2.4.8 so we'll need to try out another
iteration, instead of using the X11_xrand_LIB we'll need to try
XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt.
Thanks,
Robert.
This communication, along with any attachments, is covered by federal
and state law governing electronic communications and may contain
company proprietary and legally privileged information.
If the
Re: [osg-users] near far plane
Hi Peter, You should provide more information to help resolving your issue. What is the kind of problems you encounter? However, I think this may only be a classic depth buffer problem. You could use setComputeNearFarMode() once and then deactivate the computation to lock the near plane. But if your scene is too big, you'll always have precision problems. Among common solutions, you may try: - to use W instead of Z buffer and see what happen, - to reduce your viewing distance (and check the far plane is ok with it), - to use LODs, especially to avoid small objects far from the camera (which can cause flickering with Z-buffer), - to use tiled terrain if not already done (allows the use of LODs, culling, etc.), - or to render with multiple passes (each one having its own depth-buffer)... Hope it helps. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 11:24:16 +0100, Peter Wraae Marino osgh...@gmail.com a écrit: Hi all, At are company we are using huge terrains and have problem with the near plane for our character walking around on the ground. we use the setComputeNearFarMode to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES if we turn it off and set a hardcoded value then this solves the problem for the near plane but gives us a whole new set of problems. is there a way to use the auto computed method but lock the near plane closer to the camera. I have messed around a little with the setNearFarRatio but it seems to adjust at both ends. any suggestions? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, Thanks for the all the testing, a few more bugs and warnings have been fleshed and should be now resolved, alas this has taken me pretty well all the day, so it's now too late for me to go create the OpenSceneGraph-2.8 today. What I'll do is leave svn/trunk to be tested over night and in morning if things look sane I'll go ahead and make the 2.8 branch and the 2.8.0-rc1 from this. Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. In the past we've required a couple rc's so we should expect the same, but your never know perhaps all the i's have been doted and we'll be able to make rc1 gold and then I can take the rest of week off :-) With the rc1 done I'll be starting to nag people for feedback on how their own projects are running against the rc1, testing against real apps is what will start shaking down the build and runtime fully. My aim is to the final get 2.8.0 tagged this week, and if possible packages up for the main platforms. Thanks for you assistance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dashboard suggestion
BTW, I noticed the nightly build is set to 00:00 CET (= GMT+1 = 23:00 or 11:00PM GMT), in CTestConfig.cmake. Is there a reason for this to be not GMT (I mean this is what I expected, so maybe others may think the same)? PS: Yes, I like answering to myself... :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 13:48:47 +0100, Sukender suky0...@free.fr a écrit: Le Mon, 02 Feb 2009 13:46:51 +0100, Sukender suky0...@free.fr a écrit: Hi all, I got an tiny idea... I suggest that people building OSG with dashboard reports (Nightly, Continuous, Experimental), use a site name that includes their name on osg-users list (such as blah blah blah - my OSG name), so that it would be easier for Robert (and maybe others) to identify the builders. So, is it possible to set the default value of the CMake variable to something like Machine name - OSG_USER_NAME environment variable, so that we don't have to put it manually each time we clear the CMake cache? Or else, you could simply fill a shared speadsheet with our name and our sites names... (I think I'll do it if the first idea is not trivial to do). See you! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Why did I say a shared spreadsheet??? I was certainly thinking of something else! I mean a wiki page (that'd be enough!). :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.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@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
+1 :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:51:05 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, Once 2.8.0-rc1 is done, it'll be time to even more build and runtime testing, and for those planning to help out with packaging to start creating packaging for the rc1. Sooo... What are you planning as an upload area for packages? :-) You said we'd put them into SVN, but do you plan to give all of us commit access to a given area of the SVN? Perhaps an FTP would be easier, we could just upload and people would download and then once we've confirmed the packages are good you can commit the packages to SVN... J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Cedric, Which version of Cmake are you using? Here's my equivalent of your grep of CMaekCache.txt. Note the entry for X11_Xrandr_LIB. Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB to XRANDR_LIBRARIES would be appropriate. Robert. grep -i xran CMakeCache.txt //Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so X11_Xrandr_INCLUDE_PATH:PATH=/usr/include X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;; GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0 GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0 POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp //Advanced flag for variable: QT_XRANDR_LIBRARY QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL= XRANDR_LIBS_PATHS:INTERNAL= XRANDR_PREFIX:INTERNAL=/usr XRANDR_STATIC_CFLAGS:INTERNAL= XRANDR_STATIC_CFLAGS_I:INTERNAL= XRANDR_STATIC_CFLAGS_OTHER:INTERNAL= XRANDR_STATIC_INCLUDE_DIRS:INTERNAL= XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL= XRANDR_STATIC_LIBDIR:INTERNAL= XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp XRANDR_STATIC_LIBRARY_DIRS:INTERNAL= XRANDR_STATIC_LIBS:INTERNAL= XRANDR_STATIC_LIBS_L:INTERNAL= XRANDR_STATIC_LIBS_OTHER:INTERNAL= XRANDR_STATIC_LIBS_PATHS:INTERNAL= XRANDR_VERSION:INTERNAL=1.2.3 XRANDR_xrandr_INCLUDEDIR:INTERNAL= XRANDR_xrandr_LIBDIR:INTERNAL= XRANDR_xrandr_PREFIX:INTERNAL= XRANDR_xrandr_VERSION:INTERNAL= __pkg_config_checked_XRANDR:INTERNAL=1 On Mon, Feb 2, 2009 at 11:10 AM, Cedric Pinson morni...@plopbyte.net wrote: Hi Robert, It's a bit strange because it detects xrandr and set the flag ON, but does not detect libs, see the output: *morni...@macmornifle ~/dev/osg-trunk/build $ cmake ../ -DCMAKE_BUILD_TYPE=Release *-- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found --
Re: [osg-users] OSG 2.7.9 - Crash in destroying ShadowedScene
Hi Morne,
I wonder if the osgShadow technique was trying to use a Pbuffer to
implement the render to texture, this isn't supportable when using
GraphicsWindowEmbedded. However, a crash shouldn't ensue, rather
there should be a fallback to use frame buffer for RTT.
BTW, does your OpenGL diriver support frame buffer objects?
In terms of the moving to QGLWidget and osgVIewer window inheiritance
fixing the the issue, this would indicate that pbuffer might be in
play as this is one of capabilities that it adds.
Robert.
On Mon, Feb 2, 2009 at 11:42 AM, Morné Pistorius
mpistorius@googlemail.com wrote:
Hi Robert,
I tried but failed to reproduce the problem in the osg examples. It
must be some subtle difference in the way I set up my scene in my app.
I changed my viewer to the QOSGWidget implementation instead of using
the GraphicsWindowEmbedded in a QGLWidget and that fixed the crash.
Sorry I couldn't reproduce it, but at least there is a work around if
others run into this issue.
Cheers,
Morne
On Fri, Jan 30, 2009 at 4:59 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Hi Morne,
Can you get osgshadow to crash? If others can redproduce this problem
there the chances of fixing it promptly go up.
Robert.
On Fri, Jan 30, 2009 at 4:33 PM, Morné Pistorius
mpistorius@googlemail.com wrote:
Hi guys,
I am testing the current trunk version of OSG in my application (was
previously using v2.6.1) and I get a crash on shutdown when trying to
destroy a osgShadow::ShadowedScene. This only occurs when I have a
shadowTechnique set and is caused by destroying the shader program. I
am using OSG in Qt derived from a QGLWidget (yes I know I should
rather use the QWidget implementation, I am busy porting to that, but
this used to work fine in 2.6.1 so I thought I would flag it :)
I will see if this still happens when not using the GL Adapterwidget,
and report back.
Below is a stack trace of the relevant bits:
osg54-osg.dll!osg::Referenced::~Referenced() Line 262 + 0x5 bytes
C++
osg54-osg.dll!osg::Program::PerContextProgram::~PerContextProgram()
Line 425 + 0x14b bytes C++
osg54-osg.dll!osg::Program::PerContextProgram::`vector deleting
destructor'() + 0x3d bytes C++
osg54-osg.dll!std::_Destroy_rangeosg::ref_ptrosg::Program::PerContextProgram,std::allocatorosg::ref_ptrosg::Program::PerContextProgram
(osg::ref_ptrosg::Program::PerContextProgram * _First=0x02eb7b48,
osg::ref_ptrosg::Program::PerContextProgram * _Last=0x02eb7b50,
std::allocatorosg::ref_ptrosg::Program::PerContextProgram
_Al={...}, std::_Nonscalar_ptr_iterator_tag __formal={...}) Line 235
+ 0x30 bytesC++
osg54-osg.dll!osg::Program::~Program() Line 122 + 0xa8 bytes C++
osg54-osgShadow.dll!osg::Program::`scalar deleting destructor'() +
0x9 bytes C++
osg54-osg.dll!std::_Treestd::_Tmap_traitsstd::pairenum
osg::StateAttribute::Type,unsigned
int,std::pairosg::ref_ptrosg::StateAttribute,unsigned
int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum
osg::StateAttribute::Type,unsigned int const
,std::pairosg::ref_ptrosg::StateAttribute,unsigned int ,0
::_Erase(std::_Tree_nodstd::_Tmap_traitsstd::pairenum
osg::StateAttribute::Type,unsigned
int,std::pairosg::ref_ptrosg::StateAttribute,unsigned
int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum
osg::StateAttribute::Type,unsigned int const
,std::pairosg::ref_ptrosg::StateAttribute,unsigned int ,0
::_Node * _Rootnode=0x02eb7bf8) Line 1078 C++
osg54-osg.dll!osg::StateSet::clear() Line 556 + 0x26 bytes C++
osg54-osg.dll!osg::StateSet::~StateSet() Line 173 C++
osg54-osgShadow.dll!osg::StateSet::`scalar deleting destructor'() +
0x9 bytes C++
osg54-osg.dll!osg::Referenced::unref() Line 176 + 0xf bytesC++
osg54-osgShadow.dll!osgShadow::ShadowMap::~ShadowMap() Line 91 +
0xfb bytes C++
osg54-osgShadow.dll!osgShadow::SoftShadowMap::~SoftShadowMap() Line
73 + 0x7e bytes C++
RiverTestApp.exe!osgShadow::SoftShadowMap::`scalar deleting
destructor'() + 0x10 bytes C++
osg54-osg.dll!osg::Referenced::unref() Line 176 + 0xf bytesC++
osg54-osgShadow.dll!osgShadow::ShadowedScene::setShadowTechnique(osgShadow::ShadowTechnique
* technique=0x) Line 76C++
osg54-osgShadow.dll!osgShadow::ShadowedScene::~ShadowedScene() Line
50 C++
RiverTestApp.exe!VOSGShadowedScene::~VOSGShadowedScene() + 0x10
bytes C++
RiverTestApp.exe!VOSGShadowedScene::`scalar deleting destructor'()
+ 0xf bytes C++
osg54-osg.dll!std::_Destroy_rangeosg::ref_ptrosg::Node,std::allocatorosg::ref_ptrosg::Node
(osg::ref_ptrosg::Node * _First=0x02e74f50,
osg::ref_ptrosg::Node * _Last=0x02e74f5c,
std::allocatorosg::ref_ptrosg::Node _Al={...},
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Cedric,
(I always wrote C*é*dric... which one is correct?)
Ah, okay. I guessed it was something like that :)
Maybe then we could drop CMake 2.4 once 2.6 is stable on most/all platforms?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Mon, 02 Feb 2009 14:04:51 +0100, Cedric Pinson morni...@plopbyte.net a
écrit:
Hi Sukender,
just because cmake 2.6 is not tagged stable yet on my distribution.
[I] dev-util/cmake
Available versions: 2.4.6-r1 (~)2.4.7-r1 2.4.8 ~2.6.2 ~2.6.2-r1
{emacs qt4 vim-syntax}
Installed versions: 2.4.8(13:57:21 02/01/09)(emacs -vim-syntax)
Homepage:http://www.cmake.org/
Description: Cross platform Make
It's the only reason, i prefer to keep stuff stable, but if it becomes a
requierement for osg then i will jump to the 2.6
Cheers,
Cedric
Sukender wrote:
Hi Robert, hi Cédric,
Please don't take offense of this question, but why don't we simply drop the
support for older versions of CMake? As far as I know, 2.6 introduced many
improvements. Are there platforms where 2.6+ isn't available? Or is there
something I don't know (which may be the most probable answer!)?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Mon, 02 Feb 2009 12:40:06 +0100, Cedric Pinson morni...@plopbyte.net a
écrit:
Hi Robert,
I use cmake version 2.4-patch 8
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
Which version of Cmake are you using?
Here's my equivalent of your grep of CMaekCache.txt. Note the entry
for X11_Xrandr_LIB.
Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB
to XRANDR_LIBRARIES would be appropriate.
Robert.
grep -i xran CMakeCache.txt
//Set to ON to enable Xrandr support for GraphicsWindowX11.
OSGVIEWER_USE_XRANDR:BOOL=ON
QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so
X11_Xrandr_INCLUDE_PATH:PATH=/usr/include
X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so
osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;;
GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0
GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0
POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp
POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp
//Advanced flag for variable: QT_XRANDR_LIBRARY
QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1
//Advanced flag for variable: X11_Xrandr_INCLUDE_PATH
X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1
//Advanced flag for variable: X11_Xrandr_LIB
X11_Xrandr_LIB-ADVANCED:INTERNAL=1
XRANDR_CFLAGS:INTERNAL=
XRANDR_CFLAGS_I:INTERNAL=
XRANDR_CFLAGS_OTHER:INTERNAL=
XRANDR_FOUND:INTERNAL=1
XRANDR_INCLUDEDIR:INTERNAL=/usr/include
XRANDR_INCLUDE_DIRS:INTERNAL=
XRANDR_LDFLAGS:INTERNAL=-lXrandr
XRANDR_LDFLAGS_OTHER:INTERNAL=
XRANDR_LIBDIR:INTERNAL=/usr/lib
XRANDR_LIBRARIES:INTERNAL=Xrandr
XRANDR_LIBRARY_DIRS:INTERNAL=
XRANDR_LIBS:INTERNAL=
XRANDR_LIBS_L:INTERNAL=
XRANDR_LIBS_OTHER:INTERNAL=
XRANDR_LIBS_PATHS:INTERNAL=
XRANDR_PREFIX:INTERNAL=/usr
XRANDR_STATIC_CFLAGS:INTERNAL=
XRANDR_STATIC_CFLAGS_I:INTERNAL=
XRANDR_STATIC_CFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_INCLUDE_DIRS:INTERNAL=
XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp
XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_LIBDIR:INTERNAL=
Re: [osg-users] osg-users Digest, Vol 20, Issue 5
Hi Robert, thanks for the quick answer. What I feel strange is the different behavior that the standard osgviewer class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms. If I check the osgviewerGLUT example, the behavior looks almost identical in both osx and win32. Is there a way to disable the vsync check in a plain osgviewer application? I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG architecture yet... :) thanks again, Davide Date: Mon, 2 Feb 2009 14:47:28 + From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] OSX issue with the osgviewer class To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: 7ffb8e9b0902020647k51a2b4bdndf37ebaafae43...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 HI Davide, In what way is this a problem? It's quite normal for a viewer to wait on barriers, as when you have vsync on the graphics thread will be gated by the refresh of the monitor, with the OpenGL driver just putting the calling thread to sleep while it waits for the next frame. If you switch off vysnc you'll find much high CPU utilization as you then see the frame loop throwing many for frames of data quickly at the OpenGL fifo. Robert. On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] near far plane
Hi Peter, You may need to disable the compute of the near far and just manage the near/far of the projection matrix yourself. The other alternative is to provide your own osg::CullSettings::ClampProjectionMatrixCallback. To disable the compute of the near far you reset the value of the master Camera i.e. viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::DO_COMPUTE_NEAR_FAR); Or to assign your own clamp callback: viewer.getCamera()-setClampProjectionMatrixCallback(myCallback); Another approach totally would be to depth partition your scene such that you render the foreground to a transition distance, then from the transition distance out to that further point you can see. The osgdepthpartiion example implements this, although the implementation could do with a refresh (it's done with Camera in a scene graph, rather Camera in a Viewer which would be the better way to do it.) Robert. On Mon, Feb 2, 2009 at 10:24 AM, Peter Wraae Marino osgh...@gmail.com wrote: Hi all, At are company we are using huge terrains and have problem with the near plane for our character walking around on the ground. we use the setComputeNearFarMode to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES if we turn it off and set a hardcoded value then this solves the problem for the near plane but gives us a whole new set of problems. is there a way to use the auto computed method but lock the near plane closer to the camera. I have messed around a little with the setNearFarRatio but it seems to adjust at both ends. any suggestions? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ 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] OSX issue with the osgviewer class
HI Davide, In what way is this a problem? It's quite normal for a viewer to wait on barriers, as when you have vsync on the graphics thread will be gated by the refresh of the monitor, with the OpenGL driver just putting the calling thread to sleep while it waits for the next frame. If you switch off vysnc you'll find much high CPU utilization as you then see the frame loop throwing many for frames of data quickly at the OpenGL fifo. Robert. On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Robert Osfield wrote: I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. On Linux the new TF1D seems to work fine indeed (and the setColor() and friends API seems to make more sense). Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Views 1 frame out-of-sync
I have a problem with 2 independent view windows getting out of sync in a multi-channel system. Bear with me while I explain the configuration. My current test system is one machine with 2 nVidia Quadro FX 4600 graphics cards. These cards are genlocked with the GSync2 option card. Each video card renders one half of a video frame which is then combined in the display hardware. My test scene is nothing but a spinning cube with 5 black faces and 1 white face. Each frame the cube is rotated 90 degrees showing 3 frames of black and 1 frame of white. GL is synced to VBLANK with the __GL_SYNC_TO_VBLANK environment variable. The behavior I'm seeing is when the program first starts the top and bottom half are in perfect sync. What is displayed is 3 frames of black and 1 frame of white producing a seizure-enducing strobe effect. However, after a short period of time (5-10 seconds), the bottom half (second video card) is 1 frame behind the top half. Visually you see the top half strobe slightly before the bottom half (verified with light sensors and a scope). The CPU load is very low (extremely simple scene). I am running in SIngleThreaded mode, and the threading mode doesn't seem to effect the problem. I have had this same problem where the two graphics cards were split across two different machines (2 computers, 2 graphics cards, genlocked with gsync2). In the scene, you will see the two halves looking as they should then after a while you'll see the two halves torn by 1 frame, then after a while they appear to re-sync back up (somewhat dependent on scene content). But while they are split, the system still runs at 60Hz so it is not in a constant overload condition. I believe the problem may lie in the rendering pipeline on the graphics card, and I need to figure out how to keep multiple pipelines in sync with each other. Has anyone else had this problem or knows what I can do to address this synchronization problem? Thank you John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, hi Cédric, Please don't take offense of this question, but why don't we simply drop the support for older versions of CMake? As far as I know, 2.6 introduced many improvements. Are there platforms where 2.6+ isn't available? Or is there something I don't know (which may be the most probable answer!)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 12:40:06 +0100, Cedric Pinson morni...@plopbyte.net a écrit: Hi Robert, I use cmake version 2.4-patch 8 Cheers, Cedric Robert Osfield wrote: Hi Cedric, Which version of Cmake are you using? Here's my equivalent of your grep of CMaekCache.txt. Note the entry for X11_Xrandr_LIB. Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB to XRANDR_LIBRARIES would be appropriate. Robert. grep -i xran CMakeCache.txt //Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so X11_Xrandr_INCLUDE_PATH:PATH=/usr/include X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;; GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0 GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0 POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp //Advanced flag for variable: QT_XRANDR_LIBRARY QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL= XRANDR_LIBS_PATHS:INTERNAL= XRANDR_PREFIX:INTERNAL=/usr XRANDR_STATIC_CFLAGS:INTERNAL= XRANDR_STATIC_CFLAGS_I:INTERNAL= XRANDR_STATIC_CFLAGS_OTHER:INTERNAL= XRANDR_STATIC_INCLUDE_DIRS:INTERNAL= XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL= XRANDR_STATIC_LIBDIR:INTERNAL= XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp XRANDR_STATIC_LIBRARY_DIRS:INTERNAL= XRANDR_STATIC_LIBS:INTERNAL= XRANDR_STATIC_LIBS_L:INTERNAL= XRANDR_STATIC_LIBS_OTHER:INTERNAL= XRANDR_STATIC_LIBS_PATHS:INTERNAL= XRANDR_VERSION:INTERNAL=1.2.3 XRANDR_xrandr_INCLUDEDIR:INTERNAL= XRANDR_xrandr_LIBDIR:INTERNAL= XRANDR_xrandr_PREFIX:INTERNAL= XRANDR_xrandr_VERSION:INTERNAL= __pkg_config_checked_XRANDR:INTERNAL=1 On Mon, Feb 2, 2009 at 11:10 AM, Cedric Pinson morni...@plopbyte.net wrote: Hi Robert, It's a bit strange because it detects xrandr and set the flag ON, but does not detect libs, see the output: *morni...@macmornifle ~/dev/osg-trunk/build $ cmake ../ -DCMAKE_BUILD_TYPE=Release *-- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Quick note: build is done, but most warnings are wrappers-related (and seem harmless). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:54:34 +0100, Sukender suky0...@free.fr a écrit: Hi Robert, Second experimental build launched. (SUKENDER1 2009-02-02 on the dashboard, rev 9631, VC8sp1, all inclusive). Maybe you'll have the result before going to sleep (= To all: this is a joke... Robert NEVER sleeps! :D Even kill_and_go_to_bed -9 can't get rid of him!!!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 21:36:03 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender (et. al) On Mon, Feb 2, 2009 at 4:20 PM, Sukender suky0...@free.fr wrote: Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I've now gone through all the 50 warnings reported on Dashbord from your VS build, I have applied fixes for them all. Whether they are fixed or not... we I can't say till you or others do another build. I have checked my changes into svn/trunk. Since the at the end of Dashboard log there the line: The maximum number of reported warnings or errors has been reached!!! I suspect there are more warnings lurking, and even if I fix these 50, more will pop up in their place. How many we'll have to wait an see. Could everyone do another svn update on svn/trunk and build to see how things are now hanging. Posting your results on Dashboard helps me keep track of things. Thanks, 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Serge, On Mon, Feb 2, 2009 at 4:21 PM, Serge Lages serge.la...@gmail.com wrote: Here is a screenshot fo my bug. Ack... two steps forward, one step back... Looks like a bug fix for another stats rendering problem broke this particular combination. I see the problem under Linux as well so can chase it up personally. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Sukender,
just because cmake 2.6 is not tagged stable yet on my distribution.
[I] dev-util/cmake
Available versions: 2.4.6-r1 (~)2.4.7-r1 2.4.8 ~2.6.2 ~2.6.2-r1
{emacs qt4 vim-syntax}
Installed versions: 2.4.8(13:57:21 02/01/09)(emacs -vim-syntax)
Homepage:http://www.cmake.org/
Description: Cross platform Make
It's the only reason, i prefer to keep stuff stable, but if it becomes a
requierement for osg then i will jump to the 2.6
Cheers,
Cedric
Sukender wrote:
Hi Robert, hi Cédric,
Please don't take offense of this question, but why don't we simply drop the
support for older versions of CMake? As far as I know, 2.6 introduced many
improvements. Are there platforms where 2.6+ isn't available? Or is there
something I don't know (which may be the most probable answer!)?
Thanks.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Mon, 02 Feb 2009 12:40:06 +0100, Cedric Pinson morni...@plopbyte.net a
écrit:
Hi Robert,
I use cmake version 2.4-patch 8
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
Which version of Cmake are you using?
Here's my equivalent of your grep of CMaekCache.txt. Note the entry
for X11_Xrandr_LIB.
Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB
to XRANDR_LIBRARIES would be appropriate.
Robert.
grep -i xran CMakeCache.txt
//Set to ON to enable Xrandr support for GraphicsWindowX11.
OSGVIEWER_USE_XRANDR:BOOL=ON
QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so
X11_Xrandr_INCLUDE_PATH:PATH=/usr/include
X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so
osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;;
GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0
GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0
POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp
POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp
//Advanced flag for variable: QT_XRANDR_LIBRARY
QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1
//Advanced flag for variable: X11_Xrandr_INCLUDE_PATH
X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1
//Advanced flag for variable: X11_Xrandr_LIB
X11_Xrandr_LIB-ADVANCED:INTERNAL=1
XRANDR_CFLAGS:INTERNAL=
XRANDR_CFLAGS_I:INTERNAL=
XRANDR_CFLAGS_OTHER:INTERNAL=
XRANDR_FOUND:INTERNAL=1
XRANDR_INCLUDEDIR:INTERNAL=/usr/include
XRANDR_INCLUDE_DIRS:INTERNAL=
XRANDR_LDFLAGS:INTERNAL=-lXrandr
XRANDR_LDFLAGS_OTHER:INTERNAL=
XRANDR_LIBDIR:INTERNAL=/usr/lib
XRANDR_LIBRARIES:INTERNAL=Xrandr
XRANDR_LIBRARY_DIRS:INTERNAL=
XRANDR_LIBS:INTERNAL=
XRANDR_LIBS_L:INTERNAL=
XRANDR_LIBS_OTHER:INTERNAL=
XRANDR_LIBS_PATHS:INTERNAL=
XRANDR_PREFIX:INTERNAL=/usr
XRANDR_STATIC_CFLAGS:INTERNAL=
XRANDR_STATIC_CFLAGS_I:INTERNAL=
XRANDR_STATIC_CFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_INCLUDE_DIRS:INTERNAL=
XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp
XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_LIBDIR:INTERNAL=
XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp
XRANDR_STATIC_LIBRARY_DIRS:INTERNAL=
XRANDR_STATIC_LIBS:INTERNAL=
XRANDR_STATIC_LIBS_L:INTERNAL=
XRANDR_STATIC_LIBS_OTHER:INTERNAL=
XRANDR_STATIC_LIBS_PATHS:INTERNAL=
XRANDR_VERSION:INTERNAL=1.2.3
XRANDR_xrandr_INCLUDEDIR:INTERNAL=
XRANDR_xrandr_LIBDIR:INTERNAL=
XRANDR_xrandr_PREFIX:INTERNAL=
XRANDR_xrandr_VERSION:INTERNAL=
__pkg_config_checked_XRANDR:INTERNAL=1
On Mon, Feb 2, 2009 at 11:10 AM,
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi,
Yes now it compiles fine.
Thank you
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
Does osgViewer now compile if you enable Xrandr?
Robert.
On Mon, Feb 2, 2009 at 12:30 PM, Cedric Pinson morni...@plopbyte.net wrote:
Hi Robert,
here the grep with the new cmakelist.txt. I did a resetup
*morni...@macmornifle ~/dev/osg-trunk/build $ grep -i xran CMakeCache.txt
*//Set to ON to enable Xrandr support for GraphicsWindowX11.
OSGVIEWER_USE_XRANDR:BOOL=ON
Xrandr_LINK_TYPE:STATIC=optimized
Xrandrd_LINK_TYPE:STATIC=debug
osgViewer_LIB_DEPENDS:STATIC=osgGA;osgGAd;osgText;osgTextd;osgDB;osgDBd;osgUtil;osgUtild;osg;osgd;OpenThreads;OpenThreadsd;Xrandr;Xrandrd;/usr/lib/libGLU.so;/usr/lib/libGL.so;-lSM;-lICE;/usr/lib/libX11.so;/usr/lib/libXext.so;;
XRANDR_CFLAGS:INTERNAL=
XRANDR_CFLAGS_I:INTERNAL=
XRANDR_CFLAGS_OTHER:INTERNAL=
XRANDR_FOUND:INTERNAL=1
XRANDR_INCLUDEDIR:INTERNAL=/usr/include
XRANDR_INCLUDE_DIRS:INTERNAL=
XRANDR_LDFLAGS:INTERNAL=-lXrandr
XRANDR_LDFLAGS_OTHER:INTERNAL=
XRANDR_LIBDIR:INTERNAL=/usr/lib
XRANDR_LIBRARIES:INTERNAL=Xrandr
XRANDR_LIBRARY_DIRS:INTERNAL=
XRANDR_LIBS:INTERNAL=
XRANDR_LIBS_L:INTERNAL=
XRANDR_LIBS_OTHER:INTERNAL=
XRANDR_LIBS_PATHS:INTERNAL=
XRANDR_PREFIX:INTERNAL=/usr
XRANDR_STATIC_CFLAGS:INTERNAL=
XRANDR_STATIC_CFLAGS_I:INTERNAL=
XRANDR_STATIC_CFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_INCLUDE_DIRS:INTERNAL=
XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lXau;-lXdmcp
XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_LIBDIR:INTERNAL=
XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;Xau;Xdmcp
XRANDR_STATIC_LIBRARY_DIRS:INTERNAL=
XRANDR_STATIC_LIBS:INTERNAL=
XRANDR_STATIC_LIBS_L:INTERNAL=
XRANDR_STATIC_LIBS_OTHER:INTERNAL=
XRANDR_STATIC_LIBS_PATHS:INTERNAL=
XRANDR_VERSION:INTERNAL=1.2.1
XRANDR_xrandr_INCLUDEDIR:INTERNAL=
XRANDR_xrandr_LIBDIR:INTERNAL=
XRANDR_xrandr_PREFIX:INTERNAL=
XRANDR_xrandr_VERSION:INTERNAL=
__pkg_config_checked_XRANDR:INTERNAL=1
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Mon, Feb 2, 2009 at 11:40 AM, Cedric Pinson morni...@plopbyte.net
wrote:
I use cmake version 2.4-patch 8
OK, this is probably why there is deviation in the CMake generated env
vars. I've just tweaked the relevant src/osgViewer/CMakeLists.txt
part:
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
Attached is the changed file, could you try this out on your machine?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+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] near far plane
Hi all, At are company we are using huge terrains and have problem with the near plane for our character walking around on the ground. we use the setComputeNearFarMode to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES if we turn it off and set a hardcoded value then this solves the problem for the near plane but gives us a whole new set of problems. is there a way to use the auto computed method but lock the near plane closer to the camera. I have messed around a little with the setNearFarRatio but it seems to adjust at both ends. any suggestions? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dashboard suggestion
Le Mon, 02 Feb 2009 13:46:51 +0100, Sukender suky0...@free.fr a écrit: Hi all, I got an tiny idea... I suggest that people building OSG with dashboard reports (Nightly, Continuous, Experimental), use a site name that includes their name on osg-users list (such as blah blah blah - my OSG name), so that it would be easier for Robert (and maybe others) to identify the builders. So, is it possible to set the default value of the CMake variable to something like Machine name - OSG_USER_NAME environment variable, so that we don't have to put it manually each time we clear the CMake cache? Or else, you could simply fill a shared speadsheet with our name and our sites names... (I think I'll do it if the first idea is not trivial to do). See you! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Why did I say a shared spreadsheet??? I was certainly thinking of something else! I mean a wiki page (that'd be enough!). :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Sukender, I apply a pain vs gain to this type of decision. How much pain is it to maintain 2.4.x support vs how much pain it would be to those who'd have to upgrade, and also against how much we have to gain in streamlining our own maintenance work. Right now for Cmake 2.4.x it doesn't seem too difficult to retain support. A similar situation occurred back when we wanted to migrate from supporting VS 6.0 and to now when we've officially dropped support. VS 6.0 became almost impossible to maintain as there wasn't enough active users using VS 6.0 to be able to keep the build running, and given the small numbers of VS 6.0 the pain of removing this support got less over time. At OSG 2.0 we may the decision to officially drop support for VS 6.0. CMake 2.4.x is still quite a long way from this point though. Robert. On Mon, Feb 2, 2009 at 12:38 PM, Sukender suky0...@free.fr wrote: Hi Robert, hi Cédric, Please don't take offense of this question, but why don't we simply drop the support for older versions of CMake? As far as I know, 2.6 introduced many improvements. Are there platforms where 2.6+ isn't available? Or is there something I don't know (which may be the most probable answer!)? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 12:40:06 +0100, Cedric Pinson morni...@plopbyte.net a écrit: Hi Robert, I use cmake version 2.4-patch 8 Cheers, Cedric Robert Osfield wrote: Hi Cedric, Which version of Cmake are you using? Here's my equivalent of your grep of CMaekCache.txt. Note the entry for X11_Xrandr_LIB. Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB to XRANDR_LIBRARIES would be appropriate. Robert. grep -i xran CMakeCache.txt //Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so X11_Xrandr_INCLUDE_PATH:PATH=/usr/include X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;; GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0 GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0 POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp //Advanced flag for variable: QT_XRANDR_LIBRARY QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL= XRANDR_LIBS_PATHS:INTERNAL= XRANDR_PREFIX:INTERNAL=/usr XRANDR_STATIC_CFLAGS:INTERNAL= XRANDR_STATIC_CFLAGS_I:INTERNAL= XRANDR_STATIC_CFLAGS_OTHER:INTERNAL= XRANDR_STATIC_INCLUDE_DIRS:INTERNAL= XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL= XRANDR_STATIC_LIBDIR:INTERNAL=
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Cedric,
Does osgViewer now compile if you enable Xrandr?
Robert.
On Mon, Feb 2, 2009 at 12:30 PM, Cedric Pinson morni...@plopbyte.net wrote:
Hi Robert,
here the grep with the new cmakelist.txt. I did a resetup
*morni...@macmornifle ~/dev/osg-trunk/build $ grep -i xran CMakeCache.txt
*//Set to ON to enable Xrandr support for GraphicsWindowX11.
OSGVIEWER_USE_XRANDR:BOOL=ON
Xrandr_LINK_TYPE:STATIC=optimized
Xrandrd_LINK_TYPE:STATIC=debug
osgViewer_LIB_DEPENDS:STATIC=osgGA;osgGAd;osgText;osgTextd;osgDB;osgDBd;osgUtil;osgUtild;osg;osgd;OpenThreads;OpenThreadsd;Xrandr;Xrandrd;/usr/lib/libGLU.so;/usr/lib/libGL.so;-lSM;-lICE;/usr/lib/libX11.so;/usr/lib/libXext.so;;
XRANDR_CFLAGS:INTERNAL=
XRANDR_CFLAGS_I:INTERNAL=
XRANDR_CFLAGS_OTHER:INTERNAL=
XRANDR_FOUND:INTERNAL=1
XRANDR_INCLUDEDIR:INTERNAL=/usr/include
XRANDR_INCLUDE_DIRS:INTERNAL=
XRANDR_LDFLAGS:INTERNAL=-lXrandr
XRANDR_LDFLAGS_OTHER:INTERNAL=
XRANDR_LIBDIR:INTERNAL=/usr/lib
XRANDR_LIBRARIES:INTERNAL=Xrandr
XRANDR_LIBRARY_DIRS:INTERNAL=
XRANDR_LIBS:INTERNAL=
XRANDR_LIBS_L:INTERNAL=
XRANDR_LIBS_OTHER:INTERNAL=
XRANDR_LIBS_PATHS:INTERNAL=
XRANDR_PREFIX:INTERNAL=/usr
XRANDR_STATIC_CFLAGS:INTERNAL=
XRANDR_STATIC_CFLAGS_I:INTERNAL=
XRANDR_STATIC_CFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_INCLUDE_DIRS:INTERNAL=
XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lXau;-lXdmcp
XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_LIBDIR:INTERNAL=
XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;Xau;Xdmcp
XRANDR_STATIC_LIBRARY_DIRS:INTERNAL=
XRANDR_STATIC_LIBS:INTERNAL=
XRANDR_STATIC_LIBS_L:INTERNAL=
XRANDR_STATIC_LIBS_OTHER:INTERNAL=
XRANDR_STATIC_LIBS_PATHS:INTERNAL=
XRANDR_VERSION:INTERNAL=1.2.1
XRANDR_xrandr_INCLUDEDIR:INTERNAL=
XRANDR_xrandr_LIBDIR:INTERNAL=
XRANDR_xrandr_PREFIX:INTERNAL=
XRANDR_xrandr_VERSION:INTERNAL=
__pkg_config_checked_XRANDR:INTERNAL=1
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Mon, Feb 2, 2009 at 11:40 AM, Cedric Pinson morni...@plopbyte.net
wrote:
I use cmake version 2.4-patch 8
OK, this is probably why there is deviation in the CMake generated env
vars. I've just tweaked the relevant src/osgViewer/CMakeLists.txt
part:
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
Attached is the changed file, could you try this out on your machine?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash errors/warnings
Robert,
This latest CMakeLists.txt file works on my machine.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, February 02, 2009 3:01 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
I'm a bit surpised it didn't work, similar code elsewhere in the OSG
works for other libs, so I can only guess the that directory env var
for XRANDR isn't being set.
To try a fix it I've changed the code to be:
IF (X11_Xrandr_LIB)
SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
ELSE(X11_Xrandr_LIB)
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES}
${LIB_EXTRA_LIBS})
ENDIF(X11_Xrandr_LIB)
The first branch is what was compiling on your machine before I
applied my patch to fix CMake 2.4.8 build, the second branch should
now be picked up for 2.4.8 support.
Could you let me know if this works.
Cheers,
Robert.
On Mon, Feb 2, 2009 at 7:49 PM, Shue, John A john.s...@mantech.com
wrote:
Robert,
The INCLUDE_DIRECTORIES() line didn't fix the error. It added
-I/usr/local/lib to the command lines used to compile the cpp files,
but didn't add the requried -L/usr/local/lib.
Looking at the output of grep Xrandr CMakeCache.txt, I see the
following:
XRANDR_LDFLAGS:INTERNAL=-L/usr/local/lib;-lXrandr
which has both the -L and -l options we need to pass to the linker.
Question is, how does this get added to the linker commandline?
Looking
through osgViewer's CmakeLists.txt file, I don't see any obvious
place.
I got it to link with the following change:
#SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LDFLAGS} ${LIB_EXTRA_LIBS})
I have no idea if this is correct usage.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Robert
Osfield
Sent: Monday, February 02, 2009 12:47 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
Could you try the attached src/osgViewer/CMakeLists.txt. This adds a
:
INCLUDE_DIRECTORIES(${XRANDR_LIBDIR})
Robert.
On Mon, Feb 2, 2009 at 5:24 PM, Shue, John A john.s...@mantech.com
wrote:
Robert,
I haven't read all the messages on the other thread with Cedric, but
I
tried this new CMakeLists.txt and it fails like the original one:
Linking CXX shared library ../../lib/libosgViewer.so
cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/osgViewer.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long
-Wno-import -pedantic -Wreturn-type -Wmissing-braces
-Wunknown-pragmas
-Wunused -fpermissive -O3 -DNDEBUG -shared
-Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9
CMakeFiles/osgViewer.dir/CompositeViewer.o
CMakeFiles/osgViewer.dir/HelpHandler.o
CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o
CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o
CMakeFiles/osgViewer.dir/StatsHandler.o
CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o
CMakeFiles/osgViewer.dir/Viewer.o
CMakeFiles/osgViewer.dir/ViewerBase.o
CMakeFiles/osgViewer.dir/ViewerEventHandlers.o
CMakeFiles/osgViewer.dir/GraphicsWindowX11.o
CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9
../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9
../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9
../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so
/usr/local/lib/libICE.so
/usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us
r/X11R6/lib
/usr/bin/ld: cannot find -lXrandr
gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1
My libXrandr.so is in /usr/local/lib. I don't see a -L option for
/usr/local/lib in the commandline above. Also the end of that
commandline doesn't look right to me, namely
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u
sr/X11R6/lib.
If I add -L/usr/local/lib to the end of the above commandline, it
links.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Robert
Osfield
Sent: Monday, February 02, 2009 7:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A
john.s...@mantech.com
wrote:
That did the trick. Compiled all the way to the end of the build
without
errors.
Turns out that this fix that works for you and me using CMake 2.6.x,
breaks the build with Cmake 2.4.8 so we'll need to try out another
iteration,
Re: [osg-users] CDash errors/warnings
Robert, I haven't read all the messages on the other thread with Cedric, but I tried this new CMakeLists.txt and it fails like the original one: Linking CXX shared library ../../lib/libosgViewer.so cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer /usr/local/bin/cmake -E cmake_link_script CMakeFiles/osgViewer.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused -fpermissive -O3 -DNDEBUG -shared -Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9 CMakeFiles/osgViewer.dir/CompositeViewer.o CMakeFiles/osgViewer.dir/HelpHandler.o CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o CMakeFiles/osgViewer.dir/StatsHandler.o CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o CMakeFiles/osgViewer.dir/Viewer.o CMakeFiles/osgViewer.dir/ViewerBase.o CMakeFiles/osgViewer.dir/ViewerEventHandlers.o CMakeFiles/osgViewer.dir/GraphicsWindowX11.o CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9 ../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9 ../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9 ../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm /usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread -Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us r/X11R6/lib /usr/bin/ld: cannot find -lXrandr gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1 My libXrandr.so is in /usr/local/lib. I don't see a -L option for /usr/local/lib in the commandline above. Also the end of that commandline doesn't look right to me, namely -Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u sr/X11R6/lib. If I add -L/usr/local/lib to the end of the above commandline, it links. -john -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, February 02, 2009 7:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] CDash errors/warnings Hi John, On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com wrote: That did the trick. Compiled all the way to the end of the build without errors. Turns out that this fix that works for you and me using CMake 2.6.x, breaks the build with Cmake 2.4.8 so we'll need to try out another iteration, instead of using the X11_xrand_LIB we'll need to try XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt. Thanks, Robert. This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
Hi guys, Just one more data point: a colleague of mine tested our OSG app in linux last week and also found one of the cores (on his 8 core machine) utilising 100% cpu. After some investigation, this turned out to a call to schedyield on the thread in the gl driver. Posibly you are seeing something similar.. Cheers, Morne On Mon, Feb 2, 2009 at 8:25 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Greate news (or bad news) that means we have not a windows issue. what happens when you switch to singelthreaded ? /adrian 2009/2/1 Simon Loic simon1l...@gmail.com Hi, in my case when I am runing osgviewer on a ubuntu distribution with 4 cores I get 25% of cpu, which means that one of my cores is over used. One of my colleagues have exactly the same behavior. Thus I don't think this is windows related only. On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron gwald...@gmail.com wrote: Adrian, I have observed an intermittent problem on Windows in which osgviewer starts up using a high CPU %, but then cycling through the threading modes with 'm' makes the problem go away - even when you return to the mode in which you started. I never did figure out why. Just a data point... Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Sun, Feb 1, 2009 at 7:45 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi Cory, I am working with Windows Vista dual core system. I get 50% CPU usage when i am running osgviewer cow.osg if i start osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i have about 0.5-3% CPU usage ! i am very busy at the moment, but may tomorrow i will debug the OSG core, may there is a bug inside or a thread running at max. or robert has some idea,where i can start with debugging. may it's a windows vista bug adrian 2009/2/1 Robert Osfield robert.osfi...@gmail.com Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Robert. On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell c...@codeware.com wrote: I'm not sure about vysync. I'll look that up and check it. I thought about the possibility of it being a debug build and I don't think that's it. In my bin directory I have osgviewer.exe at 25,600 bytes and osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU pegging behavior (as observed by SysInternals Process Explorer). My command line is osgviewer.exe --window 100 100 200 200 cessna.osg. My video card is an ATI FireGL V7700 and the drivers are up to date. Ah- I just noticed something-- an error message: Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found, trying GDI. Reason: The specified procedure could not be found. I'm running over remote desktop right now, so perhaps that's related. I don't recall seeing this error message before. Cory On Sat, Jan 31, 2009 at 3:54 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Cory, It's not normal to have this high level of CPU usage for this model, the expceptions to this would be: You have vysync switched off, so the app is racing as fast it can to dispatch frames You've compiled the OSG with debug build. Robert. On Fri, Jan 30, 2009 at 8:36 PM, Cory Riddell c...@codeware.com wrote: When I run the osg viewer app and load just about any osg file (like cesna.osg), my CPU usage is a constant 23% - 30%. This is with no interaction, it is basically using an entire CPU core. Fortunatelly I have a 4 core machine, so it hasn't been a problem so far, but I'm wondering what this means for single core machines (which most of our customers have). Is this typical? Cory ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org
[osg-users] OSX issue with the osgviewer class
Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide, You don't need to dig deep into the internals of the OSG. The differences are likely high level, non OSG specific. Could please start by specifying how you are doing your tests, what framerates your are getting on each platform, what specific value is making your conclude the performance differences? What types of models and applications are you seeing the difference? What is your hardware setup in Windows + OSX? Robert. On Mon, Feb 2, 2009 at 4:00 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi Robert, thanks for the quick answer. What I feel strange is the different behavior that the standard osgviewer class has on OSX and Win32. I mean, if the reason is the vsync, in win32 it is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms. If I check the osgviewerGLUT example, the behavior looks almost identical in both osx and win32. Is there a way to disable the vsync check in a plain osgviewer application? I'm sorry if I'm asking stupid questions, I'm not so deep into the OSG architecture yet... :) thanks again, Davide (I reposted this mail using the correct subject, sorry) HI Davide, In what way is this a problem? It's quite normal for a viewer to wait on barriers, as when you have vsync on the graphics thread will be gated by the refresh of the monitor, with the OpenGL driver just putting the calling thread to sleep while it waits for the next frame. If you switch off vysnc you'll find much high CPU utilization as you then see the frame loop throwing many for frames of data quickly at the OpenGL fifo. Robert. On Mon, Feb 2, 2009 at 1:42 PM, Davide Bacchet davide.bacc...@gmail.com wrote: Hi to everybody, I'm having a problem under OSX with the osgviewer implementation. The application is using only 5 to 10% of the processor power, because the most part of the time it is waiting on a mutex inside the osgViewer::ViewerBase::renderingTraversals() call. Exactly the same code (I'm creating a multi-platform application) under windows works like a charm; I can't try under linux. My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. Actually I'm using osg 2.4.0, but I tried with the version 2.6.0 too and there is the same problem. Attached the call graph, with the number of milliseconds spent on each function call (out of a total time of 3 sec). As you can see, the renderingTraversal call performs 2 sub-calls: OpenThreads::Condition::wait(...) and osgViewer::Renderer::cull(), but it waits for a huge amount of time (more than 95%). Call graph: 2091 Thread_2503 2091 start 2091 main 2091 simpleGraphicsLoop() 2089 graphics::GraphicsManager::update() 2075 osgViewer::ViewerBase::renderingTraversals() 2049 OpenThreads::Condition::wait(OpenThreads::Mutex*) 2049 pthread_cond_wait 2049 _pthread_cond_wait 2041 semaphore_wait_signal_trap 2041 semaphore_wait_signal_trap 8 _pthread_cond_wait 24 osgViewer::Renderer::cull() 17 osgUtil::SceneView::cull() It's easy to reproduce the problem with the standard osgviewer example distributed with the library. Does somebody encountered the same problem and, hopefully, solved it in some way? or there is some workarounds? or maybe I'm making some stupid mistake... Thanks! Davide Bacchet ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Alright... Strange thing it took 40 minutes on my machine (which is faster than your laptop, and I had a few *.cpp already compiled). Or maybe you disable compiling wrappers, examples, applications, plugins or such (I do compile them all)? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 17:25:22 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 17:20 +0100, Sukender wrote: Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... I have two machines: a laptop (Dell M90 with Core2Duo 1.6Ghz) and a desktop (QuadCore 2.6Ghz). It takes about 20 minutes to build from scratch on my laptop (no including the introspection stuff) and about 5 minutes on my desktop. The laptop runs Fedora 10 and the desktop Vista 64. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... 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 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] OSG 2.7.9 - Crash in destroying ShadowedScene
Hi Robert,
I tried but failed to reproduce the problem in the osg examples. It
must be some subtle difference in the way I set up my scene in my app.
I changed my viewer to the QOSGWidget implementation instead of using
the GraphicsWindowEmbedded in a QGLWidget and that fixed the crash.
Sorry I couldn't reproduce it, but at least there is a work around if
others run into this issue.
Cheers,
Morne
On Fri, Jan 30, 2009 at 4:59 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Hi Morne,
Can you get osgshadow to crash? If others can redproduce this problem
there the chances of fixing it promptly go up.
Robert.
On Fri, Jan 30, 2009 at 4:33 PM, Morné Pistorius
mpistorius@googlemail.com wrote:
Hi guys,
I am testing the current trunk version of OSG in my application (was
previously using v2.6.1) and I get a crash on shutdown when trying to
destroy a osgShadow::ShadowedScene. This only occurs when I have a
shadowTechnique set and is caused by destroying the shader program. I
am using OSG in Qt derived from a QGLWidget (yes I know I should
rather use the QWidget implementation, I am busy porting to that, but
this used to work fine in 2.6.1 so I thought I would flag it :)
I will see if this still happens when not using the GL Adapterwidget,
and report back.
Below is a stack trace of the relevant bits:
osg54-osg.dll!osg::Referenced::~Referenced() Line 262 + 0x5 bytes
C++
osg54-osg.dll!osg::Program::PerContextProgram::~PerContextProgram()
Line 425 + 0x14b bytes C++
osg54-osg.dll!osg::Program::PerContextProgram::`vector deleting
destructor'() + 0x3d bytes C++
osg54-osg.dll!std::_Destroy_rangeosg::ref_ptrosg::Program::PerContextProgram,std::allocatorosg::ref_ptrosg::Program::PerContextProgram
(osg::ref_ptrosg::Program::PerContextProgram * _First=0x02eb7b48,
osg::ref_ptrosg::Program::PerContextProgram * _Last=0x02eb7b50,
std::allocatorosg::ref_ptrosg::Program::PerContextProgram
_Al={...}, std::_Nonscalar_ptr_iterator_tag __formal={...}) Line 235
+ 0x30 bytesC++
osg54-osg.dll!osg::Program::~Program() Line 122 + 0xa8 bytes C++
osg54-osgShadow.dll!osg::Program::`scalar deleting destructor'() +
0x9 bytes C++
osg54-osg.dll!std::_Treestd::_Tmap_traitsstd::pairenum
osg::StateAttribute::Type,unsigned
int,std::pairosg::ref_ptrosg::StateAttribute,unsigned
int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum
osg::StateAttribute::Type,unsigned int const
,std::pairosg::ref_ptrosg::StateAttribute,unsigned int ,0
::_Erase(std::_Tree_nodstd::_Tmap_traitsstd::pairenum
osg::StateAttribute::Type,unsigned
int,std::pairosg::ref_ptrosg::StateAttribute,unsigned
int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum
osg::StateAttribute::Type,unsigned int const
,std::pairosg::ref_ptrosg::StateAttribute,unsigned int ,0
::_Node * _Rootnode=0x02eb7bf8) Line 1078 C++
osg54-osg.dll!osg::StateSet::clear() Line 556 + 0x26 bytes C++
osg54-osg.dll!osg::StateSet::~StateSet() Line 173 C++
osg54-osgShadow.dll!osg::StateSet::`scalar deleting destructor'() +
0x9 bytes C++
osg54-osg.dll!osg::Referenced::unref() Line 176 + 0xf bytesC++
osg54-osgShadow.dll!osgShadow::ShadowMap::~ShadowMap() Line 91 +
0xfb bytes C++
osg54-osgShadow.dll!osgShadow::SoftShadowMap::~SoftShadowMap() Line
73 + 0x7e bytes C++
RiverTestApp.exe!osgShadow::SoftShadowMap::`scalar deleting
destructor'() + 0x10 bytes C++
osg54-osg.dll!osg::Referenced::unref() Line 176 + 0xf bytesC++
osg54-osgShadow.dll!osgShadow::ShadowedScene::setShadowTechnique(osgShadow::ShadowTechnique
* technique=0x) Line 76C++
osg54-osgShadow.dll!osgShadow::ShadowedScene::~ShadowedScene() Line
50 C++
RiverTestApp.exe!VOSGShadowedScene::~VOSGShadowedScene() + 0x10
bytes C++
RiverTestApp.exe!VOSGShadowedScene::`scalar deleting destructor'()
+ 0xf bytes C++
osg54-osg.dll!std::_Destroy_rangeosg::ref_ptrosg::Node,std::allocatorosg::ref_ptrosg::Node
(osg::ref_ptrosg::Node * _First=0x02e74f50,
osg::ref_ptrosg::Node * _Last=0x02e74f5c,
std::allocatorosg::ref_ptrosg::Node _Al={...},
std::_Nonscalar_ptr_iterator_tag __formal={...}) Line 235 + 0x30
bytes C++
osg54-osg.dll!osg::Group::~Group() Line 53 + 0x26 bytesC++
RiverTestApp.exe!VOSGScene::~VOSGScene() Line 25 + 0x19 bytes C++
RiverTestApp.exe!VRiver3DScene::~VRiver3DScene() Line 103 + 0x21
bytes C++
RiverTestApp.exe!VRiver3DScene::`scalar deleting destructor'() +
0xf bytes C++
osg54-osg.dll!osg::Referenced::unref() Line 176 + 0xf bytesC++
RiverTestApp.exe!osg::ref_ptrVOSGScene::~ref_ptrVOSGScene()
Line 33 + 0x1a bytesC++
Cheers,
Morne
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
On Mon, 2009-02-02 at 17:32 +, Robert Osfield wrote: HI Jeremy, On Mon, Feb 2, 2009 at 5:19 PM, Jeremy Moles jer...@emperorlinux.com wrote: The only MAJOR one I'm getting anymore is this: In copy constructor 'osgViewer::InteractiveImageHandler::InteractiveImageHandler(const osgViewer::InteractiveImageHandler, const osg::CopyOp)': /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osg::Object' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'class osgGA::GUIEventHandler' should be explicitly initialized in the copy constructor /home/cubicool/sources/svn-OpenSceneGraph/include/osgViewer/ViewerEventHandlers:396: warning: base class 'struct osg::Drawable::CullCallback' should be explicitly initialized in the copy constructor I've just checked in a fix for this. Could you do an svn update and let me know what warnings remain. The warning remains with the latest revision; osg::Object must also be initialized for this warning to go away. Why this is the case, I do not know. I'm using GCC 4.3 building both my software (osgPango/osgCairo/osgWidget) and OSG itself using: -W -Wall -Wno-unused Speaking of Cairo, what did you ever decide to do about that? :) For Cairo I've kept the implementations local in the svg and gecko plugins. Rather than go for an CarioImage subclass class, I opted to have a custom user data object that implements the Cario integration. This allows one to add and then remove the Cario support to any image - it needn't be one subclassed from a Cario base class. For 2.8 I've not rolled this Cario helper class out into osgWidget as it was a another little feature that could cause complication and necessitate wider platform testing/debugging. Once 2.8 is out we can look at the issue of exposing an Cario helper class out into osgWidget or other NodeKit. I still think it's probably be best to keep such a class entirely in the header. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, It's a bit strange because it detects xrandr and set the flag ON, but does not detect libs, see the output: *morni...@macmornifle ~/dev/osg-trunk/build $ cmake ../ -DCMAKE_BUILD_TYPE=Release *-- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- checking for module 'gtk+-2.0' -- found gtk+-2.0, version 2.12.11 -- checking for module 'gtkglext-x11-1.0' -- found gtkglext-x11-1.0, version 1.2.0 -- checking for module 'librsvg-2.0' -- found librsvg-2.0, version 2.22.2 -- checking for module 'cairo' -- found cairo, version 1.6.4 -- checking for module 'poppler-glib' -- found poppler-glib, version 0.8.7 -- Found JPEG: /usr/lib/libjpeg.so -- Found PNG: /usr/lib/libpng.so -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS -- Performing Test _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS - Success -- Performing Test _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS -- Performing Test _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS - Failed -- Performing Test _OPENTHREADS_ATOMIC_USE_SUN -- Performing Test _OPENTHREADS_ATOMIC_USE_SUN - Failed -- Performing Test _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED -- Performing Test _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED - Failed -- Performing Test _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC -- Performing Test _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC - Failed -- Looking for pthread_yield -- Looking for pthread_yield - found -- Looking for pthread_setconcurrency -- Looking for pthread_setconcurrency - found -- Looking for pthread_getconcurrency -- Looking for pthread_getconcurrency - found -- Looking for pthread_setaffinity_np -- Looking for pthread_setaffinity_np - found -- checking for module 'xrandr' -- found xrandr, version 1.2.1 The build system is configured to instal libraries to /usr/local/lib Your applications may not be able to find your installed libraries unless you: set your LD_LIBRARY_PATH (user specific) or update your ld.so configuration (system wide) You have an ld.so.conf file in /etc, if you wish to ensure that applications find the installed osg libraries, system wide, you could add /usr/local/lib to it. -- Configuring done -- Generating done -- Build files have been written to: /home/mornifle/dev/osg-trunk/build morni...@macmornifle ~/dev/osg-trunk/build $ *morni...@macmornifle ~/dev/osg-trunk/build $ grep -i xran CMakeCache.txt *//Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL= XRANDR_LIBS_PATHS:INTERNAL= XRANDR_PREFIX:INTERNAL=/usr XRANDR_STATIC_CFLAGS:INTERNAL= XRANDR_STATIC_CFLAGS_I:INTERNAL= XRANDR_STATIC_CFLAGS_OTHER:INTERNAL= XRANDR_STATIC_INCLUDE_DIRS:INTERNAL= XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lXau;-lXdmcp XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL= XRANDR_STATIC_LIBDIR:INTERNAL= XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;Xau;Xdmcp XRANDR_STATIC_LIBRARY_DIRS:INTERNAL= XRANDR_STATIC_LIBS:INTERNAL= XRANDR_STATIC_LIBS_L:INTERNAL= XRANDR_STATIC_LIBS_OTHER:INTERNAL= XRANDR_STATIC_LIBS_PATHS:INTERNAL= XRANDR_VERSION:INTERNAL=1.2.1 XRANDR_xrandr_INCLUDEDIR:INTERNAL= XRANDR_xrandr_LIBDIR:INTERNAL= XRANDR_xrandr_PREFIX:INTERNAL= XRANDR_xrandr_VERSION:INTERNAL= __pkg_config_checked_XRANDR:INTERNAL=1 Cheers, Cedric Robert Osfield wrote: Hi Cedric, I did make some changes to CMakeLists.txt to fix build problems under FreeBSD that related the Xrandr functionality. Could you check the Cmake variable that have been picked up for X11_Xrandr_LIB, mine points to .usr/lib/libXrandr.so. Robert. On Sun, Feb 1, 2009 at 5:08 PM, Cedric Pinson morni...@plopbyte.net wrote: Hi Robert and all I get the trunk this afternoon, and get a compile issue ./configure
Re: [osg-users] CPU usage
Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Well, using Remote Desktop adds a variable into the mix for sure, so eliminating this and running the app locally would eliminate one possible thing. About one core being pegged, some video drivers implement vsync as a busy wait, which means that the CPU is not really pegged, it just looks like that. If you were to actually run real code on that core, along with OSG, you would see that that code would run at a normal speed because the vsync busy wait would relinquish the CPU while it's waiting for the next frame to start. So my guess is that your ATI drivers are doing this, and what you're seeing is just the idle time between frames being counted as active time by Process Explorer because it's implemented as a busy wait. Of course, I'm speculating here, you'll have to run a real app (not just osgviewer) to see for yourself. Note also that ATI's OpenGL drivers have never been the best... Though they say they're getting better, they have a long way to go. So there might be some of that here. Hope this helps, 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] CDash errors/warnings
Hi John,
Could you try the attached src/osgViewer/CMakeLists.txt. This adds a :
INCLUDE_DIRECTORIES(${XRANDR_LIBDIR})
Robert.
On Mon, Feb 2, 2009 at 5:24 PM, Shue, John A john.s...@mantech.com wrote:
Robert,
I haven't read all the messages on the other thread with Cedric, but I
tried this new CMakeLists.txt and it fails like the original one:
Linking CXX shared library ../../lib/libosgViewer.so
cd /home/jshue/working-OSG/OpenSceneGraph/src/osgViewer
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/osgViewer.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -Wall -Wparentheses -Wformat=2 -Wno-long-long
-Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas
-Wunused -fpermissive -O3 -DNDEBUG -shared
-Wl,-soname,libosgViewer.so.54 -o ../../lib/libosgViewer.so.2.7.9
CMakeFiles/osgViewer.dir/CompositeViewer.o
CMakeFiles/osgViewer.dir/HelpHandler.o
CMakeFiles/osgViewer.dir/Renderer.o CMakeFiles/osgViewer.dir/Scene.o
CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o
CMakeFiles/osgViewer.dir/StatsHandler.o
CMakeFiles/osgViewer.dir/Version.o CMakeFiles/osgViewer.dir/View.o
CMakeFiles/osgViewer.dir/Viewer.o CMakeFiles/osgViewer.dir/ViewerBase.o
CMakeFiles/osgViewer.dir/ViewerEventHandlers.o
CMakeFiles/osgViewer.dir/GraphicsWindowX11.o
CMakeFiles/osgViewer.dir/PixelBufferX11.o ../../lib/libosgGA.so.2.7.9
../../lib/libosgText.so.2.7.9 ../../lib/libosgDB.so.2.7.9
../../lib/libosgUtil.so.2.7.9 ../../lib/libosg.so.2.7.9
../../lib/libOpenThreads.so.2.3.1 -lXrandr -lm /usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
/usr/local/lib/libX11.so /usr/local/lib/libXext.so -lpthread
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/us
r/X11R6/lib
/usr/bin/ld: cannot find -lXrandr
gmake[2]: *** [lib/libosgViewer.so.2.7.9] Error 1
My libXrandr.so is in /usr/local/lib. I don't see a -L option for
/usr/local/lib in the commandline above. Also the end of that
commandline doesn't look right to me, namely
-Wl,-rpath,/home/jshue/working-OSG/OpenSceneGraph/lib:/usr/local/lib:/u
sr/X11R6/lib.
If I add -L/usr/local/lib to the end of the above commandline, it links.
-john
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, February 02, 2009 7:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] CDash errors/warnings
Hi John,
On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com
wrote:
That did the trick. Compiled all the way to the end of the build
without
errors.
Turns out that this fix that works for you and me using CMake 2.6.x,
breaks the build with Cmake 2.4.8 so we'll need to try out another
iteration, instead of using the X11_xrand_LIB we'll need to try
XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt.
Thanks,
Robert.
This communication, along with any attachments, is covered by federal and
state law governing electronic communications and may contain company
proprietary and legally privileged information.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution, use or copying of this message
is strictly prohibited.
If you have received this in error, please reply immediately to the sender
and delete this message. Thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
# FIXME: For OS X, need flag for Framework or dylib
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSGVIEWER_LIBRARY)
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC)
ENDIF(DYNAMIC_OPENSCENEGRAPH)
SET(LIB_NAME osgViewer)
SET(HEADER_PATH ${OpenSceneGraph_SOURCE_DIR}/include/${LIB_NAME})
SET(LIB_PUBLIC_HEADERS
${HEADER_PATH}/CompositeViewer
${HEADER_PATH}/Export
${HEADER_PATH}/GraphicsWindow
${HEADER_PATH}/Renderer
${HEADER_PATH}/Scene
${HEADER_PATH}/Version
${HEADER_PATH}/View
${HEADER_PATH}/Viewer
${HEADER_PATH}/ViewerBase
${HEADER_PATH}/ViewerEventHandlers
)
SET(LIB_COMMON_FILES
CompositeViewer.cpp
HelpHandler.cpp
Renderer.cpp
Scene.cpp
ScreenCaptureHandler.cpp
StatsHandler.cpp
Version.cpp
View.cpp
Viewer.cpp
ViewerBase.cpp
ViewerEventHandlers.cpp
)
SET(LIB_EXTRA_LIBS)
IF(WIN32)
#
# Enable workaround for OpenGL driver issues when used in
multithreaded/multiscreen with NVidia drivers on Windows XP
# For example: osgviewer dumptruck.osg was showing total garbage (screen
looked like shattered, splashed hedgehog)
# There were also serious issues with render to texture cameras.
# Workaround repeats makeCurrentContext call as it was found that this
causes the problems to dissapear.
#
[osg-users] Dashboard suggestion
Hi all, I got an tiny idea... I suggest that people building OSG with dashboard reports (Nightly, Continuous, Experimental), use a site name that includes their name on osg-users list (such as blah blah blah - my OSG name), so that it would be easier for Robert (and maybe others) to identify the builders. So, is it possible to set the default value of the CMake variable to something like Machine name - OSG_USER_NAME environment variable, so that we don't have to put it manually each time we clear the CMake cache? Or else, you could simply fill a shared speadsheet with our name and our sites names... (I think I'll do it if the first idea is not trivial to do). See you! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage
Hi Adrian, Even with --SingleThreaded option one core is used at 100%. Tell me if I should do other tests. On Mon, Feb 2, 2009 at 9:25 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Greate news (or bad news) that means we have not a windows issue. what happens when you switch to singelthreaded ? /adrian 2009/2/1 Simon Loic simon1l...@gmail.com Hi, in my case when I am runing osgviewer on a ubuntu distribution with 4 cores I get 25% of cpu, which means that one of my cores is over used. One of my colleagues have exactly the same behavior. Thus I don't think this is windows related only. On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron gwald...@gmail.com wrote: Adrian, I have observed an intermittent problem on Windows in which osgviewer starts up using a high CPU %, but then cycling through the threading modes with 'm' makes the problem go away - even when you return to the mode in which you started. I never did figure out why. Just a data point... Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Sun, Feb 1, 2009 at 7:45 AM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi Cory, I am working with Windows Vista dual core system. I get 50% CPU usage when i am running osgviewer cow.osg if i start osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i have about 0.5-3% CPU usage ! i am very busy at the moment, but may tomorrow i will debug the OSG core, may there is a bug inside or a thread running at max. or robert has some idea,where i can start with debugging. may it's a windows vista bug adrian 2009/2/1 Robert Osfield robert.osfi...@gmail.com Hi Cory, I'll have to defer to others on the situation under Windows when doing remote desktop. My guess is that it's likely to be a driver issue. Robert. On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell c...@codeware.com wrote: I'm not sure about vysync. I'll look that up and check it. I thought about the possibility of it being a debug build and I don't think that's it. In my bin directory I have osgviewer.exe at 25,600 bytes and osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU pegging behavior (as observed by SysInternals Process Explorer). My command line is osgviewer.exe --window 100 100 200 200 cessna.osg. My video card is an ATI FireGL V7700 and the drivers are up to date. Ah- I just noticed something-- an error message: Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() - wglChoosePixelFormatARB extension not found, trying GDI. Reason: The specified procedure could not be found. I'm running over remote desktop right now, so perhaps that's related. I don't recall seeing this error message before. Cory On Sat, Jan 31, 2009 at 3:54 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Cory, It's not normal to have this high level of CPU usage for this model, the expceptions to this would be: You have vysync switched off, so the app is racing as fast it can to dispatch frames You've compiled the OSG with debug build. Robert. On Fri, Jan 30, 2009 at 8:36 PM, Cory Riddell c...@codeware.com wrote: When I run the osg viewer app and load just about any osg file (like cesna.osg), my CPU usage is a constant 23% - 30%. This is with no interaction, it is basically using an entire CPU core. Fortunatelly I have a 4 core machine, so it hasn't been a problem so far, but I'm wondering what this means for single core machines (which most of our customers have). Is this typical? Cory ___ 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 -- Adrian Egli ___ 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
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Could you specify the command line you are using to reproduce these problems? osgviewerQT --QOSGWidget cow.osg Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. If the window doesn't have any camera's active on it then there is nothing to clear the window, if one enable the clear on the window this issue may well disappear. As for adding views back after they've all been removed should work, but I haven't tested this combination personally. Yup, I have the clearmask enabled for the viewer and it works fine as long as at least one view is still present. But as soon as the last camera is removed, the entire viewer stops working, even if adding new views afterwards. I am trying to reproduce that now in a small example, will send it in a bit. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I successfully built the current trunk on Windows, VS8. Attached are more warnings if you are interested (about 71), they look to be mostly benign. In tests with my app I found some curious behaviour with the QOSGWidget (non-GraphicsWindowEmbedded) implementation. Since moving from the GLWidget approach to this, the throwing functionality of the TrackballManipulator disappeared. This is also visible in the osgViewerQt example - spinning a model works for the GLAdapterWidget, but not for the QOSGWidget. (Oh, and the example hangs when pressing ESC.) Also, I have problems manually adding/removing views from a composite viewer. Adding/removing works fine until I remove the last view and try to add a view to an empty composite viewer. The viewer just shows garbage from the last view visible before it was removed and wont update with any new views added. I will try and reproduce this in the composite viewer example. Cheers, Morne On Mon, Feb 2, 2009 at 3:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Warning 1 warning C4239: nonstandard extension used : 'static_cast' : conversion from 'volatile const long' to 'volatile const unsigned int ' c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\OpenThreads\common\Atomic.cpp 133 Warning 2 warning C4189: 'pd' : local variable is initialized but not referenced c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\OpenThreads\win32\Win32Thread.cpp 139 Warning 3 warning C4512: 'TransformVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\Transform.cpp 89 Warning 4 warning C4512: 'DrawShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 67 Warning 5 warning C4512: 'ComputeBoundShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 1058 Warning 6 warning C4512: 'PrimitiveShapeVisitor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osg\ShapeDrawable.cpp 1328 Warning 7 warning C4701: potentially uninitialized local variable 'p' used c:\p\testlibs\osg\openscenegraph-svn\src\osg\matrixdecomposition.cpp506 Warning 8 warning C4245: '=' : conversion from 'int' to 'unsigned int', signed/unsigned mismatch c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgAnimation\Timeline.cpp 30 Warning 9 warning C4245: '=' : conversion from 'int' to 'unsigned int', signed/unsigned mismatch c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgAnimation\Timeline.cpp 45 Warning 10 warning C4512: 'WriteValue' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgUtil\TriStripVisitor.cpp49 Warning 11 warning C4512: 'RemapArray' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgUtil\TriStripVisitor.cpp166 Warning 12 warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 13 warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 14 warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated C:\Program Files\Microsoft Visual Studio 8\VC\include\list 42 Warning 15 warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required C:\Program
[osg-users] Collada Plugin for Mac OS X...some building problems
I need to build collada plugin for Mac OS X (10.5) but I didn't manage to build it. Actually I did not understand which version of Collada DOM must be used with which OSG's version. In my last try (OSG 2.7.8 + Collada DOM 2.2) I had an error concerning BOOST...it looks like that many collada plugin files try to include boost/filesystem/convenience.hpp but unsuccessfully. Anyway I found it somewhere in the Collada files, so I manually added that path to build the plugin, but the linking failed because collada14dom was not found. Actually the Xcode project for Collada DOM builds just libdom.a (which I choose with Cmake). Am I missing something? Any suggestion? Thank. Alessandro ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert,
here the grep with the new cmakelist.txt. I did a resetup
*morni...@macmornifle ~/dev/osg-trunk/build $ grep -i xran CMakeCache.txt
*//Set to ON to enable Xrandr support for GraphicsWindowX11.
OSGVIEWER_USE_XRANDR:BOOL=ON
Xrandr_LINK_TYPE:STATIC=optimized
Xrandrd_LINK_TYPE:STATIC=debug
osgViewer_LIB_DEPENDS:STATIC=osgGA;osgGAd;osgText;osgTextd;osgDB;osgDBd;osgUtil;osgUtild;osg;osgd;OpenThreads;OpenThreadsd;Xrandr;Xrandrd;/usr/lib/libGLU.so;/usr/lib/libGL.so;-lSM;-lICE;/usr/lib/libX11.so;/usr/lib/libXext.so;;
XRANDR_CFLAGS:INTERNAL=
XRANDR_CFLAGS_I:INTERNAL=
XRANDR_CFLAGS_OTHER:INTERNAL=
XRANDR_FOUND:INTERNAL=1
XRANDR_INCLUDEDIR:INTERNAL=/usr/include
XRANDR_INCLUDE_DIRS:INTERNAL=
XRANDR_LDFLAGS:INTERNAL=-lXrandr
XRANDR_LDFLAGS_OTHER:INTERNAL=
XRANDR_LIBDIR:INTERNAL=/usr/lib
XRANDR_LIBRARIES:INTERNAL=Xrandr
XRANDR_LIBRARY_DIRS:INTERNAL=
XRANDR_LIBS:INTERNAL=
XRANDR_LIBS_L:INTERNAL=
XRANDR_LIBS_OTHER:INTERNAL=
XRANDR_LIBS_PATHS:INTERNAL=
XRANDR_PREFIX:INTERNAL=/usr
XRANDR_STATIC_CFLAGS:INTERNAL=
XRANDR_STATIC_CFLAGS_I:INTERNAL=
XRANDR_STATIC_CFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_INCLUDE_DIRS:INTERNAL=
XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lXau;-lXdmcp
XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL=
XRANDR_STATIC_LIBDIR:INTERNAL=
XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;Xau;Xdmcp
XRANDR_STATIC_LIBRARY_DIRS:INTERNAL=
XRANDR_STATIC_LIBS:INTERNAL=
XRANDR_STATIC_LIBS_L:INTERNAL=
XRANDR_STATIC_LIBS_OTHER:INTERNAL=
XRANDR_STATIC_LIBS_PATHS:INTERNAL=
XRANDR_VERSION:INTERNAL=1.2.1
XRANDR_xrandr_INCLUDEDIR:INTERNAL=
XRANDR_xrandr_LIBDIR:INTERNAL=
XRANDR_xrandr_PREFIX:INTERNAL=
XRANDR_xrandr_VERSION:INTERNAL=
__pkg_config_checked_XRANDR:INTERNAL=1
Cheers,
Cedric
Robert Osfield wrote:
Hi Cedric,
On Mon, Feb 2, 2009 at 11:40 AM, Cedric Pinson morni...@plopbyte.net wrote:
I use cmake version 2.4-patch 8
OK, this is probably why there is deviation in the CMake generated env
vars. I've just tweaked the relevant src/osgViewer/CMakeLists.txt
part:
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
Attached is the changed file, could you try this out on your machine?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
+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
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Jeremy, hi Robert, Robert: Dashboard updated. Jeremy: What kind of machine do you have??? It seems to take ages to compile on my computer (Core2Duo 2.5Ghz)! Or maybe you've compiled just before and there was few to recompile... Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 02 Feb 2009 16:56:06 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: On Mon, 2009-02-02 at 15:01 +, Robert Osfield wrote: Hi All, I've now finished all the merges/bug/features fixes that is required for OpenSceneGraph-2.8 branch. I had to do a few more changes since 2.7.9 than I would have liked due to resolve usage problems associated with the osg::TransferFunction1D class. TransferFunction1D has had to be refactored in API and implementation. I've done testing here at it looks to be running fine (now with .osg support that was missing in 2.7.9) but as I don't have Windows and other platforms I can't test the build there, so pretty please could people do an svn update and let me know how you get on. In prep for the branch I've now updated the version and so numbers so we now have: OpenThreads-2.4.0, SO version 11 OpenSceneGraph-2.8.0, SO version 55 I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. I'm still getting a good deal of warnings (the same from my previous submission); in particular, the one from InteractiveImageHandler in ViewerEventHandlers. On my own system I'm having to fix that every time so that I can use warnings in my code... 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Robert, I use cmake version 2.4-patch 8 Cheers, Cedric Robert Osfield wrote: Hi Cedric, Which version of Cmake are you using? Here's my equivalent of your grep of CMaekCache.txt. Note the entry for X11_Xrandr_LIB. Perhaps change src/osgViewer/CMakeLists.txt from using X11_Xrandr_LIB to XRANDR_LIBRARIES would be appropriate. Robert. grep -i xran CMakeCache.txt //Set to ON to enable Xrandr support for GraphicsWindowX11. OSGVIEWER_USE_XRANDR:BOOL=ON QT_XRANDR_LIBRARY:FILEPATH=/usr/lib/libXrandr.so X11_Xrandr_INCLUDE_PATH:PATH=/usr/include X11_Xrandr_LIB:FILEPATH=/usr/lib/libXrandr.so osgViewer_LIB_DEPENDS:STATIC=general;osgGA;general;osgText;general;osgDB;general;osgUtil;general;osg;general;OpenThreads;general;/usr/lib/libXrandr.so;general;/usr/lib/libGLU.so;general;/usr/lib/libGL.so;general;/usr/lib/libSM.so;general;/usr/lib/libICE.so;general;/usr/lib/libX11.so;general;/usr/lib/libXext.so;general;; GTK_STATIC_LDFLAGS:INTERNAL=-lgtk-x11-2.0;-lgdk-x11-2.0;-latk-1.0;-lpangoft2-1.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lcairo;-lm;-lpixman-1;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp;-lpango-1.0;-lfontconfig;-lexpat;-lfreetype;-lz;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0 GTK_STATIC_LIBRARIES:INTERNAL=gtk-x11-2.0;gdk-x11-2.0;atk-1.0;pangoft2-1.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;cairo;m;pixman-1;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp;pango-1.0;fontconfig;expat;freetype;z;gobject-2.0;gmodule-2.0;dl;glib-2.0 POPPLER_STATIC_LDFLAGS:INTERNAL=-lpoppler-glib;-lpoppler;-lgdk-x11-2.0;-lXinerama;-lXi;-lXrandr;-lXcursor;-lXcomposite;-lXdamage;-lgdk_pixbuf-2.0;-ltiff;-ljpeg;-lpangocairo-1.0;-lgio-2.0;-lXext;-lXfixes;-lpango-1.0;-lcairo;-lm;-lgobject-2.0;-lgmodule-2.0;-ldl;-lglib-2.0;-lpixman-1;-lfontconfig;-lexpat;-lfreetype;-lz;-lpng12;-lxcb-render-util;-lXrender;-lxcb-render;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp POPPLER_STATIC_LIBRARIES:INTERNAL=poppler-glib;poppler;gdk-x11-2.0;Xinerama;Xi;Xrandr;Xcursor;Xcomposite;Xdamage;gdk_pixbuf-2.0;tiff;jpeg;pangocairo-1.0;gio-2.0;Xext;Xfixes;pango-1.0;cairo;m;gobject-2.0;gmodule-2.0;dl;glib-2.0;pixman-1;fontconfig;expat;freetype;z;png12;xcb-render-util;Xrender;xcb-render;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp //Advanced flag for variable: QT_XRANDR_LIBRARY QT_XRANDR_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_INCLUDE_PATH X11_Xrandr_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xrandr_LIB X11_Xrandr_LIB-ADVANCED:INTERNAL=1 XRANDR_CFLAGS:INTERNAL= XRANDR_CFLAGS_I:INTERNAL= XRANDR_CFLAGS_OTHER:INTERNAL= XRANDR_FOUND:INTERNAL=1 XRANDR_INCLUDEDIR:INTERNAL=/usr/include XRANDR_INCLUDE_DIRS:INTERNAL= XRANDR_LDFLAGS:INTERNAL=-lXrandr XRANDR_LDFLAGS_OTHER:INTERNAL= XRANDR_LIBDIR:INTERNAL=/usr/lib XRANDR_LIBRARIES:INTERNAL=Xrandr XRANDR_LIBRARY_DIRS:INTERNAL= XRANDR_LIBS:INTERNAL= XRANDR_LIBS_L:INTERNAL= XRANDR_LIBS_OTHER:INTERNAL= XRANDR_LIBS_PATHS:INTERNAL= XRANDR_PREFIX:INTERNAL=/usr XRANDR_STATIC_CFLAGS:INTERNAL= XRANDR_STATIC_CFLAGS_I:INTERNAL= XRANDR_STATIC_CFLAGS_OTHER:INTERNAL= XRANDR_STATIC_INCLUDE_DIRS:INTERNAL= XRANDR_STATIC_LDFLAGS:INTERNAL=-lXrandr;-lXext;-lXrender;-lX11;-lpthread;-lxcb-xlib;-lxcb;-lXau;-lXdmcp XRANDR_STATIC_LDFLAGS_OTHER:INTERNAL= XRANDR_STATIC_LIBDIR:INTERNAL= XRANDR_STATIC_LIBRARIES:INTERNAL=Xrandr;Xext;Xrender;X11;pthread;xcb-xlib;xcb;Xau;Xdmcp XRANDR_STATIC_LIBRARY_DIRS:INTERNAL= XRANDR_STATIC_LIBS:INTERNAL= XRANDR_STATIC_LIBS_L:INTERNAL= XRANDR_STATIC_LIBS_OTHER:INTERNAL= XRANDR_STATIC_LIBS_PATHS:INTERNAL= XRANDR_VERSION:INTERNAL=1.2.3 XRANDR_xrandr_INCLUDEDIR:INTERNAL= XRANDR_xrandr_LIBDIR:INTERNAL= XRANDR_xrandr_PREFIX:INTERNAL= XRANDR_xrandr_VERSION:INTERNAL= __pkg_config_checked_XRANDR:INTERNAL=1 On Mon, Feb 2, 2009 at 11:10 AM, Cedric Pinson morni...@plopbyte.net wrote: Hi Robert, It's a bit strange because it detects xrandr and set the flag ON, but does not detect libs, see the output: *morni...@macmornifle ~/dev/osg-trunk/build $ cmake ../ -DCMAKE_BUILD_TYPE=Release *-- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
Hi Cedric,
On Mon, Feb 2, 2009 at 11:40 AM, Cedric Pinson morni...@plopbyte.net wrote:
I use cmake version 2.4-patch 8
OK, this is probably why there is deviation in the CMake generated env
vars. I've just tweaked the relevant src/osgViewer/CMakeLists.txt
part:
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
Attached is the changed file, could you try this out on your machine?
Robert.
# FIXME: For OS X, need flag for Framework or dylib
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSGVIEWER_LIBRARY)
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC)
ENDIF(DYNAMIC_OPENSCENEGRAPH)
SET(LIB_NAME osgViewer)
SET(HEADER_PATH ${OpenSceneGraph_SOURCE_DIR}/include/${LIB_NAME})
SET(LIB_PUBLIC_HEADERS
${HEADER_PATH}/CompositeViewer
${HEADER_PATH}/Export
${HEADER_PATH}/GraphicsWindow
${HEADER_PATH}/Renderer
${HEADER_PATH}/Scene
${HEADER_PATH}/Version
${HEADER_PATH}/View
${HEADER_PATH}/Viewer
${HEADER_PATH}/ViewerBase
${HEADER_PATH}/ViewerEventHandlers
)
SET(LIB_COMMON_FILES
CompositeViewer.cpp
HelpHandler.cpp
Renderer.cpp
Scene.cpp
ScreenCaptureHandler.cpp
StatsHandler.cpp
Version.cpp
View.cpp
Viewer.cpp
ViewerBase.cpp
ViewerEventHandlers.cpp
)
SET(LIB_EXTRA_LIBS)
IF(WIN32)
#
# Enable workaround for OpenGL driver issues when used in
multithreaded/multiscreen with NVidia drivers on Windows XP
# For example: osgviewer dumptruck.osg was showing total garbage (screen
looked like shattered, splashed hedgehog)
# There were also serious issues with render to texture cameras.
# Workaround repeats makeCurrentContext call as it was found that this
causes the problems to dissapear.
#
OPTION(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND Set to ON if
you have NVidia board and drivers earlier than 177.92 ver OFF)
MARK_AS_ADVANCED(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
IF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ADD_DEFINITIONS(-DOSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ENDIF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Win32/GraphicsWindowWin32
${HEADER_PATH}/api/Win32/PixelBufferWin32
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowWin32.cpp
PixelBufferWin32.cpp
)
ELSE(WIN32)
IF(APPLE)
SET(OSG_WINDOWING_SYSTEM Carbon CACHE STRING Windowing system type
for graphics window creation, options Carbon or X11.)
ELSE(APPLE)
SET(OSG_WINDOWING_SYSTEM X11 CACHE STRING Windowing system type for
graphics window creation. options only X11)
ENDIF(APPLE)
IF(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# FIXME: OS X needs selection mechanism for Cocoa, Carbon, X11
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Carbon/GraphicsWindowCarbon
${HEADER_PATH}/api/Carbon/PixelBufferCarbon
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowCarbon.cpp
PixelBufferCarbon.cpp
)
ELSE(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# X11 for everybody else
INCLUDE(FindPkgConfig OPTIONAL)
IF (PKG_CONFIG_FOUND)
PKG_CHECK_MODULES(XRANDR xrandr)
IF (XRANDR_FOUND)
OPTION(OSGVIEWER_USE_XRANDR Set to ON to enable Xrandr support
for GraphicsWindowX11. ON)
ELSE(XRANDR_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF (XRANDR_FOUND)
ELSE(PKG_CONFIG_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF(PKG_CONFIG_FOUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/X11/GraphicsWindowX11
${HEADER_PATH}/api/X11/PixelBufferX11
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowX11.cpp
PixelBufferX11.cpp
)
IF(OSGVIEWER_USE_XRANDR)
ADD_DEFINITIONS(-DOSGVIEWER_USE_XRANDR)
SET(LIB_PRIVATE_HEADERS ${LIB_PRIVATE_HEADERS}
${XRANDR_INCLUDE_DIRS} )
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
ENDIF(OSGVIEWER_USE_XRANDR)
# X11 on Apple requires X11 library plus OpenGL linking hack on Leopard
IF(APPLE)
# Find GL/glx.h
IF(EXISTS ${CMAKE_OSX_SYSROOT}/usr/X11/include/GL/glx.h)
SET(OPENGL_INCLUDE_DIR /usr/X11/include)
SET(OPENGL_LIBRARIES /usr/X11/lib/libGL.dylib)
ELSEIF(EXISTS ${CMAKE_OSX_SYSROOT}/usr/X11R6/include/GL/glx.h)
SET(OPENGL_INCLUDE_DIR /usr/X11R6/include)
SET(OPENGL_LIBRARIES
Re: [osg-users] CDash errors/warnings
Hi John,
On Sat, Jan 31, 2009 at 10:34 PM, Shue, John A john.s...@mantech.com wrote:
That did the trick. Compiled all the way to the end of the build without
errors.
Turns out that this fix that works for you and me using CMake 2.6.x,
breaks the build with Cmake 2.4.8 so we'll need to try out another
iteration, instead of using the X11_xrand_LIB we'll need to try
XRANDR_LIBRARIES var. Could you try the attached CMakeLists.txt.
Thanks,
Robert.
# FIXME: For OS X, need flag for Framework or dylib
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSGVIEWER_LIBRARY)
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC)
ENDIF(DYNAMIC_OPENSCENEGRAPH)
SET(LIB_NAME osgViewer)
SET(HEADER_PATH ${OpenSceneGraph_SOURCE_DIR}/include/${LIB_NAME})
SET(LIB_PUBLIC_HEADERS
${HEADER_PATH}/CompositeViewer
${HEADER_PATH}/Export
${HEADER_PATH}/GraphicsWindow
${HEADER_PATH}/Renderer
${HEADER_PATH}/Scene
${HEADER_PATH}/Version
${HEADER_PATH}/View
${HEADER_PATH}/Viewer
${HEADER_PATH}/ViewerBase
${HEADER_PATH}/ViewerEventHandlers
)
SET(LIB_COMMON_FILES
CompositeViewer.cpp
HelpHandler.cpp
Renderer.cpp
Scene.cpp
ScreenCaptureHandler.cpp
StatsHandler.cpp
Version.cpp
View.cpp
Viewer.cpp
ViewerBase.cpp
ViewerEventHandlers.cpp
)
SET(LIB_EXTRA_LIBS)
IF(WIN32)
#
# Enable workaround for OpenGL driver issues when used in
multithreaded/multiscreen with NVidia drivers on Windows XP
# For example: osgviewer dumptruck.osg was showing total garbage (screen
looked like shattered, splashed hedgehog)
# There were also serious issues with render to texture cameras.
# Workaround repeats makeCurrentContext call as it was found that this
causes the problems to dissapear.
#
OPTION(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND Set to ON if
you have NVidia board and drivers earlier than 177.92 ver OFF)
MARK_AS_ADVANCED(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
IF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ADD_DEFINITIONS(-DOSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ENDIF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Win32/GraphicsWindowWin32
${HEADER_PATH}/api/Win32/PixelBufferWin32
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowWin32.cpp
PixelBufferWin32.cpp
)
ELSE(WIN32)
IF(APPLE)
SET(OSG_WINDOWING_SYSTEM Carbon CACHE STRING Windowing system type
for graphics window creation, options Carbon or X11.)
ELSE(APPLE)
SET(OSG_WINDOWING_SYSTEM X11 CACHE STRING Windowing system type for
graphics window creation. options only X11)
ENDIF(APPLE)
IF(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# FIXME: OS X needs selection mechanism for Cocoa, Carbon, X11
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Carbon/GraphicsWindowCarbon
${HEADER_PATH}/api/Carbon/PixelBufferCarbon
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowCarbon.cpp
PixelBufferCarbon.cpp
)
ELSE(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# X11 for everybody else
INCLUDE(FindPkgConfig OPTIONAL)
IF (PKG_CONFIG_FOUND)
PKG_CHECK_MODULES(XRANDR xrandr)
IF (XRANDR_FOUND)
OPTION(OSGVIEWER_USE_XRANDR Set to ON to enable Xrandr support
for GraphicsWindowX11. ON)
ELSE(XRANDR_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF (XRANDR_FOUND)
ELSE(PKG_CONFIG_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF(PKG_CONFIG_FOUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/X11/GraphicsWindowX11
${HEADER_PATH}/api/X11/PixelBufferX11
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowX11.cpp
PixelBufferX11.cpp
)
IF(OSGVIEWER_USE_XRANDR)
ADD_DEFINITIONS(-DOSGVIEWER_USE_XRANDR)
SET(LIB_PRIVATE_HEADERS ${LIB_PRIVATE_HEADERS}
${XRANDR_INCLUDE_DIRS} )
#SET(LIB_EXTRA_LIBS ${X11_Xrandr_LIB} ${LIB_EXTRA_LIBS})
SET(LIB_EXTRA_LIBS ${XRANDR_LIBRARIES} ${LIB_EXTRA_LIBS})
ENDIF(OSGVIEWER_USE_XRANDR)
# X11 on Apple requires X11 library plus OpenGL linking hack on Leopard
IF(APPLE)
# Find GL/glx.h
IF(EXISTS ${CMAKE_OSX_SYSROOT}/usr/X11/include/GL/glx.h)
SET(OPENGL_INCLUDE_DIR /usr/X11/include)
SET(OPENGL_LIBRARIES /usr/X11/lib/libGL.dylib)
ELSEIF(EXISTS ${CMAKE_OSX_SYSROOT}/usr/X11R6/include/GL/glx.h)
SET(OPENGL_INCLUDE_DIR /usr/X11R6/include)
SET(OPENGL_LIBRARIES /usr/X11R6/lib/libGL.dylib)
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
On Mon, Feb 2, 2009 at 10:36 AM, Paul Melis p...@science.uva.nl wrote: Robert Osfield wrote: Hi Sukender, I apply a pain vs gain to this type of decision. How much pain is it to maintain 2.4.x support vs how much pain it would be to those who'd have to upgrade, and also against how much we have to gain in streamlining our own maintenance work. Right now for Cmake 2.4.x it doesn't seem too difficult to retain support. One reason I like CMake 2.6 more than 2.4 is that it seems to have worked around the stupid and time-consuming relink step that it did when doing make install. When I call make and it finishes I expect to have a fully built set of libraries and executables, not something that isn't directly installable by simply copying files to a destination directory. I'm on a system where only CMake 2.4 is available, btw, but it's hardly any pain to compile and install 2.6 by hand. Unless I'm patching CVS I've actually gotten used to just using the prebuilt binaries on CMake.org's website for i386 Linux. They seem to work fine pretty much anywhere I've tried them. http://www.cmake.org/cmake/resources/software.html http://www.cmake.org/files/v2.6/ -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hi Davide, Quoting Davide Bacchet davide.bacc...@gmail.com: is ignored or handled differently (maybe by the graphics board driver or by the OS itself). The main consequence is that the same application runs 15-20 times slower on OSX, and I cannot use the same code across the platforms. ... My laptop is a Macbook Core2Duo, with an integrated Intel graphics card. That could be your problem right there... especially when you're using lots of textures, shaders(!) and such. What kind of setups are you comparing it against? /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] (no subject)
-- How can i get the staeset of the model i have lodeaded to the openScenegraph I am loading an iv file which has the state set attribute in it i need the current state set attribute does any one know... I am using getStateset but its returning null. Always Keep Smiling! Defeat the defeat before defeat defeats you Regards Sunitha.S.Sunagad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph -2.8 branch, please do last build test of sn v/trunk :-)
Hi Robert, On Monday 02 February 2009 16:01, Robert Osfield wrote: I will now go across the machines I have and test out the build with a fresh checkout. I'll also do testing on an OSX box that I can remotely log into - I'll test just the CMake/Makefile build though, won't be able to test the XCode projects. As of yesterday evening (rev 9622), Solaris, HP-UX and SuSE 9.0 built successfully. Thanks for all your work! 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: Michel Lepert 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
Re: [osg-users] Blender osgAnimation Issue
Cedric, Thanks for taking the time to look into this. I did have a revelation a few days ago that lead me to the same conclusion. Basically I had to go back and assign vertices to the named vgroups. not a big deal once I figured it out I was just going crazy thinking I was doing something completely wrong. I figured the exporter should recognize this but it works perfectly if I do the following: -select a vgroup -select the vertices I want in the group -click the assign button that seemed to fix my issues. Again thanks Cedric for all your help and hard work! -Russ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Do any one know
-- Hi, I am loading an iv file in Osg i need to know the StateSet of the particular node i pick in the iv file loaded on to the osg iv file has its Attributes in itthat is applied to the mode i need the information from it I am getting the picked node information and in turn i need to know the StateSet Atrributes of the current picked node... I am using the Pickednode-getStateSet() i get null each time Is ther any way that i have to set the attributes ON while Loading the mode Please Let me know Regards Sunitha. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Just for the record: I've had several segfaults in OSG's particle code (threading related) since I updated a few days ago. I'll post a backtrace when I run into it again. m. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
