[osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). I actually can't perform world to screen space coordinate conversion using matrices provided by the State, at least not using this kind of formula: screenSpacePoint = worldSpacePoint * view * proj * viewPortComputedWindowMatrix. The same calculation works with camera matrices. Am I missing something? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34388#34388 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi Fred, - Fred Smith a écrit : Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). I actually can't perform world to screen space coordinate conversion using matrices provided by the State, at least not using this kind of formula: screenSpacePoint = worldSpacePoint * view * proj * viewPortComputedWindowMatrix. The same calculation works with camera matrices. Am I missing something? This is a wild guess but I think ModelViewMatrix != ViewMatrix so State::getModelViewMatrix() shouldn't be the same than Camera::getViewMatrix() Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
On Thu, Dec 2, 2010 at 9:18 AM, Fred Smith osgfo...@tevs.eu wrote: Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). Very few, if any, things in the State object are valid during the cull traversal. They could be changed asynchronously by the draw traversal in another thread, for example. You want the CullVisitor (actually, CullStack) methods getModelViewMatrix() and getProjectionMatrix(), which give you the concatenated matrices at that point in the scene graph. Also, as Fred said, the View matrix is not the same as the ModelView matrix. Tim I actually can't perform world to screen space coordinate conversion using matrices provided by the State, at least not using this kind of formula: screenSpacePoint = worldSpacePoint * view * proj * viewPortComputedWindowMatrix. The same calculation works with camera matrices. Am I missing something? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34388#34388 ___ 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] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi, *harrumph* emmm, what is the difference? :) Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34391#34391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] second-order equation
Hi Kurt, On Thu, Dec 2, 2010 at 6:09 AM, Cracj Kurt couple...@mail.ru wrote: Surface , for example z= sin(x)sin(y). I see only one solution. Calculate the value of a formula written into the matrix and show the shape. But may exist complete class or method... There are many solutions, but the one you suggest I can't make any sense from. Down on the gpu you can use sin functions, and the osgparametric example is a good example of this so have a look at it. The osgparametric example creates a large flat mesh with z value of 0, then it uses a vertex shader to take the x and y quantities to compute the z value, along with a uniform that provide a time varying quantity that animates the resulting mesh. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi Fred, On Thu, Dec 2, 2010 at 8:18 AM, Fred Smith osgfo...@tevs.eu wrote: In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). I actually can't perform world to screen space coordinate conversion using matrices provided by the State, at least not using this kind of formula: screenSpacePoint = worldSpacePoint * view * proj * viewPortComputedWindowMatrix. The same calculation works with camera matrices. Am I missing something? As mentioned Tim mentioned the osg::State object tracks the current OpenGL state that the OSG is managing during the draw traversal, it's values change dynamically as the OSG dispatches data to OpenGL. The OSG also allows the update and cull to overlap with the draw traversal when the viewer is running in DrawThreadPerContext or CullThreadPerCameraDrawThreadPexContext threading models. This all means when and where you check the values will be critical - it's only really valid during a draw callback. Another factor is that the cull traversal by default updates the near and far planes of the projection matrix to fit the extents of the scene graph being rendered. The big question for me is what are you trying to do, where are you doing it, and how. You almost certainly are trying to solve a problem in an inappropriate way, what way you should be tackling it is something that we can't answer based on what information you've provided. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hidden Viewer
Hello Jean-Sébastien, Thanks for your reply, Skylark wrote: Hello Oliver, Hmmm, seems you are tripping over something else on your hardware... I just remembered you had mentioned in another post that setting the threading model to SingleThreaded didn't work for you either, but in my case it did... So that indicates something else is going on for you. The code works for me as well if I set the threading model to SingleThreaded! I think it is the osg lib, as I have used the official build libs and no custom builds. I will update the nVidia driver but I think the difference between our two systems is the osg version. I will try to get the current osg trunk to work. In the mean time, could you test out your altered pbuffertest.cpp with the offical 2.8.3 libs (VS2005) to verify if this is the problem? You can find them here: http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.8.3/binaries/Windows/VisualStudio8/. @ Robert: If I get the dev build to work, I will check the two solutions you mentioned. Greetings, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34394#34394 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Tim Moore wrote: On Thu, Dec 2, 2010 at 9:18 AM, Fred Smith () wrote: Hi, In a drawable cull callback, I have found that State::getModelViewMatrix() and State::getProjectionMatrix() are different from the matrices returned by Camera::getViewMatrix() and Camera::getProjectionMatrix(). Very few, if any, things in the State object are valid during the cull traversal. They could be changed asynchronously by the draw traversal in another thread, for example. You want the CullVisitor (actually, CullStack) methods getModelViewMatrix() and getProjectionMatrix(), which give you the concatenated matrices at that point in the scene graph. Also, as Fred said, the View matrix is not the same as the ModelView matrix. Thanks for your replies. ModelView is a bit misleading, but if you mean the difference between the drawable's model-space matrix and the view-space matrix, I follow you. Maybe I should put the question this way: in my cull callback, how can I access the View matrix, i.e. the view space - world space matrix? Anyway, I understand from your messages that one simple way to do it is the following: - cast NodeVisitor to CullVisitor (this was the bit I wasn't looking at. I am now assuming this is OK to do this, eg. this will always remain valid in future OSG versions) - call CullVisitor::getCurrentCamera() - use usual Camera methods. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34395#34395 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi Frad, On Thu, Dec 2, 2010 at 9:18 AM, Fred Smith osgfo...@tevs.eu wrote: Anyway, I understand from your messages that one simple way to do it is the following: - cast NodeVisitor to CullVisitor (this was the bit I wasn't looking at. I am now assuming this is OK to do this, eg. this will always remain valid in future OSG versions) - call CullVisitor::getCurrentCamera() - use usual Camera methods. CullVisitor has a osg::RefMatrix* getModelViewMatrix() and getProjectionMatrix() methods that it inherits from osg::CullStack that can be used to get the current modelview and projection matrices. There multiple ways to modify the modelview and projection matrices outwith osg::Camera, and even Camera's can be nested so I wouldn't recommend hard-wiring code to code to any particular camera. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG on iPhone (size?)
On 2/12/10 15:13 , Mike Wozniewski wrote: On 2/12/10 12:49 , Mike Wozniewski wrote: $ du -hs *.a 328KlibOpenThreads.a 240Mlibosg.a 51MlibosgAnimation.a 116MlibosgDB.a 34MlibosgFX.a 75MlibosgGA.a 67MlibosgManipulator.a 75MlibosgParticle.a 25MlibosgPresentation.a 69MlibosgShadow.a 56MlibosgSim.a 24MlibosgTerrain.a 32MlibosgText.a 227MlibosgUtils.a 547MlibosgViewer.a 31MlibosgVolume.a 92MlibosgWidget.a What sort of a build is this? Debug or release? Device or simulator? The numbers I'm getting from a release/simulator build (Xcode 3.2.3) are far lower: 5.5Mlibosg.a 1.2MlibosgAnimation.a 1.7MlibosgDB.a 408KlibosgFX.a 1.2MlibosgGA.a 692KlibosgManipulator.a 848KlibosgParticle.a 484KlibosgPresentation.a 952KlibosgShadow.a 1020KlibosgSim.a 384KlibosgTerrain.a 616KlibosgText.a 3.1MlibosgUtil.a 1.2MlibosgViewer.a 448KlibosgVolume.a 744KlibosgWidget.a This is a release/device build (Xcode 3.2.4), but oddly, the debug build is pretty similar... just slightly larger (eg, 244M for libosg.a rather than 240M). Remember that this is a *simulator* build, hence i386 architecture. The armv6/v7 might explain a certain increase (CISC vs RISC; maybe x2?) but nothing this massive. Maybe another x2 for a universal build but this is still nowhere near what you're seeing... /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG on iPhone (size?)
Hi, Am 02.12.10 03:54, schrieb Chris 'Xenon' Hanson: I don't know if you can static link on iOS, or how you would go about doing it. For now static linking is the only way on IOS. So the lib sizes do not matter, as only needed code get linked into the app. And: most of the time I am only using OpenThreads, osg, osgDB, osgGA, osgUtil and osgViewer, you don't have to include all libs. One of my osg based iphone apps is about 20 MB which utilize some of the osg libs, and some of my own libs. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hidden Viewer
Hi All, I have now checked in the removal of the makeCurrentImplememtation() from the PixelBufferWin32.cpp's realizeImplementation() method, rather the go for the earlier suggestion of adding a releaseContext(). I asked J-S to test this out the removal of the makeCurrentImplementation(), using both osgscreencapture and osgprerender --pbuffer yesterday and he reported that it worked fine so I have checked the change in. Could members of the community do an svn update and do the tests again to see how things fair. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] testing osgtexture1d..
Hi, I am not 100% sure what this example does and how it should perform! I am noticing a lot of flickering of the 1d texture applied? Will send some screen shots if no else can reproduce? Regards Martin Naylor. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] testing osgtexture1d..
On 2/12/10 21:03 , Martin Naylor wrote: I am not 100% sure what this example does and how it should perform! I am noticing a lot of flickering of the 1d texture applied? Will send some screen shots if no else can reproduce? The example is cycling between OBJECT_LINEAR and EYE_LINEAR texgen modes, so you should see the truck with one texture that's fixed to the object (OBJECT_LINEAR, doesn't change when rotating) and one where the texture changes when the object is rotated (EYE_LINEAR). Just tested on OS X and it looks fine. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] testing osgtexture1d..
Hi Ulrich, Cheers that makes sense... Regards Martin. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ulrich Hertlein Sent: 02 December 2010 10:17 To: OpenSceneGraph Users Subject: Re: [osg-users] testing osgtexture1d.. On 2/12/10 21:03 , Martin Naylor wrote: I am not 100% sure what this example does and how it should perform! I am noticing a lot of flickering of the 1d texture applied? Will send some screen shots if no else can reproduce? The example is cycling between OBJECT_LINEAR and EYE_LINEAR texgen modes, so you should see the truck with one texture that's fixed to the object (OBJECT_LINEAR, doesn't change when rotating) and one where the texture changes when the object is rotated (EYE_LINEAR). Just tested on OS X and it looks fine. /ulrich ___ 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] SEPERATE_WINDOW is that correct?
Hello, a little question or hint about the expression SEPERATE_WINDOW in the osg::Camera. It is not so important, but I guess SEPARATE_WINDOW would be correct. I have noticed that and I thought I post it here. Cheers Martin -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SEPERATE_WINDOW is that correct?
Hi Martin, 2010/12/2 Martin Großer grosser.mar...@gmx.de: a little question or hint about the expression SEPERATE_WINDOW in the osg::Camera. It is not so important, but I guess SEPARATE_WINDOW would be correct. I have noticed that and I thought I post it here. I can't work out what your question is... SEPARATE_WINDOW is useful for debugging render to texture techniques, instead of using an FBO or a pbuffer it hints to the OSG to create a separate GraphicsWindow that is rendered to and then a copy is done to the attach texture/image. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SEPERATE_WINDOW is that correct?
Hello Robert, no no I don't have a question. SEPARATE_WINDOW is misspelt in osg::Camera. I had use that and the compiler said something like SEPARATE_WINDOW is not found because in osg it is misspelt -- SEPERATE_WINDOW. Maybe it is not so important, but I want to let you know that. That's all. Additional I'm using osg-2.8.3. Cheers Martin Original-Nachricht Datum: Thu, 2 Dec 2010 11:58:39 + Von: Robert Osfield robert.osfi...@gmail.com An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] SEPERATE_WINDOW is that correct? Hi Martin, 2010/12/2 Martin Großer grosser.mar...@gmx.de: a little question or hint about the expression SEPERATE_WINDOW in the osg::Camera. It is not so important, but I guess SEPARATE_WINDOW would be correct. I have noticed that and I thought I post it here. I can't work out what your question is... SEPARATE_WINDOW is useful for debugging render to texture techniques, instead of using an FBO or a pbuffer it hints to the OSG to create a separate GraphicsWindow that is rendered to and then a copy is done to the attach texture/image. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgscreencapture sample doesn't work
Thanks a lot, guys! Yesterday i though i'd go mad, it was like hitting the head against a wall.. But yes, i checked out the current subversion tomorrow morning and managed to write an image successfully under Windows with osgscreencapture. Now it should be (hopefully) trivial to use it in my project. Thanks for help and for the fix! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34408#34408 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to render the OSG scene to an image file?
OK, the problem was with the bug in the Windows implementation of the PixelBuffer implementation. Checked out the latest version from SVN trunk (development one) and got osgscreencapture working under Windows. Will use it now in my project. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34409#34409 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Trackball Manipulator and RTT
Hi, I'm rendering a scene to texture and display it later on on an orthoquad with an orthocam.., now I want to manipulate the rtt cam (obviously not the orthocam) with a trackball manipulator. Could anybody point me to a tutorial or give me some addvise on where to start here!? Thank you! Cheers, Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34410#34410 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] crash in destructor of RegisterReaderWriterProxy
Hi all, I'm using osg 2.8.3 and I experience a program crash when closing the program. It happens after I used 3ds export function which dynamically loads the corresponding library. The crash is in the destructor of RegisterReaderWriterProxy when calling Registry::instance()-removeReaderWriter(_rw.get()); The crash happens on Linux and Windows. Is there anything known about that? - Werner - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Application crash
Hi Tim and Robert, I just want to give you a feedback. I AM VERY, VERY LUCKY You took me on the right path. Thanks for your great support. - Werner - Am Mittwoch, 24. November 2010, 17:13:09 schrieb Robert Osfield: Hi Werner, On Wed, Nov 24, 2010 at 3:02 PM, Werner Modenbach werner.modenb...@texion.eu wrote: I was told using indexes is leaving fast path rendering. Isn't that the case? I would be very, very lucky!!! Use vertex/colour/normal/etc index arrays in osg::Geometry will force the OSG to dispatch data to OpenGL using OpenGL slow paths, as OpenGL does not support independent index arrays for vertex data. So avoid using osg::Geometry::setVertexIndices(..), setNormalIndex(..), setColorIndices(..). These *Indices() methods are deprecated and only currently kept around for backwards compatibility. However, using DrawElementUShort primitive sets (a wrapper around glDrawElements) to pass in indexed primitive data is directly supported by OpenGL and is the generally the best way to pass primitive data as you can share vertex data, reducing the amount of vertex data you need and enables efficient use of the vertex cache down on the GPU. For you case you should look at trying to minimize both the number of vertices you have by sharing as much as possible, and reducing the amount of data per vertex. As Tim suggested you don't need to pass normal, binormal and tangent vectors as you can compute the third vector very easily and quickly down on the GPU. You may even be able to compute the surface orientation data down on the GPU if you start using deferred rendering techniques. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- TEXION Software Solutions TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu Geschäftsführer/Managing Director: Werner Modenbach ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trackball Manipulator and RTT
HI Thomas, The osgdistortion example sets up a render to texture slave camera that renders the scene along with inheriting the view matrix from the master Camera or the view, it uses a relative reference frame to achieve this. A second slave camera is used to a that has an absolure reference frame so ignores the views master camera. The camera manipulator (the trackball in your case) controls the viewer's master camera's view matrix. Robert. On Thu, Dec 2, 2010 at 12:36 PM, Thomas Klemmer klem...@uni-weimar.de wrote: Hi, I'm rendering a scene to texture and display it later on on an orthoquad with an orthocam.., now I want to manipulate the rtt cam (obviously not the orthocam) with a trackball manipulator. Could anybody point me to a tutorial or give me some addvise on where to start here!? Thank you! Cheers, Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34410#34410 ___ 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] Window content stretching when resized after updating from 2.6.1 to 2.8.3
Hi Jasper, There is chance that the issue comes from a fix to a bug rather than introduction of a bug, with your original code working around the bug. Removing the workaround could well just fix things. The reason why I suggest that is that I recall merging fixes to the way the projection matrices are updated, I don't recall the dates though, but I'm sure it's since 2.6.x. Try just removing your code that attempts to update the projection matrix when you the window is resized. Robert. On Thu, Dec 2, 2010 at 12:46 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi all, I had hoped I would figure this out myself, but no luck so far. I just upgraded my OSG usage from 2.6.1 to 2.8.3, and without changing anything about how my windows are set up, I’m now getting a behavior where the viewed contents of a window stays the same when the window is rescaled, whereas in 2.6.1 I would have a constant pixel-size for the contents of the window when resized. Please see the attached images if I’m not making myself clear enough (please note that the HUD-text is supposed to be stretched to the window size in both versions). I’m using a release OSG 2.8.3, compiled on Visual Studio 2005 sp1, on Vista 64 (Nvidia Quadro graphics card). The camera and graphics context are created like this (done once): RECT rect; mViewer = new osgViewer::Viewer(); mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); ::GetWindowRect(m_hWnd, rect); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-supportsResize = true; traits-inheritedWindowData = windata; m_gc = osg::GraphicsContext::createGraphicsContext(traits.get()); camera = mViewer-getCamera(); camera-setGraphicsContext(m_gc.get()); camera-setViewport(new osg::Viewport(traits-x, traits-y, traits-width, traits-height)); mViewer-addSlave(camera.get()); And for each frame I’m drawing I’m setting the camera like this: mOSG-getViewer()-getCamera()-getGraphicsContext()-resized(x, y, w, h); mOSG-getViewer()-getCamera()-setViewport(x,y,w,h); double n = (double)m_OSGView.near_dist; double f = (double)(m_OSGView.far_dist + m_OSGView.eye_dist_add_ortho); double t = (double)(m_OSGView.focal_height/2.0f); double r = (double)m_OSGView.aspect_ratio*t; mOSG-getViewer()-getCamera()-setProjectionMatrixAsOrtho(-r,r,-t,t,n,f*50); The eyepoint is set via setViewMatrix elsewhere. This worked just fine in OSG 2.6.1, but the behavior has changed in 2.8.3, and I know that’s it’s probably something I’m either doing wrong or forgetting to do, but I would like to keep the pixel-aspect the same when resize the view, and any help/hints would be most welcome. I’m just about to create a new graphicscontext with new traits for each window resize, but I just know that that can’t be the proper way to solve this. Regards, and thanks in advance. Jesper D. Thomsen AnyBody Technology A/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] Application crash
Hi Werner, additionally to the solutions to your rendering purpose, you can pimp up 32bit windows to support 3GB Adressspace per process ( in reality it is alittle bit less) via the /3GB switch in the boot.ini: http://msdn.microsoft.com/en-us/library/bb613473%28VS.85%29.aspx Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34416#34416 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] MRT with trunk version
Hi, ok, I found the trick. I must set the output depth to the number of output textures: setOutputDepth(3); Vince ... Thank you! Cheers, Vincent -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34417#34417 ___ 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.9.10 dev release
Hi Thomas, On Wed, Dec 1, 2010 at 11:10 PM, Thomas Hogarth thomas.hoga...@gmail.com wrote: I did want to raise one issue with the Texture objects being released from my NPOT subloadcallback, this is also effecting osgArt so I know others will be looking for a fix. If you check out this post http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg44349.html I found the problem, around line 157 of texture2d.cpp but need the subloadcallback to be able to override the release if the texture and image are different sizes. i.e. I don't want them to match sizes, my image is always smaller then the texture space. You added the generateTextureObject function to the subloadcallback so perhaps a shouldReleaseTextureObject could be added also? This sounds rather too hacky workaround to what should probably be amendments elsewhere. Could you modify one of the existing OSG examples or put together a small test program that illustrates the problem so that I and others can try it out. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3
Hi Robert, thank you very much for your answer. It led me to implement at rather hacky (in my mind at least solution). Instead of : double r = (double)m_OSGView.aspect_ratio*t; I now use: double r = (double)m_OSGView.aspect_ratio*(double)m_OSGView.aspect_ratio*t / mOSG-getOriginalAspect(); //where mOSG-getOriginalAspect() is the aspect ratio from the creation time of the graphicscontext. This gives me exactly the same view as in my 2.6.1 version when resizing the window, even though it feels very hacky. Thank you very much for your help. Jesper D. Thomsen AnyBody Technology A/S -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 2. december 2010 14:40 To: OpenSceneGraph Users Subject: Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3 Hi Jasper, There is chance that the issue comes from a fix to a bug rather than introduction of a bug, with your original code working around the bug. Removing the workaround could well just fix things. The reason why I suggest that is that I recall merging fixes to the way the projection matrices are updated, I don't recall the dates though, but I'm sure it's since 2.6.x. Try just removing your code that attempts to update the projection matrix when you the window is resized. Robert. On Thu, Dec 2, 2010 at 12:46 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi all, I had hoped I would figure this out myself, but no luck so far. I just upgraded my OSG usage from 2.6.1 to 2.8.3, and without changing anything about how my windows are set up, I'm now getting a behavior where the viewed contents of a window stays the same when the window is rescaled, whereas in 2.6.1 I would have a constant pixel-size for the contents of the window when resized. Please see the attached images if I'm not making myself clear enough (please note that the HUD-text is supposed to be stretched to the window size in both versions). I'm using a release OSG 2.8.3, compiled on Visual Studio 2005 sp1, on Vista 64 (Nvidia Quadro graphics card). The camera and graphics context are created like this (done once): RECT rect; mViewer = new osgViewer::Viewer(); mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); ::GetWindowRect(m_hWnd, rect); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-supportsResize = true; traits-inheritedWindowData = windata; m_gc = osg::GraphicsContext::createGraphicsContext(traits.get()); camera = mViewer-getCamera(); camera-setGraphicsContext(m_gc.get()); camera-setViewport(new osg::Viewport(traits-x, traits-y, camera-traits-width, traits-height)); mViewer-addSlave(camera.get()); And for each frame I'm drawing I'm setting the camera like this: mOSG-getViewer()-getCamera()-getGraphicsContext()-resized(x, y, w, mOSG-h); mOSG-getViewer()-getCamera()-setViewport(x,y,w,h); double n = (double)m_OSGView.near_dist; double f = (double)(m_OSGView.far_dist + m_OSGView.eye_dist_add_ortho); double t = (double)(m_OSGView.focal_height/2.0f); double r = (double)m_OSGView.aspect_ratio*t; mOSG-getViewer()-getCamera()-setProjectionMatrixAsOrtho(-r,r,-t,t,n mOSG-,f*50); The eyepoint is set via setViewMatrix elsewhere. This worked just fine in OSG 2.6.1, but the behavior has changed in 2.8.3, and I know that's it's probably something I'm either doing wrong or forgetting to do, but I would like to keep the pixel-aspect the same when resize the view, and any help/hints would be most welcome. I'm just about to create a new graphicscontext with new traits for each window resize, but I just know that that can't be the proper way to solve this. Regards, and thanks in advance. Jesper D. Thomsen AnyBody Technology A/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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Length unit
Hi, i've an issue with my application. How kind of unit is used by osg for length? Can i configure it? Moreover, between lighting techniques supported by osg, is there also a global one? Thank you! Cheers, Axel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34426#34426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Length unit
Hi Axel, As far as I know is OSG as well as OpenGL unit less. You can render your model in cm as well as in km. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34427#34427 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3
Hi Jasper, I don't understand the details of what you are attempting to do, but the OSG directly supports resizing the projection matrix to keep the aspect ratio of the scene the same even when you resize the window. There are also controls in osg::Camera for controlling this. You shouldn't need to do anything special to handle window resize and projection matrix setting, instead you should be able to just set it at setup time and then not have to do anything there after. To me it feels like you are trying to do something overly complicated and likely unnecessary. Robert. On Thu, Dec 2, 2010 at 2:35 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi Robert, thank you very much for your answer. It led me to implement at rather hacky (in my mind at least solution). Instead of : double r = (double)m_OSGView.aspect_ratio*t; I now use: double r = (double)m_OSGView.aspect_ratio*(double)m_OSGView.aspect_ratio*t / mOSG-getOriginalAspect(); //where mOSG-getOriginalAspect() is the aspect ratio from the creation time of the graphicscontext. This gives me exactly the same view as in my 2.6.1 version when resizing the window, even though it feels very hacky. Thank you very much for your help. Jesper D. Thomsen AnyBody Technology A/S -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 2. december 2010 14:40 To: OpenSceneGraph Users Subject: Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3 Hi Jasper, There is chance that the issue comes from a fix to a bug rather than introduction of a bug, with your original code working around the bug. Removing the workaround could well just fix things. The reason why I suggest that is that I recall merging fixes to the way the projection matrices are updated, I don't recall the dates though, but I'm sure it's since 2.6.x. Try just removing your code that attempts to update the projection matrix when you the window is resized. Robert. On Thu, Dec 2, 2010 at 12:46 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi all, I had hoped I would figure this out myself, but no luck so far. I just upgraded my OSG usage from 2.6.1 to 2.8.3, and without changing anything about how my windows are set up, I'm now getting a behavior where the viewed contents of a window stays the same when the window is rescaled, whereas in 2.6.1 I would have a constant pixel-size for the contents of the window when resized. Please see the attached images if I'm not making myself clear enough (please note that the HUD-text is supposed to be stretched to the window size in both versions). I'm using a release OSG 2.8.3, compiled on Visual Studio 2005 sp1, on Vista 64 (Nvidia Quadro graphics card). The camera and graphics context are created like this (done once): RECT rect; mViewer = new osgViewer::Viewer(); mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); ::GetWindowRect(m_hWnd, rect); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-supportsResize = true; traits-inheritedWindowData = windata; m_gc = osg::GraphicsContext::createGraphicsContext(traits.get()); camera = mViewer-getCamera(); camera-setGraphicsContext(m_gc.get()); camera-setViewport(new osg::Viewport(traits-x, traits-y, camera-traits-width, traits-height)); mViewer-addSlave(camera.get()); And for each frame I'm drawing I'm setting the camera like this: mOSG-getViewer()-getCamera()-getGraphicsContext()-resized(x, y, w, mOSG-h); mOSG-getViewer()-getCamera()-setViewport(x,y,w,h); double n = (double)m_OSGView.near_dist; double f = (double)(m_OSGView.far_dist + m_OSGView.eye_dist_add_ortho); double t = (double)(m_OSGView.focal_height/2.0f); double r = (double)m_OSGView.aspect_ratio*t; mOSG-getViewer()-getCamera()-setProjectionMatrixAsOrtho(-r,r,-t,t,n mOSG-,f*50); The eyepoint is set via setViewMatrix elsewhere. This worked just fine in OSG 2.6.1, but the behavior has changed in 2.8.3, and I know that's it's probably something I'm either doing wrong or forgetting to do, but I would like to keep the pixel-aspect the same when resize the view, and any help/hints would be most welcome. I'm just about to create a new graphicscontext with new traits for each window resize, but I just know that that can't be the proper way to solve this. Regards, and thanks in advance. Jesper D. Thomsen AnyBody Technology A/S
Re: [osg-users] Length unit
Hi Torben, thanks for your answer. I imagined it, but when i loaded the cow model in my scene, the model was bigger than my room (that is, 8x5x3), so I've had this doubt :-) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34429#34429 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Length unit
Hi Axel, - Axel Spirtaat a écrit : Hi Torben, thanks for your answer. I imagined it, but when i loaded the cow model in my scene, the model was bigger than my room (that is, 8x5x3), so I've had this doubt :-) So the right question is : In what unit is the cow ? and the room ? -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3
Hi again, you are naturally quite right. I did a search for osg camera aspect ratio, and it turned out that there was a change in 2.8.0 regarding ABSOLUTE_RF for slave cameras. Setting this for my slave camera which is displaying the view fixed the problem completely (as far as I can tell). It might be absolutely correct that I'm still jumping through a couple of hoops regarding how the projectionmatrix is being set when resizing. Thanks for your patience :) Jesper D. Thomsen AnyBody Technology A/S -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 2. december 2010 16:05 To: OpenSceneGraph Users Subject: Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3 Hi Jasper, I don't understand the details of what you are attempting to do, but the OSG directly supports resizing the projection matrix to keep the aspect ratio of the scene the same even when you resize the window. There are also controls in osg::Camera for controlling this. You shouldn't need to do anything special to handle window resize and projection matrix setting, instead you should be able to just set it at setup time and then not have to do anything there after. To me it feels like you are trying to do something overly complicated and likely unnecessary. Robert. On Thu, Dec 2, 2010 at 2:35 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi Robert, thank you very much for your answer. It led me to implement at rather hacky (in my mind at least solution). Instead of : double r = (double)m_OSGView.aspect_ratio*t; I now use: double r = (double)m_OSGView.aspect_ratio*(double)m_OSGView.aspect_ratio*t / mOSG-getOriginalAspect(); //where mOSG-getOriginalAspect() is the aspect ratio from the creation time of the graphicscontext. This gives me exactly the same view as in my 2.6.1 version when resizing the window, even though it feels very hacky. Thank you very much for your help. Jesper D. Thomsen AnyBody Technology A/S -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 2. december 2010 14:40 To: OpenSceneGraph Users Subject: Re: [osg-users] Window content stretching when resized after updating from 2.6.1 to 2.8.3 Hi Jasper, There is chance that the issue comes from a fix to a bug rather than introduction of a bug, with your original code working around the bug. Removing the workaround could well just fix things. The reason why I suggest that is that I recall merging fixes to the way the projection matrices are updated, I don't recall the dates though, but I'm sure it's since 2.6.x. Try just removing your code that attempts to update the projection matrix when you the window is resized. Robert. On Thu, Dec 2, 2010 at 12:46 PM, Jesper D. Thomsen j...@anybodytech.com wrote: Hi all, I had hoped I would figure this out myself, but no luck so far. I just upgraded my OSG usage from 2.6.1 to 2.8.3, and without changing anything about how my windows are set up, I'm now getting a behavior where the viewed contents of a window stays the same when the window is rescaled, whereas in 2.6.1 I would have a constant pixel-size for the contents of the window when resized. Please see the attached images if I'm not making myself clear enough (please note that the HUD-text is supposed to be stretched to the window size in both versions). I'm using a release OSG 2.8.3, compiled on Visual Studio 2005 sp1, on Vista 64 (Nvidia Quadro graphics card). The camera and graphics context are created like this (done once): RECT rect; mViewer = new osgViewer::Viewer(); mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); ::GetWindowRect(m_hWnd, rect); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; osg::ref_ptrosg::Referenced windata = new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd); traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; traits-windowDecoration = false; traits-doubleBuffer = true; traits-sharedContext = 0; traits-setInheritedWindowPixelFormat = true; traits-supportsResize = true; traits-inheritedWindowData = windata; m_gc = osg::GraphicsContext::createGraphicsContext(traits.get()); camera = mViewer-getCamera(); camera-setGraphicsContext(m_gc.get()); camera-setViewport(new osg::Viewport(traits-x, traits-y, camera-traits-width, traits-height)); mViewer-addSlave(camera.get()); And for each frame I'm drawing I'm setting the camera like this: mOSG-getViewer()-getCamera()-getGraphicsContext()-resized(x, y, mOSG-w, h); mOSG-getViewer()-getCamera()-setViewport(x,y,w,h); double n = (double)m_OSGView.near_dist; double f =
Re: [osg-users] OSG on iPhone (size?)
On 10-12-02 4:53 AM, Ulrich Hertlein wrote: On 2/12/10 15:13 , Mike Wozniewski wrote: On 2/12/10 12:49 , Mike Wozniewski wrote: $ du -hs *.a 328KlibOpenThreads.a 240Mlibosg.a 51MlibosgAnimation.a 116MlibosgDB.a 34MlibosgFX.a 75MlibosgGA.a 67MlibosgManipulator.a 75MlibosgParticle.a 25MlibosgPresentation.a 69MlibosgShadow.a 56MlibosgSim.a 24MlibosgTerrain.a 32MlibosgText.a 227MlibosgUtils.a 547MlibosgViewer.a 31MlibosgVolume.a 92MlibosgWidget.a What sort of a build is this? Debug or release? Device or simulator? The numbers I'm getting from a release/simulator build (Xcode 3.2.3) are far lower: 5.5Mlibosg.a 1.2MlibosgAnimation.a 1.7MlibosgDB.a 408KlibosgFX.a 1.2MlibosgGA.a 692KlibosgManipulator.a 848KlibosgParticle.a 484KlibosgPresentation.a 952KlibosgShadow.a 1020KlibosgSim.a 384KlibosgTerrain.a 616KlibosgText.a 3.1MlibosgUtil.a 1.2MlibosgViewer.a 448KlibosgVolume.a 744KlibosgWidget.a This is a release/device build (Xcode 3.2.4), but oddly, the debug build is pretty similar... just slightly larger (eg, 244M for libosg.a rather than 240M). Remember that this is a *simulator* build, hence i386 architecture. The armv6/v7 might explain a certain increase (CISC vs RISC; maybe x2?) but nothing this massive. Maybe another x2 for a universal build but this is still nowhere near what you're seeing... /ulrich Hmm. Indeed, optimizing for arm6/7 cut the size in half, but I get a libosg.a of 133MB. So, I'm definitely confused. I'm building using Xcode. Are you using cmake instead? I'm a bit at a loss here. I've tried playing with various optimization settings in Xcode, but the result is usually insignificant. It takes a long time to compile and verify too, so I'm curious if there's a way to compare settings somehow? I'm not so great with Xcode, but a sample compilation call for me looks like this: CompileC build/OSGIPhone.build/Debug-iphoneos/osg.build/Objects-normal/armv6/Node.o ../src/osg/Node.cpp normal armv6 c++ com.apple.compilers.gcc.4_2 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv LANG en_US.US-ASCII setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c++ -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -mfix-and-continue -gdwarf-2 -mno-thumb -miphoneos-version-min=3.2 -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-generated-files.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-own-target-headers.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-all-target-headers.hmap -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-project-headers.hmap -F/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos/include -I../include -I../../OpenThreads/include -Iconfig -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/DerivedSources/armv6 -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/DerivedSources -c /Users/mikewoz/src/osg-iphone/IPhone_Project/../src/osg/Node.cpp -o /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/Objects-normal/armv6/Node.o and linking looks like this: Libtool build/Debug-iphoneos/libosg.a normal armv6 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv IPHONEOS_DEPLOYMENT_TARGET 3.2 setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/libtool -static -arch_only armv6 -syslibroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -L/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos -filelist /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/Objects-normal/armv6/osg.LinkFileList -o /Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos/libosg.a Would it be possible for someone to post theirs, so I can compare? ... it's the only idea I have right now. Thanks, Mike Wozniewski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Length unit
Hi Axel, for each Model/Obejct in the scene you have to use the same unit, otherwise the models/obejts won't fit together as expected. If this is not the case, you could use a transform node (scene-transform-cow) and use its scale function to scale the object fitting in your screen. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34433#34433 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hidden Viewer
Hello Oliver, but I think the difference between our two systems is the osg version. I will try to get the current osg trunk to work. In the mean time, could you test out your altered pbuffertest.cpp with the offical 2.8.3 libs (VS2005) to verify if this is the problem? You can find them here: http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.8.3/binaries/Windows/VisualStudio8/. The fix has been checked in to SVN so if you can try with the SVN trunk it would help eliminate another possibility. But the viewer.stopThreading(), gc-releaseContext(), viewer.startThreading() workaround I posted yesterday worked for me on OSG 2.8.3 (our own applications use that version so I was able to test pbuffertest with it easily). That's why I say there must be something else going on with your hardware. Getting OSG built is not too hard, and you'll be able to build release and debug, so once you have SVN trunk built and verified if the fix works for you, you'll also be able to debug into the OSG source (put breakpoints and trace through the execution) as I described in my previous post. 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] OSG on iPhone (size?)
Hello Mike: I have not tried to build the iphone OS port but it appears in your cut and paste you have the Active configuration as Debug as seen with the link path .Debug-iphoneos/osg.build/osg-generated-files.hmap. What are the Active configuration targets available and if a Release target is available try to select that. There should be a drop down box labeled Active Build Configuration or an equivalent. There just appears to be some level of debug symbols still in your binary distribution. Take care Garrett On Dec 2, 2010, at 10:27 AM, Mike Wozniewski wrote: On 10-12-02 4:53 AM, Ulrich Hertlein wrote: On 2/12/10 15:13 , Mike Wozniewski wrote: On 2/12/10 12:49 , Mike Wozniewski wrote: $ du -hs *.a 328KlibOpenThreads.a 240Mlibosg.a 51MlibosgAnimation.a 116MlibosgDB.a 34MlibosgFX.a 75MlibosgGA.a 67MlibosgManipulator.a 75MlibosgParticle.a 25MlibosgPresentation.a 69MlibosgShadow.a 56MlibosgSim.a 24MlibosgTerrain.a 32MlibosgText.a 227MlibosgUtils.a 547MlibosgViewer.a 31MlibosgVolume.a 92MlibosgWidget.a What sort of a build is this? Debug or release? Device or simulator? The numbers I'm getting from a release/simulator build (Xcode 3.2.3) are far lower: 5.5Mlibosg.a 1.2MlibosgAnimation.a 1.7MlibosgDB.a 408KlibosgFX.a 1.2MlibosgGA.a 692KlibosgManipulator.a 848KlibosgParticle.a 484KlibosgPresentation.a 952KlibosgShadow.a 1020KlibosgSim.a 384KlibosgTerrain.a 616KlibosgText.a 3.1MlibosgUtil.a 1.2MlibosgViewer.a 448KlibosgVolume.a 744KlibosgWidget.a This is a release/device build (Xcode 3.2.4), but oddly, the debug build is pretty similar... just slightly larger (eg, 244M for libosg.a rather than 240M). Remember that this is a *simulator* build, hence i386 architecture. The armv6/v7 might explain a certain increase (CISC vs RISC; maybe x2?) but nothing this massive. Maybe another x2 for a universal build but this is still nowhere near what you're seeing... /ulrich Hmm. Indeed, optimizing for arm6/7 cut the size in half, but I get a libosg.a of 133MB. So, I'm definitely confused. I'm building using Xcode. Are you using cmake instead? I'm a bit at a loss here. I've tried playing with various optimization settings in Xcode, but the result is usually insignificant. It takes a long time to compile and verify too, so I'm curious if there's a way to compare settings somehow? I'm not so great with Xcode, but a sample compilation call for me looks like this: CompileC build/OSGIPhone.build/Debug-iphoneos/osg.build/Objects-normal/armv6/Node.o ../src/osg/Node.cpp normal armv6 c++ com.apple.compilers.gcc.4_2 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv LANG en_US.US-ASCII setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c++ -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -mfix-and-continue -gdwarf-2 -mno-thumb -miphoneos-version-min=3.2 -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-generated-files.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-own-target-headers.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-all-target-headers.hmap -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/osg-project-headers.hmap -F/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Debug-iphoneos/include -I../include -I../../OpenT hreads/include -Iconfig -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/DerivedSources/armv6 -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/DerivedSources -c /Users/mikewoz/src/osg-iphone/IPhone_Project/../src/osg/Node.cpp -o /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Debug-iphoneos/osg.build/Objects-normal/armv6/Node.o and linking looks like this: Libtool build/Debug-iphoneos/libosg.a normal armv6 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv IPHONEOS_DEPLOYMENT_TARGET 3.2 setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/libtool -static -arch_only armv6 -syslibroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk
Re: [osg-users] Hidden Viewer
Hi, I have successfully build the current svn trunk version: -Just before Robert checked in the Bugfix: As before with 2.8.3 I get Code: PixelBufferWin32::makeCurrentImplementation, wglMakeCurrent error: Die angeforde rte Ressource wird bereits verwendet. Frame : 0 Test completed!!! Now I think I understand that J-S meant with pbuffertest example works that the application is not crashing and terminates successfully. Sorry I think I misunderstood you, seeing the initial error was enough for my bug senses to cry out ;) After updating to the latest version (including the bug fix), the error message has vanished! I removed J-S bug fix in pbuffertest itself and lo and behold: The errors are gone too! For the time being I will build 2.8.3 with the single change to be compatible with the rest of my application and work with that. So thanks to you all for your great help, I really appreciate it! On small last thing (not related to the bugs but to the hidden viewer approach): With the pbuffer active, my WindowCaptureCallback is not called anymore. I used osgscreencapture to create an image grabber derived from WindowCaptureCallback but it looks like I have to use another approach with pbuffer (as done in the example code). I was curious if I could activate the WindowCaptureCallback even though using a pbuffer so that I use only one code for both cases? Greetings, Oliver Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34436#34436 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hidden Viewer
Hello Oliver, With the pbuffer active, my WindowCaptureCallback is not called anymore. I used osgscreencapture to create an image grabber derived from WindowCaptureCallback but it looks like I have to use another approach with pbuffer (as done in the example code). I was curious if I could activate the WindowCaptureCallback even though using a pbuffer so that I use only one code for both cases? The ScreenCaptureHandler in OSG 2.8.3 only looped through GraphicsWindow-derived contexts, which means contexts that are in a window. A pbuffer is derived from GraphicsContext, i.e. a context that might have a window but not necessarily (and indeed a pbuffer is meant not to spawn a window). I submitted a change to this (in November 2009, so before the OpenSceneGraph-2.9.6 tag... geez it's been a while since the last trunk release ;-) ) so in the SVN version your callback should be called even for pbuffers. If you want this to work for pbuffers in 2.8.3, you can copy the code from SVN. It's in include/osgViewer/ViewerEventHandlers and src/osgViewer/ScreenCaptureHandler.cpp, the relevant method is called findAppropriateCameraForCallback(..). I have made a few other similar submissions over the past year or so, since we've been using pbuffers for some things too. For example in the SVN version the StatsHandler will be displayed even in a pbuffer if there's no GraphicsWindow at all. 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] debugging slow path
Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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 and QT
http://www.easy-share.com/1913167873/qtgui_170.zip -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34439#34439 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi Keith, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. Robert. On Thu, Dec 2, 2010 at 4:30 PM, Keith Parkins kpark...@cs.rochester.edu wrote: Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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] debugging slow path
Hi Robert, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. He could still be using an optimized build and setting breakpoints, as debug information settings are separate from optimization settings, and as long as you're in a Release build, you won't be using the debug STL (which is what destroys OSG's performance in Debug builds - since OSG uses the STL heavily in its traversals and VC++ does extensive/expensive checking of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) We sometimes include debug info in Release builds to be able to debug some problems that happen only in optimized builds. Sometimes the stack traces it gives then is bogus because of the optimization, but it's still useful if you know what to do with it. 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] Hidden Viewer
Hi J-S, Great! You solved my problems before they appeared ;), I will try to get it to work in 2.8.3. Thank you! Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34442#34442 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Hidden Viewer
Hi Oliver, Great! You solved my problems before they appeared ;), I will try to get it to work in 2.8.3. Thank you! Hah, I'm just happy because it proves that what I wanted to do is not so weird as it appeared to be when I did it :-) Glad I could help, 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] debugging slow path
Hi J-S and Robert, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) Trust me, I'm not going to get into any design arguments. People in glass houses and all . . . . Unless you want to get into some text editor argument (all hail ed!!). Those seem productive. ;-) -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Robert, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. He could still be using an optimized build and setting breakpoints, as debug information settings are separate from optimization settings, and as long as you're in a Release build, you won't be using the debug STL (which is what destroys OSG's performance in Debug builds - since OSG uses the STL heavily in its traversals and VC++ does extensive/expensive checking of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) We sometimes include debug info in Release builds to be able to debug some problems that happen only in optimized builds. Sometimes the stack traces it gives then is bogus because of the optimization, but it's still useful if you know what to do with it. 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] OSG on iPhone (size?)
On 10-12-02 10:43 AM, Garrett Potts wrote: Hello Mike: I have not tried to build the iphone OS port but it appears in your cut and paste you have the Active configuration as Debug as seen with the link path .Debug-iphoneos/osg.build/osg-generated-files.hmap. Hi Garrett, Yeah, sorry; that was a Debug build... but a Release build is still 125MB (for libosg.a). Below is sample Xcode output for the Release configuration (you can see that it even uses the -Os option to optimize for space). I don't get it. CompileC build/OSGIPhone.build/Release-iphoneos/osg.build/Objects-normal/armv6/Node.o ../src/osg/Node.cpp normal armv6 c++ com.apple.compilers.gcc.4_2 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv LANG en_US.US-ASCII setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c++ -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -Os -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -gdwarf-2 -mno-thumb -miphoneos-version-min=3.2 -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-generated-files.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-own-target-headers.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-all-target-headers.hmap -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-project-headers.hmap -F/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Release-iphoneos -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Release-iphoneos/include -I../include -I../../OpenThreads/include -Iconfig -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/DerivedSources/armv6 -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/DerivedSources -c /Users/mikewoz/src/osg-iphone/IPhone_Project/../src/osg/Node.cpp -o /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/Objects-normal/armv6/Node.o ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
On Thu, Dec 2, 2010 at 5:30 PM, Keith Parkins kpark...@cs.rochester.eduwrote: Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. Actually, I meant setting a breakpoint in the actual glBegin function. You won't have the source code to it, of course, but it should still be possible to break at that function. Tim This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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] debugging slow path
Hi Keith, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. Ah, so my apologies to Robert, he was right to mention it. I thought that had been mentioned at the beginning of the thread, but it must have been another thread. As both Robert and I said, doing any kind of performance measurement in VC++ in Debug builds will lead to bad results (unrepresentative of the real performance). I've seen cases where the performance from one run to the next was totally different, with no changes to source code, with Debug builds. So try to find out what's slowing down the program in that case... :-) But using a Release build (optimization turned on, Release C++ runtime, Release STL) with debugging symbols turned on (/Z* compiler options and /DEBUG linker option) is fine, performance will be a bit slower but still representative. And another part of the equation is running in the debugger or not. Pressing F5 attaches the debugger, whether in Debug or Release builds. That slows things down a bit too (because the debugger can show you what DLLs have been loaded while it's happening, things like that). Pressing Ctrl-F5 does not attach the debugger, whether in Debug or Release builds. You always have the option to attach it later (when a crash happens, or when you get to the point in your app that you want to trace), by using the Debug - Attach to Process menu option. If doing performance testing, I will use a Release build, no debugging symbols, and press Ctrl-F5 to get accurate results (the same as an end-user would get on my machine). I've seen especially large slowdowns when running in the debugger versus not running in the debugger (even with Release builds) when using boost::persistence, but that's just one example. So in that case I might start with Ctrl-F5, load our data files (which is done with boost::persistence), and then attach the debugger once boost::persistence has finished doing its thing. 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
[osg-users] [build] [Linux] Could not open shared object file: No such file or directory
Hi, I have written a Plugin for Firefox. The Plugin realizes a osgViewer within a QApplication. Now when I start Firefox and open about#058;plugins, firefox fails loading the plugin with the message (translated in English): Code: Shared to initialize shared library . [libosgViewer.so.55: could not open shared object file: File not found] When I change the order of the libraries in the .pro file, the message changes accordingly. I followed the build steps from the osg page and everything went fine (no errors etc.). The .so files are located in /usr/local/lib . The code of my program worked fin a while ago, but after having changed the system. So the problem must somewhere else. Do you have any ideas? Greetz Patrick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34331#34331 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
J-S and Robert, You rule! That was it. Don't link to debug libraries on Windows -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Keith, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. Ah, so my apologies to Robert, he was right to mention it. I thought that had been mentioned at the beginning of the thread, but it must have been another thread. As both Robert and I said, doing any kind of performance measurement in VC++ in Debug builds will lead to bad results (unrepresentative of the real performance). I've seen cases where the performance from one run to the next was totally different, with no changes to source code, with Debug builds. So try to find out what's slowing down the program in that case... :-) But using a Release build (optimization turned on, Release C++ runtime, Release STL) with debugging symbols turned on (/Z* compiler options and /DEBUG linker option) is fine, performance will be a bit slower but still representative. And another part of the equation is running in the debugger or not. Pressing F5 attaches the debugger, whether in Debug or Release builds. That slows things down a bit too (because the debugger can show you what DLLs have been loaded while it's happening, things like that). Pressing Ctrl-F5 does not attach the debugger, whether in Debug or Release builds. You always have the option to attach it later (when a crash happens, or when you get to the point in your app that you want to trace), by using the Debug - Attach to Process menu option. If doing performance testing, I will use a Release build, no debugging symbols, and press Ctrl-F5 to get accurate results (the same as an end-user would get on my machine). I've seen especially large slowdowns when running in the debugger versus not running in the debugger (even with Release builds) when using boost::persistence, but that's just one example. So in that case I might start with Ctrl-F5, load our data files (which is done with boost::persistence), and then attach the debugger once boost::persistence has finished doing its thing. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hello Keith, That was it. Don't link to debug libraries on Windows -K Well, not when testing performance, of course. When you want to do actual debugging, you kind of have to (apart from in some specific cases). Generalities like the above are most often wrong because so many exceptions exist... It always depends on the situation. You're the developer, you make your decisions with hopefully as much information as required to make the right ones. 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] Hidden Viewer [solved]
Hi Jean-Sebastien, I included the changes in my 2.8.3 build and it is now working as I had originally intended. I removed the mentioned one line in osgViewer::PixelBufferWin32 and changed the code of my own ScreenCaptureHandler derivative just like you did (use context and not windows). So thanks again to all of you, I changed the title to [solved]. Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34451#34451 ___ 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.9.10 dev release
Hi All, Thanks for the testing so far. I've merged a few build and bug fixes through today so anymore testing you can do would be greatly appreciated. I'm heading offline now for the day, will catch with you all tomorrow morning and if things still look good will tag in 2.9.10. Cheers, 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.9.10 dev release
Hello Robert, Thanks for the testing so far. I've merged a few build and bug fixes through today so anymore testing you can do would be greatly appreciated. I'm heading offline now for the day, will catch with you all tomorrow morning and if things still look good will tag in 2.9.10. I'm in the process of building our simulator with OSG SVN trunk. I don't expect any trouble. I'll let you know in the next few hours how it goes. 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] [build] [Linux] Could not open shared object file: No such file or directory
On Wednesday 01 December 2010 15:23:04 Patrick Steffens wrote: Hi, I have written a Plugin for Firefox. The Plugin realizes a osgViewer within a QApplication. Now when I start Firefox and open about#058;plugins, firefox fails loading the plugin with the message (translated in English): Code: Shared to initialize shared library . [libosgViewer.so.55: could not open shared object file: File not found] When I change the order of the libraries in the .pro file, the message changes accordingly. I followed the build steps from the osg page and everything went fine (no errors etc.). The .so files are located in /usr/local/lib . The code of my program worked fin a while ago, but after having changed the system. So the problem must somewhere else. Do you have any ideas? Hi Patrick, please make sure that the runtime linker is configured to look in /usr/local/lib. Typically the plugins will be found in a osgPlugins* subdirectory in the lib directory. As you probably know, you can temporarily instruct the runtime linker to add to the known paths by setting the LD_LIBRARY_PATH environment variable. In addition to this, OSG also supports the OSG_LIBRARY_PATH environment variable, which helps with locating the shared objects for plugins. Hope this helps, Magnus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] rain/snow accumulation on the screen
I'd use a pixel shader for the effects. Pass in the texture that represents the snow overlay and have the shader scale the alpha up and down as it accumulates. Rain would be handled the same way but you'd have to come up with a way to make the water droplets move around on the screen. That should be possible in the shader as well. Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34455#34455 ___ 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.9.10 dev release
Hi again Robert, I'm in the process of building our simulator with OSG SVN trunk. I don't expect any trouble. I'll let you know in the next few hours how it goes. Just finished building, and ran a few scenarios to test, and everything seems fine. I ran some pretty heavy scenarios and things were stable. This also tests that osgOcean and osgEphemeris build and run fine with OSG SVN trunk, since we use both. 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] OSG on iPhone (size?)
Okay... so the libraries need to have all of that (ie, all symbols), but when the .app is created and dead code stripping is enabled, any unneeded symbols are stripped away. This leaves me with an .app size of around 15-20MB. Thanks for everyone's help, Mike On 10-12-02 12:10 PM, Mike Wozniewski wrote: On 10-12-02 10:43 AM, Garrett Potts wrote: Hello Mike: I have not tried to build the iphone OS port but it appears in your cut and paste you have the Active configuration as Debug as seen with the link path .Debug-iphoneos/osg.build/osg-generated-files.hmap. Hi Garrett, Yeah, sorry; that was a Debug build... but a Release build is still 125MB (for libosg.a). Below is sample Xcode output for the Release configuration (you can see that it even uses the -Os option to optimize for space). I don't get it. CompileC build/OSGIPhone.build/Release-iphoneos/osg.build/Objects-normal/armv6/Node.o ../src/osg/Node.cpp normal armv6 c++ com.apple.compilers.gcc.4_2 cd /Users/mikewoz/src/osg-iphone/IPhone_Project setenv LANG en_US.US-ASCII setenv PATH /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x c++ -arch armv6 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -Os -Wreturn-type -Wunused-variable -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -gdwarf-2 -mno-thumb -miphoneos-version-min=3.2 -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-generated-files.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-own-target-headers.hmap -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-all-target-headers.hmap -iquote /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/osg-project-headers.hmap -F/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Release-iphoneos -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/Release-iphoneos/include -I../include -I../../OpenThreads/include -Iconfig -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/DerivedSources/armv6 -I/Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/DerivedSources -c /Users/mikewoz/src/osg-iphone/IPhone_Project/../src/osg/Node.cpp -o /Users/mikewoz/src/osg-iphone/IPhone_Project/build/OSGIPhone.build/Release-iphoneos/osg.build/Objects-normal/armv6/Node.o ___ 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] Need help about Night Vision Effect
The easy/cheating way is to calculate the luminance of each pixel, amplify it, (color it green to fit the stereotype) then add electric noise. This is easiest to do on a fragment shader. Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34458#34458 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Old really nasty OpenThreads bug?
Hi all. Im using OpenSceneGraph 2.8.3 under windows. Visual studio 2008. However, this problem has been around for at least 2 years, so it existed in previous versions too. I have finally after two years? isolated the bug I reported quite a while back: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2008-May/011360.html I took a deep breath, and after quite a few hours I managed to isolate the problem into one .dll file and one .exe file. The problem: Assume I have an application, it creates a thread. For various reason, I want to register this thread to a function for later destruction (in our lib we give the pointer of the thread to a singleton which later destroys the thread). In this example, its just registers a function in atexit() which will delete the thread. Notice that this call to atexit() is done within ANOTHER DLL (otbugdll.cpp). When the app exits, the atexit() is called and the thread is destroyed. But the problem is that it hangs at the call to m_block.release() in the destructor. If I instead call atexit() from the main app, everything works just fine. This means, that the call to delete for the thread is the same, its just initiated from an atexit() call done from main(). What this does, is that we need to have a call: ThreadPool::instance()-shutdown(); that HAVE to be called BEFORE the end of the scope of main. Really irritating. We cant use atexit() from within the library (because it is done from a separate lib/dll, which regenerates the problem). To build this, you need to set the OSG_DIR path to your OpenSceneGraph install, run cmake on it, and build the project. If SHOULD_HANG is defined it will...hang. http://www8.cs.umu.se/~andersb/otbug.zip I have done just about everything I can come up with to try to resolve this problem, but nothing works. I have tried to use a DllMain() function, which catches the events for attaching and detaching the dll, and doing the delete of the thread there. I have tried every combination of singletons, static variables etc, but it all fails. So the above example is not really exactly my original problem, but it reproduces the problem quite nicely. I cannot really see what the problem is. The flow of code is exactly the same no matter if SHOULD_HANG is defined or not. It might be a bug in how OpenThreads use the win32 threading API. OR it might be a limitation of the Win32 threading API. Thankful for any help on this matter. It has been on my mind now for more two years. /Anders -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Graphic Context + Texture Memory
I have a newby question to ask... so please be gentil Let's say I have 2 cameras running in different draw threads. Each camera is also associated with a different graphic context. If I load a 2D texture then each context will have its own opengl texture object (created in the Texture2D::Apply() function). So far so good... My question is: will the opengl driver have 2 instance of the texture object in memory and therefore occuping twice the amount necessary? Or is the driver smart enough to somehow share the same memory space for both instances? I guess the answer is that each texture is represented in each graphic context by a different opengl texture object, and thus will occupy N times the required memory space, where N is the number of graphic context. Am I understanding this right? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34460#34460 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgExp: problems with user properties?
Hi, I'm using the latest osgExp version and I see a problem in user properties. Try the following: - create a sphere - add some user properties to it - export it with default settings: everything should be fine - export it tagging the Flatten Static Transform on: the properties don't show up. I guess this is due to the fact that the flatter optimization removes some of the transforms. I think this is a problem because that option is heavily used to optimize exports and I would say the exporter should be able to maintain the user properties in some way, at least when - like in this case - there is not a complex hierarchy. Do you see any chance in solving that? Also, I have no idea if Max supports that, but is there a way to have user properties on materials rather than on geom and transform nodes? That would allow to set useful info about the shaders to build for each stateset. Thanks, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34461#34461 ___ 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.9.10 dev release
Hi Robert, Build and work well with mingw 5.1.6. Now I'm looking forward to the 2.9.10 release. Cheers, Wang Rui 2010/12/3 Robert Osfield robert.osfi...@gmail.com: Hi All, Thanks for the testing so far. I've merged a few build and bug fixes through today so anymore testing you can do would be greatly appreciated. I'm heading offline now for the day, will catch with you all tomorrow morning and if things still look good will tag in 2.9.10. Cheers, 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] Question about setting speed/acceleration with AnimationPath
Dear all, I need to move an object along a line with the speed of 1m/s. The object starts from stationary (0m/s). I use AnimationPath like this: osg::AnimationPath* animationPath = new osg::AnimationPath; animationPath-setLoopMode(osg::AnimationPath::NO_LOOPING); osg::Vec3 startPoint(startMat(3,0), startMat(3,1), startMat(3,2)); animationPath-insert(0.0,osg::AnimationPath::ControlPoint(startPoint , rotation)); osg::Vec3 endPoint(endMat(3,0), endMat(3,1), endMat(3,2)); float speed = 1.0; // (m/s) float timeOfAnimation = distanceFromStartPointToEndPoint/speed; animationPath-insert(timeOfAnimation,osg::AnimationPath::ControlPoint(endPoint , rotation)); matTransNode.setUpdateCallback(new osg::AnimationPathCallback(animationPath)); The animation works, but it seems to me that the speed instantly becomes 1m/s and there's no acceleration. So my question is: is there a way I can specify that, say, in the first second the acceleration is +1 m/s^2, and the next few seconds the acceleration is 0 m/s^2 (so that the speed is constant), and then in the last second the acceleration is -1 m/s^2? Thank you very much for your help. Best, Dat ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG + QT and QTabWidget: Disappearing scene graph
Hi, I am trying to build a Qt application with multiple independent OSG scene graphs, each of which in it's own tab in a QTabWidget. I am using the osgViewer::Viewer (not osgViewer::CompositeViewer) version of the adapter widget from the osgviewerQT example. Each tab has an instance of the adapter widget managing it's scene graph. When the application has more than one tabs and when I try to close one of them, sometimes the scene graph in the other tab may disappear, but I can still pick a node in the scene graph. Some people fixed a similar situation by sharing/not sharing the graphics context among the widgets, but none of the solutions that people suggested for the situations fix my problem. I wonder if I should use a different approach for the OSG + QT integration or if I need to do something particular to the graphics context. I appreciate all of your suggestions. Thank you! Cheers, Angus Lau -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34464#34464 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] rain/snow accumulation on the screen
Thanks Steven .. good hint! -Nick On Thu, Dec 2, 2010 at 11:56 PM, Steven Powers stevenapow...@gmail.comwrote: I'd use a pixel shader for the effects. Pass in the texture that represents the snow overlay and have the shader scale the alpha up and down as it accumulates. Rain would be handled the same way but you'd have to come up with a way to make the water droplets move around on the screen. That should be possible in the shader as well. Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34455#34455 ___ 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] debugging slow path
On 12/02/2010 01:39 PM, Jean-Sébastien Guay wrote: Generalities like the above are most often wrong because so many exceptions exist... It always depends on the situation. You're the developer, you make your decisions with hopefully as much information as required to make the right ones. One of my favorite axioms: All generalizations are false. ;-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphic Context + Texture Memory
On 12/02/2010 05:18 PM, Guy Volckaert wrote: I have a newby question to ask... so please be gentil Let's say I have 2 cameras running in different draw threads. Each camera is also associated with a different graphic context. If I load a 2D texture then each context will have its own opengl texture object (created in the Texture2D::Apply() function). So far so good... My question is: will the opengl driver have 2 instance of the texture object in memory and therefore occuping twice the amount necessary? Or is the driver smart enough to somehow share the same memory space for both instances? The driver won't implicitly share GL objects like textures, but you can configure it to do so explicitly. The GraphicsContext::Traits object has a field where you can specify a shared context. I've never used it personally, so I don't know exactly how it works, but I know it's there. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi Jason, One of my favorite axioms: All generalizations are false. That's a good one, I'll have to remember it. :-) 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
