Re: [osg-users] Windows XP GDI Menu Shadow flicker on ATI Radeon

Hi, we are having the same issues here and I think the problem is related to multithreading. One solution may be to sync your drawing thread to the drawing of windows or to sync the swap operation in double buffered mode. I don't know if that helps, it's just a guess. Richard

Re: [osg-users] osgVolume ready for testing

Hi Robert, Sounds great. I have never done any volume rendering stuff - but you mentioned gpu raytraying. Is related to http://www.gamedev.net/community/forums/topic.asp?topic_id=516446 Can one implement a sparse voxel octree using osgVolume? Richard

Re: [osg-users] Limitation on setUserData, due to setThreadSafeRefUnref()?

Mhh, you got a cyclic dependency in there anyway. Even if you resolve the setThreadSafeRefUnref call, releasing MyMatrixTransform will cause a memory leak. Solution: Don't introduce cyclic dependencies ;-) ___ osg-users mailing list

Re: [osg-users] Multithreading crash due toosgDb::Registry::instance()

http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf Greetings, Richard Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Dienstag, 17. März 2009 10:07 An:

Re: [osg-users] Multithreading crash duetoosgDb::Registry::instance()

] Multithreading crash duetoosgDb::Registry::instance() 2009/3/17 Schmidt, Richard richard.schm...@eads.com http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf Could you explain what the above document is all about... Robert. ___ osg-users mailing list osg-users

Re: [osg-users] new Optimizer improvement rocks

hi, i think this fix breaks the design of the DataVariance field. A better solution would be to fix the loaders and make those objects static which ARE static. Or remove the 'unspecified' flag from the DataVariance enum at all. Richard This improvement to sharing duplicate state in Optimizer

Re: [osg-users] osg and speedtree

Hi Jon, we have tried to integrate speedtree into osg. There are serveral ways to do it: 1. alternative: Just use the opengl example from speedtree and wrap it with a custom drawable. Using this solution there are many pros: * easy to integrate cons: * your are using the texture

Re: [osg-users] Confused about Uniforms and StateSets.

Hi Robert, Hi Colin, As a general rule it's best to minimize the number of StateSet and associated StateAttribute/Uniform/Mode changes, both form the OSG's CPU cost, as well as the cost down on the GPU with stalling the graphics pipeline with state changes. Uniforms in particular can be a very

Re: [osg-users] Confused about Uniforms and StateSets.

Users Subject: Re: [osg-users] Confused about Uniforms and StateSets. HI Richard, On Fri, Aug 15, 2008 at 12:06 PM, Schmidt, Richard [EMAIL PROTECTED] wrote: As a general rule it's best to minimize the number of StateSet and associated StateAttribute/Uniform/Mode changes, both form the OSG's CPU

Re: [osg-users] SpeedTree4.1\OSG2.2 draw lagging

Hi Albino, why don't you //Update camera //Update speedtree forest //Draw forest ??? Greetings, Richard Hi, I have implemented SpeedTree4.1 as a custom drawable in OSG2.2. While the camera is stationary the trees appear to draw correctly. However once the camera moves, the trees rendering

[osg-users] Building static osg and dynamic plugins dlls

Hi, I wonder if it's possible to build osg statically and the plugin dlls dynamically?! Looking at the code currently it does not seem to be possible. The main reason seems to be the static variables (like the registry). Instead of referencing it by the plugin, the pointer of the registry should

[osg-users] Resize event behavior when pressing the fullscreen button

Hi, I just did some debugging of the resize events: KeyDown 102 Resized 1920 1174 Resized 800 600 KeyDown 102 Resized 808 634 Resized 800 600 Resized 1920 1200 KeyDown 102 Resized 1920 1174 Resized 800 600 KeyDown 102 Resized 808 634 Resized 800 600 Resized 1920

[osg-users] observer_ptr threadsafe?

Hi, I wonder if observer_ptrs are threadsafe? Especially when going from observer_ptr to ref_ptr like done multiple times in the database pager. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office:

Re: [osg-users] osgdot graph generation tool

Hi Paul I created it based on your idea. Richard Schmidt, Richard wrote: I have written an osgDot some time ago, maybe you can use it as a base for yours. It's designed as a plugin, contains the cmake makefiles and uses the visitor concept. Curious, is this a similar tool you wrote

