[osg-users] position list
Hi, I just saw setPosition() from OSG Billboard, what is the _positionList for? why define multiple positions for a Billboard? For what could you use multiple Positions? Cheers, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] position list
Hi you can add several drawables to billboard with different positions, and setPosition is there to change position of previously added drawable. Cheers. 25.01.2013, 13:30, DavidHornung horn...@googlemail.com: Hi, I just saw setPosition() from OSG Billboard, what is the _positionList for? why define multiple positions for a Billboard? For what could you use multiple Positions? Cheers, David ___ 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] ARB_instanced_arrays
Hello, I've just stumbled across the ARB_instanced_array extension [http://sol.gfxile.net/instancing.html] It seems to be the most efficient way to handle instanced drawing. Can someone help me out to do this in OpenSceneGraph? As I see, the glVertexAttribDivisor is needed for this, but I'm unsure how to add it. cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Method for Converting FLT files to use DDS Textures
This isn't a direct OSG question, but one I was hoping people on this list might be able to help out with. We have several thousand FLT files that use rgbs as textures. Unfortunately we can't convert these to ive or osgb files as they are shared with another application that is not made in OSG and only supports FLT files. However, both can support FLT files using DDS textures to allow for texture compression. Through testing we have shown a large improvement by doing this, so we want to go that route. The issue is how to convert all of these FLT files over. We can easily batch convert all of the textures, that is not a problem. The issue is updating the FLT files themselves to tell them to point to the dds texture instead of the rgb texture. Having someone manually open up each file and edit the texture names is VERY time consuming. Does anyone know of an easy way we could do this through scripting or a custom converter or something else? The files will stay named the same except for the .rgb will become .dds. Thanks in advance. Karl Cary SAIC Software Developer 301-227-5656 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Method for Converting FLT files to use DDS Textures
Hi Karl, Have you tried using the OSG's write support for OpenFlight, the process would be opening the original model, convert the textures to dds, record the new filename then write out to .flt. Another approach would be cheat ;-) The trick would be to leave the OpenFlight database as is and on the fly re-map the .rgb files to the associated pre-generated .dds file using a osgDB::Registry::ReadFileCallback that intercepts all the readImage() calls and remaps the name then does the load. Robert. On 25 January 2013 12:54, Cary, Karl A. karl.a.c...@saic.com wrote: This isn’t a direct OSG question, but one I was hoping people on this list might be able to help out with. We have several thousand FLT files that use rgbs as textures. Unfortunately we can’t convert these to ive or osgb files as they are shared with another application that is not made in OSG and only supports FLT files. However, both can support FLT files using DDS textures to allow for texture compression. Through testing we have shown a large improvement by doing this, so we want to go that route. The issue is how to convert all of these FLT files over. We can easily batch convert all of the textures, that is not a problem. The issue is updating the FLT files themselves to tell them to point to the dds texture instead of the rgb texture. Having someone manually open up each file and edit the texture names is VERY time consuming. Does anyone know of an easy way we could do this through scripting or a custom converter or something else? The files will stay named the same except for the .rgb will become .dds. Thanks in advance. Karl Cary SAIC Software Developer 301-227-5656 ___ 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] Remove node runtime from another thread
Hi, I want to remove and add a child from/to a group runtime, while rendering is running, moreover, I am doing this from a different thread. What is the thread safe way to do it? Which callback should I use, or how would you do it? If I remove the node in the update callback I get crashes. On adding, it works. Thank you! Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52195#52195 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remove node runtime from another thread
Hi Peter, On 25 January 2013 14:24, Peter Bako osgfo...@tevs.eu wrote: I want to remove and add a child from/to a group runtime, while rendering is running, moreover, I am doing this from a different thread. What is the thread safe way to do it? Which callback should I use, or how would you do it? If I remove the node in the update callback I get crashes. On adding, it works. You need to do the update of the scene during the update phase and can't be safely done multi-threaded without mutexing access to the whole scene graph. If using an update callback you have to be careful about invalidating iterators for the thread calling the update callback. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] API changelog for OSG3
Hi, I am using OSG2.8.2, and recently am trying to upgrade, I am following the cumulative changelogs already but I appreciate if there is any document that explains any possible API changes (I have not seen any). It seems I should be able to start with 3.0 but then I wonder why 2.8 is still popular. Specially I noticed alphapixel kindly provides desktop binaries, that also includes the rather old 2.8.5. Is there any major leap that has made 3.0 dramatically different? Thank you! Cheers, Ehsan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52198#52198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] API changelog for OSG3
Hi Ehsan, For the most part the common API of 2.8.x and 3.0.x has been maintained so applications should port from 2.8.x to 3.0.x easily. Often it will simply be a case of recompiling against the new version, occasionally you might find a difference, if you do just ping the list or have a look through the API in question, if there has been a change that effects you it's very likely it's something like typo fix or minor revision. The big differences between 2.8.x and 3.0.x lie in internals of the OSG, and additional new functionality that sits alongside the old classes. The really big change is that the OSG now supports OpenGL ES, but for an OpenGL/OSG application developer this will just be latent functionality that you won't use and won't be affected by. Robert. On 25 January 2013 15:47, Ehsan Azar dash...@gmail.com wrote: Hi, I am using OSG2.8.2, and recently am trying to upgrade, I am following the cumulative changelogs already but I appreciate if there is any document that explains any possible API changes (I have not seen any). It seems I should be able to start with 3.0 but then I wonder why 2.8 is still popular. Specially I noticed alphapixel kindly provides desktop binaries, that also includes the rather old 2.8.5. Is there any major leap that has made 3.0 dramatically different? Thank you! Cheers, Ehsan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52198#52198 ___ 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] VBO as default
This is a great topic and I am very interested to learn the facts about this. In osgEarth using display lists (on my NVIDIA GTX275) yields a sizable performance boost over VBOs in many scenarios. In some of my tests I've seen a 50%+ reduction in DRAW and GPU times. But there are strange artifacts that seem to be related to the use of display lists with shaders that prevent me from making DL's the default. Driver bugs perhaps? All I can find is speculation and guessing when it comes to using shaders wtih DLs. Same goes for performance comparisons. Some swear you can always get the same or better performance using a VBO, but it's hard to track down the best practices for doing so. Some say NVIDIA drivers have a special code path that speeds up DL's compared to VBOs. Some say it's all about the number of size of your primitive sets. Obviously VBOs are the future since DLs are deprecated. So assembling some best practices for their application is critical! Glenn Waldron / @glennwaldron On Thu, Jan 24, 2013 at 1:57 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Terry, On 24 January 2013 18:21, Terry Welsh mogu...@gmail.com wrote: Mathias's point that display lists are deprecated are probably the best reason to try to make the switch. I'm of this view as well, and would go further and say now that modern graphics developers are working across a wider range of platforms - OpenGL ES and OpenGL and targeting shader pipelines with other modern features in the mix for the these developers using the same features across all the platforms is advantageous, VBO's are very much part of this mix of modern feature spread across targets while display lists are very much a hang up old systems. If OSG isn't close to a major release, I suggest trying it and seeing if it causes problems. Once I get some time to experiment I will have a play with different datasets and see how I get on. I think we'll need to beef up the Optimizer to make sure it handles things better. Also plugins also need updating to create more VBO friendly meshes. To do the job properly we have to take this all into account, I don't feel just switching the default is acceptable as it'll lead to some odd performance drops. As for big vs. small geometries, I used to see differences as well. Years ago, my rule of thumb was to make geometries with fewer than 200 vertices use display lists and bigger ones use VBOs. I just tested this again this morning on NVidia and Intel graphics and I see no difference anymore. However, I'm using a practical test scenario that runs through a scene in my game with geometries ranging in size from about 20 to 1000 vertices. I'm not doing a contrived test. My test scene is about 10% faster using all VBOs vs. all display lists. For modern scene graphs it's likely that VBO's will be strongest, but older scene graphs built with triangle strips and small clumps of geometry will prefer display lists - think OpenFlight databases for an example where display lists will be strongest. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] API changelog for OSG3
On 1/25/2013 8:47 AM, Ehsan Azar wrote: It seems I should be able to start with 3.0 but then I wonder why 2.8 is still popular. In my experience providing OSG consulting and dev services, some of my customers are content with the stability of 2.8.5 (June 2011), and have no particular need for the features in OSG 3.0.1 (July 2011 -- so 2.8.5 is really not that much older per se). Of my customers who *have* moved to 3.0.1, none are making extensive use of the big new features as far as I know. The big features that I recall are: - OpenGL ES support - OpenGL 3 support - New native file format - Performance enhancements for DBPager I know there are many people on the list who are using these features. Whether you have a need to move to 3.0.1 or not is entirely up to you and your needs. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Remove node runtime from another thread
Hi robert, thank you for the reply If using an update callback you have to be careful about invalidating iterators for the thread calling the update callback. Do you have an example, where this is done? what iterators should I check? Yes, as I do it now - sometimes it crashes, and the message is : iterator not incrementable. The exception comes deep from osg libraries. ... Thank you! Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52209#52209 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] API changelog for OSG3
Paul and Robert, Thank you that is exactly the information I was looking for, and for the reference both 2.8.5 and 3.0.1 linked fine and so far I do not see any issues. Well, even 2.8.2 was working great, OSG is an excellent software. I guess I will update to 2.8.5, and then to 3.0.1 later after doing some more tests. Thank you for this great software! Regards, Ehsan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52210#52210 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgShadow LiSPSM culling problem
Hi Robert, I checked the svn/trunk last week and as you said the clipping problem seems to have been resolved. After exploring your new VDSM implementation further, it seems that there is a bug with the ReceivesShadowTraversalMask (or I am missing something). If I turn off this mask bit the geometry is culled out entirely. The Casting bit seems to work fine as expected. This is demonstrated in the osgshadow example by setting the mask on one of the models. For instance adding: scene-setNodeMask(scene-getNodeMask() ~ReceivesShadowTraversalMask); in Model Three. I'm attempting to track this down now, but hoped you might have some insight. Thanks much, Garrett -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52212#52212 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] API changelog for OSG3
I'd wait until the next stable release before going with 3. There's several bugs in the 2.9.x/ 3 releases that have been resolved. Such as incorrect text rendering, buggy slow path rendering and some sort of GL resource handling bug that was causing reuse of invalid display lists. These have all been fixed in the 3.1.x branch. On 25 January 2013 17:16, Ehsan Azar dash...@gmail.com wrote: Paul and Robert, Thank you that is exactly the information I was looking for, and for the reference both 2.8.5 and 3.0.1 linked fine and so far I do not see any issues. Well, even 2.8.2 was working great, OSG is an excellent software. I guess I will update to 2.8.5, and then to 3.0.1 later after doing some more tests. Thank you for this great software! Regards, Ehsan -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BAK extension
In my experience a .bak file is typically an indication that the file is a back-up copy of a file. Many programs that run active log files typically copy the current log file to .bak etc As to a data, model, texture format that use a .bak extention I have never come across one __ Gordon Tomlinson -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, January 24, 2013 10:41 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] BAK extension On 22 January 2013 09:49, chandrasekar gopal chandraseka...@ymail.com wrote: '.BAK' extension refers usually to what kind of file? .BAK extension has nothing to do with any of the formats that the OSG loads. Are you not able to use a search engine for your answer? Or any experience with an editors or tools that make a backup when modifying a file??? This type of question is really not something one would expect the OSG community to answer or to need to answer as it has nothing to do with the OSG, OpenGL or graphics. 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
