Re: [osg-users] Erros with ProxyNode
Hi Robert, yep, i think the easiest solution would be to have a proxynode with just one filename. For the 'future' I would prefer an association (just the index of the filename in the group) between the database query and the node which gets paged in. So the database pager can 'mark' the query as loaded. This would allow additional features like: * Let the ProxyNode decide if it continues to query if the node isn't loadable. * Mark a node as dirty, so that the database pager will replace it with a freshly loaded node. The 'null' children problem may be solved by having dummy nodes which are still marked as dirty. Richard -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Mittwoch, 24. März 2010 15:36 An: OpenSceneGraph Users Betreff: Re: [osg-users] Erros with ProxyNode Hi Richard, Interesting bug... fixing it is likely to be a bit awkward given the currently implementation of ProxyNode/DatabasePager, doing one file at a time won't even address all the potential issues as the ordering can sit get out of sync if early children fail to load but later children succeed. Adding support into DatabasePager to allow it to set specific children would require osg::Group to support having null children, something which has quite a few potential pitfalls. My first thought for a solution would be to change ProxyNode so that is only has one filename, 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 richard.schm...@eads.com wrote: 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 and the node which gets paged in, so the proxyNode, request may request nodes twice. Possible solution: Let ProxyNode::traverse only request one Node at a time. If the file is not found however, the follow up filenames will never be requested. Regards, Richard ___ 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] 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 and the node which gets paged in, so the proxyNode, request may request nodes twice. Possible solution: Let ProxyNode::traverse only request one Node at a time. If the file is not found however, the follow up filenames will never be requested. Regards, Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error in Databasepager::run
Hi Robert, i am using 2.8.2 The method getParentalNodePaths is used to retrieve the parent node paths. This is done in the database pager thread. However these node paths might change while traversing them, because the user may change the scenegraph in the update loop. Richard -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Mittwoch, 24. März 2010 15:45 An: OpenSceneGraph Users Betreff: Re: [osg-users] Error in Databasepager::run Hi Richard, On Wed, Mar 24, 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 version of the OSG you looking at? svn/trunk has been significantly re-factored to deal with various different cases where threading issues were causing problems before. So if you aren't using svn/trunk then try it out, if you think svn/trunk is still not thread safe then could you be a bit more specific about which parts you think might not be thread safe. 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] [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 Chairman of the Supervisory Board: Thomas Enders Managing Directors: Dr. Stefan Zoller (Chairman), Dr. Christoph Hoppe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 {}
and then:
class ProxyNode : public PageingNode {}
class PagedLOD : public PageingNode {}
and now one can easily add custom implementations on top of PageingNode
like
class MyCustomNodeWhichRefreshesTheSubgraphEvery10Seconds : public
PageableNode {}
The design of the databasepager would be cleaner as well.
Regards,
Richard
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 Hello all, Many moons ago I emailed the list to announce my intentions of releasing an ocean rendering library for the OSG. Well after many delays and things getting in the way i've put some code up for your perusal. http://code.google.com/p/osgocean/ At the moment i have only put the surface simulation and ocean rendering code online there is more to follow. But I wanted to get this out as a point for discussion. It uses a precomputed FFT ocean simulation combined with a geomipmapping lod algorithm. This has obvious limitations as the ocean surface is of a fixed size, but I'm afraid I don't have time at the moment to come up with something slicker. The FFT technique can be used in conjunction with a geoclipmap approach which I think would allow for an endless ocean and would be more usable, so if anyone wants to pitch in with that get in touch as it would be valuable addition and quite easy to slot in. One of the big problems with the design is turning parts of the shader on and off. I've used boolean uniforms for this, but it's messy. Ideally it would be more effecient either to dynamically generate the shader or insert #defines to include or block out bits of code. I suspect the latter would be the easiest to implement but i noticed Hydrax chooses to create them on the fly. I'd love to hear from the more experience OSG programmers about this, as I anticipate that this aspect will get rather complicated quite quickly. I remember there was quite a lot of interest in collaborating, if the will is still there get in touch either by email or here and we'll chat about where we can take it. So have a play and let me know what you think! Regards, Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Paul Martz Gesendet: Donnerstag, 23. April 2009 22:30 An: 'OpenSceneGraph Users' Betreff: Re: [osg-users] Modifying SG based on viewpoint location Yeah, what does modify mean, that's the question. I have a client who is modifying the scene graph in a number of ways during the cull traversal and is therefore only able to run SingleThreaded. I'm still digging in to find out exactly what it is they are doing that isn't thread safe (even the client isn't exactly sure, or isn't able to spell it out precisely for some reason), but it seems to be some type of viewpoint-dependent LOD-like modification. In the meantime, I wanted to poll the community for thread-safe alternatives. So I want to thank all that have replied, especially Robert for telling me how those OSG classes handle this requirement. At some point, I'll summarize all this into some kind of document or posting, so that people don't go down the non-thread safe path in the future. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: Thursday, April 23, 2009 10:15 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Modifying SG based on viewpoint location Paul Martz wrote: Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph I guess the important question is, what kind of modifications exactly? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] 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: OpenSceneGraph Users Betreff: Re: [osg-users] Multithreading crash due toosgDb::Registry::instance() Hi Anthony, I have avoided adding a mutex into the Registry::instance() method as it would incur a cost for every call to it, and it's only the very first call that it's an issue for so it's the only time you need to be careful about access to it. Given I don't want to introduce a mutex one then has to make sure the instance() method is called up front in your app, and most OSG applications will call it during the single thread init of the app, and in your case you'll just need to call it explictly. An alternative might be to have a proxy class call the instance() method, or perhaps just have the viewer constructor call instance() just in case. Robert. On Tue, Mar 17, 2009 at 6:25 AM, I-Nixon, Anthony D anthony.d.ni...@boeing.com wrote: I've encountered a crash when using CompositeViewer in Multithreaded mode due to concurrent access to osgDb::Registry::instance(). The usage scenario is having two views (that have an empty scene graph - since no data has been loaded, osgdb::Registry::instance() hasn't yet been called). On the first frame, each of the render threads calls osgDb::Registry::instance(), and one gets back a null pointer (which is kind of bad for an instance :-) The fix for me is easy - just call osgDb::Registry::instance() sometime before starting rendering, but a more general solution would be better, of course. This is with OSG 2.8.0 - although there don't appear to have been any changes in this area in the trunk, either. I've only confirmed this on Windows XP and Visual C++ 8. Anthony Nixon ___ 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] Multithreading crash duetoosgDb::Registry::instance()
The document is about a design pattern called double locking, which is
especially suitable for singleton objects in multithreaded environments.
The pattern is essentially this:
static Singleton *instance (void)
{
// First check
if (instance_ == 0)
{
// Ensure serialization (guard
// constructor acquires lock_).
GuardMutex guard (lock_);
// Double check.
if (instance_ == 0)
instance_ = new Singleton;
}
return instance_;
// guard destructor releases lock_.
}
The guard mutex is only accessed in the initialization phase of the singleton.
Once instance_ is set the guard does not need to be queried anymore.
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 11:07
An: OpenSceneGraph Users
Betreff: Re: [osg-users] 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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 objects you don't have to think about datavariance anymore. Attached you will find a 'setup' design pattern, which helps you spawning immutable objects. Richard PS.: Just an idea. TestClass.cpp Description: TestClass.cpp TestClass.h Description: TestClass.h Test.cpp Description: Test.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Caching Nodes is not a threadsafe operation
Hi Robert, I am using osg 2.6.0 and you're right, osg::Node as well as osg::Stateset use getRefMutex for protecting the access to the parent list. However getRefMutex isn't used in the atomic refcounted case and osg::StateAttribute doesn't use a mutex at all for protecting the parents. The method (Node|Stateset|StateAttribute) ::getParent, ::getParents, ::getNumParents doesn't seem to be protected by a mutex as well. I wonder if that's intented. Richard HI Richard, Which version of the OSG are you using? The OSG has had mutex protection of addParents/removeParent() for quite some while. 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::getParents is not threadsafe. Consider this scenario: A node gets 'disposed' in the main thread, because the 'user' deatches the node from the graph. At the same time the node may be loaded from the cache by the databasepager. While the refcounting will work perfectly, the calls to Node::addParent and Node::removeParent is not threadsafe, causing the node to get an invalid parent setup. The same holds for StateSet and StateAttribute (because they have parentlinks as well). Example: The openflight loader stores static ref pointers to various StateAttributes. The StateAttribute::addParent and StateAttribute::removeParent may be called from multiple threads, i.e the main thread releases a model, while another thread (the databasepager) loads the model. Possible solution: Make the parent links threadsafe. For Statesets and StateAttributes I would remove them and implementing an immutable pattern instead. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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: * The StateManager disables UnrefImageAfterApply, or * Images don't get unreffed at all, but unref their data internally. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 released (when shared) again. Possible solution: ShareStateManager:isShared should compare and shared TextureAttributes as well. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 thread, because the 'user' deatches the node from the graph. At the same time the node may be loaded from the cache by the databasepager. While the refcounting will work perfectly, the calls to Node::addParent and Node::removeParent is not threadsafe, causing the node to get an invalid parent setup. The same holds for StateSet and StateAttribute (because they have parentlinks as well). Example: The openflight loader stores static ref pointers to various StateAttributes. The StateAttribute::addParent and StateAttribute::removeParent may be called from multiple threads, i.e the main thread releases a model, while another thread (the databasepager) loads the model. Possible solution: Make the parent links threadsafe. For Statesets and StateAttributes I would remove them and implementing an immutable pattern instead. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 yourself, or is this my original tool completely restructured? It's hard to tell :) Paul Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thrall, Bryan Gesendet: Montag, 6. Oktober 2008 18:23 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgdot graph generation tool Jean-Sébastien Guay wrote on Monday, October 06, 2008 10:19 AM: Hi Bryan, Another improvement I'd be interested in seeing applied is: http://sourceforge.net/tracker/index.php?func=detailaid=1866010group_id=139833atid=744686 Yes, I saw that, I just wanted to keep the modifications small w.r.t. Mike's version of osgdot.cpp in the osgtoy SVN. But I agree, doing that in a visitor is more in keeping with OSG's normal practices. If I make an output plugin out of this, I'll make it with a visitor, as then the modifications will be pretty large anyways. :-) I just didn't want my patch to be forgotten, and thought this was a good opportunity to bring it up :) I'm glad I'm not the only one who thinks this is a nifty tool and is working to improve it. Thanks! ___ 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] 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 1200 KeyDown 102 Resized 1920 1174 Resized 800 600 Key 102 is the Fullscreen Key. Somehow I would expect that it's flipping between 1920 1200 and 800 600. Btw: I am using the win32 graphics window. Richard Richard Schmidt System Designer EADS Deutschland GmbH Organisationseinheit (SDGE1) EADS Deutschland GmbH Registered Office: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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: Ottobrunn District Court of Munich HRB107648 Chairman of the Supervisory Board: Dr. Thomas Enders Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht This E-mail And any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality Or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 be injected into the dll when loading it. Any other ideas? The one above seems to be a major rewrite. Another solution would be to link completely static, which means one would lose the whole plugin system. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 (translations?) appears to lag in relation to the rest of the scene. Once the camera stops, they catch up. In my test application, I integrate a speedtree forest into a custom drawable and have a simple terrain model loaded into a osg::Node. The scenegraph has a Group node as the root with the custom drawable and terrain as children. Screenshot of the scene with a stationary camera: The trees are rendering where they were placed. (feel free to admire the programmer art :) http://img293.imageshack.us/img293/5408/stationaryrv8.jpg Screenshot of the camera being moved down: Once the camera stops, the trees will catch up and the scene will render correctly like in the above screenshot. http://img242.imageshack.us/img242/764/lagmq5.jpg Implementation details: I've adapted my implementation using the reference application that comes with speedtree as it suits my needs pretty well. I'm happy to leave LODding and culling to speedtree. The drawImplementation of my custom drawable: (speed tree code is commented out in case it violates the license agreement. It's just a line of code.) glGetFloatv(GL_PROJECTION_MATRIX, projMat); glGetFloatv(GL_MODELVIEW_MATRIX, modelViewMat); glPushAttrib(GL_ALL_ATTRIB_BITS); //Draw speedtree forest //Update speedtree camera with the camera's position, projMat, modelViewMat and false as the final parameter. //Update wind glPopAttrib(); renderInfo.getState()-apply(); //needed? I set the boundingbox to be osg::BoundingBox bbox(0,0,0, 999, 999, 999); My rationale behind this is to make a HUGE box so that OSG doesn't try culling it. I leave that upto speedtree. Is there a better way? Finally, I set this drawable not to use display lists, so that the speedtree code called from drawImplementation always gets called. I haven't found a good strategy to solve this yet. - I've moved around API calls. - Look into forcing draw calls. - Forced OSG to not use multithreading - Prayed to some deity My next plan of attack will be to throw in the osgteapot custom drawable example and see if the same issue occurs but with teapots. Any ideas or thoughts are greatly appreciated. Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Confused about Uniforms and StateSets.
Hi again,
i tried using vertex attributes like this:
void PartialTreesDrawable::drawImplementation(osg::RenderInfo
renderInfo) const {
const osg::Drawable::Extensions* extensions =
osg::Geometry::getExtensions(renderInfo.getContextID(),true);
if ( extensions _drawable.valid() _speedTrees.valid()
!_speedTrees-_trees.empty() ) {
Speedtrees::Trees trees = _speedTrees-_trees;
Speedtrees::Trees::iterator it;
for ( it = trees.begin(); it != trees.end(); ++it ) {
extensions-glMultiTexCoord3fv(GL_TEXTURE0+4,
it-_position.ptr() );
extensions-glMultiTexCoord4fv(GL_TEXTURE0+5,
it-_rotation.ptr() );
extensions-glMultiTexCoord1f(GL_TEXTURE0+6, it-_scale );
extensions-glMultiTexCoord1f(GL_TEXTURE0+7, it-_windOffset );
// draw the tree
_drawable-drawImplementation( renderInfo );
}
}
}
However it seems to run slower than the implementation using uniforms.
Any ideas? Is this the recommend way for uploading variables to the
shader?
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Friday, August 15, 2008 1:40 PM
To: OpenSceneGraph 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 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 expensive state change as some drivers treat uniforms as
constants and recompile or relink the shader program.
I doubt that this is reality.
Well perhaps you need to do some reading up on uniforms and GLSL and
the optimizations that drivers are allowed to do and do undertake.
In particular Speedtree uploads the
treeposition (and other per instance parameters) via a uniform and is
known as a fast tree rendering api.
This suggests that that uniforms they are varying aren't ones that can
be easily optimized away, or that they are missing a trick to
optimizing the code further.
For commonly varying values you should always use vertex attributes,
the graphics hardware and drivers are all optimized for handling
varying vertex attributes. Uniforms are very different from vertex
attributes, uniforms are akin to the parameters you set in glLight,
glTexGen etc, they are a state change.
It would be nice if uniforms do not affect stateset sorting or require
statestets at all. I don't know if that fits into the current
architecture, however osg should provide a mechanism for updating a
single uniform many times in the same frame.
The mechanism is via osg::StateSet, it fits with the granularity of
state that OpenGL and the hardware suits, so it's the right place for
them. However, the CPU cost is higher than I'd like, the loose
coupling between uniforms and programs makes the OSG pretty flexible,
but wiring up uniforms to they current active program is relatively
expensive - perhaps this could be improved, but it won't change the
fact that uniforms aren't meant to be treated like vertex attributes
and changed often.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 expensive state change as some drivers treat uniforms as constants and recompile or relink the shader program. I doubt that this is reality. In particular Speedtree uploads the treeposition (and other per instance parameters) via a uniform and is known as a fast tree rendering api. Regradless of the driver however modelling the example Colin explained as well as the one provided by Speedtree) is expensive in OpenSceneGraph. It would be nice if uniforms do not affect stateset sorting or require statestets at all. I don't know if that fits into the current architecture, however osg should provide a mechanism for updating a single uniform many times in the same frame. The way to avoid using lots of separate Uniforms is to move to using vertex attributes attached to an osg::Geometry. In the osgParticular::PrecipitationEffect I tackled this by sharing a single shared geometry and then having a custom drawable that uses this shared geometry to send down most of the data and then in addition sets the vertex attribute I wanted to vary. The osgforest example also does a similar trick in the GLSL path. Robert. Richard. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 loading/management of speedtree * you loose the ability of multithreading/multicontext stuff of osg, because the speedtree example uses CG in a non-multicontext version 2. alternative: Create a osg wrapper for CG (as custom stateattributes) in osg and use the example to build the appropiate osg geometry. pros: * no need to touch the speedtree shader * useable in multicontext/multithreaded environment. cons: * Integrating CG into osg is a daunting task. However CG does not make any guaranties about the opengl state after it has been applied, so you can't use it with other stateattributes or in a hierarchy of statesets. So I wouldn't recommend using CG at all in OSG. 3. alternative: Like above you port all the geometry to osg as well as the CG shaders to GLSL. Porting the shaders to GLSL is easy. I haven't done anything with shaders before, but if you take a look at Mike Weiblen GLSL quickrefernce it should be really easy to port the CG shader. pros: * now is pure osg, you don't have any custom drawable or wrappers in it, EXCEPT: SpeedWind - Speedtree provides a class for creating wind. Just build a basic wrapper which gets called in the update cycle. The next thing you have to care about is how you organize your scenegraph (for LOD stuff). Thats were I am currently stuck with. Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Newell Sent: Thursday, August 07, 2008 1:56 AM To: OpenSceneGraph Users Subject: [osg-users] osg and speedtree Hi everyone, I know this question has been asked previously but I have not been able to locate a definitive answer so.. We have a need to implement speedtree into OSG, and am wondering if anyone has had prior success with this? From a cursory glance it does not appear that it will be as straight forward as the SPT documentation would have us believe. If so does anyone have any pointers, tips or perhaps even reference code they may be willing to share that may be of assistance??? I would be grateful for any help! cheers Jon Newell ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 has boosted my app's performance 10-20% on my various computers at work. Nice job, and thanks. I'm running a pretty complex .flt city model with lots of textures for all the buildings and cars. It also loads lots of external models. I wonder if others are seeing this much improvement. revision 8513: Changed the Optimizer::StateVisitor so that it can individually decide whether to optimize away duplicate state with dynamic, static and unspecified DataVarience. By default the code now optimizes away duplicate state with either static and unspecied state, previously it was just handling static state. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Some questions about the stategraph of osg
Hi Robert, thanks for the quick reply. I think one can solve the inheritance stuff regardless of the sorting of the state graph. In the current implementation you already provide both directions (inheritance and overriding of states) and in a bottom up implementation of the stategraph one could do the same?! (Don't know, but I think so). But inheritance brings me to another example. By adding Transform Nodes one adds transformations to the initial transformation of the model. You 'inherit' the transformation of the base model and add your own stuff by adding an transformnode on top of it. Exactly the same thing I like to do with shaders. The shader should be attached to the geometry. By adding instance parameters on top of it I like to change the behaviour of the shader. This is possible in the current implementation, however one will loose the stategraph sorting, possibly causing the shader to be rebind all the time. To benefit from startgraphsorting one has to 'mix' the instance parameters below the shader statesets in the graph, which is really difficult, if you think about an abstract layer, like the plugin system. (Is it?) Richard Hi Richard, I'm afriad I'm not going to dive into a complex topic as I'm away on a trip, I'll try to give a quick reply to one quetion. 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? All OpenGL state in the OSG is inherited top down, and does so in the same way that scene graph is structured from the root at the top to the leaf at the bottom. The osgUtil::StateGraph is built as mini graph that mimics the scene graph structure and the inheritance that it implies, but contains only 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, Richard, SDGE1 [EMAIL PROTECTED] wrote: 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 example), which is available as .ive file. The model itself has a complex stateset with many texturebinds. For each instance of the model in your scene you add a transform node and a stateset which sets the material color. By doing so you will loose the ability of osg to build a proper stategraph, the stategraph becomes 'fragmented' because of setting the material color in the parent stateset of the models graph. The general problem is: In the scenegraph, the parameters of the instances are in the inner nodes (the transform nodes). In the stategraph, the parameters of the instances are at the leaf nodes. Just consider another example: Lets assume you want upload positions/rotations through uniforms to a shader. The statesets of the uniforms have to be placed under the shader stateset to get the stategraph sorting work properly. I am currently working on integrating speedtree into osg. I converted the shaders to glsl and the parameters to uniforms. The geometry is setup like the examples of speedtree. It's all working pretty well, but I am stuck with the problem above. I'd like to organize the scenegraph as shown at the attached image (please ignore the PositionAttitudeTransform, the position and rotations are part of the stateset InstancesParms). Basics of speedtree: *four different shaders( in the example above are just three of them) *3 levels of statesets: *first level: the shaders *second level: the 'template' parameters of the model (like texture and material properties *third level: the instance parameters (like scale, position, windoffset, rotation) Now consider adding level of detail to the graph and try to organize the graph like osg needs it: The shaders at the root, than the 'template' stateset and than the instances. The result is that one has to clone the whole LOD hierarchy for each shader which is not a desired solution. I would prefer, if the stategraph is build from bottom up, instead of top down. Greetings, Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 example), which is available as .ive file. The model itself has a complex stateset with many texturebinds. For each instance of the model in your scene you add a transform node and a stateset which sets the material color. By doing so you will loose the ability of osg to build a proper stategraph, the stategraph becomes 'fragmented' because of setting the material color in the parent stateset of the models graph. The general problem is: In the scenegraph, the parameters of the instances are in the inner nodes (the transform nodes). In the stategraph, the parameters of the instances are at the leaf nodes. Just consider another example: Lets assume you want upload positions/rotations through uniforms to a shader. The statesets of the uniforms have to be placed under the shader stateset to get the stategraph sorting work properly. I am currently working on integrating speedtree into osg. I converted the shaders to glsl and the parameters to uniforms. The geometry is setup like the examples of speedtree. It's all working pretty well, but I am stuck with the problem above. I'd like to organize the scenegraph as shown at the attached image (please ignore the PositionAttitudeTransform, the position and rotations are part of the stateset InstancesParms). Basics of speedtree: *four different shaders( in the example above are just three of them) *3 levels of statesets: *first level: the shaders *second level: the 'template' parameters of the model (like texture and material properties *third level: the instance parameters (like scale, position, windoffset, rotation) Now consider adding level of detail to the graph and try to organize the graph like osg needs it: The shaders at the root, than the 'template' stateset and than the instances. The result is that one has to clone the whole LOD hierarchy for each shader which is not a desired solution. I would prefer, if the stategraph is build from bottom up, instead of top down. Greetings, Richard attachment: best.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduardo
Gutiérrez Sanmartín
Sent: Friday, November 16, 2007 1:47 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Taking screenshots using OSG 2.2
Hello,
While using OSG version 1.20, I was taking screenshots with the following code:
while( !viewer.done() )
{
viewer.frame();
// Here I get x, y, width and height.
osg::Image *image = new osg::Image;
image-readPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE);
osgDB::writeImageFile(*image, capture.bmp);
}
The obtained image was correct - however, with OSG 2.2 it is not.
I am obtaining a totally black image (and it seems that x, y, width and height
are the right values).
Is there something wrong here? How do I take a screenshot of my application?
Thx!
Edu
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 decision to use post multiplication long way pre-dates GLSL. The OSG follows how OpenGL actually stores matrices, rather than what is documented and adopted for GLSL. Changing to fit GLSL conventions would require refactoring a lot of OSG and critically user code, and in a way that would be awkward to catch automatically catch possible bugs that it'd introduce. If we were still in pre beta days it'd be easier, but right now we have a lot less flexibility, the 2.x has to stick with the current convention. Fixing the Vec Quat bug is important to do, I'll currently focused on other work right now so can't tackle this right away. Any chance you fix the offending methods and send them into osg-users? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-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 osg::StateSet(); stateSet-setAttributeAndModes( l1 ); stateSet-setAttributeAndModes( l2 ); l1-setLightNum( 0 ); l2-setLightNum( 1 ); 1. This won't work, because the stateset caches the type/member of the attribute. If you change the member afterwards things will blow up... 2. Next bug is here that osg caches stateattributes internally, using the method cloneType. cloneType however needs to clone the member as well, so the glDisable will be called for the correct light. Attached you will find a version which fixed (2.) . For 1. the interface osg provides should be changed (currently catched using assertions). Richard Hint.cpp Description: Hint.cpp Light.cpp Description: Light.cpp ClipPlane Description: ClipPlane Hint Description: Hint Light Description: Light ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for errors in osg::Light, osg::Hint and osg::ClipPlane
Hi Robert, a proper solution could be by setting member variables(lightnum, clipplane, etc.) only through the constructor. Richard Hi Richard, Could you send future submissions to osg-submissions as ones to osg-users can easily be lost. As for caching in StateSet this does make 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 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 osg::StateSet(); stateSet-setAttributeAndModes( l1 ); stateSet-setAttributeAndModes( l2 ); l1-setLightNum( 0 ); l2-setLightNum( 1 ); 1. This won't work, because the stateset caches the type/member of the attribute. If you change the member afterwards things will blow up... 2. Next bug is here that osg caches stateattributes internally, using the method cloneType. cloneType however needs to clone the member as well, so the glDisable will be called for the correct light. Attached you will find a version which fixed (2.) . For 1. the interface osg provides should be changed (currently catched using assertions). Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixes for errors in osg::Light, osg::Hint and osg::ClipPlane
Dooh, I submitted an outdated version. The clipplane ::cloneType must clone the MemberType only and not the clipplane as well. Richard Hi Richard, Could you send future submissions to osg-submissions as ones to osg-users can easily be lost. As for caching in StateSet this does make 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 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 osg::StateSet(); stateSet-setAttributeAndModes( l1 ); stateSet-setAttributeAndModes( l2 ); l1-setLightNum( 0 ); l2-setLightNum( 1 ); 1. This won't work, because the stateset caches the type/member of the attribute. If you change the member afterwards things will blow up... 2. Next bug is here that osg caches stateattributes internally, using the method cloneType. cloneType however needs to clone the member as well, so the glDisable will be called for the correct light. Attached you will find a version which fixed (2.) . For 1. the interface osg provides should be changed (currently catched using assertions). Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ClipPlane Description: ClipPlane ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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] Highlighting with OSG Hi @all I'm new here and I try to make a simple hightlighting effect with OpenSceneGraph. I want to highlight triangles, vertexes and lines from a loaded model by picking it with the mouse. The picking isn't the problem. But how can I make a highlighting effect? For example change the color of the object... A second Question... If I loaded a model into my scene. Where can I get a list with all the triangles and its vertexes? Thank you! Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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()... viewer.getCamera()-getGraphicsContext()-getState()-reset(); osg::flushAllDeletedGLObjects(0); Yes, This works better, Thank You!, there is some issues with PagedLOD nodes, so I need to debug more and see how to solve them. It might well be the database pager has objects still held into its internal lists but not just merged. Once you get to the bottom of it we could possibly wrap up all that is required in a clean up method in osgViewer::Viewer/CompositeViewer/GraphicsWindowEmbedded. BTW, could you try removing the original GraphicsWindowEmbedded and replace it with new one as this is effectively you are doing - changing the graphics context from underneath the viewer. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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 scenegraph... Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