[osg-users] SharedStateManager and autoUnrefImageAfterApply

Hi, the SharedStateManager is not able to share TextureAttributes which have the UnrefImageAfterApply flag set. Unreffing the images will 'change' the TextureAttribute with regard to its comparison operator. (i.e. image name, image data, etc.) There are several solutions for this problem: *

[osg-users] SharedStateManager does not check on already compiled TextureAttributes

The ShareStateManager:isShared( ... ) Method does not compare on shared TextureAttributes, but only on shared StateSets. A StateSet (and its TextureAttribute) will get compiled, even if its TextureAttributes are already shared. The causes the texture to be uploaded (when compiling) and being

[osg-users] SharedStateManager does not releaseGLObjects

SharedStateManager does not release any GLObjects (like TextureAttributes, for instance). Possible solution osg::Registry::releaseGLObjects calls a SharedStateManager::releaseGLObjects which releases the GLObjects of the shared Statesets and TextureAttributes. Richard Richard Schmidt

[osg-users] Caching Nodes is not a threadsafe operation

Osg has the option to cache nodes by using osgDB:Registry. Retrieving a node from the cache and attaching them to your subgraph is not threadsafe, because Node::addParent, Node::removeParent and Node::getParents is not threadsafe. Consider this scenario: A node gets 'disposed' in the main

Re: [osg-users] Caching Nodes is not a threadsafe operation

. Robert. On Mon, Oct 13, 2008 at 7:59 AM, Schmidt, Richard [EMAIL PROTECTED] wrote: Osg has the option to cache nodes by using osgDB:Registry. Retrieving a node from the cache and attaching them to your subgraph is not threadsafe, because Node::addParent, Node::removeParent and Node

Re: [osg-users] DataVariance

Hi, i have encountered some similiar problems with multithreading (and the datavariance stuff). One thing I have considered is changing the design of osg::Statesets and osg::StateAttribute to immutable classes. So once the stuff is created you can only change it by cloning it. At least for those

Re: [osg-users] PagedLOD/ProxyNode design discussion

Hi, got another opinion on the PagedLOD and ProxyNode topic. :-) We have been using both nodes for stuff like pseudo loaders as well and I would recommend to change the interface a little bit. There should be a common interface for all pageable nodes like: class PageingNode : public Group {}

[osg-users] [osgEarth]General question

Hi, is there an osgEarth submissions list? Regards, Richard Richard Schmidt System Designer EADS, Defence Security, System Design Center 88090 Friedrichshafen, Germany + 49 (7545) 8-2553 EADS Deutschland GmbH Registered Office: Ottobrunn, District Court of Munich HRB 107648

Re: [osg-users] Modifying SG based on viewpoint location

Hi Paul, we are handling it like the 'perContextData' of StateAttributes gets handled, assuming that we don't have multiple threads per context. Like Robert pointed out some data can be created on the fly - which we are doing with context- and view-dependend statesets. Richard Schmidt

Re: [osg-users] osgOcean release

Wow, looks great! Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Kim C Bale Gesendet: Dienstag, 5. Mai 2009 21:11 An: osg-users@lists.openscenegraph.org Betreff: [osg-users] osgOcean release

[osg-users] Erros with ProxyNode

Hi, there seems to be an error using proxyNodes. If you setup a proxyNode using multiple filenames, not all files may get paged in correctly. This is related to the sequence the databasepager loads nodes, which may vary if you load nodes using curl. There is no association between the filename

[osg-users] Error in Databasepager::run

Hi, there is an error in the osgDB::Databasepager::run method. groupForAddingLoadedSubgraph-getParentalNodePaths(); Is not threadsafe, because the user might delete a parent of groupForAddingLoaded in the UpdateTraversal. Regards, Richard

Re: [osg-users] Error in Databasepager::run

, 2010 at 2:00 PM, Schmidt, Richard richard.schm...@eads.com wrote: there is an error in the osgDB::Databasepager::run method. groupForAddingLoadedSubgraph-getParentalNodePaths(); Is not threadsafe, because the user might delete a parent of groupForAddingLoaded in the UpdateTraversal. Which

Re: [osg-users] Erros with ProxyNode

