[osg-users] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
Hi everyone. Check out the online OSG demos here: http://www.3djam.com/roozz/Demo/osg_demo.aspx (http://www.3djam.com/roozz/Demo/osg_demo.aspx) Tell us what you think. We also seek students who want to do a project on this new technology. Evaluate the potentials and compare with other technologies, speed, cost, etc. -- Just a few words about What is the Roozz plugin: * It allow you to run 3D applications embedded in a webpage quickly and easy? * It allow you to get full access to CPU and GPU from the Roozz browser plugin. * It will take you less than 5 minutes to publish your .exe application using the Roozz plugin (no need to recompile you .exe) Try the windows beta version and give us feedback. www.3djam.com (http://www.3djam.com) [Image: http://www.3djam.com/roozz/images/main.png ] For more detailed information see the tutorial videos. Thanks, Roozz team.[/img] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11154#11154 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
On Thu, Apr 30, 2009 at 9:15 PM, Michael Platings mplati...@pixelpower.com wrote: However, I've discovered that using std::for_each in place of a for loop provides a massive speed up - it performs the same is if iterator debugging were disabled. So I'd like to replace the frequently run for loops in osg with a std::for_each equivalent. This would be a major performance win for Visual Studio users, and I assume it wouldn't hurt everyone else. Before I do this I want to check will this be OK with you guys? This is a VS bug, not a OSG one. Introducing workarounds for a VS bug that may has a risk of breaking the OSG is one that I'd be very cautious about as any code that isn't actually broken introduces a risk of introducing bugs, so changing for loops to for_each it's not a without risk. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Edge blending
Hi Su Hu, Have a look at Projection Designer and the osgDistortion example. http://orihalcon.jp/projdesigner/ http://orihalcon.jp/download/osgdistortviewer_src.zip Regards Brede On Wed, Oct 15, 2008 at 10:18 AM, su hu ttts...@gmail.com wrote: Hi all, I want to implement edge blending by osg, but I don't know which way is better. Our requirement of edge blending is simple: overlapped area of two screens is rectangular. If someone has done it, please give me some advice. Much appreciation to any reply. Regards, Su Hu ___ 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] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
Hi, Good work, it works very well on my machine ! I always hoped that such a plugin could become a standard installed on every machine to easily deploy applications via the net. For the OSG examples, should it be possible to have an example showing an OSG app running inside the browser and not on fullscreen ? On Fri, May 1, 2009 at 9:31 AM, Thomas tho...@3djam.com wrote: Hi everyone. Check out the online OSG demos here: http://www.3djam.com/roozz/Demo/osg_demo.aspx ( http://www.3djam.com/roozz/Demo/osg_demo.aspx) Tell us what you think. We also seek students who want to do a project on this new technology. Evaluate the potentials and compare with other technologies, speed, cost, etc. -- Just a few words about What is the Roozz plugin: * It allow you to run 3D applications embedded in a webpage quickly and easy? * It allow you to get full access to CPU and GPU from the Roozz browser plugin. * It will take you less than 5 minutes to publish your .exe application using the Roozz plugin (no need to recompile you .exe) Try the windows beta version and give us feedback. www.3djam.com ( http://www.3djam.com) [Image: http://www.3djam.com/roozz/images/main.png ] For more detailed information see the tutorial videos. Thanks, Roozz team.[/img] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11154#11154 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom search paths...
Hi Robert, Thanks for the reply, I'll look into this approach. Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Neil, The ReaderWriter::Options structure has a data file path list built into it, this is checked before the main data file path list stored in the Registry is checked. So if you want a certainly directory checked just put it on your path, either via the ReaderWriter::Options or via the Registry using osgDB::s/getDataFilePathList. You'd typically use Options when you only want to locally set the search path. Robert. On Thu, Apr 30, 2009 at 5:29 PM, neil.hug...@tesco.net wrote: Hi All, I'd like to pick your collective brains for a moment in regards to search paths for files within OSG. I'm currently working on the 3DS plugin for OSG, looking at a little problem. The scenario is as follows. I have a 3DS file whose material table references a texture. When this model was created the texture resided in the same directory as the model, and hence no path information was stored - at least I guess that's why there is no path information for the texture referenced. Now when I want to load this model, the 3DS loader tries to locate the texture in the directory that the model resides in - using the findfileindirectory function - but as the texture is no longer in this directory, the function fails to find the file, and the 3DS reader decides not to put a texture on the geometry. Now, the thing is, I do know where the texture is relative to the model. Its in a parallel directory. In fact, if I ignore the result of the find file, and merely just try and load the image, my readfilecallback handler amends the path to the file, and the image loads. So, what I was wondering was whether there already exists a way by which I can direct the findfileindirectory function to take account of a custom search algorithm? I've had a look and I can't spot one, but wondered if others might know differently? On the assumption that no such methodology exists, my thoughts were that I could amend the existing function to call a custom defined function on the user supplied readfilecallback - if one has been supplied - in the event where the readfileindirectory function has failed. Any thoughts ? Thanks for any assistance/comments. Kind regards, Neil. ___ 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] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
Hi Serge Lages I always hoped that such a plugin could become a standard installed on every machine Me too. :-) For the OSG examples, should it be possible to have an example showing an OSG app running inside the browser and not on fullscreen ? Does it run as full screen on your machine? (it is not supposed to) What is your OS version and browser and version? Did you try just one of the OSG demos or several of them. On my test machines it run inside the browser. [Image: http://www.3djam.com/roozz/images/temp/osg_in_crome.jpg ] /Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11160#11160 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Broken Windows build
I hadn't tested this yet, and I can confirm Oleg's errors. I have submitted a fix. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 01 May 2009 08:46 To: OpenSceneGraph Users Subject: Re: [osg-users] Broken Windows build Hi Oleg, The OSG-2.8 release went out with the UTF8 code in place, svn/trunk doesn't change this in any way. Lots and lots of Windows users have been testing it out across different compilers and not reported problems. What build suit are you using? Have you compiled other OSG versions OK? Robert. On Thu, Apr 30, 2009 at 8:11 PM, Oleg Dedkow oded...@gmx.de wrote: Hi Robert, the latest SVN revision cannot be build under Windows if OSG_USE_UTF8_FILENAME config option is enabled. The error occurs in FileUtils.cpp file, line 663, since there is no UNICODE-capable version of the GetProcAddress function. The OSGDB_WINDOWS_FUNCT_STRING makro is defined as follows in that case #define OSGDB_WINDOWS_FUNCT_STRING(x) L ## #x LW Thus the second parameter cannot be converted from wchar_t to LPCSTR. Should we convert the second parameter from wchar_t* to LPCSTR or use the same definition for the OSGDB_WINDOWS_FUNCT_STRING makro in both cases? The second error occurs in the same file, line 669. The second parameter for the pGetModuleHandleEx function should be defined as wchar_t, but it's defined as static char static_variable in the line 667. Best Regards, Oleg ___ 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.or g __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
Hi, Yeah all of them run in fullscreen mode. I am under Windows, use Firefox and I am using a dual screen setup (maybe it's the problem, I'll try with only one screen). On Fri, May 1, 2009 at 10:17 AM, Thomas tho...@3djam.com wrote: Hi Serge Lages I always hoped that such a plugin could become a standard installed on every machine Me too. :-) For the OSG examples, should it be possible to have an example showing an OSG app running inside the browser and not on fullscreen ? Does it run as full screen on your machine? (it is not supposed to) What is your OS version and browser and version? Did you try just one of the OSG demos or several of them. On my test machines it run inside the browser. [Image: http://www.3djam.com/roozz/images/temp/osg_in_crome.jpg ] /Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11160#11160 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Broken Windows build
On Fri, May 1, 2009 at 9:30 AM, Michael Platings mplati...@pixelpower.com wrote: I hadn't tested this yet, and I can confirm Oleg's errors. I have submitted a fix. Now merged thanks. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Broken Windows build
Hi Robert, This is the first time I have problems to compile OSG under Windows. My last SVN build is four to five weeks old with enabled Unicode support. There were no problems. I'm using VS2008 under Vista, OSG is compiled in 64-bit mode. I reverted FileUtils.cpp to rev. 9990 and compiled this file without any problems. Rev. 9991 of FileUtils.cpp cannot be build anymore. Lines 654 to 692 were added in this revision. I saw there is new config option OSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS. Could it be that this option causes these problems? Regards, Oleg -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Freitag, 1. Mai 2009 09:46 An: OpenSceneGraph Users Betreff: Re: [osg-users] Broken Windows build Hi Oleg, The OSG-2.8 release went out with the UTF8 code in place, svn/trunk doesn't change this in any way. Lots and lots of Windows users have been testing it out across different compilers and not reported problems. What build suit are you using? Have you compiled other OSG versions OK? Robert. On Thu, Apr 30, 2009 at 8:11 PM, Oleg Dedkow oded...@gmx.de wrote: Hi Robert, the latest SVN revision cannot be build under Windows if “OSG_USE_UTF8_FILENAME” config option is enabled. The error occurs in “FileUtils.cpp” file, line 663, since there is no UNICODE-capable version of the “GetProcAddress” function. The “OSGDB_WINDOWS_FUNCT_STRING” makro is defined as follows in that case #define OSGDB_WINDOWS_FUNCT_STRING(x) L ## #x LW Thus the second parameter cannot be converted from wchar_t to LPCSTR. Should we convert the second parameter from wchar_t* to LPCSTR or use the same definition for the “OSGDB_WINDOWS_FUNCT_STRING” makro in both cases? The second error occurs in the same file, line 669. The second parameter for the “pGetModuleHandleEx” function should be defined as wchar_t, but it’s defined as “static char static_variable” in the line 667. Best Regards, Oleg ___ 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] Broken Windows build
It can be build now. Oleg -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Freitag, 1. Mai 2009 10:51 An: OpenSceneGraph Users Betreff: Re: [osg-users] Broken Windows build On Fri, May 1, 2009 at 9:30 AM, Michael Platings mplati...@pixelpower.com wrote: I hadn't tested this yet, and I can confirm Oleg's errors. I have submitted a fix. Now merged thanks. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
Hi FYI I've tried the plugin on my laptop (nVidia NVS 110) with Firefox and WinXP, single-screen, and the samples ran in fullscreen mode - the browser window would show only the loading gauge, even after exiting the sample. Thibault On Fri, May 1, 2009 at 10:49 AM, Serge Lages serge.la...@gmail.com wrote: Hi, Yeah all of them run in fullscreen mode. I am under Windows, use Firefox and I am using a dual screen setup (maybe it's the problem, I'll try with only one screen). On Fri, May 1, 2009 at 10:17 AM, Thomas tho...@3djam.com wrote: Hi Serge Lages I always hoped that such a plugin could become a standard installed on every machine Me too. :-) For the OSG examples, should it be possible to have an example showing an OSG app running inside the browser and not on fullscreen ? Does it run as full screen on your machine? (it is not supposed to) What is your OS version and browser and version? Did you try just one of the OSG demos or several of them. On my test machines it run inside the browser. [Image: http://www.3djam.com/roozz/images/temp/osg_in_crome.jpg ] /Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11160#11160 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ 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] Broken Windows build
Hi Oleg, Initially I couldn't figure out the case of this, as all the cmake and C++ files looked correct, but just had a eureka moment - the exports were missing. I've now added these and checked them in. Could you do an svn update and see if this problem is now addressed. Cheers, Robert. On Fri, May 1, 2009 at 10:30 AM, Oleg Dedkow oded...@gmx.de wrote: Hi Robert, There are still link errors in Plugins P3D project: Error 1 error LNK2019: unresolved external symbol public: bool __cdecl osgDB::XmlNode::read(class osgDB::XmlNode::Input ) (?r...@xmlnode@osgDB@@qeaa_naeavin...@12@@Z) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 2 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::XmlNode(void) (??0xmln...@osgdb@@q...@xz) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 3 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::~Input(void) (??1in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 4 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::readAllDataIntoBuffer(void) (?readalldataintobuf...@input@xmln...@osgdb@@QEAAXXZ) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 5 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::open(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?o...@input@xmln...@osgdb@@qeaaxaebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 6 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::Input(void) (??0in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 7 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::attach(class std::basic_istreamchar,struct std::char_traitschar ) (?att...@input@xmln...@osgdb@@qeaaxaeav?$basic_istr...@du?$char_traits@d...@std@@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_istreamchar,struct std::char_traitschar ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aeav?$basic_istr...@du?$char_traits@d...@std@@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Oleg -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Freitag, 1. Mai 2009 09:46 An: OpenSceneGraph Users Betreff: Re: [osg-users] Broken Windows build Hi Oleg, The OSG-2.8 release went out with the UTF8 code in
Re: [osg-users] custom search paths...
Hi Neil, This type of customization is exactly what ReadFileCallback is for. I don't feel it's appropriate for search routines to do anything other than search, having them remap file names is inappropriate. Robert. On Fri, May 1, 2009 at 11:32 AM, neil.hug...@tesco.net wrote: Hi Robert, I've had a look at this, and whilst it will address the specific scenario I described, I left out a little top spin to the scenario that has some bearing on the issue. Not only do I want to specify the directory where the search looks, but I also wish to amend the file extension. Essentially the issue is that when we originally started out modelling - circa 10 years ago now - we only used TGA files. Now we tend to prefer to load jpg files, unless there is an alpha channel in which case we'll load TGA's. For space reasons, and speed of load/download we therefore want to say that if a tga file is referenced, try loading, but if not found, try the jpg equivalent. I can handle this at the load image time within my supplied readfilecallback, if I circumvent the search results. However, I'd like the search routines to be able to handle this type of functionality as well. i.e. I request Pear.TGA, the search try's to locate it, but if it fails it tries some alternative extensions. Now I recognise that this is somewhat specific to myself, but rather than have customised 3DS readers, I was hoping to extend the search routines in a general way to permit an application to supply its own search algorithm, that could be used in the event that the file was not found with the current search implementations. I recognise that for the majority of people either the standard search path, or the options route you describe, is sufficient. Its just that I can't see a way to amend the extension/path according to some application defined rules using this approach. Robert, I think I'll code up a solution, and perhaps submit it for consideration if that's ok with you, and then we'll have a framework to bat about. Kind regards Neil. a jpgour models were producedmodelled, neil.hug...@tesco.net wrote: Hi Robert, Thanks for the reply, I'll look into this approach. Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Neil, The ReaderWriter::Options structure has a data file path list built into it, this is checked before the main data file path list stored in the Registry is checked. So if you want a certainly directory checked just put it on your path, either via the ReaderWriter::Options or via the Registry using osgDB::s/getDataFilePathList. You'd typically use Options when you only want to locally set the search path. Robert. On Thu, Apr 30, 2009 at 5:29 PM, neil.hug...@tesco.net wrote: Hi All, I'd like to pick your collective brains for a moment in regards to search paths for files within OSG. I'm currently working on the 3DS plugin for OSG, looking at a little problem. The scenario is as follows. I have a 3DS file whose material table references a texture. When this model was created the texture resided in the same directory as the model, and hence no path information was stored - at least I guess that's why there is no path information for the texture referenced. Now when I want to load this model, the 3DS loader tries to locate the texture in the directory that the model resides in - using the findfileindirectory function - but as the texture is no longer in this directory, the function fails to find the file, and the 3DS reader decides not to put a texture on the geometry. Now, the thing is, I do know where the texture is relative to the model. Its in a parallel directory. In fact, if I ignore the result of the find file, and merely just try and load the image, my readfilecallback handler amends the path to the file, and the image loads. So, what I was wondering was whether there already exists a way by which I can direct the findfileindirectory function to take account of a custom search algorithm? I've had a look and I can't spot one, but wondered if others might know differently? On the assumption that no such methodology exists, my thoughts were that I could amend the existing function to call a custom defined function on the user supplied readfilecallback - if one has been supplied - in the event where the readfileindirectory function has failed. Any thoughts ? Thanks for any assistance/comments. Kind regards, Neil. ___ 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
Re: [osg-users] Broken Windows build
Hi Robert, It compiles now :-) Regards, Oleg -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Freitag, 1. Mai 2009 12:27 An: OpenSceneGraph Users Betreff: Re: [osg-users] Broken Windows build Hi Oleg, Initially I couldn't figure out the case of this, as all the cmake and C++ files looked correct, but just had a eureka moment - the exports were missing. I've now added these and checked them in. Could you do an svn update and see if this problem is now addressed. Cheers, Robert. On Fri, May 1, 2009 at 10:30 AM, Oleg Dedkow oded...@gmx.de wrote: Hi Robert, There are still link errors in Plugins P3D project: Error 1 error LNK2019: unresolved external symbol public: bool __cdecl osgDB::XmlNode::read(class osgDB::XmlNode::Input ) (?r...@xmlnode@osgDB@@qeaa_naeavin...@12@@Z) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 2 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::XmlNode(void) (??0xmln...@osgdb@@q...@xz) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 3 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::~Input(void) (??1in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 4 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::readAllDataIntoBuffer(void) (?readalldataintobuf...@input@xmln...@osgdb@@QEAAXXZ) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 5 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::open(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?o...@input@xmln...@osgdb@@qeaaxaebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 6 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::Input(void) (??0in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 7 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::attach(class std::basic_istreamchar,struct std::char_traitschar ) (?att...@input@xmln...@osgdb@@qeaaxaeav?$basic_istr...@du?$char_traits@d...@std@@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_istreamchar,struct std::char_traitschar ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aeav?$basic_istr...@du?$char_traits@d...@std@@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Oleg -Ursprüngliche
Re: [osg-users] render depth buffer to image for one time
As I understand, the command camera-attach(osg::Camera::COLOR_BUFFER, depth.get(),0,0); tells osg, that I want the color buffer of the camera to be stored in the image depth. This works, but when I change it to camera-attach(osg::Camera::DEPTH_BUFFER, depth.get(),0,0); I get the same result. A colored picture. Regards, jojo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11173#11173 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom search paths...
Hi Robert, I've had a look at this, and whilst it will address the specific scenario I described, I left out a little top spin to the scenario that has some bearing on the issue. Not only do I want to specify the directory where the search looks, but I also wish to amend the file extension. Essentially the issue is that when we originally started out modelling - circa 10 years ago now - we only used TGA files. Now we tend to prefer to load jpg files, unless there is an alpha channel in which case we'll load TGA's. For space reasons, and speed of load/download we therefore want to say that if a tga file is referenced, try loading, but if not found, try the jpg equivalent. I can handle this at the load image time within my supplied readfilecallback, if I circumvent the search results. However, I'd like the search routines to be able to handle this type of functionality as well. i.e. I request Pear.TGA, the search try's to locate it, but if it fails it tries some alternative extensions. Now I recognise that this is somewhat specific to myself, but rather than have customised 3DS readers, I was hoping to extend the search routines in a general way to permit an application to supply its own search algorithm, that could be used in the event that the file was not found with the current search implementations. I recognise that for the majority of people either the standard search path, or the options route you describe, is sufficient. Its just that I can't see a way to amend the extension/path according to some application defined rules using this approach. Robert, I think I'll code up a solution, and perhaps submit it for consideration if that's ok with you, and then we'll have a framework to bat about. Kind regards Neil. a jpgour models were producedmodelled, neil.hug...@tesco.net wrote: Hi Robert, Thanks for the reply, I'll look into this approach. Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Neil, The ReaderWriter::Options structure has a data file path list built into it, this is checked before the main data file path list stored in the Registry is checked. So if you want a certainly directory checked just put it on your path, either via the ReaderWriter::Options or via the Registry using osgDB::s/getDataFilePathList. You'd typically use Options when you only want to locally set the search path. Robert. On Thu, Apr 30, 2009 at 5:29 PM, neil.hug...@tesco.net wrote: Hi All, I'd like to pick your collective brains for a moment in regards to search paths for files within OSG. I'm currently working on the 3DS plugin for OSG, looking at a little problem. The scenario is as follows. I have a 3DS file whose material table references a texture. When this model was created the texture resided in the same directory as the model, and hence no path information was stored - at least I guess that's why there is no path information for the texture referenced. Now when I want to load this model, the 3DS loader tries to locate the texture in the directory that the model resides in - using the findfileindirectory function - but as the texture is no longer in this directory, the function fails to find the file, and the 3DS reader decides not to put a texture on the geometry. Now, the thing is, I do know where the texture is relative to the model. Its in a parallel directory. In fact, if I ignore the result of the find file, and merely just try and load the image, my readfilecallback handler amends the path to the file, and the image loads. So, what I was wondering was whether there already exists a way by which I can direct the findfileindirectory function to take account of a custom search algorithm? I've had a look and I can't spot one, but wondered if others might know differently? On the assumption that no such methodology exists, my thoughts were that I could amend the existing function to call a custom defined function on the user supplied readfilecallback - if one has been supplied - in the event where the readfileindirectory function has failed. Any thoughts ? Thanks for any assistance/comments. Kind regards, Neil. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Broken Windows build
Hi Robert, There are still link errors in Plugins P3D project: Error 1 error LNK2019: unresolved external symbol public: bool __cdecl osgDB::XmlNode::read(class osgDB::XmlNode::Input ) (?r...@xmlnode@osgDB@@qeaa_naeavin...@12@@Z) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 2 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::XmlNode(void) (??0xmln...@osgdb@@q...@xz) referenced in function public: class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class osgDB::XmlNode::Input ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@qeba?avreadres...@readerwriter@osgDB@@aeavin...@xmlnode@4...@pebvoptions@34@@Z) ReaderWriterP3D.obj Error 3 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::~Input(void) (??1in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 4 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::readAllDataIntoBuffer(void) (?readalldataintobuf...@input@xmln...@osgdb@@QEAAXXZ) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 5 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::open(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ) (?o...@input@xmln...@osgdb@@qeaaxaebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 6 error LNK2019: unresolved external symbol public: __cdecl osgDB::XmlNode::Input::Input(void) (??0in...@xmlnode@osgDB@@q...@xz) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aebv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Error 7 error LNK2019: unresolved external symbol public: void __cdecl osgDB::XmlNode::Input::attach(class std::basic_istreamchar,struct std::char_traitschar ) (?att...@input@xmln...@osgdb@@qeaaxaeav?$basic_istr...@du?$char_traits@d...@std@@@std@@@Z) referenced in function public: virtual class osgDB::ReaderWriter::ReadResult __cdecl ReaderWriterP3DXML::readNode(class std::basic_istreamchar,struct std::char_traitschar ,class osgDB::ReaderWriter::Options const *)const (?readn...@readerwriterp3dxml@@ueba?avreadres...@readerwriter@osgDB@@aeav?$basic_istr...@du?$char_traits@d...@std@@@std@@pebvopti...@34@@Z) ReaderWriterP3D.obj Oleg -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Freitag, 1. Mai 2009 09:46 An: OpenSceneGraph Users Betreff: Re: [osg-users] Broken Windows build Hi Oleg, The OSG-2.8 release went out with the UTF8 code in place, svn/trunk doesn't change this in any way. Lots and lots of Windows users have been testing it out across different compilers and not reported problems. What build suit are you using? Have you compiled other OSG versions OK? Robert. On Thu, Apr 30, 2009 at 8:11 PM, Oleg Dedkow oded...@gmx.de wrote: Hi Robert, the latest SVN revision cannot be build under Windows if “OSG_USE_UTF8_FILENAME” config option is
Re: [osg-users] custom search paths...
Hi Robert, I suspect we may be saying the same thing, and perhaps I haven't explained myself clearly. All I'm suggesting is a slight amendment to the search functions to delegate to an application supplied readfilecallback the role of searching when the default search has failed to locate the file. OSG would be agnostic as far as the actual alternative search algorithm is concerned. It merely invokes it and returns the result. Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Neil, This type of customization is exactly what ReadFileCallback is for. I don't feel it's appropriate for search routines to do anything other than search, having them remap file names is inappropriate. Robert. On Fri, May 1, 2009 at 11:32 AM, neil.hug...@tesco.net wrote: Hi Robert, I've had a look at this, and whilst it will address the specific scenario I described, I left out a little top spin to the scenario that has some bearing on the issue. Not only do I want to specify the directory where the search looks, but I also wish to amend the file extension. Essentially the issue is that when we originally started out modelling - circa 10 years ago now - we only used TGA files. Now we tend to prefer to load jpg files, unless there is an alpha channel in which case we'll load TGA's. For space reasons, and speed of load/download we therefore want to say that if a tga file is referenced, try loading, but if not found, try the jpg equivalent. I can handle this at the load image time within my supplied readfilecallback, if I circumvent the search results. However, I'd like the search routines to be able to handle this type of functionality as well. i.e. I request Pear.TGA, the search try's to locate it, but if it fails it tries some alternative extensions. Now I recognise that this is somewhat specific to myself, but rather than have customised 3DS readers, I was hoping to extend the search routines in a general way to permit an application to supply its own search algorithm, that could be used in the event that the file was not found with the current search implementations. I recognise that for the majority of people either the standard search path, or the options route you describe, is sufficient. Its just that I can't see a way to amend the extension/path according to some application defined rules using this approach. Robert, I think I'll code up a solution, and perhaps submit it for consideration if that's ok with you, and then we'll have a framework to bat about. Kind regards Neil. a jpgour models were producedmodelled, neil.hug...@tesco.net wrote: Hi Robert, Thanks for the reply, I'll look into this approach. Neil. Robert Osfield robert.osfi...@gmail.com wrote: Hi Neil, The ReaderWriter::Options structure has a data file path list built into it, this is checked before the main data file path list stored in the Registry is checked. So if you want a certainly directory checked just put it on your path, either via the ReaderWriter::Options or via the Registry using osgDB::s/getDataFilePathList. You'd typically use Options when you only want to locally set the search path. Robert. On Thu, Apr 30, 2009 at 5:29 PM, neil.hug...@tesco.net wrote: Hi All, I'd like to pick your collective brains for a moment in regards to search paths for files within OSG. I'm currently working on the 3DS plugin for OSG, looking at a little problem. The scenario is as follows. I have a 3DS file whose material table references a texture. When this model was created the texture resided in the same directory as the model, and hence no path information was stored - at least I guess that's why there is no path information for the texture referenced. Now when I want to load this model, the 3DS loader tries to locate the texture in the directory that the model resides in - using the findfileindirectory function - but as the texture is no longer in this directory, the function fails to find the file, and the 3DS reader decides not to put a texture on the geometry. Now, the thing is, I do know where the texture is relative to the model. Its in a parallel directory. In fact, if I ignore the result of the find file, and merely just try and load the image, my readfilecallback handler amends the path to the file, and the image loads. So, what I was wondering was whether there already exists a way by which I can direct the findfileindirectory function to take account of a custom search algorithm? I've had a look and I can't spot one, but wondered if others might know differently? On the assumption that no such methodology exists, my thoughts were that I could amend the existing function to call a custom defined
Re: [osg-users] Feedback request: New browser plugin allow you to run 3D .exe embedded in webpage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas wrote: Hi everyone. Check out the online OSG demos here: http://www.3djam.com/roozz/Demo/osg_demo.aspx (http://www.3djam.com/roozz/Demo/osg_demo.aspx) Tell us what you think. No worky for me - I need a Linux version. Please, do not make distribution-specific packages (Debian, Ubuntu, whatever), that is not very useful. Make something that can be installed by a simple script dropping the plugin in my .mozilla/firefox/plugins directory. Also, do not forget a 32bit and 64bit version - people running 64bit Linux will have problems with 32bit plugin. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ+uajn11XseNj94gRAqcxAKDZUudykkUg4Q2Epcs462u4JKA+rwCcDO4W 7QRDHeaszkDNmGmhr00+YR4= =qLPB -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to maximize and minimize the window of the osg program
Hi,
I want to realize the function:When I push the key f,I can maximize the
window of the osg program.When I push the key f again,I can recover the size of
the window of the osg program.Such as
if(ea.getKey()==osgGA::GUIEventAdapter::KEY_F)
{
}
Can you tell me?
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11177#11177
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] stats
Hi Robert, I am trying to make stats about osgAnimation, i started from the stats of osgViewer but there are something i am not sure to understand. I started to fill the osg::Stats structure with information of osgAnimation. But when i display my stats it seems that sometime the rendering of stats are not sync with the regular update/draw, or the stats is a bit in advance from the regular update/rendering. Is there a way to sync the stats rendering with the regular update/draw or should i change the way it's made. Does it make sense to you ? Cheers, Cedric -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to maximize and minimize the window of the osg program
Hi. The WindowSizeHandler (in osgViewer/ViewerEventHandlers) does exactly this. Look at the toggleFullScreen method. Better yet, just add a WindowSizeHandler to your viewers event hander list with viewer.addEventHandler(new osgViewer::WindowSizeHandler()); Hope that helps, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bubble effect at some positions
Hi, I want to realize the bubble effect at one position.For example,if I know the coordinate of the top of the bottle,I want to create some bubble at the top of the bubble.Can you tell me? ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11181#11181 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hello Michael,
I've recently encountered this same problem myself. My experiments show
that iterating over a vector with an iterator is ***TEN TIMES SLOWER***
than with iterator debugging disabled. In release builds!
I'm somewhat skeptical of this claim. What experiments were they, and
are you sure they're representative of an actual application?
Sure, we all know that iterator debugging (_HAS_ITERATOR_DEBUGGING) and
checking (_SECURE_SCL) takes a lot of time in debug builds, but release
builds should be virtually unaffected. Note that _HAS_ITERATOR_DEBUGGING
only has an effect in debug builds - it is completely disabled in
release - but _SECURE_SCL stays enabled even in release. However, in my
testing, it has virtually no effect in release.
Think about it - would MS really put default values into their compiler
that would make all applications on their platform ten times slower? How
would that make their platform look, especially now that most
applications can run on multiple platforms?
I think you may be focusing on test cases that do not match actual
application results, but of course to be sure you'd have to publish your
test cases.
Ideally I'd just define _SCL_SECURE to 0, but I can't as I'm dependent
on closed-source libraries without it defined and this has given me
weird crashes.
We're on the same boat. We have to make two builds of everything because
in some builds we link to Vega Prime which is built with iterator
debugging disabled, but in all other cases we want to keep the VS
default values so we don't put an additional burden on our customers who
want to link to our libraries. It just about doubles the number of
builds we need in our build matrix, which is a drag.
I personally think that until we can publically and conclusively prove
otherwise, changing the VS default values for this is not useful and
just puts an additional burden on others trying to link to your libs.
See what happens with Vega Prime - because they decided to change the
iterator debugging setting, they force us to make twice the number of
builds. That's a considerable waste of time and resources for us.
A while ago, we tried building all our libraries with iterator debugging
and _SECURE_SCL turned off. We thought it would be a good way to reduce
our build matrix, but it ended up just moving the burden onto support
because customers who wanted to link to our libraries had to remember to
disable these in their projects too. Anyways - we switched back to
default settings on our OSG-based builds lately, and as I said I haven't
seen a significant performance difference in release. That's for actual
applications in a real-world setting... I didn't do any real timings at
the time, but I think I would have noticed a 10x difference! Especially
since OSG is iterator-heavy.
Remember - you're not supposed to do any benchmarking in debug (it's not
representative of real performance, on any platform) and release builds
*should* be relatively unaffected (unless you can prove otherwise).
However, I've discovered that using std::for_each in place of a for loop
provides a massive speed up - it performs the same is if iterator
debugging were disabled.
I'm skeptical about this too... Here's the source for std::for_each
(MSVC's implementation):
// TEMPLATE FUNCTION for_each
templateclass _InIt,
class _Fn1 inline
_Fn1 for_each(_InIt _First, _InIt _Last, _Fn1 _Func)
{ // perform function for each element
_DEBUG_RANGE(_First, _Last);
_DEBUG_POINTER(_Func);
_CHECKED_BASE_TYPE(_InIt) _ChkFirst(_CHECKED_BASE(_First));
_CHECKED_BASE_TYPE(_InIt) _ChkLast(_CHECKED_BASE(_Last));
for (; _ChkFirst != _ChkLast; ++_ChkFirst)
_Func(*_ChkFirst);
return (_Func);
}
Apart from the 2 _DEBUG and 2 _CHECKED macros, this does not do anything
different than I would do manually. It could be rewritten:
void for_each(iterator first, iterator last, function_ptr function)
{
for (; first!= last; ++first)
function(*first);
}
Now, out of the 4 macros, the first two are enabled if iterator
debugging is enabled (_HAS_ITERATOR_DEBUGGING), and the other two are
enabled if _SECURE_SCL is enabled. Now, the savings you see might come
from the fact that the iterators are checked only once and then
unchecked iterators are used for the loop itself. That would actually
make sense. But I haven't seen any significant performance difference
between the two myself, so I'm skeptical.
I agree with Robert, changing all loops to std::for_each wholesale would
be likely to introduce bugs, since you need to code up a functor for
each loop. In addition to introducing more code, that moves the inner
loop logic out of the scope where it's used, which makes it harder to
follow.
If we could use boost::foreach instead - and if we could prove that it
has the same benefits that you say std::for_each has - then that might
be
Re: [osg-users] bubble effect at some positions
Hi Wangjian; If you have looked at the osgParticle nodekit, you should know about emitter. I think you want to create a bubble effect on the top of your bottle, so you know related coordinates, at this point you can change the emitter position as you expected. That's all. Ps : I recommend you to use Delta3D Particle Editor which can create particle effects and save in osg format as a simple bubble effect file and then you can read this file in your application and add as a child to any MatrixTrasform and as a result you can control your effect easily. Hope this helps. 2009/5/1 Wangjian dmt198...@163.com Hi, I want to realize the bubble effect at one position.For example,if I know the coordinate of the top of the bottle,I want to create some bubble at the top of the bubble.Can you tell me? ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11181#11181 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
I have to admit my experience backs up Michael claims.
Checked Iterators (in release) can have a significant impact on performance
depending on how you use iterators. Most STL calls have been optimized by MS to
have almost a 0% overhead with checked iterators enabled. Code directly using
iterators (such as Boost or OSG for example) will be significantly slower. 10x
slower does not surprise me, although I've noticed 0.1x to 3x slower to be more
common.
Checked Iterators enabled by default is a bad decision from MSVC STL team. Most
C++ developers have been complaining quite loudly about it on MS forums and
blogs for ages, only to be met by the same answer everytime: It's for
security. Security is good for you, you should have checked iterators enabled
all the time (aka Microsoft knows what's good for you better than you do).
For the same reasons Robert explained, I'm not in favour of changing OSG code
to make it faster with checked iterators. But I can definitely understand why
one would want to disable checked iterators.
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien
Guay
Sent: Friday 01 May 2009 14:29
To: OpenSceneGraph Users
Subject: Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow
Performance, and getFileExtension bug
Hello Michael,
I've recently encountered this same problem myself. My experiments show
that iterating over a vector with an iterator is ***TEN TIMES SLOWER***
than with iterator debugging disabled. In release builds!
I'm somewhat skeptical of this claim. What experiments were they, and
are you sure they're representative of an actual application?
Sure, we all know that iterator debugging (_HAS_ITERATOR_DEBUGGING) and
checking (_SECURE_SCL) takes a lot of time in debug builds, but release
builds should be virtually unaffected. Note that _HAS_ITERATOR_DEBUGGING
only has an effect in debug builds - it is completely disabled in
release - but _SECURE_SCL stays enabled even in release. However, in my
testing, it has virtually no effect in release.
Think about it - would MS really put default values into their compiler
that would make all applications on their platform ten times slower? How
would that make their platform look, especially now that most
applications can run on multiple platforms?
I think you may be focusing on test cases that do not match actual
application results, but of course to be sure you'd have to publish your
test cases.
Ideally I'd just define _SCL_SECURE to 0, but I can't as I'm dependent
on closed-source libraries without it defined and this has given me
weird crashes.
We're on the same boat. We have to make two builds of everything because
in some builds we link to Vega Prime which is built with iterator
debugging disabled, but in all other cases we want to keep the VS
default values so we don't put an additional burden on our customers who
want to link to our libraries. It just about doubles the number of
builds we need in our build matrix, which is a drag.
I personally think that until we can publically and conclusively prove
otherwise, changing the VS default values for this is not useful and
just puts an additional burden on others trying to link to your libs.
See what happens with Vega Prime - because they decided to change the
iterator debugging setting, they force us to make twice the number of
builds. That's a considerable waste of time and resources for us.
A while ago, we tried building all our libraries with iterator debugging
and _SECURE_SCL turned off. We thought it would be a good way to reduce
our build matrix, but it ended up just moving the burden onto support
because customers who wanted to link to our libraries had to remember to
disable these in their projects too. Anyways - we switched back to
default settings on our OSG-based builds lately, and as I said I haven't
seen a significant performance difference in release. That's for actual
applications in a real-world setting... I didn't do any real timings at
the time, but I think I would have noticed a 10x difference! Especially
since OSG is iterator-heavy.
Remember - you're not supposed to do any benchmarking in debug (it's not
representative of real performance, on any platform) and release builds
*should* be relatively unaffected (unless you can prove otherwise).
However, I've discovered that using std::for_each in place of a for loop
provides a massive speed up - it performs the same is if iterator
debugging were disabled.
I'm skeptical about this too... Here's the source for std::for_each
(MSVC's implementation):
// TEMPLATE FUNCTION for_each
templateclass _InIt,
class _Fn1 inline
_Fn1 for_each(_InIt _First, _InIt _Last, _Fn1 _Func)
{ // perform function for each element
_DEBUG_RANGE(_First, _Last);
_DEBUG_POINTER(_Func);
Re: [osg-users] osgEarth + OSG 2.8.0 + ATI card
Hi Manu, There isn't currently an osgearth_version or anything similar yet. At some point when the API for osgEarth becomes more flushed out we'll probably introduce some more strict versioning. I'd just download the latest version and rebuild if you can't remember, it's not too big;) There should be any issues with applying shaders to osgEarth models, it's just regular OSG code so it should be simliar to working with a VPB database. Jason On Thu, Apr 30, 2009 at 2:51 AM, Emmanuel Roche roche.emman...@gmail.comwrote: Hi Jason, I've already tried deleting the cache folders, unsuccessfully. And how can I retrieve the version of my current osgEarth lib ?? :-) I cannot find that in the sources, and I just don't remember which version I downloaded :-) And by the way, this as nothing to do with this thread yet, I have another question for you: are you aware of a mayor problem which would happen if I try to apply a shader on the osgEarth model and compute the terrain elevation in the shader ? (I could pass the elevation texture as an additional ImageLayer I guess ? And if I add a few uniforms for each terrain tile, this should not be too complex, is it ? ) Manu. 2009/4/29 Jason Beverage jasonbever...@gmail.com Hi Manu, Are you using a cache for your .earth files? If so, try deleting your disk cache and see if that helps. Also, what version of osgEarth are you using 1.0 or 1.1? 1.1 added support for mixing mercator and geodetic sources, which can sometimes result in non-power-of-two textures being used. I wonder if perhaps there is an issue with your card and NPOT. Thanks, Jason On Wed, Apr 29, 2009 at 4:49 AM, Emmanuel Roche roche.emman...@gmail.com wrote: Here are a few screen captures... Note the half visible groenland on the right side on picture 2 (with part of africa on the right :-) ). Or the low level Europe map on the left on picture 1. The position of the camera is somewhere next to munich in Germany ! If I don't move the camera the textures eventually change but they are replaced by other incorrect textures :-( So if you have any idea what I could try here this could be very helpful. Manu. 2009/4/29 Emmanuel Roche roche.emman...@gmail.com Hi Jason, thanks for your answer. Actually, I just downloaded 2.8.1 rc3, built it and tested my software with those binaries: it solved to problem !!... to some extends... :-( Actually, i think i'm now facing another ATI specific issue: I can start my app, retrieve image and elevation tiles and built my earth model... except that after some time (and this is also true if I use an simple example like osgviewer yahoo_aerial.earth) it seems that my ATI just start mixing all the loaded textures! And in fact it seems to be a quite advanced feature as the mixing is progressive !!! (ie. We have a nice fading effect when you move slowing !!) My guess is, it could be that the graphic card memory is filled with textures, and then the ATI driver start using old texture objects depending on your distance to your model expecting to create a nice fading effect (assuming what we have here are mipmaped textures ?) (except that osgEarth keeps updating all the textures any way, so old textures for a given area are actually replaced by other textures for other areas). Could this make sense ? (or maybe I'm just saying silly things I'm really not an expert when it comes to the low level details like that :-) ). I'm joining a couple of screen capture in a following mail: maybe someone already faced this before. Manu. 2009/4/28 Jason Beverage jasonbever...@gmail.com Hi Emmanuel, Glad to hear osgEarth is working out for you:) Try disabling VBO's by setting the OSG_GL_EXTENSION_DISABLE environment variable to GL_ARB_vertex_buffer_object. This is really a temporary solution, once 2.8.1 is out the door, you can probably just upgrade and it should work fine. Thanks! Jason On Tue, Apr 28, 2009 at 6:12 AM, Emmanuel Roche roche.emman...@gmail.com wrote: Hi everyone ! I've been testing osgEarth for a few days now: it works perfectly on my nvidia cards. But when trying the same application with an ATI cards, the app just shutdowns on some cards, or crashes (with the error mentioned on the osgEarth forum here: http://n2.nabble.com/Ati-error-td2603275.html ) I've read that the rc3 for OSG 2.8.1 comes with a fix item : fixes to display lists/vbo creation that prevent crash under ATI drivers. My question is : do you know if this is related to the problem I'm experiencing currently and has someone already tested osgEarth on a previously crashing ATI cards with that version of OSG ? best regards, Manu. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hi Tanguy, For the same reasons Robert explained, I'm not in favour of changing OSG code to make it faster with checked iterators. But I can definitely understand why one would want to disable checked iterators. Well, you certainly have control over that, disable them if you want. But if you're planning on releasing a library to be linked to client code and perhaps other libraries, it places a considerable burden on your clients (they have to make sure their code, and *all* their external dependencies, are also compiled with the same options, which is not the norm), so you better be sure that it is worth it. I can only tell you that in our applications we haven't been able to verify that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hi J-S, We've been disabling checked iterators in our products, so I know the burden of maintaining third party libraries that are correctly compiled with the correct options. In fact, it's sometimes so subtle that it took us about 2 months to find all the issues on what should be a trivial matter. I guess you could always ship your library to your client with and without checked iterators, but I understand it may not be practical from a company point of view. What I still do not understand is what went through Microsoft mind when they enabled such a performance critical option by default. It's native C++ FFS, not Visual Basic. Not to mention that debug and checked iterators introduced several subtle but serious bugs in their STL implementation that are still not fully resolved. Cheers, Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Friday 01 May 2009 15:03 To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug Hi Tanguy, For the same reasons Robert explained, I'm not in favour of changing OSG code to make it faster with checked iterators. But I can definitely understand why one would want to disable checked iterators. Well, you certainly have control over that, disable them if you want. But if you're planning on releasing a library to be linked to client code and perhaps other libraries, it places a considerable burden on your clients (they have to make sure their code, and *all* their external dependencies, are also compiled with the same options, which is not the norm), so you better be sure that it is worth it. I can only tell you that in our applications we haven't been able to verify that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hi Robert, Yet despite all this people still want to use VisualStudio :-) Well, on Windows platforms and despite all that, C++ code is faster when compiled with MS's compiler (compared to gcc - either mingw or cygwin). Plus, Visual Studio is much more than just the compiler. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Well Visual Studio is actually a very accomplished IDE The issue is mainly the compiler and linker and the stupid things MS do in the name of security etc, and if you want you can actually plug-in in other compilers and linkers like Intel's etc... Another tip for running inside of the Visual Studio to speed up things is to use the Environment ( NOT a #deinfe) variable _NO_DEBUG_HEAP to 1, you need to close all VS's instance etc.. (see http://msdn.microsoft.com/en-us/library/aa366705.aspx ) this along with the other #deinfe you can use do speed up debug a lot etc... Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Friday, May 01, 2009 10:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug Hi Robert, Yet despite all this people still want to use VisualStudio :-) Well, on Windows platforms and despite all that, C++ code is faster when compiled with MS's compiler (compared to gcc - either mingw or cygwin). Plus, Visual Studio is much more than just the compiler. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio, Iterator Debugging, Secure SCL, Slow Performance, and getFileExtension bug
Hi Tanguy, My little finger tells me that most mistakes done in VC7/8/9 and its libraries are probably due to the technical incompetence of a few rather than an MS global conspiracy to eliminate native C++. I think it might just be a misguided corporate policy that has very bad ramifications on the technical side of things (like we haven't seen that before... MS wouldn't be the first, but perhaps it's the worst offender in this regard). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DoomLike manipulator
I've started a new thread called FirstPersonManipulator with the files. On Thu, Apr 23, 2009 at 1:50 PM, Simon Loic simon1l...@gmail.com wrote: Hi Richard, I wouldn't want to fool you with this collision stuff. The goal is simply to prevent the player (the camera) to cross through the walls of the scene, and in the meantime to stick to the ground in case of grounded mode. Something alike is already done in the DriveManipulator, using a LineSegmentIntersector. I wanted to improve it by modeling the player as a rectangle box, and use a PolytopeIntersector, but then I ran into a lot of trouble. So I think I will release a version with the LineSegmentIntersector first and when/if I find some time I will try again with the polytope one. -- Loïc Simon On Thu, Apr 23, 2009 at 12:33 AM, Richard Baron Penman richardbp+...@gmail.com richardbp%2b...@gmail.com wrote: 'collision handling' - oh wow! I eagerly await. Richard On Wed, Apr 22, 2009 at 7:59 AM, Simon Loic simon1l...@gmail.com wrote: Hi, In fact I've struggled quite a while to handle collision in a way that apparently doesn't work, and finally I had to postpone coding on it for work reason. I'll try to post a version of this manipulator with simple collision tests soon , let's say by the week end. On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman richardbp+...@gmail.com richardbp%2b...@gmail.com wrote: hi, I'm interested in using this manipulator. Have any updates been posted or should I use the originally posted one? Richard 2009/3/24 Simon Loic simon1l...@gmail.com In fact I didn't have enough time to finish this week-end. So It will be postponed to next week. On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic simon1l...@gmail.comwrote: All right, I'll certainly finish during the week-end and post it on osg-users for testing. 2009/3/20 Robert Osfield robert.osfi...@gmail.com Hi Loic, Great little discussion :-) 2009/3/19 Simon Loic simon1l...@gmail.com Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode you can give it a try and decide which name best fits. In my concern I clearly incline towars grounded as the implementation I was about to propose allows step over small obstacles like stairs. If you have remarks on the implementation so far, go ahead... to sukender : I didn't exacly get your remarks while I'm sure they are founded. Anyway I think that when I wil have finished to code both mode, things will become clearer for me and for you. Get you informed as soon as the manipulator is ready. When you ready just post the changes to either osg-submissions if it's ready to merge, or to osg-users if you feel it still needs more discussion. Cheers, Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon -- Loïc Simon ___ 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 -- Loïc Simon ___ 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 -- Loïc Simon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.8.0 osgviewer and dae plugin
Hi All, I have the following error (pls see end of email) when I tried to load dae file with osgviewer I compiled with collada-dom version 2.2.0. It was compiled on a RHEL 5.3 linux variation (simular to centos) with boost 1.33 installed in /usr. But I am not using boost 1.33 but using boost 1.38 and collada-dom makefile is modified to point to my boost 1.38 compilation directory by adding the following lines to line 12 of the make/dom.mk file. includeOpts := -Iinclude -Iinclude/$(colladaVersion) includeOpts += -I/usr/local/tools/boost/boost-1.38.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/include/boost-1_38 libOpts += -L/usr/local/tools/boost/boost-1.38.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib I also tried 2.8.1-rc3 with similar error. I cannot find a way to specify boost location in the cmake and I also cannot uninstall boost 1.33 from the machine. Any help is much appreciated. Thanks Simon Linux version is 2.6.18-128.1.1.el5 compiler is 4.1.2 arch is x86_64 === error message=== [...@vis MINI X-Wing]$ osgviewer MINI\ X-Wing.dae Warning: dynamic library '/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64/osgPlugins-2.8.1/osgdb_dae.so' exists, but an error occurred while trying to open it: /usr/local/tools/collada-dom/collada-dom-2.2.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/libcollada14dom.so: undefined symbol: _ZN5boost6system19get_system_categoryEv Warning: Could not find plugin to read objects from file MINI X-Wing.dae. osgviewer: No data loaded ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0 osgviewer and dae plugin
Hi Simon, [...@vis MINI X-Wing]$ osgviewer MINI\ X-Wing.dae Warning: dynamic library '/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64/osgPlugins-2.8.1/osgdb_dae.so' exists, but an error occurred while trying to open it: /usr/local/tools/collada-dom/collada-dom-2.2.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/libcollada14dom.so: undefined symbol: _ZN5boost6system19get_system_categoryEv Warning: Could not find plugin to read objects from file MINI X-Wing.dae. osgviewer: No data loaded Looks to me like your LD_LIBRARY_PATH does not contain the path to your boost dynamic libraries, or it is after the path to the system-compiled boost libraries. You'll need to add the bin/ directory of your own compiled version of boost (where the .so files are) to your LD_LIBRARY_PATH, before the directory where the system-compiled versions are. You might want to do this only when starting your app, otherwise other programs which might expect to find the system-compiled version of boost might have problems too. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GPU Stat Collection Crash When Rendering Multithreaded - Driver Bug?
I am running into a weird crash when trying to use the gpu stat collection mechanism employed by osgViewer. Here is what I have at the moment. osg::Stats * pStats = new osg::Stats(Viewer Stats); pStats-collectStats(frame_rate, true); pStats-collectStats(update, true); pStats-collectStats(rendering, true); pStats-collectStats(gpu, true); If I run my code so that the rendering model runs in parallel with other viewpoints, the Nvidia driver will crash when trying to poll the gpu for the query timer. If I run my code so that the rendering model runs serially, then the driver is happy. If I comment out the collection of the gpu stats, then I never see the crash when testing the parallel case. This same problem exists in the osgViewer application. If either of the parallel rendering models are used, at some point when viewing the stats the application will crash. If I use the single threaded model, the driver is happy. Here is my setup Windows XP SP3 Intel Core 2 6600 OSG 2.8.0 Nvidia Quadro FX 3450 - Driver ver. 182.46 Dual Monitor Setup I have tried to turn off the Threaded Optimizations from the control panel, but for some reason the two GL worker threads are always created when SetPixelFormat is called. I've even looked into the registry to verify that the control panel was setting the registry value to 2. Seeing that this is more than likely an issue with the driver, I'm going to have to take it up with Nvidia, but I was wondering if anyone in the Windows community might be able to provide me with some insight into how I can truly shutdown the worker threads that the driver seems to be creating. If anyone else has seen this problem and knows of a workaround, please chime in and share that knowledge. Thanks. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Changing Versions of Visual Studio
I have been working exclusively with Visual Studio 2003 and now I'm dealing with different machines with newer VS versions on them. My question is: With each version of Visual Studio, does there need to be a separate OSG build? The first problem I saw was something as simple as the code snippet below: 1 osg::ref_ptr osg::Group theRoot = new osg::Group; 2 theRoot-setName(Root); 3 cout theRoot-getName(); This executes just fine on my current machine with VS2003 (under which OSG was compiled ). However when I copy that baseline over (with the same OSG lib/dll files) to a machine with VS2005 on it, compile it and run that same code, it crashes on line 3. I didn't think it should need a rebuild but I don't see what else might cause that problem. I thought I'd ask if indeed OSG needs to be rebuilt for each VS version while I'm looking for other causes. Thanks, Tom ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] render depth buffer to image for one time
Hi, I tried to fix it a few more times, but I can't. It's working for color but not for the depth buffer. When I execute the following code I get the variables texture2D and depth filled with white color. I draw the image and the texture on a rectangle. Thanks for help, jojo Code: osgViewer::Viewer* v = new osgViewer::Viewer; v-setCameraManipulator(new osgGA::TrackballManipulator()); v-getCameraManipulator()-setHomePosition(getCameraPosition2(), getLookAtPoint(), getUpVector()); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; traits-target = osg::Camera::FRAME_BUFFER_OBJECT; traits-x =0; traits-y = 0; traits-width = 720; traits-height = 576; traits-windowDecoration = false; traits-doubleBuffer = false; traits-sharedContext = 0; traits-pbuffer = true; osg::GraphicsContext* _gc= osg::GraphicsContext::createGraphicsContext(traits.get()); v-getCamera()-setGraphicsContext(_gc); osg::Camera* camera = v-getCamera(); camera-setViewport(new osg::Viewport(0,0,720,576)); double fovy, aspectRatio, zNear, zFar; camera-getProjectionMatrixAsPerspective(fovy, aspectRatio, zNear, zFar); std::cout fovy aspectRatiozNear zFar\n; fovy+=41.0; camera-setProjectionMatrixAsPerspective(fovy, aspectRatio, zNear, zFar); std::cout fovy aspectRatiozNear zFar\n; v-setSceneData(osgDB::readNodeFile(Scene1.osg)); v-setDataVariance(osg::Object::DYNAMIC); v-setThreadingModel(osgViewer::Viewer::SingleThreaded); v-realize(); osg::ref_ptrosg::Image depth = new osg::Image; osg::ref_ptrosg::Image color = new osg::Image; color-allocateImage(720, 576, 1, GL_RGBA, GL_UNSIGNED_BYTE); depth-allocateImage(720, 576, 1, GL_DEPTH_COMPONENT, GL_FLOAT); camera-attach(osg::Camera::COLOR_BUFFER, color.get()); camera-attach(osg::Camera::DEPTH_BUFFER, depth.get()); osg::ref_ptrosg::Texture2D texture2D = new osg::Texture2D; texture2D-setTextureSize(720, 576); texture2D-setInternalFormat(GL_DEPTH_COMPONENT); texture2D-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR); texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR); camera-attach(osg::Camera::DEPTH_BUFFER, texture2D.get(), 0, 0, false); //camera-attach(osg::Camera::DEPTH_BUFFER, depth.get(),0,0); v-frame(); -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11207#11207 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0 osgviewer and dae plugin
Hi J-S, Thank you for your help. Yes I have the lib dir of my boost in my LD_LIBRARY_PATH. I even tried to create libboost_filesystem.so link everywhere with the same outcome. The thing is, /usr/lib64 where the system boost reside is not on the LD_LIBRARY_PATH. How do you set that so that whatever value I set in LD_LIBRARY_PATH will superceed /usr/lib64? I am using PU_AIS (Princeton University version of centos). Is ordering of the packages on the LD_LIBRARY_PATH also an issue? Thanks Simon [...@vis build]$ osgviewer /home/one/data/3dmodels/MINI\ X-Wing/MINI\ X-Wing.dae Warning: dynamic library '/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64/osgPlugins-2.8.1/osgdb_dae.so' exists, but an error occurred while trying to open it: /usr/local/tools/collada-dom/collada-dom-2.2.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/libcollada14dom.so: undefined symbol: _ZN5boost6system19get_system_categoryEv Warning: Could not find plugin to read objects from file /home/one/data/3dmodels/MINI X-Wing/MINI X-Wing.dae. osgviewer: No data loaded [...@vis build]$ echo $LD_LIBRARY_PATH /usr/local/tools/gdal/gdal-1.6.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/vrjuggler/vrjuggler-2.2.1/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64:/usr/local/tools/boost/boost-1.38.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/cppunit/cppunit-1.12.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/cppdom/cppdom-0.7.10/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64:/usr/local/tools/OpenSG/OpenSG-2.0.0-r1874/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64:/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64:/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64/osgPlugins-2.8.0:/usr/local/tools/collada-dom/collada-dom-2.2.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/jasper/ jasper-1.900.1/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/Coin/Coin-3.0.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/tools/vtk/vtk-5.2.1/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/vtk-5.2:/usr/local/tools/paraview/paraview-3.4.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/paraview-3.2:/usr/local/tools/qt/qt-4.3.5/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib:/usr/local/openmpi/1.2.8/gcc/x86_64/lib64:/usr/local/lib64/openmpi:/usr/local/tools/omniORB/omniORB-4.1.3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, May 1, 2009 1:23:07 PM Subject: Re: [osg-users] OpenSceneGraph-2.8.0 osgviewer and dae plugin Hi Simon, [...@vis MINI X-Wing]$ osgviewer MINI\ X-Wing.dae Warning: dynamic library '/usr/local/tools/OpenSceneGraph/OpenSceneGraph-2.8.1-rc3/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib64/osgPlugins-2.8.1/osgdb_dae.so' exists, but an error occurred while trying to open it: /usr/local/tools/collada-dom/collada-dom-2.2.0/vis.Linux-2.6.18-128.1.1.el5.x86_64.gcc-4.1.2.release/lib/libcollada14dom.so: undefined symbol: _ZN5boost6system19get_system_categoryEv Warning: Could not find plugin to read objects from file MINI X-Wing.dae. osgviewer: No data loaded Looks to me like your LD_LIBRARY_PATH does not contain the path to your boost dynamic libraries, or it is after the path to the system-compiled boost libraries. You'll need to add the bin/ directory of your own compiled version of boost (where the .so files are) to your LD_LIBRARY_PATH, before the directory where the system-compiled versions are. You might want to do this only when starting your app, otherwise other programs which might expect to find the system-compiled version of boost might have problems too. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning message during VPB configure
I did what the warning suggested and added the if statement above the line given. I then had to do it for CMakeModules/VpbMacroUtils.cmake. It now runs without giving me a warning. However, I get the following when I try to make: [ 14%] Building CXX object src/vpb/CMakeFiles/vpb.dir/Commandline.o /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp: In member function ‘void vpb::Commandline::processImageOrHeightField(vpb::Source::Type, const std::string)’: /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:108: error: ‘class osgTerrain::Terrain’ has no member named ‘getNumColorLayers’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:108: error: ‘class osgTerrain::Terrain’ has no member named ‘getColorLayer’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:116: error: ‘class osgTerrain::Terrain’ has no member named ‘setColorLayer’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:121: error: ‘class osgTerrain::Terrain’ has no member named ‘getElevationLayer’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:129: error: ‘class osgTerrain::Terrain’ has no member named ‘setElevationLayer’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp: In member function ‘int vpb::Commandline::read(std::ostream, osg::ArgumentParser, osgTerrain::Terrain*)’: /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:491: error: ‘class osgTerrain::Terrain’ has no member named ‘getTerrainTechnique’ /home/mwhall/Download/VirtualPlanetBuilder/src/vpb/Commandline.cpp:495: error: ‘class osgTerrain::Terrain’ has no member named ‘setTerrainTechnique’ make[2]: *** [src/vpb/CMakeFiles/vpb.dir/Commandline.o] Error 1 make[1]: *** [src/vpb/CMakeFiles/vpb.dir/all] Error 2 make: *** [all] Error 2 Any ideas? Michael On Fri, 2009-05-01 at 14:39 -0500, Michael W. Hall wrote: I get the following warning during the generate of ccmake for VPB: CMake Warning (dev) at src/vpb/CMakeLists.txt:38 (ADD_LIBRARY): Policy CMP0003 should be set before this line. Add code such as if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) as early as possible but after the most recent call to cmake_minimum_required or cmake_policy(VERSION). This warning appears because target vpb links to some libraries for which the linker must search: -lpthread and other libraries with known full path: /usr/local/lib64/libosg.so CMake is adding directories in the second list to the linker search path in case they are needed to find libraries from the first list (for backwards compatibility with CMake 2.4). Set policy CMP0003 to OLD or NEW to enable. Could someone tell me how to fix this? My OSG is build and working. I am running 2.8.0 Thanks, Michael ___ 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] Linker error with VirtualPlanetBuilder
Howdy, When building both VirtualPlanetBuilder and some custom PyOSG bindings against OSG 2.8.0 I get the following linker error (among others): 1TaskManager.obj : error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3d __thiscall osg::Group::computeBound(void)const (?computebo...@group@osg@@ube?av?$boundingspherei...@vvec3d@osg@@@2...@xz) The Vec3d portion of the error is, in fact, correct. There is no such symbol in all of the OSG libs. There is, however, a osg@@ube?av?$boundingspherei...@vvec3f@osg@@@2...@xz (note that it's a Vec3f). Is this a difference between OSG 2.6.x and 2.8.0? Is there a solution? We've been able to build our PyOSG bindings against OSG 2.6 successfully without this issue in the past. Thanks, Michael Day ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Set view direction
I am trying to switch the current view to show th emodel from top/front/side etc. I'm trying both getCamer()-setViewMatrix() and trackballmanipulator setRotation() but I can't seem to work out the correct angle and X/Y/Z_AXIS Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11213#11213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT example
Hi all, There's a significant new clue here. Two of my three systems that crash with osgviewerQT --QOSGWidget cow.osg are multi-processor systems. The third is a very fast single core Xenon. All they systems where there's no crash are single processor systems. Is anyone else able to run this demo on a multi-core system? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linker error with VirtualPlanetBuilder
It might be a version issue. Are you sure that your VPB version is compatible with your OSG version? For example, I wouldn't expect current svn head of VPB to be compatible with OSG v2.6... Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Day, Michael (Mike) (CIV) Sent: Friday, May 01, 2009 3:52 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Linker error with VirtualPlanetBuilder Howdy, When building both VirtualPlanetBuilder and some custom PyOSG bindings against OSG 2.8.0 I get the following linker error (among others): 1TaskManager.obj : error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3d __thiscall osg::Group::computeBound(void)const (?computebo...@group@osg@@ube?av?$boundingspherei...@vvec3d@osg@@@2...@xz) The Vec3d portion of the error is, in fact, correct. There is no such symbol in all of the OSG libs. There is, however, a osg@@ube?av?$boundingspherei...@vvec3f@osg@@@2...@xz (note that it's a Vec3f). Is this a difference between OSG 2.6.x and 2.8.0? Is there a solution? We've been able to build our PyOSG bindings against OSG 2.6 successfully without this issue in the past. Thanks, Michael Day ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linker error with VirtualPlanetBuilder
Paul, Thanks for the quick response. Current svn trunk of VPB should build find under 2.8.0, though, right? I haven't tried to build VPB with OSG 2.6, only our custom PyOSG. My point was only that the linker errors we're getting are identical for both projects. Thanks, Mike - Paul Martz pmartz at skew-matrix.com mailto:osg-users%40lists.openscenegraph.org?Subject=Re%3A%20%5Bosg-user s%5D%20Linker%20error%20with%20VirtualPlanetBuilderIn-Reply-To=%3C5DA29 666083C4982B7E055D55DD1A378%40supreme%3E Fri May 1 15:43:54 PDT 2009 * Previous message: [osg-users] Linker error with VirtualPlanetBuilder http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/027369.html * Next message: [osg-users] Set view direction http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/027370.html * Messages sorted by: [ date ] http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/date.html#27373 [ thread ] http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/thread.html#27373 [ subject ] http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/subject.html#27373 [ author ] http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/ 2009-May/author.html#27373 It might be a version issue. Are you sure that your VPB version is compatible with your OSG version? For example, I wouldn't expect current svn head of VPB to be compatible with OSG v2.6... Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-bounces at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg [mailto:osg-users-bounces at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg ] On Behalf Of Day, Michael (Mike) (CIV) Sent: Friday, May 01, 2009 3:52 PM To: osg-users at lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg Subject: [osg-users] Linker error with VirtualPlanetBuilder Howdy, When building both VirtualPlanetBuilder and some custom PyOSG bindings against OSG 2.8.0 I get the following linker error (among others): 1TaskManager.obj : error LNK2001: unresolved external symbol public: virtual class osg::BoundingSphereImplclass osg::Vec3d __thiscall osg::Group::computeBound(void)const (?computeBound at Group http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg @osg@@UBE?AV?$BoundingSphereImpl at VVec3d http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg @osg@@@2 at XZ http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg ) The Vec3d portion of the error is, in fact, correct. There is no such symbol in all of the OSG libs. There is, however, a osg@@UBE?AV?$BoundingSphereImpl at VVec3f http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg @osg@@@2 at XZ http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg (note that it's a Vec3f). Is this a difference between OSG 2.6.x and 2.8.0? Is there a solution? We've been able to build our PyOSG bindings against OSG 2.6 successfully without this issue in the past. Thanks, Michael Day ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] preDrawCallback?
If I want to draw something in the client area of the window OSG is rendering into (via Windows GDI calls), would I do this in a preDrawCallback? (after setting an appropriate ClearMask in the camera) I want to have a gradient background and I'm thinking that I could do this easily with the GradientFill() function. I realize I could accomplish the same thing using methods from the osgHud example, but I'm thinking that a GDI call would be faster. Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Set view direction
Hm. This seems to work fine for me. I've never encountered any problems setting the view direction. Do you have a camera manipulator set that is overriding your matrix? 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 Martin Beckett Sent: Friday, May 01, 2009 4:10 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Set view direction I am trying to switch the current view to show th emodel from top/front/side etc. I'm trying both getCamer()-setViewMatrix() and trackballmanipulator setRotation() but I can't seem to work out the correct angle and X/Y/Z_AXIS Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11213#11213 ___ 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] Changing Versions of Visual Studio
Hi Tom -- My guess is your VS 2003 app is not compatible with VS 2005 c runtime libs. If you were to also copy the VS 2003 c runtime libs to the other machine, or use something like InstallShield to pick them up and package them and install them, then that should work. As J-S said, this problem is not limited to OSG but is a general issue with any VS app. 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 Appolloni, Thomas Sent: Friday, May 01, 2009 12:30 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Changing Versions of Visual Studio I have been working exclusively with Visual Studio 2003 and now I'm dealing with different machines with newer VS versions on them. My question is: With each version of Visual Studio, does there need to be a separate OSG build? The first problem I saw was something as simple as the code snippet below: 1 osg::ref_ptr osg::Group theRoot = new osg::Group; 2 theRoot-setName(Root); 3 cout theRoot-getName(); This executes just fine on my current machine with VS2003 (under which OSG was compiled ). However when I copy that baseline over (with the same OSG lib/dll files) to a machine with VS2005 on it, compile it and run that same code, it crashes on line 3. I didn't think it should need a rebuild but I don't see what else might cause that problem. I thought I'd ask if indeed OSG needs to be rebuilt for each VS version while I'm looking for other causes. Thanks, Tom ___ 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] Simple moving map using CADRG data
Michael, I'm actually not loading the TOC file at all. My map operates on a directory full of tiles. What's convenient about this is that sometimes I don't have a TOC file at all (for example, sometimes I just have a bunch of GeoTIFFs). I don't actually read the image data myself. I let the OSG plugin do that work for me. I just read the header of each tile using GDAL (to get the georeferencing information), then close the GDAL dataset, then read the image data from the tile using the normal OSG method (osgDB::readImageFile()). Right here, you might want to use an osgDB::ImageOptions and set the pixel window up to control the maximum resolution you want to load. Some CADRG images can get very large. Keep in mind though, that you'll have to tell osgDB::Registry that files with the file extension of the file you're trying to read (tl1, ja1, etc.) should be read by the OSG GDAL Plugin by calling: osgDB::Registry::addFileExtensionAlias http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00595.html#0f72e649a69082e9d357ef7b5b3e4455 (YOUR_FILE_EXTENSION_HERE, gdal) . So to answer your question, I never even get a subdataset, because I don't use the TOC file. Alan. Day, Michael (Mike) (CIV) wrote: Alan, The georeferencing part makes sense, thanks for pointing that out. When you load from GDAL are you doing something more sophisticated than this? poDataset = (GDALDataset*) GDALOpen(path\\RPF\\A.TOC, GA_ReadOnly); for each subdataset (tile): nextSubDataset = (GDALDataset*) GDALOpen(path, GA_ReadOnly); for each tile in nextSubDataset: //is this necessary??! extract pixel information //It's pretty involved... going //through RasterBands and //Blocks, etc. The reason I is because it seems like you're saying that once you get to a subdataset then the OSG plugin might be able to extract the tile to an image for you? This would save a lot of pain. If it's not possible, do you have any sample code showing how to extract a tile into an image? Thanks, Michael Day - Joe, I've done this, and I'll give you a basic overview of what I've done, but there may be better ways to do it, because I was fairly new to OSG at the time, and some of my ideas may be obsolete these days. The GDAL OSG plugin will give you image data (pixels), but will not provide the geo-referencing data, so you'll have to link to GDAL directly to get the geographic extents of each tile. Shane is right that the A.TOC file is not supported by OSG, so I had to just load all the map tiles which existed in a directory, building my own index of tiles with their extents in them. I do all the paging myself, going through the index and finding out what's in range and loading it if need-be. This could probably be done a lot more elegantly using the PagedLOD class, but I found that in practice, what I do is fairly fast. Check the GDAL documentation, and look for GetGeoTransform(). This returns a bunch of numbers in an array, but one of the GDAL examples will tell you what each number represents (lat/long, degrees per pixel, etc.). You'll need to come up with a projection to map the Lat/Long to some kind of XYZ that can be used by OSG. I use SEDRIS (www.sedris.org) for my coordinate conversions these days because it will convert from anything to anything else (Geodetic, Geocentric, UTM, MGRS, and more). Check the license to make sure you're comfortable with it. It's free to use, and available in source form, but they have their own license. For your purposes though, there's likely a simpler way to do your coordinate conversion. Good luck. Alan. Glenn Waldron wrote: / Supposedly GDAL does support the TOC for CADRG/CIB:/ / / / http://www.gdal.org/frmt_various.html (search for RPF)/ / / / You might be able to coerce osgEarth's GDAL driver into doing what you / / want./ / / / / / Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : / / +1.703.652.4791/ / / / / / On Tue, Apr 28, 2009 at 11:28 AM, Tueller, Shayne R Civ USAF AFMC 519 / / SMXS/MXDEC Shayne.Tueller at hill.af.mil http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org / / mailto:Shayne.Tueller at hill.af.mil http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org wrote:/ / / / Joe,/ / / / From what I understand, GDAL will import a single CADRG image but/ / it won't/ / handle the dynamic decompression and different map resolutions as/ / you zoom/ / in and out (the A.TOC file). I've done some moving map support/ / using OSG for/ / our software but I built my own paged moving map database using/ / the OSG/ / paging database support with different CADRG images. It seems to/ / work for/ / what we need./ / / / IMO, I think a real moving map plugin that
[osg-users] VPB cURL dependency
Hi Robert -- I'm curious about the cURL dependency in VPB's CMakeLists.txt file. Was this left in from old development? VPB seems to build and link fine with this dependency removed. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
