Re: [osg-users] Opaque black shadows since moving to OSG V3.0.1
Hi all, I actually posted about a similar issue 3 days ago, and included screenshots and a cpp file, but my post never made it on to the list. It may have been filtered due to attachments on first post. Anyway, I think there is a general regression in osgShadow from 2.8.3 to 3.0.1. The problem that I was seeing was with SoftShadowMap where the shaded areas are transparent. It is easily reproducible in the osgShadow example by making the SoftShadow technique default, and adding GL_BLEND to the default model 3 stateset. If GL_BLEND is enabled, shadows make the receiver object transparent in the areas where the shadows are projected. I tracked this down to a change in the shader code where shadows values were changed from a vec4 to a float. Using the original shader from 2.8.3 works fine, but the current one is broken. Cheers, Morné On Fri, Dec 2, 2011 at 6:53 PM, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: Hi, Guys, I think I see the reason why Robert commented it. For spotlights ambient factor should be attenuated with distance from light. It would be hard to compute attenuation in frag shader without assistance of vertex shader. I would bet it would be possible but very tricky, though. Anyway, IMHO when that line is commented its worse because such ambient factor is both wrong for directional and spot lights. That issue again proves that there is no silver bullet for shadow technique shaders. Depending on what your app does you may need different set of shaders, if not whole technique. So maybe you guys should consider passing in your own shaders (copied from 2.8 version) to make that look right again... Cheers, Wojtek Lewandowski 2011/12/1 Wojciech Lewandowski w.p.lewandow...@gmail.com Hi, Michael, Well, then I guess addition of gl_FrontLightProduct[0] should be uncomented. And thats a missing piece of the puzzle... SVN Blame shows that Robert commented it in 12737 rev on 29th of July. I guess its time to ask Robert what to do with this. Cheers, WL 2011/12/1 Michael Guerrero mjgue...@nps.edu Hi Wojtek, It certainly did seem as though I completely missed the addition with gl_FrontLightProduct[0].ambient. Unfortunately what happened was that after I copy/pasted it in the message I removed the quotes around it and more importantly the comment characters //. Here is a link to the file in question: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/tags/OpenSceneGraph-3.0.1/src/osgShadow/StandardShadowMap.cpp FYI, that piece of code looks the same on the trunk: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgShadow/StandardShadowMap.cpp -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44170#44170 ___ 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] Build Osg with 64Bit (dependency)
Excellent news! Thank you, that will be really helpful! Regards, Morne On Wed, Feb 24, 2010 at 7:49 PM, Anders Backman ande...@cs.umu.se wrote: I managed to build what I need in 64bit. My take on it was to cmakeify them all. Collada, boost (only libsystem, libfilesystem), (jpeg, png and zlib was alredy cmakified.) There are a few which Im not interested in, including jasper, tiff and a few more. I can certainly pack this into a zip including the bin/lib/include content. I'll see if I get it done tomorrow. Took a while though to get everything to build, which everyone (including the Collada team would open their eyes and spot CMake. /A On Wed, Feb 24, 2010 at 6:41 PM, Luigi Calori l.cal...@cineca.it wrote: Hi, I ' m building a somehow cmaked, static version of the (currently basic) osg dependencies. I' m trying also to make it extensible by keeping patch and compiler options in separate folders. I attach a zip of my current repo: try to build the Assemblies/test2 folder with latest 2.8 cmake. It should work also for win64 i tested with msvc9 32 Hope it helps Luigi Morné Pistorius wrote: Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ 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] Build Osg with 64Bit (dependency)
Hi Anders, How did you get on with this? Were you able to build the third party dependencies for Win64? A third party package, even with just the basic dependencies to build most of OSG, would really be helpful. I was about to start building my own when I found this thread, and hoped you had beat me to it! :) Cheers, Morne On Wed, Feb 10, 2010 at 8:45 AM, Anders Backman ande...@cs.umu.se wrote: Hi all. Looong time no see. Im currently trying to build OSG on 64bit under windows (VS2009). Getting all the dependencies over to 64bit is apain. I did a quick search through forum/mail, and it seems that not many does this. Is there ANYONE with a prebuilt package including Collada (with boost, pcre, libxml), jpeg, png, zlib for 64bit windows? The Cmake:d versions of jpeg, zlib, png was certainly a big help. But before I dig into this, perhaps someone has a prebuilt package? -- /Anders ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc3 tagged, please test
Hi Robert, Built 2.8.0 branch, revision 9716 on Windows, VS 2005 SP1. Everything built fine, 0 errors, 0 warnings. Cheers, Morne On Mon, Feb 9, 2009 at 12:37 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I would like to tag 2.8.0 this afternoon, which means in the next hour or two. I'm basically ready. The code this last week has actually looked pretty stable considering the relatively small number of problems reported. I would have liked more feedback on the niche platforms such as Solaris, IRIX, HP-UX and AIX, but we can't hold back the release indefinitely - we all have other work to get on with. Please shout now if you are about to do some testing and wish to hold the release till you get your results. 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] Please test OSG-2.8 in prep for 2.8.0-rc2
Hi Robert, Just did a fresh build on Windows Vista, VS 2005 SP1. Everything built fine without a single warning! I see nothing unexpected in testing on my application. Good stuff :) Cheers, Morne On Thu, Feb 5, 2009 at 3:31 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I've made several check-in's to OpenSceneGraph-2.8 since rc1, so these all now need testing. Could you please try out the 2.8 in svn and let me know how you get on. I want to know about success + failures. I've also checked in some experimental VS versioning of libs into the svn/trunk version of the OSG, so it's already diverted a bit from OSG-2.8, so a failure on svn/trunk won't necessarily map to problems with OSG-2.8. 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 :-)
Hi Robert, Just built a clean checkout of the 2.8 branch on Windows Vista, Visual Studio 8 SP1. Apart from the std::list warning that we can't do much about, there were 4 left in OSGA_Archive.cpp (below). I tested the build in our app and everything worked as expected. Cheers, Morne warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 727 warning C4512: 'OSGA_Archive::WriteImageFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 737 warning C4512: 'OSGA_Archive::WriteHeightFieldFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 747 warning C4512: 'OSGA_Archive::WriteNodeFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 757 On Wed, Feb 4, 2009 at 1:02 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. 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 (2.8) bugs in osgviewerQt
Hi Robert, J-S, Thanks for the suggestions! I removed the Qt event relay methods and added a dummy view with a zero sized viewport to my viewer. The single context, multiple view tiled viewer now works as expected, adding/removing views and clearing the window as it should. Thanks again for your help!! You saved me a lot of debugging headache :) Regards, Morné PS. Do you want me to submit a modified osgviewerQt example with these fixes/workarounds? On Tue, Feb 3, 2009 at 7:57 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Morné, The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Yep, in my testing what Robert suggests would work since as long as you have at least one view there is no problem. It's removing that last view and then adding others that brings up the problem. Sorry I couldn't find anything more definitive on my end. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert,
I first posted about these problems in the Test 2.8 thread. I still
see two problems in the osgviewerQt example and managed to reproduce
both in the attached modified file.
1. Unable to spin/throw a model using QOSGWidget as a viewer.
2. viewer-addView doesn't work if the composite viewer is empty and
trying to add a new view at runtime.
These problems can be reproduced with the following command line (and
the above modified file):
osgviewerQt cessna.osg --QOSGWidget --CompositeViewer
Apart from this issue, 2.8 works fine in my application.
Thanks for all the effort you put into OSG, it really is an excellent library!
Cheers,
Morne
/* OpenSceneGraph example, osganimate.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#if USE_QT4
#include QtCore/QString
#include QtCore/QTimer
#include QtGui/QKeyEvent
#include QtGui/QApplication
#include QtGui/QtGui
#include QtGui/QWidget
using Qt::WindowFlags;
#else
class QWidget;
#include qtimer.h
#include qgl.h
#include qapplication.h
#define WindowFlags WFlags
#endif
#include osgViewer/Viewer
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgViewer/GraphicsWindow
#include osgViewer/ViewerEventHandlers
#if defined(WIN32) !defined(__CYGWIN__)
#include osgViewer/api/Win32/GraphicsWindowWin32
typedef HWND WindowHandle;
typedef osgViewer::GraphicsWindowWin32::WindowData WindowData;
#elif defined(__APPLE__) // Assume using Carbon on Mac.
#include osgViewer/api/Carbon/GraphicsWindowCarbon
typedef WindowRef WindowHandle;
typedef osgViewer::GraphicsWindowCarbon::WindowData WindowData;
#else // all other unix
#include osgViewer/api/X11/GraphicsWindowX11
typedef Window WindowHandle;
typedef osgViewer::GraphicsWindowX11::WindowData WindowData;
#endif
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgDB/ReadFile
#include iostream
#include sstream
class QOSGWidget : public QWidget
{
public:
QOSGWidget( QWidget * parent = 0, const char * name = 0, WindowFlags f
= 0, bool overrideTraits = false);
virtual ~QOSGWidget() {}
osgViewer::GraphicsWindow* getGraphicsWindow() { return _gw.get(); }
const osgViewer::GraphicsWindow* getGraphicsWindow() const { return
_gw.get(); }
protected:
void init();
void createContext();
virtual void mouseDoubleClickEvent ( QMouseEvent * event );
virtual void closeEvent( QCloseEvent * event );
virtual void destroyEvent( bool destroyWindow = true, bool
destroySubWindows = true);
virtual void resizeEvent( QResizeEvent * event );
virtual void keyPressEvent( QKeyEvent* event );
virtual void keyReleaseEvent( QKeyEvent* event );
virtual void mousePressEvent( QMouseEvent* event );
virtual void mouseReleaseEvent( QMouseEvent* event );
virtual void mouseMoveEvent( QMouseEvent* event );
osg::ref_ptrosgViewer::GraphicsWindow _gw;
bool _overrideTraits;
};
QOSGWidget::QOSGWidget( QWidget * parent, const char * name, WindowFlags f,
bool overrideTraits):
#if USE_QT4
QWidget(parent, f), _overrideTraits (overrideTraits)
#else
QWidget(parent, name, f), _overrideTraits (overrideTraits)
#endif
{
createContext();
#if USE_QT4
setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_NoSystemBackground);
setFocusPolicy(Qt::ClickFocus);
#else
setBackgroundMode(Qt::NoBackground);
#endif
}
void QOSGWidget::createContext()
{
osg::DisplaySettings* ds = osg::DisplaySettings::instance();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-readDISPLAY();
if (traits-displayNum0) traits-displayNum = 0;
traits-windowName = osgViewerQt;
traits-screenNum = 0;
traits-x = x();
traits-y = y();
traits-width = width();
traits-height =
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi J-S,
Thank you so much for the help, much appreciated. I downloaded and
built Qt 4.4.3 today, thinking it might have been a Qt problem, since
I was using an older version than Robert.
I will replace the event methods with your suggestion.
W.r.t the composite viewer, I would really rather use it with multiple
views in single context. In our application, these tiled views could
be very many at once and I think context switching between all of them
would be bad for performance.
Again, I appreciate your help looking into this!
Thanks,
Morné
On Tue, Feb 3, 2009 at 4:21 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi again Morné,
- The trackball manipulator does not throw (since Robert does not see this
we can assume this is a Windows-specific problem, either caused by Qt on
Windows or GraphicsWindowWin32's event handling)
I've found out why this is. Since QOSGWidget uses GraphicsWindowWin32
directly, the graphics window already sends mouse events to the event queue.
So in QOSGWidget::mouse*Event (Press, DoubleClick, Release, Move), you don't
want to call _gw-getEventQueue()-mouseButton*() because then it means that
the same event is sent twice. This has the effect that if two release events
are received by the TrackballManipulator, it stops the throw since the mouse
speed when it gets the second release is 0.
I would still send the events to QWidget though, just to be sure, so I would
replace those methods by:
void QOSGWidget::mousePressEvent( QMouseEvent* event )
{
QWidget::mousePressEvent(event);
}
(or just not override them) and so on for all other event methods. The
actual event will be put in the event queue in
GraphicsWindowWin32::handleNativeWindowingEvent().
In our project, we had run into the same problem, but we resolved it
differently. We subclassed GraphicsWindowWin32 to ignore all events, and
instead add them in the event queue in the overridden QOSGWidget methods. I
don't remember why we did it this way, but I think the above is more
general, in addition to not requiring a subclass.
I'm still looking for the cause/solution to the addView() problem.
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert, On Tue, Feb 3, 2009 at 11:21 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, On Tue, Feb 3, 2009 at 10:50 AM, Morné Pistorius mpistorius@googlemail.com wrote: I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. I've just downloaded and tested your modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. For me at least, the spinning and throwing works for both of the cessna models. What platform and Qt version are you working with? I am on Windows Vista, using Qt 4.3.3. Do you think it is a Qt problem? When trying to debug it, I could rotate the model, but not throw it. TrackballManipulator::IsMouseMoving() always returned false on a mouse button RELEASE event. This only happens for the QOSGWidget though, I can throw it fine using the QGLWidget. 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. How do I reproduce this problem? Sorry, not enough info :) Pressing 'a' will add a view, 'r' will remove it. It works as expected until the last view is removed. Another way to see it is to construct the composite viewer without adding any views at compile time, and then trying to add one pressing 'a' at runtime. 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 think in VS, specifiying something as just unsigned causes the
compiler to read unsigned int.
If you change the line to
return static_castunsigned long const volatile (_value);
I think the warning will disappear.
Cheers,
Morne
On Tue, Feb 3, 2009 at 2:48 PM, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Windows experts,
Here's another Windows warning that I'll like a hand resolving:
2..\common\Atomic.cpp(133) : warning C4239: nonstandard extension
used : 'static_cast' : conversion from 'volatile const long' to
'volatile const unsigned int '
The code is:
Atomic::operator unsigned() const
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
__sync_synchronize();
return _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
MemoryBarrier();
return static_castunsigned const volatile (_value);
Here is line 133, problem line.
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
OSMemoryBarrier();
return static_castunsigned const volatile(_value);
#else
# error This implementation should happen inline in the include file
#endif
}
To me a fix would be to remove the from the static_castunsigned
const volatile as it seems a tad superfluous in this method as it's
returning an unsigned int on the stack anyway.
Thoughts?
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] 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
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 :-)
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] OSG 2.7.9 - Crash in destroying ShadowedScene
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
___
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
And again, attached are warnings on Windows. Down to 66 now... Cheers, Morne On Wed, Jan 28, 2009 at 2:18 PM, Tony Horrobin a.j.horro...@its.leeds.ac.uk wrote: Hi Robert, These are the warnings I get under Linux with latest SVN. -Tony OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:966: warning: comparison of unsigned expression 0 is always false OpenSceneGraph/src/osg/KdTree.cpp:797: warning: base class 'class osg::Referenced' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgUtil/CullVisitor.cpp:104: warning: base class 'class osg::Referenced' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgAnimation/Skeleton:34: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgAnimation/Skeleton:34: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgAnimation/AnimationManagerBase.cpp:60: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgAnimation/Skeleton:34: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgAnimation/Skeleton:34: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgPlugins/curl/ReaderWriterCURL.h:60: warning: base class 'class osg::Referenced' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgAnimation/Skeleton:34: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgViewer/CompositeViewer.cpp:30: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgViewer/View.cpp:156: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgViewer/Viewer.cpp:165: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/src/osgViewer/Viewer.cpp:165: warning: base class 'class osgViewer::ViewerBase' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in the copy constructor OpenSceneGraph/include/osgViewer/ViewerEventHandlers:393: warning: base class 'class osg::Object' should be explicitly initialised in
Re: [osg-users] cant clear background in composite viewer
Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed. Also, the gaps between the views shows garbage. I attached two screenshots showing the problem. Is there something that I could call on the composite viewer to clear the entire window? It could also be a Qt problem, since the composite viewer is derived from QGLWidget. If I resize the window after removing the fourth view, then the background is cleared. I tried calling repaint()/paintGL() on the QtWidget, but that didn't help. I would appreciate pointers from people who have successfully used composite viewers with Qt before. Thanks a lot! Morne ___ 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
Re: [osg-users] cant clear background in composite viewer
Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed. Also, the gaps between the views shows garbage. I attached two screenshots showing the problem. Is there something that I could call on the composite viewer to clear the entire window? It could also be a Qt problem, since the composite viewer is derived from QGLWidget. If I resize the window after removing the fourth view, then the background is cleared. I tried calling repaint()/paintGL() on the QtWidget, but that didn't help. I would appreciate pointers from people who have successfully used
Re: [osg-users] cant clear background in composite viewer
Hi Robert, As I expected, the problem lies with using a GraphicsWindowEmbedded. I was able to reproduce the bug in oagviewerQt by adding viewerWindow-getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); viewerWindow-getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the composite viewer. Attached is the example recreating the bug. Cheers, Morne On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hello again Robert, I modified the osgcompositeviewer example and setClearMask() works as expected when creating a new graphics context with proper traits, etc. I suspect my problem comes from using the graphics context created by osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass to my cameras) in our Qt app. It will take a bit of time to test my theory, because I didn't build OSG with Qt support and need a proper Qt install. I will do this now and see if I can reproduce the error in osgviewerQt. I just thought I would mention it, maybe this hint could shed some light on the problem. Cheers, Morne On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius mpistorius@googlemail.com wrote: Not intentionally, no. I added pCamera-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); to the camera attached to the view just to make sure, but it didn't change anything. It sounds like a bug then, I will try and recreate it in a simple example. Cheers, Morne On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, I'm rather perplexed that it didn't just work. The clear of the graphics context/window should be done before everything else runs, the construction order should have no effect on this as it's a feature hard-wired into GraphicsContext. Is there a chance that you've disabled the clear of the colour and depth buffer for the cameras? Robert. On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius mpistorius@googlemail.com wrote: Hi Robert, Thanks for the info. I had a look at the osgcamera example and changed my code to call getGraphicsWindow()-setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f)); getGraphicsWindow()-setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) in the constructor of my derived osgViewer::CompositeViewer. This clears the viewer to green, but now none of my views show up inside the composite viewer, the whole viewer is just green. When I add a view, it is created like this: osgViewer::View * pView = new osgViewer::View; osg::Camera * pCamera = pView-getCamera(); pCamera-setGraphicsContext( getGraphicsWindow() ); pCamera-setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ; addView( pView ); ...compute viewport dimentions, etc... pCamera-setViewport( new osg::Viewport( Left, Bottom , BestWindowWidth, BestWindowHeight ) ); pCamera-setProjectionMatrixAsPerspective( 30.0f, double( BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 1.0f ); It is as if the call to clear the viewer comes after the call to render the views and I just see the cleared result. Removing the setClearColor/setClearMask in the constructor shows my views again. Is it necessary to create a new GraphicsContexts for the cameras as in the osgcameras example? I tried that, without success, so I guess I must be missing something else. Attached is what I see. Thanks again for the help! Regards, Morne On Mon, Jan 26, 2009 at 4:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, This isn't a bug, rather a limitation of using camera's to clear the background colour of the graphics context. If your camera's don't cover the whole window then you have tell the GraphicsContext to do a clear - something it doesn't do by default for efficiency reasons - as the vast majority of apps have camera's covering the whole graphics context. The osgcamera example has an example of enabling the clear of the GraphicsContext. It's simply a case of doing a window-setClearMask(..) and window-setClearColor(..); Robert. On Mon, Jan 26, 2009 at 4:20 PM, Morné Pistorius mpistorius@googlemail.com wrote: Hi guys, I am having trouble clearing the background on a composite viewer. I have a composite viewer derived from QGLWidget to which I add and remove views dynamically. The viewports are automatically tiled into a number of rows and columns inside the viewer window to make the best use of the available space, with a small gap between each view. My problem is that I can't clear the background of the composite viewer when I add/remove views. For example, if I had 4 views tiled in a 2x2 matrix, and remove one view, I my tiler keeps two views in the top row and 1 in the bottom row with an empty square where the fourth view was. Although the fourth view was removed, I still see some data drawn from the last frame that the removed viewer displayed
[osg-users] Modifying scene graph in event handler is safe, right?
Hi all, I used to work under the rule of thumb to only ever modify my scene using update callbacks, but scanning the lists I found reference saying that modification anywhere outside the viewer.RenderTraversal() is safe. I just want to verify this: directly modifying my scene graph in an eventhandler should be safe, right? And this should still be safe if my scene is shared between multiple views (as in a composite viewer), but not if my scene is shared between more than one viewer window (assuming my viewers are created with a QGLWidget, instead of a QWidget in which case it will be safe again). I call viewer.frame() on a QTimer evnet as in the OSG QtViewer examples. Have I got that right? Thanks! Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Exportable file formats
Thanks all for the info, much appreciated! Regards, Morne On Fri, Jan 9, 2009 at 2:18 AM, Paul Martz pma...@skew-matrix.com wrote: A while back, I posted a submission that tried to programmatically determine which formats were supported, did they support read or write, and did they support the read/writeNode, read/writeImage, read/writeObject, or read/writeHeightfield interface. To query for reading, the code created an empty file in a temp directory with the appropriate extension, then tried to read that file with OSG. It depended on the plugin returning the correct error code: FILE_LOADED or ERROR_READING_FILE (because it was, after all, an empty file) meant it was supported, anything else indicated a lack of support. And it tried to do something similar with writing. Unfortunately, this algorithm didn't work because many plugins contain bugs than cause them to return the incorrect error code. This caused my algorithm to return incorrect results a large percentage of the time. As a result, the submission was rejected. Ultimately, though, Robert did see value in having a way to determine some level of file support, and he coded up the osgconv --formats support. While this lists supported formats, unfortunately it provides no information about whether read or write is supported, or which interface is supported. On the plus side, the current implementation has a mechanism to display information about supported plugin Options; on the minus side, the output is somewhat incomplete, and we're still waiting for members of the community to flesh this out. In summary, the best mechanism available today to determine supported formats is to look at the code. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Morné Pistorius Sent: Thursday, January 08, 2009 3:11 AM To: OpenSceneGraph Users Subject: [osg-users] Exportable file formats Hi guys, I am trying to figure out which of the osg plugins support writing/exporting. Is there a list of supported formats or a way to query osg to find out which plugins support exporting? I will be happy if I can just get a handful - from comments read on the list, I think these are all supported: osg ive obj flt collada (dae) Thanks, Morne ___ 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] Exportable file formats
Hi guys, I am trying to figure out which of the osg plugins support writing/exporting. Is there a list of supported formats or a way to query osg to find out which plugins support exporting? I will be happy if I can just get a handful - from comments read on the list, I think these are all supported: osg ive obj flt collada (dae) Thanks, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem applying MatrixTransform to PositionAttitudeTransform
Hi all,
I am hitting my head against a brick wall with this one. I am trying
to use osgManipulators to edit nodes in my scene. I attach a node to
a manipulator, rotate it, and then detach the node from the
manipulator and apply the manipulator's MatrixTransform to the node's
PositionAttitudeTransform (all nodes that I manipulate have a PAT as
root) so that the PAT affects its children in the same way that the
osgManipulator affected its children. Here is the code snippet:
NodeUpdateCallback that updates node with osgManipulator's MatrixTransform:
virtual void operator() ( osg::Node* node, osg::NodeVisitor* nv )
{
osgManipulator::Selection * pSelection = dynamic_cast
osgManipulator::Selection * ( node );
if ( pSelection m_Manip-m_PrevMatrix !=
m_Manip-m_Dragger-getMatrix() )
{
// Apply the transform
for ( int i = 0; i m_Manip-m_SelectionCache-getNumChildren(); ++i )
{
osg::PositionAttitudeTransform * pElem = dynamic_cast
osg::PositionAttitudeTransform * ( pSelection -getChild(i) );
VOSGSceneElement * pElemCache = dynamic_cast VOSGSceneElement
* ( m_Manip-m_SelectionCache-getChild(i) );
osg::Matrix ManipMatrix = pSelection-getMatrix();
ManipMatrix.preMult(osg::Matrix::translate( -pElem-getPivotPoint() )*
osg::Matrix::scale( pElem-getScale() )*
osg::Matrix::rotate( pElem-getAttitude() )*
osg::Matrix::translate( pElem-getPosition() ) );
pElemCache-setPosition( ManipMatrix.getTrans() );
pElemCache-setAttitude( ManipMatrix.getRotate() );
pElemCache-setScale( ManipMatrix.getScale() );
}
m_Manip-m_PrevMatrix = m_Manip-m_Dragger-getMatrix();
}
}
In this example a VOSGSceneElement is the node that I'm trying to
manipulate and is derived from PositionAttitudeTransform. pSelection
contains a copy of this. The copy in pSelection is transformed
correctly by the manipulator. In this update callback, I'm trying to
apply the same transform from pSelection to the VOSGSceneElement in
the scene graph.
Unfortunately this doesn't work properly, and I'm having difficulty
figuring out how to apply the correct transformation. I would be very
grateful if anybody can point me in the right direction..How do I
apply a MatrixTransform to a PositionAttitudeTransform?
As always, thank you!
Morne
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem applying MatrixTransform to PositionAttitudeTransform
Replying to myself, but I found the solution if anybody else might run
into this. Calling getRotate() on the matrix can give unexpected
results if there was also a scale transform involved. The correct way
is to call Matrix.decompose(..) to get to the contributing parts:
ManipMatrix.preMult(osg::Matrix::translate( -pElem-getPivotPoint() )*
osg::Matrix::scale( pElem-getScale() )*
osg::Matrix::rotate( pElem-getAttitude() )*
osg::Matrix::translate( pElem-getPosition() ) );
osg::Vec3 s,t;
osg::Quat r,so;
ManipMatrix.decompose( t, r, s, so );
pElemCache-setPosition( t );
pElemCache-setAttitude( r );
pElemCache-setScale( s );
Cheers,
Morne
On Fri, Dec 5, 2008 at 1:08 PM, Morné Pistorius
[EMAIL PROTECTED] wrote:
Hi all,
I am hitting my head against a brick wall with this one. I am trying
to use osgManipulators to edit nodes in my scene. I attach a node to
a manipulator, rotate it, and then detach the node from the
manipulator and apply the manipulator's MatrixTransform to the node's
PositionAttitudeTransform (all nodes that I manipulate have a PAT as
root) so that the PAT affects its children in the same way that the
osgManipulator affected its children. Here is the code snippet:
NodeUpdateCallback that updates node with osgManipulator's MatrixTransform:
virtual void operator() ( osg::Node* node, osg::NodeVisitor* nv )
{
osgManipulator::Selection * pSelection = dynamic_cast
osgManipulator::Selection * ( node );
if ( pSelection m_Manip-m_PrevMatrix !=
m_Manip-m_Dragger-getMatrix() )
{
// Apply the transform
for ( int i = 0; i m_Manip-m_SelectionCache-getNumChildren(); ++i )
{
osg::PositionAttitudeTransform * pElem = dynamic_cast
osg::PositionAttitudeTransform * ( pSelection -getChild(i) );
VOSGSceneElement * pElemCache = dynamic_cast VOSGSceneElement
* ( m_Manip-m_SelectionCache-getChild(i) );
osg::Matrix ManipMatrix = pSelection-getMatrix();
ManipMatrix.preMult(osg::Matrix::translate( -pElem-getPivotPoint() )*
osg::Matrix::scale( pElem-getScale() )*
osg::Matrix::rotate( pElem-getAttitude() )*
osg::Matrix::translate( pElem-getPosition() ) );
pElemCache-setPosition( ManipMatrix.getTrans() );
pElemCache-setAttitude( ManipMatrix.getRotate() );
pElemCache-setScale( ManipMatrix.getScale() );
}
m_Manip-m_PrevMatrix = m_Manip-m_Dragger-getMatrix();
}
}
In this example a VOSGSceneElement is the node that I'm trying to
manipulate and is derived from PositionAttitudeTransform. pSelection
contains a copy of this. The copy in pSelection is transformed
correctly by the manipulator. In this update callback, I'm trying to
apply the same transform from pSelection to the VOSGSceneElement in
the scene graph.
Unfortunately this doesn't work properly, and I'm having difficulty
figuring out how to apply the correct transformation. I would be very
grateful if anybody can point me in the right direction..How do I
apply a MatrixTransform to a PositionAttitudeTransform?
As always, thank you!
Morne
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem applying MatrixTransform to PositionAttitudeTransform
Hi J-S, Yup, the documentation certainly helped. In this case I blame automatic code completion and bad assumptions. I thought there would be something in osg::Matrix that would return the individual composing parts and autocomplete suggested getRotate() when I typed in 'get'. I just assumed that is the right thing to use, without actually going to check the documentation. My bad :) Cheers, Morné On Fri, Dec 5, 2008 at 2:44 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Morné, Calling getRotate() on the matrix can give unexpected results if there was also a scale transform involved. The correct way is to call Matrix.decompose(..) to get to the contributing parts: I was going to point that out, and it's even in the osg::Matrix header doc comments for getRotate() I think... Just looked it up, and yes: _ Quat osg::Matrixd::getRotate() const Get the matrix rotation as a Quat. Note that this function assumes a non-scaled matrix and will return incorrect results for scaled matrixces. Consider decompose() instead. _ Good to see you found it yourself. It means the doxygen comments really do work! We should add more of them (darn don't tell me I started the documentation discussion again...) :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Outline technique that doesn't triple (or worse) my frame time?
Hi J-S, Just as another datapoint, I also implemented outlining in a similar way to osgFX::Effect. All times stay the same except draw which triples. In my application, this doesn't affect me too much and I still make 60 fps if an object is selected or not, so I don't mind the jump that much, but I can see it being a problem if you have a very flexible scene/selection strategy... Cheers, Morne On Wed, Nov 26, 2008 at 2:40 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, I presume that you won't be selecting too many objects in the scene, so it's not like you'll be doubling the cost of the whole scene, and if there is only one object in the scene that you select you are unlikely to be breaking frame... Well, that assumption is one I can't make... Since this is an application similar to a modeling application, the user could load anything up. And yes, we support multi-select, so the user could conceivably select the whole scene. Now, of course if the user loads objects which bring their system to a crawl, I can't do anything to prevent that. However, if they load up objects and the app just barely make frame, and then selects one of them and it suddenly breaks frame, it makes our app look bad. It's a contrived example, but it could really happen. And that's supposing they only select that one object - they could select them all, and then the total frame time might triple (I haven't tested this, but my results with multiple objects seem to indicate that would be the result). Anyways, the more general question: why is the frame time so affected by such a simple effect? As I said, it's a two-pass effect, I would expect the time for the selected object(s) to double, but not more... And I disable lighting, blending, texturing for the second pass, so I would think that pass would be quicker than the first. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Understanding node/traversal masks
Hi guys, I have a scene setup problem that I am sure is easy to solve with OSG if someone could help me properly understand the use of node masks. Consider this scene: Root /\ / \ __/ \__ /\ DecorateGroupRenderGroup \ | \ /\ \ ___/ \ \/\ \___ PAT Subgraph with more objects /\ / \ GeodeA GeodeB I have a group of objects that I want to render, all children of the RenderGroup. Some of these objects I want to decorate by drawing the same geometry with a different stateset that enables cartoon outlines when I pick it. Now I want to add a subgraph to this decoration, but I only want to allow some of the nodes within the subgraph to be affected by the stateset in DecorateGroup. For example, if I attach PositionAttitudeTransform PAT to DecorateGroup, I only want GeodeA to be decorated. I think one way would be to protect attributes that are overridden by the stateset in DecorateGroup, but I don't want to have to do that for all objects that might be picked. I expect this can be done with node masks, but I am not sure how to set up a node mask so that GeodeB is drawn only once when RenderGroup is traversed and not drawn when DecorateGroup is traversed. I would be really grateful if someone could explain this to me. Thanks! Morne Pistorius ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bump mapping using GLSL shaders
://3dshaders.com/ Hope it helps. -- A. On Mon, Nov 24, 2008 at 10:39 AM, Morné Pistorius [EMAIL PROTECTED] wrote: Hi all, I added bump mapping to a model using osgFX::BumpMapping, but I need something more flexible. My model has two sided lighting and osgFX doesn't support that. Do we have GLSL shaders for bumpmapping in OSG? I think that would be easier to modify to suit my needs than the assembler coded shaders used in osgFX. If anyone has an example of applying normal mapping with shaders in OSG, I would greatly appreciate it. Thank you kindly, Morne ___ 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 bumpmap.frag Description: Binary data bumpmap.vert Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bump mapping using GLSL shaders
Hi all, I added bump mapping to a model using osgFX::BumpMapping, but I need something more flexible. My model has two sided lighting and osgFX doesn't support that. Do we have GLSL shaders for bumpmapping in OSG? I think that would be easier to modify to suit my needs than the assembler coded shaders used in osgFX. If anyone has an example of applying normal mapping with shaders in OSG, I would greatly appreciate it. Thank you kindly, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Wrong vertex count when loading OBJ files.
Hi guys, I see a strange problem when I load OBJ files. I use osg::readfilenode() to load an .obj with a known number of vertices, and then inspect the resulting node to see how many vertices was loaded, like so: //debug osg::Node* node = osgDB::readNodeFile( C:/Data/Meshes/Hand3DIS/Hand3.obj ); osg::Geode* g = dynamic_cast osg::Geode* ( node-asGroup()-getChild(0) ); osg::Geometry * gm = g-getDrawable(0)-asGeometry(); osg::Vec3Array * v = (osg::Vec3Array*) gm-getVertexArray(); std::cout verts: v-size() std::endl; I know my model has 7570 vertices (I inspected the contents of the file, and this is also reported by other obj loaders I tried). but when osg loads this file, it reports 'verts: 8369' in the code above. I need a one to one mapping between osg's vertices and the ones specified in the obj file. Does osg somehow try to automatically optimise the geometry when it is loaded, i.e create triangle strips, etc. Funny thing though, when I subsequently save the node to .obj using osg, it saves it with the correct no of vertices. Any ideas? Thanks, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug? Unable to pick osgSim::SphereSegment
Hi all,
I seem to be unable to pick a osgSim::SphereSegment using a
LineSegmentIntersector. I have many other models in my scene as well that
all work fine with the picker, including loaded models and manually
assembled geometries. It is just the SphereSegment that doesn't respond.
When I click on it, picker-containsIntersections() always returns false:
osgUtil::LineSegmentIntersector* picker;
picker = new osgUtil::LineSegmentIntersector(
osgUtil::Intersector::PROJECTION, ea.getXnormalized(),ea.getYnormalized() );
osgUtil::IntersectionVisitor iv( picker );
viewer-getCamera()-accept( iv );
if ( picker-containsIntersections() ) -- ALWAYS FALSE
{
osgUtil::LineSegmentIntersector::Intersection intersection =
picker-getFirstIntersection();
osg::NodePath nodePath = intersection.nodePath;
node = ( nodePath.size() = 1 )? nodePath[ nodePath.size() - 1 ] : NULL;
}
I will investigate this further, but I was hoping someone might have some
insights as to where to look for what goes wrong. Is this a bug or is it
something specific to SphereSegments? (I am using OSG v2.2)
Thanks!
Morne
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader or effect to show selected model
Hi guys, Thanks for the tips. In case anybody else reading this thread might find it useful, I found a nice subtle way of highlighting a selected model (see attached screen shot). Using the stateset decorating method from the scribe example and outlining code from the cartoon effect in osgfx, I draw thick line around the silhouette of the selected model. This nicely conveys the message that the model is selected without obscuring the geometry too much. Thanks again, Morne On Tue, Aug 12, 2008 at 1:52 PM, Fuesz, Matthew [EMAIL PROTECTED] wrote: Color overlays are fairly simple. A one-line fragment shader: gl_FragColor = gl_Color * color_uniform; Where color_uniform is a vec4 uniform specifying RGBA color. This is the simplest of cases, of course. If you have other lighting or texturing going on, you would also need to account for that. Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morné Pistorius Sent: Tuesday, August 12, 2008 8:47 AM To: OpenSceneGraph Users Subject: Re: [osg-users] shader or effect to show selected model I did have a look at osgScribe before posting, but overlaying the wireframe is a bit heavy for models with very high polygon counts. I was looking for something a bit more subtle. Cheers, Morne On Tue, Aug 12, 2008 at 12:13 PM, Paul Melis [EMAIL PROTECTED] wrote: Morné Pistorius wrote: Hi everybody, I am looking for a bit of inspiration. I want to apply some sort of effect to a picked model in my scene to show that it has been selected. Does anyone have some ideas (or an example shader or code snippet would be excellent!) that they are willing to throw my way? Ideally I would like to have something that uses the geometry of the model itself, instead of creating new geometry. See the osgscribe example for a possible way... Paul Thanks! Regards, Morne ___ 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 attachment: Selection.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader or effect to show selected model
I did have a look at osgScribe before posting, but overlaying the wireframe is a bit heavy for models with very high polygon counts. I was looking for something a bit more subtle. Cheers, Morne On Tue, Aug 12, 2008 at 12:13 PM, Paul Melis [EMAIL PROTECTED] wrote: Morné Pistorius wrote: Hi everybody, I am looking for a bit of inspiration. I want to apply some sort of effect to a picked model in my scene to show that it has been selected. Does anyone have some ideas (or an example shader or code snippet would be excellent!) that they are willing to throw my way? Ideally I would like to have something that uses the geometry of the model itself, instead of creating new geometry. See the osgscribe example for a possible way... Paul Thanks! Regards, Morne ___ 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] osgPPU-0.1 developer release
Hi Art, Could you provide a downloadable zip file or something? When I try to check out the SVN version, I get this error: Error: Can't connect to host 'projects.tevs.eu': No connection could be made because the target machine actively refused it. Cheers, Morne On Thu, Mar 27, 2008 at 1:56 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi folks, I finally found some time and now there is a first developer release of osgPPU Nodekit (ok not directly a node kit, because not derived from a node, but this will follow ;-). Here is the homepage of the project: http://projects.tevs.eu/osgppu/wiki There are couple of example applications showing it in action. I will be very appreciated if somebody of you would contribute to this project with new ideas/critics/bug-huntings/features/... Best regards, Art Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go ___ 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] osgshadowd.exe = black
Just a thought - Is your OSG_FILE_PATH set up properly? When I run it (on stable 2.2 release) the entire scene is black if osg can't find the texture images. If OSG_FILE_PATH is set to my data directory, shadows work fine. From your screen shots it looks like the textures aren't loaded. cheers, Morne On Feb 7, 2008 12:16 PM, Anders Backman [EMAIL PROTECTED] wrote: Not black, but full of artefacts on VISTA, XP, Ubuntu (gcc) Screenshots found at: http://www.vrlab.umu.se/osg pssm.png --pssm sv.png --sv sm.png --sm All shadow implementations in the trunk (including --ssm) shows a very bad result in svn for XP,VISTA, very recent drivers, GeForce8600Go, GeForce 6800Go, and finally 8800GTX under Ubuntu. shadowmaps worked in the svn version from November that we used previously. /Anders On Feb 7, 2008 11:37 AM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: What about PSSM ? 2008/2/7, Anders Backman [EMAIL PROTECTED]: Just verified this under Ubuntu with osg svn version. Same problem, everything is black when using shadowmaps. /Anders On Feb 7, 2008 11:21 AM, Anders Backman [EMAIL PROTECTED] wrote: Hi all. I just did a svn checkout of osg and build it with VS2008 in windows Vista (and xp). On both of my machines (one vista 64bit but built in 32bit, and one xp 32bit) the shadowed scene in osgshadowd.exe is completely black. osgshadowd --sv works but none of the --ssm or --sm ANyone seen this? -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Efficient mesh data structures
Hi all, I am looking for an efficient general mesh data structure and I thought I would bounce this one off the list. I came across OpenMesh (http://www.openmesh.org), which looks like it might be useful and could conceivably be integrated into an osgNodeKit. Has anyone here ever used it or could you recommend something else? As always, feedback is greatly appreciated! Thanks, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