, rather than multiple ones as it has now. This would avoid any issues about which files are loaded and keep the filename list in sync with the children. This is an API change though, but I can't see a better option right now. Thoughts? Robert. On Wed, Mar 24, 2010 at 1:25 PM, Schmidt, Richard

[osg-users] Some questions about the stategraph of osg

Hi, I got some questions about the stategraph build by osg while culltraversal. So the primary question is: Why is the stategraph build from the root to the leafs of the scenegraph and not the other way around? To explain it a bit, lets make an example: You want to display a model (a car for

Re: [osg-users] Some questions about the stategraph of osg

the elements that are visible. The state graph has to built this way to achieve the standard model of inheritance that the OSG adheres too, to do it any other way would break this inheritance convention and break most features along with it. Robert. On Wed, Apr 9, 2008 at 7:19 AM, Schmidt

[osg-users] Design flaw in ReaderWriter?

Hi, how does a plugin get noticed when osg releases an opengl context and the plugin caches nodes (which are currently not used in the users scenegraph)? Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org

Re: [osg-users] Design flaw in ReaderWriter?

Ok, got it. Registry caches nodes by name or by objectCacheHint. Richard Hi, how does a plugin get noticed when osg releases an opengl context and the plugin caches nodes (which are currently not used in the users scenegraph)? Richard

Re: [osg-users] ...framing only visible objects

Hi, I think the problem here is that some manipulators take the bounding box of the scenegraph to calculate the home position. Setting the nodemask to zero will not affect the bounding box, so the whole hierarchy is still regarded. One solution may be to fully detach the invisible node from the

Re: [osg-users] release and flush GL Objects?

Another problem is, that nodes which are currently not connected to the sceneview/camera won't release their GL objects. Richard On 9/17/07, Rafa Gaitan [EMAIL PROTECTED] wrote: viewer.getSceneData()-releaseGLObjects(); // or getCamera()...

Re: [osg-users] Highlighting with OSG

Hi Daniel Ulrich presented a nice outlining technique on his homepage: http://www.sandbox.de/osg/ Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Moos Sent: Sunday, October 07, 2007 1:52 PM To: osg-users@lists.openscenegraph.org Subject:

[osg-users] CullCallbacks don't have a releaseGLObjects

Is hat intented? A CullCallback may store Statesets and push/pop them on the cullvisitor. It would be nice if those GL Objects get released as well. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org

[osg-users] Fixes for errors in osg::Light, osg::Hint and osg::ClipPlane

Hi, if you have problems with multiple lightsources in your scenegraph not glEnableling/glDisableing correctly this may be a solution for you. First lets recap the error: osg::Light* l1 = new osg::Light(); osg::Light* l2 = new osg::Light(); osg::StateSet* stateSet = new

Re: [osg-users] Fixes for errors in osg::Light, osg::Hint and osg::ClipPlane

the assumption that the light number/clip plane number is invariant once assigned. This is done for efficiency purposes and is a trade off in the design. Robert. On 10/23/07, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote: Hi, if you have problems with multiple lightsources in your scenegraph

Re: [osg-users] Fixes for errors in osg::Light, osg::Hint and osg::ClipPlane

the assumption that the light number/clip plane number is invariant once assigned. This is done for efficiency purposes and is a trade off in the design. Robert. On 10/23/07, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote: Hi, if you have problems with multiple lightsources in your scenegraph

Re: [osg-users] That why I think the osg math is really wrong

Yep, I gonna fix it and send it in asap. Richard On Nov 13, 2007 2:24 PM, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote: This would require a huge a amount of change, however it's compilant to glsl than... (is it?!) While it would be the nice to have the same convention as GLSL, the OSG's

Re: [osg-users] Real Time Ray-Tracing: The End of Rasterization?

To answer the question: Real Time Ray-Tracing: The End of Rasterization? Yeah, I think so. Interesting topic for graphics freaks :-) http://blogs.intel.com/research/2007/10/real_time_raytracing_the_end_o. html -- Adrian Egli

Re: [osg-users] Taking screenshots using OSG 2.2

Depending on our hardware, the viewer may run in multithreaded mode, which means you can't access the openGL context everytime everywhere. Try setting your viewer into singlethreaded mode with ViewerBase::setThreadingModel( ... ) . The context should be available all the time now... Richard