Re: [osg-users] Proposed changes to VPB re compression
Hi Brad, To benchmark, you can change the quality of the compression in TextureUtils.cpp. For the moment, the compression is set to nvtt::Quality_Production, using nvtt::Quality_Normal you should have much better result. As I remember from the nvtt documentation, nvtt::Quality_Normal is much faster and produces quite good result. When I have tested NVTT with VPB, I don't remember to have such difference between CPU and OpenGL, but maybe the texture compression does not take so much time compared to the rest of the VPB processing. Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: mardi 26 octobre 2010 13:00 To: OpenSceneGraph Users Subject: Re: [osg-users] Proposed changes to VPB re compression Hi, I have just finished some basic benchmarking of the three different compression methods I am playing with with some very surprising results (to me anyway : ) I created a small test app that used either the current GL context, NVTT with CUDA or vanilla CPU based NVTT to compress an image to a specified format. The image was compressed ten times and the total time taken is given in seconds. I ran the tests on two machines (one laptop and one desktop). Desktop Win7 3.2ghz CPU Geforce GTX275 -- CPUCUDA GL DXT117.0 1.47 0.66 DXT1a 14.22 0.47 DXT312.58 1.48 0.52 Laptop Win7 3.17ghz CPU ATI Mobility FireGL V5700 - CPUGL DXT118.61 3.913 DXT1a 20.65 3.948 DXT318.13 0.977 The main surprise for me was how much faster using the current GL approach is compared to using NVTT. There is a big difference between the two video cards but both are much faster than the CPU. I was a bit disappointed at the CUDA results especially given this will only work on Nvidia cards and some formats (the DXT1a cuda score isn't given as this output format doesn't support cuda acceleration atm). Before these tests I was leaning towards defaulting to using NVTT for maximum compatibility but this doesn't look so good now. Cheers, Brad DISCLAIMER:- -- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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 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] New nvtt based compression in VPB
I have not tried at all the cuda code path. My primary goal was to use VPB on a linux server without any graphics card. You can try to enable cuda acceleration in the code maybe. You can set commpressor.enableCudaAcceleration(true); in TextureUtils.cpp. Just by curiosity, it can be interesting to see if it really improves the performance. Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: lundi 11 octobre 2010 10:08 To: OpenSceneGraph Users Subject: Re: [osg-users] New nvtt based compression in VPB Thanks for the answer. I literally just opened up the project to try and track down the issue. I am glad I check my email first! I will apply the patch you submit to my local repository and test it as soon as its available. Have you managed to get the cuda code path working with nvtt? I saw no difference in performance when I rebuilt with cuda support so I am guessing it wasn't being used. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Fabien Lavignotte Sent: Monday, 11 October 2010 4:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users] New nvtt based compression in VPB Hi Brad, I just check the code, in fact it does not work when using --terrain, only with --polygonal. I am submitting a fix to Robert. Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: dimanche 10 octobre 2010 07:02 To: OpenSceneGraph Users Subject: [osg-users] New nvtt based compression in VPB Hi, I have just completed a build of VPB using the new nvtt code path. Everything thing seems to have compiled and linked ok and VPB still works. The issue I am seeing is that the resulting textures arnt compressed. Some processing is definitely being done as using --RGBA-compressed or -compressed-dxt5 results in my test build taking 4 times longer than using --RGBA. The resulting dds images are not compressed at all though. Using RGBA-compressed result in RGBA images and DXT5 results in RGB images (determined using nvtt nvddsinfo). I will try and track down what is going on but it seems very odd. Has anyone had success with this new code path? I am running: Windows 7 64 bit VS 2009 SP1 64 bit builds OSG, VPB and nvtt (and gdal) were all compiled from source using the latest versions. Cheers, Brad DISCLAIMER:- -- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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 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.or g DISCLAIMER:- -- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is su
Re: [osg-users] New nvtt based compression in VPB
Hi Brad, I just check the code, in fact it does not work when using --terrain, only with --polygonal. I am submitting a fix to Robert. Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: dimanche 10 octobre 2010 07:02 To: OpenSceneGraph Users Subject: [osg-users] New nvtt based compression in VPB Hi, I have just completed a build of VPB using the new nvtt code path. Everything thing seems to have compiled and linked ok and VPB still works. The issue I am seeing is that the resulting textures arnt compressed. Some processing is definitely being done as using --RGBA-compressed or -compressed-dxt5 results in my test build taking 4 times longer than using --RGBA. The resulting dds images are not compressed at all though. Using RGBA-compressed result in RGBA images and DXT5 results in RGB images (determined using nvtt nvddsinfo). I will try and track down what is going on but it seems very odd. Has anyone had success with this new code path? I am running: Windows 7 64 bit VS 2009 SP1 64 bit builds OSG, VPB and nvtt (and gdal) were all compiled from source using the latest versions. Cheers, Brad DISCLAIMER:- -- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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 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] Performance problem with osgTerrain
Hi Robert, We are testing in release build. And we have the same result on windows and linux. The high cost is a little bit surprising but i didn't have time to investigate further. So, the idea is add a flag on osgTerrain (hum set/getProcessNeigbours maybe?) Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: mercredi 6 octobre 2010 14:58 To: OpenSceneGraph Users Subject: Re: [osg-users] Performance problem with osgTerrain Hi Fabien, Such high costs when doing boundary equalization are not good news. Disabling this should be an option, placing this control into osgTerrain::Terrain would be the appropriate thing to do rather than just commenting a code path out in GeometryTechnique.cpp. It would also be good to get to bottom of why the cost is so high. Are you testing in debug build of the OSG? Robert. On Wed, Oct 6, 2010 at 1:47 PM, Fabien Lavignotte wrote: > Hi, > We uses the last developer version of OpenSceneGraph 2.9.9, with the > last version of VPB. > There is a very important performance problem with terrain generated > by VPB using --terrain, so based on osgTerrain. > The update time takes very long at different intervals (between 8 and > 10 ms, instead of below 1 ms the rest of the time). > As a result, a solid frame rate of 60 Hz cannot be obtained. > After investigation, the reason is the neighbouring computation to in > GeometryTechnique. By just removing it (see file attached), the > performance problem is gone. > I don't really understand why this neighbouring computation is needed, > apparently it is here to be sure that tile border are equals, but i > don't see any problem when commented out. > So, maybe it would be interesting to add an option in order to > desactive the neighbouring computation? > > Cheers, > Fabien > > __ > 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 > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ 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] [VPB] VPB without opengl context
About the patent issue, i found this on the nvidia site : http://code.google.com/p/nvidia-texture-tools/wiki/FAQ Apparently no problem, even in US. So is it ok if i send you a submission in the next few days to use nvidia texture tools into VPB ? Fabien. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: jeudi 19 août 2010 17:41 To: OpenSceneGraph Users Subject: Re: [osg-users] [VPB] VPB without opengl context Hi Fabien, I've been planning to make it possible to use osgdem without a graphics context - it's only used for mipmapping and texture compression. Libsquish is already something I've experimented with but haven't reployed as the result I got were mixed and there is also the patent on the S3TC compression technique which libsquish uses which complicates it's usage. Robert. On Thu, Aug 19, 2010 at 4:10 PM, Fabien Lavignotte wrote: > Hi Robert, > I modify a little bit VPB so that it can works without an active > opengl context. > First, i use some command line options in order to not need a opengl > context, disable compressed textures and creation of mip-map (--RGB-24 > -mip-mapping-hardware). Then i desactivate the creation of graphics > context in DataSet::_run (see attached the modified file). > It works, at least i can generate a small database without problem. > My plan is to add the support of compressed textures and mipmapping > through the nvidia-texture-tools library > (http://code.google.com/p/nvidia-texture-tools/). It is based on > libsquish for the compression part. So i can safely remove the > creation of a graphics context in DataSet. > But there is also a graphics context created in ThreadPool, and more > precisely only for writing threads. Looking at the code, i cannot see > why this is needed. In which case, the graphics context is needed ? Is > it safe just to remove it ? > Thanks, > Fabien > > __ > 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 > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ 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] osg::Particle problem
Hi Wang, It is just my personal experience that a simple to use and high performance generic particle system is a huge if not impossible task. Just see for exemple in osgParticle the PrecipitationEffect done by Robert, in fact it does not use osgParticle framework. I send you the ParticleSystemBuilder class i use to create my effects. Very basic but sufficient for my own needs. It covers particle drawing (using PointSprite), and basic particle management. It is a template class so that you can easily reuse it with different kind of particles. Too rough to be really useful for OSG, but it can give an idea of a lightweight solution. Then most of the code (particle simulation) is done in each effect and deals with various problems, like precision issues when dealing with earth-like databases. Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wang Rui Sent: mardi 17 août 2010 16:25 To: OpenSceneGraph Users Subject: Re: [osg-users] osg::Particle problem Hi Fabien, Today's osgParticle already uses GLBeginEndAdapter for rendering particles, which is actually glDrawArray() at its low-level implementation. I wonder if this is not too inefficient comparing with the use of osg::Geometry. Of course, making use of shaders will be much better on modern graphics devices. To develop new features for osgParticle, I mainly refer to a good open-source project by David McAllister (http://www.particlesystems.org/). Any other ideas and usable source code are welcome and appreciated. Cheers, Wang Rui 2010/8/17 Fabien Lavignotte : > A quick mail just to give more opinions on the subject. > We stopped using osgParticle for performance reasons. osgParticle is a > little bit overengineered for a real time particle system, the > particle simulation loop is quite bloated with different layer of > abstractions that are finally not so useful. Moreover, the particle > class is quite big, with lot of informations that are not useful for > all particle systems. It is really not suited for high performance > particle systems (thousands of particles). > Finally, doing the particle simulation on my own was easier, and give > me more control. For exemple, the particle system must work with > earth-like databases. I have several effects (explosion, reactor > trail, dust trail), they just share the drawing code (convert > particles to osg::Geometry) and some basic particles management, and it is > sufficient... > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ParticleSystemBuilder.h Description: ParticleSystemBuilder.h ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
A quick mail just to give more opinions on the subject. We stopped using osgParticle for performance reasons. osgParticle is a little bit overengineered for a real time particle system, the particle simulation loop is quite bloated with different layer of abstractions that are finally not so useful. Moreover, the particle class is quite big, with lot of informations that are not useful for all particle systems. It is really not suited for high performance particle systems (thousands of particles). Finally, doing the particle simulation on my own was easier, and give me more control. For exemple, the particle system must work with earth-like databases. I have several effects (explosion, reactor trail, dust trail), they just share the drawing code (convert particles to osg::Geometry) and some basic particles management, and it is sufficient... From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Serge Lages Sent: mardi 17 août 2010 15:26 To: OpenSceneGraph Users Subject: Re: [osg-users] osg::Particle problem OK, I agree with you, the main problems with the current library are precisions issues and performance, I hope you'll be able to handle them ! On Tue, Aug 17, 2010 at 3:05 PM, Wang Rui wrote: Hi Serge, I plan to keep full back-compatibility of previous osgParticle library. Its design and structure is still usable and easy-to-extend in my opinion. Wang Rui 2010/8/17 Serge Lages : > Is there any roadmap about osgParticle ? Does it need to be completely > rewritten or only improved to take advantage of more modern techniques ? > ___ 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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ 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] Recurrent warning on SVN trunk
Hi Jean Sebastien, I have removed the warning by putting the declaration of objectDeleted() directly into the class definition. See attached file. It seems to be a compiler bug. I love template :) Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: lundi 17 mai 2010 17:39 To: OpenSceneGraph Users Subject: Re: [osg-users] Recurrent warning on SVN trunk Hi Robert, >> Anyways, any other things you want me to try? > > Afraid not. We could just use a pragma to ignore it, but I'd rather > get to the bottom of it and address it directly. OK, then anyone else have any ideas of what we could try? Anyone else had this warning in the past, and what did you do to remove it? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ observer_ptr Description: observer_ptr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk for OpenThread/OpenSceneGraph
Hi All, In order to compile on Windows with Wrappers ON, some exports are still missing on osgPresentation::AnimationMaterialCallback and osgUtil::IncrementalCompileOperation::CompileSet. Regards, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: vendredi 19 février 2010 15:08 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk for OpenThread/OpenSceneGraph Hi Martin, Thanks for testing. The errors are down to two methods that I had their implementation from Registry into a dedicated companion class, alas I hadn't removed the declaration though so these methods were indeed the cause of missing symbols. I have now removed the offending methods and updated the wrappers. Could you do an svn update and let me know that the build now works fine, Thanks, Robert. On Fri, Feb 19, 2010 at 11:40 AM, Martin Naylor wrote: > Hi Robert, > Just checkout the latest build this around 10.30am and am receiving > the following build errors under Windows 7 and VS2008. > I did check the box wrappers under cmake and these are all wrapper errors. > Hope it helps. > > Regards > > Martin. > > > > > > > Error 62 error LNK2019: unresolved external symbol > "__declspec(dllimport) public: void __thiscall > osgDB::Registry::removeDotOsgWrapper(class osgDB::DotOsgWrapper *)" > (__imp_?removedotosgwrap...@registry@osgDB@@qaexpavdotosgwrap...@2@@Z) > referenced in function "public: __thiscall `anonymous > namespace'::reflector79::reflector79(void)" > (??0reflecto...@?a0xf54704f2@@q...@xz) Registry.obj Wrapper osgDB > Error 63 error LNK2019: unresolved external symbol > "__declspec(dllimport) public: void __thiscall > osgDB::Registry::addDotOsgWrapper(class osgDB::DotOsgWrapper *)" > (__imp_?adddotosgwrap...@registry@osgDB@@qaexpavdotosgwrap...@2@@Z) > referenced in function "public: __thiscall `anonymous > namespace'::reflector79::reflector79(void)" > (??0reflecto...@?a0xf54704f2@@q...@xz) Registry.obj Wrapper osgDB > Error 64 fatal error LNK1120: 2 unresolved externals > F:\Coding\OSG\OpenSceneGraph\bin\Debug\..\..\bin\osgPlugins-2.9.7\osgw > rapper > _osgDBd.dll Wrapper osgDB > Error 65 error LNK2019: unresolved external symbol "public: > void __thiscall > osgPresentation::AnimationMaterialCallback::update(class > osg::Node &)" > (?upd...@animationmaterialcallback@osgPresentation@@qaexaavn...@osg@@@ > Z) referenced in function "public: __thiscall `anonymous > namespace'::reflector155::reflector155(void)" > (??0reflector...@?a0x73eee86d@@q...@xz) AnimationMaterial.obj > Wrapper osgPresentation Error 66 error LNK2019: unresolved > external symbol "public: double __thiscall > osgPresentation::AnimationMaterialCallback::getAnimationTime(void)const " > (?getanimationt...@animationmaterialcallback@osgPresentation@@QBENXZ) > referenced in function "public: __thiscall `anonymous > namespace'::reflector155::reflector155(void)" > (??0reflector...@?a0x73eee86d@@q...@xz) AnimationMaterial.obj > Wrapper osgPresentation Error 67 error LNK2019: unresolved > external symbol "public: void __thiscall > osgPresentation::AnimationMaterialCallback::setPause(bool)" > (?setpa...@animationmaterialcallback@osgPresentation@@qae...@z) > referenced in function "public: __thiscall `anonymous > namespace'::reflector155::reflector155(void)" > (??0reflector...@?a0x73eee86d@@q...@xz) AnimationMaterial.obj > Wrapper osgPresentation Error 68 error LNK2019: unresolved > external symbol "public: void __thiscall > osgPresentation::AnimationMaterialCallback::reset(void)" > (?re...@animationmaterialcallback@osgPresentation@@QAEXXZ) referenced > in function "public: __thiscall `anonymous > namespace'::reflector155::reflector155(void)" > (??0reflector...@?a0x73eee86d@@q...@xz) AnimationMaterial.obj > Wrapper osgPresentation Error 69 error LNK2001: unresolved > external symbol "public: virtual void __thiscall > osgPresentation::AnimationMaterialCallback::operator()(class > osg::Node *,class osg::NodeVisitor *)" > (??ranimationmaterialcallb...@osgpresentation@@uaexpavn...@osg@@PAVNod > eVisit > o...@3@@Z) AnimationMaterial.obj Wrapper osgPresentation Error > 70 fatal error LNK1120: 5 unresolved externals > F:\Coding\OSG\OpenSceneGraph\bin\Debug\..\..\bin\osgPlugins-2.9.7\osgw > rapper _osgPresentationd.dll Wrapper osgPresentation Error 71 > error LNK2019: unresolved external symbol "public: void __thiscall > osgUtil::IncrementalCompileOperation::CompileSet::buildCompileMap(clas > s std::set osg::GraphicsContext *>,class std::allocator osg::GraphicsContext *> > &,unsigned int)" > (?buildcompile...@compileset@incrementalcompileoperat...@osgutil@@QAEX > AAV?$s > e...@pavgraphicscontext@osg@@u?$l...@pavgraphicscontext@osg@@@std@@V?$al > locato > r...@pavgraphicscontext@osg@@@4@@std@@i...@z) refe
Re: [osg-users] OSG Max Exporter Modifications
Hi Chris, I have submitted some code to the OSG Max exporter in july. I have send a mail to the current maintainer : Farshid Lashkari (fla...@gmail.com). He answer quickly and my changes have been put in the trunk. Hope that helps, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: mardi 5 janvier 2010 11:35 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] OSG Max Exporter Modifications Hi Chris, I'm not involved in any way with the OSG Max Exporter (OSGExp) project so am not in a position to speak on behalf of the developers/maintainers of it, let alone check in changes to it. I don't even have a windows machine so can't even compile OSGExp. So you'll need to discuss the changes with the current OSGExp maintainers, but don't know you should contact right now though. If you have changes to the OSG itself then please just post them to osg-submissions and I'll get on and review them. Cheers, Robert. On Mon, Jan 4, 2010 at 9:24 PM, Chris Rodgers wrote: > Hi Robert, > > Several months ago I had modified the OSG Max Exporter to address some issues artists were running into. More about the changes can be read on the Delta3D forum post at delta3d org -> Forum -> Artists' Studio -> OSG Exporter for 3DS Max 2010. > > In short, the changes allow OSG helpers to become parts of model hierarchies, prevent doubly referencing objects, and overall simplify helper assignments via the 3DS Max Schematic View and Link tool. > > Currently the code is accessible as a project with the Delta3D source code. With a few tweaks the project can be OSG-ready. Please let me know if would like me to send the the source you way. > > Cheers :) > > Chris > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=22064#22064 > > > > > > ___ > 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 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] Please test svn/trunk in prep for 2.9.6 dev release
Hi Robert, It works now with my example on windows. But i have a problem with my application, i am currently playing with Texture2D::SubloadCallback to optimize my image data transfer, and also avoid double buffering when using a drawing thread. There is a small bug with your change and SubloadCallback, the texture object is destroy at each call of Texture2D::apply because the modified count is never updated when using SubloadCallback. I have made a small fix to avoid that, see attachement. Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: mardi 8 décembre 2009 15:27 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi Fabien, On Tue, Dec 8, 2009 at 9:11 AM, Robert Osfield wrote: > I have been thinking about the issue of whether to force the > reassignment of a new texture object automatically when the size > changes or leave it just rescale, using gluScale, as it does right > now, and I'm moving towards getting osg::Texture to assign a new > texture object when the size changes. This would avoid the need for > an expensive scale operation, and also enable the support under GLES > and GL3 to work as neither have GLU. I have gone ahead and implemented this for Texture2D, it's now checked into svn/trunk. I've tested against you test example. Could you please do an svn update and test you application and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ Texture2D.cpp Description: Texture2D.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release
Hi Robert, I have an explanation for the difference in behaviors. I use GL_UNSIGNED_INT_8_8_8_8_REV as image data type and it does not seem to be supported with gluScaleImage (on windows at least). So, gluScaleImage does nothing and a pointer with garbage data is passed to glTexImage2D. On linux (i have tested OSG 2.9.5 on linux), the GLU library is newer and supports GL_UNSIGNED_INT_8_8_8_8_REV. So sorry for the noise. By the way, I fully agree with forcing the reassignment of new texture object when image size changes. I don't know if it could break existing apps but it seems quite logical. Thanks, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: mardi 8 décembre 2009 10:11 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi Fabien, I have been thinking about the issue of whether to force the reassignment of a new texture object automatically when the size changes or leave it just rescale, using gluScale, as it does right now, and I'm moving towards getting osg::Texture to assign a new texture object when the size changes. This would avoid the need for an expensive scale operation, and also enable the support under GLES and GL3 to work as neither have GLU. As for the difference in behavior on your systems I can't explain. Robert. On Mon, Dec 7, 2009 at 6:23 PM, Fabien Lavignotte wrote: > I have the resize image output in the console in both case (2.9.5 and 2.9.6). > I have tested my small example on the following platform : Windows XP + > NVidia QuadroFX 1600M, driver is 186.81 notebook version. We have some other > platforms but i am the only one that has tested OSG 2.9.6. > I will try to dig further into this, but it might be only a driver issue. > Thanks, > Fabien > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Robert Osfield > Sent: lundi 7 décembre 2009 18:04 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev > release > > Hi Fabien, > > I've just tried your example it works for me under Kubuntu 9.04 + ATI > graphics, the green square changes to blue as soon as I press 'a'. On the > console I also get an Scaling image from (800,800) to (600,600), which is > osg::Texture automatically working to refit the image to the size required by > the existing osg::Texture's texture object. > > Doing a dirtyTextureObject() will discard the texture object and should allow > the osg::Texture to create the appropriate sized texture object which doesn't > need resizing. > > Do you size any resize message output the console. What OS, hardware and > drivers are you working with? > > Robert. > > On Mon, Dec 7, 2009 at 3:50 PM, Fabien Lavignotte > wrote: >> >> Hi Robert, >> I have made a simple example based on osghud. Just press the 'a' key to >> reproduce the bug, it emulates what happens on a resize in our application, >> ie modification of the image content and size of a texture. >> With OSG 2.9.5, it works correctly, with OSG 2.9.6 the texture is garbage >> (totally transparent in this small exemple instead of blue). To add >> dirtyTextureObject on parent texture resolves the bug. >> In fact, the examples shows me that i have a problem before because OSG >> resample the image when it is resized. And i want the texture to take the >> new image size. So finally, calling dirtyTextureObject is really needed... >> But there is really a change of behaviour between the two versions, maybe it >> can be interesting to look further. >> >> Thanks, >> Fabien. >> >> -Original Message- >> From: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of >> Robert Osfield >> Sent: lundi 7 décembre 2009 10:50 >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev >> release >> >> Hi Fabuen, >> >> Thanks for the testing. Could you put together small example, such as a >> modified osg example, that illustrates this bug, I can then use this to >> rerpduce the bug and then confirm a fix to it. >> >> Thanks, >> Robert. >> >> On Mon, Dec 7, 2009 at 8:55 AM, Fabien Lavignotte >> wrote: >>> Update done and everything builds correctly now on Windows, MSCV2008. >>> >>> But at runtime, i have a problem when updating texture content. >>> I have some code
Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release
I have the resize image output in the console in both case (2.9.5 and 2.9.6). I have tested my small example on the following platform : Windows XP + NVidia QuadroFX 1600M, driver is 186.81 notebook version. We have some other platforms but i am the only one that has tested OSG 2.9.6. I will try to dig further into this, but it might be only a driver issue. Thanks, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: lundi 7 décembre 2009 18:04 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi Fabien, I've just tried your example it works for me under Kubuntu 9.04 + ATI graphics, the green square changes to blue as soon as I press 'a'. On the console I also get an Scaling image from (800,800) to (600,600), which is osg::Texture automatically working to refit the image to the size required by the existing osg::Texture's texture object. Doing a dirtyTextureObject() will discard the texture object and should allow the osg::Texture to create the appropriate sized texture object which doesn't need resizing. Do you size any resize message output the console. What OS, hardware and drivers are you working with? Robert. On Mon, Dec 7, 2009 at 3:50 PM, Fabien Lavignotte wrote: > > Hi Robert, > I have made a simple example based on osghud. Just press the 'a' key to > reproduce the bug, it emulates what happens on a resize in our application, > ie modification of the image content and size of a texture. > With OSG 2.9.5, it works correctly, with OSG 2.9.6 the texture is garbage > (totally transparent in this small exemple instead of blue). To add > dirtyTextureObject on parent texture resolves the bug. > In fact, the examples shows me that i have a problem before because OSG > resample the image when it is resized. And i want the texture to take the new > image size. So finally, calling dirtyTextureObject is really needed... > But there is really a change of behaviour between the two versions, maybe it > can be interesting to look further. > > Thanks, > Fabien. > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Robert Osfield > Sent: lundi 7 décembre 2009 10:50 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev > release > > Hi Fabuen, > > Thanks for the testing. Could you put together small example, such as a > modified osg example, that illustrates this bug, I can then use this to > rerpduce the bug and then confirm a fix to it. > > Thanks, > Robert. > > On Mon, Dec 7, 2009 at 8:55 AM, Fabien Lavignotte > wrote: >> Update done and everything builds correctly now on Windows, MSCV2008. >> >> But at runtime, i have a problem when updating texture content. >> I have some code that modify a texture image size when window is resized : >> >> _image->setImage( newWidth, newHeight, 1, GL_RGBA, GL_BGRA, >> GL_UNSIGNED_INT_8_8_8_8_REV, _qimage.bits(), >> osg::Image::NO_DELETE, 4 ); >> >> It used to works ok (osg 2.9.5), the parent texture is correctly updated at >> next rendering. >> But with the trunk, something goes wrong (garbage on the screen). I have >> added the following line on the parent texture in order to make it works : >> >> _texture->dirtyTextureObject(); >> >> >> Cheers, >> Fabien >> >> >> >> -Original Message- >> From: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of >> Robert Osfield >> Sent: samedi 5 décembre 2009 11:39 >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev >> release >> >> Hi Fabien, >> >> The wrappers were up to date, but osgAnimation simply had a method defined >> and no body for it. I could find any calls to the problem method so have >> simply removed it. Perhaps Cedric added it with the intention of >> implementing it, but in the end never did or need to it. >> Since the method isn't used I've just removed it and updated the wrappers. >> >> Could you do an svn update and let me know if things work fine. >> >> Cheers, >> Robert. >> >> On Fri, Dec 4, 2009 at 5:54 PM, Fabien Lavignotte >> wrote: >>> Hello, >>> I have tested the trunk r10851 on Windows, MSVC 2008. >>> I have a problem at build time, osgAnimation wrappers has not linked >>
Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release
Hi Robert, I have made a simple example based on osghud. Just press the 'a' key to reproduce the bug, it emulates what happens on a resize in our application, ie modification of the image content and size of a texture. With OSG 2.9.5, it works correctly, with OSG 2.9.6 the texture is garbage (totally transparent in this small exemple instead of blue). To add dirtyTextureObject on parent texture resolves the bug. In fact, the examples shows me that i have a problem before because OSG resample the image when it is resized. And i want the texture to take the new image size. So finally, calling dirtyTextureObject is really needed... But there is really a change of behaviour between the two versions, maybe it can be interesting to look further. Thanks, Fabien. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: lundi 7 décembre 2009 10:50 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi Fabuen, Thanks for the testing. Could you put together small example, such as a modified osg example, that illustrates this bug, I can then use this to rerpduce the bug and then confirm a fix to it. Thanks, Robert. On Mon, Dec 7, 2009 at 8:55 AM, Fabien Lavignotte wrote: > Update done and everything builds correctly now on Windows, MSCV2008. > > But at runtime, i have a problem when updating texture content. > I have some code that modify a texture image size when window is resized : > > _image->setImage( newWidth, newHeight, 1, GL_RGBA, GL_BGRA, > GL_UNSIGNED_INT_8_8_8_8_REV, _qimage.bits(), > osg::Image::NO_DELETE, 4 ); > > It used to works ok (osg 2.9.5), the parent texture is correctly updated at > next rendering. > But with the trunk, something goes wrong (garbage on the screen). I have > added the following line on the parent texture in order to make it works : > > _texture->dirtyTextureObject(); > > > Cheers, > Fabien > > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Robert Osfield > Sent: samedi 5 décembre 2009 11:39 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev > release > > Hi Fabien, > > The wrappers were up to date, but osgAnimation simply had a method defined > and no body for it. I could find any calls to the problem method so have > simply removed it. Perhaps Cedric added it with the intention of > implementing it, but in the end never did or need to it. > Since the method isn't used I've just removed it and updated the wrappers. > > Could you do an svn update and let me know if things work fine. > > Cheers, > Robert. > > On Fri, Dec 4, 2009 at 5:54 PM, Fabien Lavignotte > wrote: >> Hello, >> I have tested the trunk r10851 on Windows, MSVC 2008. >> I have a problem at build time, osgAnimation wrappers has not linked because >> a method (updateGraph) is not found. I just commented the method, and then >> everything build correclty. The wrappers have not been updated maybe? >> During the compilation of my project based on OSG, i need to add a lot of >> headers in order to build with the new OSG : #include >> and #include . Hey, a good thing if headers have been cleaned >> up... >> >> Then, at runtime no problem. It seems to me paging is smoother at first, but >> not so sure after testing an old version of our program. And good news, a >> recent bug that seems to block the paging disappears (the bug appears just >> after i have upgraded my nvidia drivers). >> So really good works! Thanks! >> >> Fabien >> >> >> -Original Message- >> From: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of >> Robert Osfield >> Sent: vendredi 4 décembre 2009 18:34 >> To: OpenSceneGraph Users >> Subject: [osg-users] Please test svn/trunk in prep for 2.9.6 dev >> release >> >> Hi All, >> >> It's been a long long time since the last dev release, virtue of me being >> distracted by work like OpenGL ES, GL object pools etc. I'm now almost back >> on top of submissions, so the time now looks good to make the 2.9.6 >> developer release. Since it's been so long since the last dev release there >> has been lots and lots of build and source code changes so would appreciate >> testing of svn/trunk so we can catch any problems prior to the 2.9.6 release >> - all going well I'll make it this comm
Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release
Update done and everything builds correctly now on Windows, MSCV2008. But at runtime, i have a problem when updating texture content. I have some code that modify a texture image size when window is resized : _image->setImage( newWidth, newHeight, 1, GL_RGBA, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, _qimage.bits(), osg::Image::NO_DELETE, 4 ); It used to works ok (osg 2.9.5), the parent texture is correctly updated at next rendering. But with the trunk, something goes wrong (garbage on the screen). I have added the following line on the parent texture in order to make it works : _texture->dirtyTextureObject(); Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: samedi 5 décembre 2009 11:39 To: OpenSceneGraph Users Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi Fabien, The wrappers were up to date, but osgAnimation simply had a method defined and no body for it. I could find any calls to the problem method so have simply removed it. Perhaps Cedric added it with the intention of implementing it, but in the end never did or need to it. Since the method isn't used I've just removed it and updated the wrappers. Could you do an svn update and let me know if things work fine. Cheers, Robert. On Fri, Dec 4, 2009 at 5:54 PM, Fabien Lavignotte wrote: > Hello, > I have tested the trunk r10851 on Windows, MSVC 2008. > I have a problem at build time, osgAnimation wrappers has not linked because > a method (updateGraph) is not found. I just commented the method, and then > everything build correclty. The wrappers have not been updated maybe? > During the compilation of my project based on OSG, i need to add a lot of > headers in order to build with the new OSG : #include > and #include . Hey, a good thing if headers have been cleaned up... > > Then, at runtime no problem. It seems to me paging is smoother at first, but > not so sure after testing an old version of our program. And good news, a > recent bug that seems to block the paging disappears (the bug appears just > after i have upgraded my nvidia drivers). > So really good works! Thanks! > > Fabien > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Robert Osfield > Sent: vendredi 4 décembre 2009 18:34 > To: OpenSceneGraph Users > Subject: [osg-users] Please test svn/trunk in prep for 2.9.6 dev > release > > Hi All, > > It's been a long long time since the last dev release, virtue of me being > distracted by work like OpenGL ES, GL object pools etc. I'm now almost back > on top of submissions, so the time now looks good to make the 2.9.6 developer > release. Since it's been so long since the last dev release there has been > lots and lots of build and source code changes so would appreciate testing of > svn/trunk so we can catch any problems prior to the 2.9.6 release - all going > well I'll make it this comming Monday morning. > > The API should be pretty compatible between 2.8.x and 2.9.6 so I'm hopping > that users won't see too many problems arising from all these changes, what I > can say is whether all the changes have broken the build in the less actively > used platforms i.e. beyond Linux and Window. Even on the most commonly used > platforms there are still lots of different architecture, build and > dependency differences to throw a spanner in the works so as much testing as > you can throw at it the better. > > If you see build and runtime issues just post a report of them to > osg-users/forum on this thread, and any fixes to osg-submissions as complete > modified files. > > If things work well for you then please email into this thread to confirm > that your plarform/build combination is working fine so I know how well we > are converging to a reasonably stable 2.9.6. > > Thanks in advance for your assistance, Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > org > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit ht
Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release
Hello, I have tested the trunk r10851 on Windows, MSVC 2008. I have a problem at build time, osgAnimation wrappers has not linked because a method (updateGraph) is not found. I just commented the method, and then everything build correclty. The wrappers have not been updated maybe? During the compilation of my project based on OSG, i need to add a lot of headers in order to build with the new OSG : #include and #include . Hey, a good thing if headers have been cleaned up... Then, at runtime no problem. It seems to me paging is smoother at first, but not so sure after testing an old version of our program. And good news, a recent bug that seems to block the paging disappears (the bug appears just after i have upgraded my nvidia drivers). So really good works! Thanks! Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: vendredi 4 décembre 2009 18:34 To: OpenSceneGraph Users Subject: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release Hi All, It's been a long long time since the last dev release, virtue of me being distracted by work like OpenGL ES, GL object pools etc. I'm now almost back on top of submissions, so the time now looks good to make the 2.9.6 developer release. Since it's been so long since the last dev release there has been lots and lots of build and source code changes so would appreciate testing of svn/trunk so we can catch any problems prior to the 2.9.6 release - all going well I'll make it this comming Monday morning. The API should be pretty compatible between 2.8.x and 2.9.6 so I'm hopping that users won't see too many problems arising from all these changes, what I can say is whether all the changes have broken the build in the less actively used platforms i.e. beyond Linux and Window. Even on the most commonly used platforms there are still lots of different architecture, build and dependency differences to throw a spanner in the works so as much testing as you can throw at it the better. If you see build and runtime issues just post a report of them to osg-users/forum on this thread, and any fixes to osg-submissions as complete modified files. If things work well for you then please email into this thread to confirm that your plarform/build combination is working fine so I know how well we are converging to a reasonably stable 2.9.6. Thanks in advance for your assistance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ 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] osg+QT MODKEY How to
The osgViewerQt example does not take into account modifier key. So, the
OSG modifier mask is always zero.
I have changed the conversion between Qt event and OSG event to handle
modifier properly.
Here is my code. You can adapt this code in your widget. Let me know if
you need some help.
Fabien
/*! Helper function which converts a Qt mouse button code into a osg
mouse button code */
inline void convertMouseEvent( osgGA::EventQueue* eventQueue,
QMouseEvent* eventQt, osgGA::GUIEventAdapter::EventType eventType )
{
eventQueue->getCurrentEventState()->setX( eventQt->x() );
eventQueue->getCurrentEventState()->setY( eventQt->y() );
int button = 0;
switch( eventQt->button() )
{
case Qt::LeftButton :
button = osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON;
break;
case Qt::MidButton :
button = osgGA::GUIEventAdapter::MIDDLE_MOUSE_BUTTON;
break;
case Qt::RightButton :
button = osgGA::GUIEventAdapter::RIGHT_MOUSE_BUTTON;
break;
}
if ( eventQt->type() == QEvent::MouseButtonPress )
eventQueue->getCurrentEventState()->setButtonMask( button |
eventQueue->getCurrentEventState()->getButtonMask());
else
eventQueue->getCurrentEventState()->setButtonMask( ~button &
eventQueue->getCurrentEventState()->getButtonMask());
unsigned int modKeyMask = 0;
if( eventQt->modifiers() & Qt::ShiftModifier)
{
modKeyMask |= osgGA::GUIEventAdapter::MODKEY_SHIFT;
}
if( eventQt->modifiers() & Qt::ControlModifier)
{
modKeyMask |= osgGA::GUIEventAdapter::MODKEY_CTRL;
}
if( eventQt->modifiers() & Qt::AltModifier)
{
modKeyMask |= osgGA::GUIEventAdapter::MODKEY_ALT;
}
osgGA::GUIEventAdapter* event = eventQueue->createEvent();
event->setEventType(eventType);
event->setTime(eventQueue->getTime());
event->setModKeyMask(modKeyMask);
event->setButton(button);
eventQueue->addEvent(event);
}
/*! overwrites the mouse pressed handler */
void Viewer::mousePressEvent( QMouseEvent* event )
{
GLWidget::mousePressEvent(event);
if ( _graphicsWindow.valid() )
{
convertMouseEvent( _graphicsWindow->getEventQueue(),
event, osgGA::GUIEventAdapter::PUSH );
}
}
/*! overwrites the mouse released handler */
void Viewer::mouseReleaseEvent( QMouseEvent* event )
{
GLWidget::mousePressEvent(event);
if ( _graphicsWindow.valid() )
{
convertMouseEvent( _graphicsWindow->getEventQueue(),
event, osgGA::GUIEventAdapter::RELEASE );
}
}
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Dieter
Pfeffer
Sent: lundi 9 mars 2009 09:34
To: OpenSceneGraph Users
Subject: Re: [osg-users] osg+QT MODKEY How to
Hi Legeo
I had a similar problem - using osg, qt4 and the AdapterWidget example.
In AdapterWidget::keypressEvent (...)
osgGA::GUIEventAdapter::KeySymbol) * (event->text().toAscii().data()
returns 0 in the call
_gw->getEventQueue()->keyPress( (... ) ) for keys like:
Qt::Key_up ... Have a look at the Qt documentation Qt::Key.
I have managed it with:
int c = *event->text().toAscii().data();
if ( c == 0)
{
switch (event->key())
{
case Qt::Key_PageDown:
_gw->getEventQueue()->keyPress(
osgGA::GUIEventAdapter::KeySymbol::KEY_Page_Down );
break;
case Qt::Key_PageUp:
_gw->getEventQueue()->keyPress(
osgGA::GUIEventAdapter::KeySymbol::KEY_Page_Up );
break;
case Qt::Key_Up:
_gw->getEventQueue()->keyPress( osgGA::GUIEventAdapter::KEY_Up);
break;
}
}
else
_gw->getEventQueue()->keyPress( (osgGA::GUIEventAdapter::KeySymbol) *
(event->text().toAscii().data() ) );
There might be a better solution but it works.
Dieter
Unclassified Mail
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org]on Behalf Of
legeochen
Sent: Saturday, 07 March, 2009 09:14
To: OpenSceneGraph Users
Subject: [osg-users] osg+QT MODKEY How to
Hi all,
I'm trying to add a Modkey event handler to my application
with osg and qt4. But it seems that the getModKeyMask() fuction fails to
work. Return value of getModKeyMask() always is 0, even if I have a
MODKEY pressed. And, this is my code:
if ( ea.getEventType() == osgGA::GUIEventAdapter::PUSH
&&
ea.getButtonMask() ==
osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON &&
ea.getModKeyMask() ==
osgGA::GUIEventAdapter::MODKEY_SHIFT )
{
/*-
do something here
-*/
}
How can I handle it? Thanks in advance!
cheers
legeo
Disclaimer:
If you are not the intended recipient of this email, please notify the
sender and delete it.
Any unauthori
[osg-users] Blending with osgAnimation
I move the discussion to osg-users. The TimeLineAnimationManager does not really seems appropriate for my needs. Let me explain better. I want to do "cross-fade" between two animations loop. The example shows "continuous blend" not "cross-fade" and between an endless animations and "short" animations. The figures in the following link show what i mean by cross-fade and continuous blend : http://www.gamasutra.com/features/20030704/edsall_02.shtml Maybe it is possible to do cross-fade with TimeLine (using BlendOut for exemple?), but i have preferred to hack a simple method to start... Then for my blending problems, I see into the code you are just doing addition and substraction on quaternion for blending, is it exact ? Fabien. -Original Message- From: osg-submissions-boun...@lists.openscenegraph.org [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of Cedric Pinson Sent: lundi 9 février 2009 14:30 To: OpenSceneGraph Submissions Subject: Re: [osg-submissions] Small fixes for osgAnimation Hi, If you check the osganimationtimline, it blends the two animations. The idle and the scratch. It could help you i guess. The screenshoot is funny :) Cheers, Cedric Fabien Lavignotte wrote: > For blending I have checked osganimationtimeline, the TimeLine thing is quite > nice but i am not sure it cover my needs. > I just wanted to blend smoothly when going from one animation loop to another > (for exemple run->walk, then walk->stand). Looking at TimeLine code i wasn't > sure it was possible. > So, i ended up hacking a node callback with BasicAnimationManager, by > setting weight on the 2 Animation and then let osgAnimation engine blend > properly the two animations. > Blending seems to be done but result is quite weird, even funny sometimes > (check the screenshot) but i don't know if it is osgAnimation fault, my code > or even the animations. I have to dig further into it but unfortunately i > don't have much time to dedicate to character animation, it is just a side > project. > > Fabien. > > -Original Message- > From: osg-submissions-boun...@lists.openscenegraph.org > [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf Of > Cedric Pinson > Sent: lundi 9 février 2009 12:41 > To: OpenSceneGraph Submissions > Subject: Re: [osg-submissions] Small fixes for osgAnimation > > Hi Fabien, > > I will check them for integration, could send me in futur a patch it's easier > for me to watch what changed. I know Robert prefer entire file, so i propose > you send both. > > Can you describe the problem you have about blending ? Did you check in the > osganimationtimeline example ? > > Thank you for your contribution > > Cheers, > Cedric > > Fabien Lavignotte wrote: > >> Some other litte changes just to clean up the API. >> >> TimeLine : remove virtual inheritance that is not needed RigGeometry : >> put some methods/members in private section (everything was public), >> use META_Object macro osganimationskinning.cpp : remove two lines >> that are not needed >> >> By the way, i have some good result with osgAnimation. I should post a >> screenshot soon. I still have some problems with blending for the moment... >> >> Thanks, >> Fabien >> >> >> >> -Original Message- >> From: osg-submissions-boun...@lists.openscenegraph.org >> [mailto:osg-submissions-boun...@lists.openscenegraph.org] On Behalf >> Of Cedric Pinson >> Sent: jeudi 5 février 2009 20:03 >> To: OpenSceneGraph Submissions >> Subject: Re: [osg-submissions] Small fixes for osgAnimation >> >> Here the file without the virtual osg::Object >> >> Cheers, >> Cedric >> >> Cedric Pinson wrote: >> >> >>> Hi Fabien, >>> Thanks for the fix, The virtual inherit from osg::Object was due >>> some previous test, it's not require. >>> >>> Cheers, >>> Cedric >>> >>> Fabien Lavignotte wrote: >>> >>> >>>> Hi Robert and Cedric, >>>> Here is some various small fixes i have done while playing with >>>> osgAnimation. - Animation : removed the _name attribute that is >>>> never used. >>>> - BasicAnimationManager : fix a crash on Windows with the example >>>> osganimationviewer. The _lastUpdate attribute was not initialized >>>> when using copy constructor. >>>> - CMakeLists.txt : add RigGeometry to the headers list And just a >>>> small comment on the Animation class, it uses virtual inheritance >>&g
Re: [osg-users] Problem when loading local then distant png file
Yes, it works fine now. I can use earth file in my application, thanks again for your great work (both osg and osgEarth!) Fabien -Original Message- From: Robert Osfield [mailto:robert.osfi...@gmail.com] Sent: lundi 26 janvier 2009 17:33 To: Fabien Lavignotte Cc: jasonbever...@gmail.com; OpenSceneGraph Users Subject: Re: [osg-users] Problem when loading local then distant png file Hi Fabien, Have you now tested the latest svn/trunk? Ribert. On Mon, Jan 26, 2009 at 3:41 PM, Fabien Lavignotte wrote: > Hum sorry Robert to bother you, but i look at the changes from Jason : > he fix the bug! > OpenSceneGraph evolves too fast for me :) Next time i will check the > really last version of the trunk. > > Fabien > > > -Original Message- > From: Robert Osfield [mailto:robert.osfi...@gmail.com] > Sent: lundi 26 janvier 2009 16:24 > To: jasonbever...@gmail.com; Fabien Lavignotte > Cc: OpenSceneGraph Users > Subject: Re: [osg-users] Problem when loading local then distant png > file > > Hi Jason & Fabien, > > I'm introducing Jason into discussion in the hope that he'll have some > ideas about what is going wrong as Jason's recently made changes to > Registry.cpp that affect the handling of http file references. > Jason's also one of the authors of osgEarth too so doubly relevant :-) > > I have a couple of other OSG bugs I'm chasing up right now so will > happily defer to others if they can fix this bug :-) > > If not then I'll step it and make sure it gets fixed prior to OSG 2.8. > > Robert. > > -- Forwarded message -- > From: Fabien Lavignotte > Date: Mon, Jan 26, 2009 at 1:29 PM > Subject: [osg-users] Problem when loading local then distant png file > To: osg-users@lists.openscenegraph.org > > > While trying osgEarth (great work by the way), I find a OSG problem. > osgEarth works correctly with osgviewer but not with our own viewer. > After some investigations with the debugger, it was because we are > loading a png file before loading the earth file. > And then when osgEarth try to load distant png files, it calls the > method osgDB::Registry::read. It tries first to load with existing > loaded plugins. > So it tries with osgdb_png plugin that returns a FILE_NOT_FOUND. > Finally, the method returns a FILE_NOT_FOUND because the curl plugin > is not yet loaded and will never be... the code to load it is just > after the FILE_NOT_FOUND return... > Surely, other image plugin have the same behavior, it is not only a > png problem. > > I have made a small modification to osgviewer to reproduce the > problem, just loading a png file at line 46. With this line, loading > google_maps.earth does not work, comment it and then it works... > > I think of different ways to fix that: > - modify the Registry::read method to handle file with server adress > differently > - modify each image plugin to return a FILE_NOT_HANDLED when the file > name contains server adress > - force to load the curl plugin at the start somewhere in my code... > or maybe in osgDB > > Not sure which is the best? > > Fabien Lavignotte > > __ > 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. > 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 has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ 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] Problem when loading local then distant png file
Hum sorry Robert to bother you, but i look at the changes from Jason : he fix the bug! OpenSceneGraph evolves too fast for me :) Next time i will check the really last version of the trunk. Fabien -Original Message- From: Robert Osfield [mailto:robert.osfi...@gmail.com] Sent: lundi 26 janvier 2009 16:24 To: jasonbever...@gmail.com; Fabien Lavignotte Cc: OpenSceneGraph Users Subject: Re: [osg-users] Problem when loading local then distant png file Hi Jason & Fabien, I'm introducing Jason into discussion in the hope that he'll have some ideas about what is going wrong as Jason's recently made changes to Registry.cpp that affect the handling of http file references. Jason's also one of the authors of osgEarth too so doubly relevant :-) I have a couple of other OSG bugs I'm chasing up right now so will happily defer to others if they can fix this bug :-) If not then I'll step it and make sure it gets fixed prior to OSG 2.8. Robert. -- Forwarded message -- From: Fabien Lavignotte Date: Mon, Jan 26, 2009 at 1:29 PM Subject: [osg-users] Problem when loading local then distant png file To: osg-users@lists.openscenegraph.org While trying osgEarth (great work by the way), I find a OSG problem. osgEarth works correctly with osgviewer but not with our own viewer. After some investigations with the debugger, it was because we are loading a png file before loading the earth file. And then when osgEarth try to load distant png files, it calls the method osgDB::Registry::read. It tries first to load with existing loaded plugins. So it tries with osgdb_png plugin that returns a FILE_NOT_FOUND. Finally, the method returns a FILE_NOT_FOUND because the curl plugin is not yet loaded and will never be... the code to load it is just after the FILE_NOT_FOUND return... Surely, other image plugin have the same behavior, it is not only a png problem. I have made a small modification to osgviewer to reproduce the problem, just loading a png file at line 46. With this line, loading google_maps.earth does not work, comment it and then it works... I think of different ways to fix that: - modify the Registry::read method to handle file with server adress differently - modify each image plugin to return a FILE_NOT_HANDLED when the file name contains server adress - force to load the curl plugin at the start somewhere in my code... or maybe in osgDB Not sure which is the best? Fabien Lavignotte __ 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.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 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] Problem when loading local then distant png file
I live on the bleeding edge, i am using the trunk revision 9521. Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: lundi 26 janvier 2009 14:46 To: OpenSceneGraph Users Subject: Re: [osg-users] Problem when loading local then distant png file Hi Fabien, Which version of the OSG are you testing osgEarth against? Robert. On Mon, Jan 26, 2009 at 1:29 PM, Fabien Lavignotte wrote: > While trying osgEarth (great work by the way), I find a OSG problem. > osgEarth works correctly with osgviewer but not with our own viewer. > After some investigations with the debugger, it was because we are > loading a png file before loading the earth file. > And then when osgEarth try to load distant png files, it calls the > method osgDB::Registry::read. It tries first to load with existing > loaded plugins. > So it tries with osgdb_png plugin that returns a FILE_NOT_FOUND. > Finally, the method returns a FILE_NOT_FOUND because the curl plugin > is not yet loaded and will never be... the code to load it is just > after the FILE_NOT_FOUND return... > Surely, other image plugin have the same behavior, it is not only a > png problem. > > I have made a small modification to osgviewer to reproduce the > problem, just loading a png file at line 46. With this line, loading > google_maps.earth does not work, comment it and then it works... > > I think of different ways to fix that: > - modify the Registry::read method to handle file with server adress > differently > - modify each image plugin to return a FILE_NOT_HANDLED when the file > name contains server adress > - force to load the curl plugin at the start somewhere in my code... > or maybe in osgDB > > Not sure which is the best? > > Fabien Lavignotte > > __ > 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 > > ___ 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 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
[osg-users] Problem when loading local then distant png file
While trying osgEarth (great work by the way), I find a OSG problem. osgEarth works correctly with osgviewer but not with our own viewer. After some investigations with the debugger, it was because we are loading a png file before loading the earth file. And then when osgEarth try to load distant png files, it calls the method osgDB::Registry::read. It tries first to load with existing loaded plugins. So it tries with osgdb_png plugin that returns a FILE_NOT_FOUND. Finally, the method returns a FILE_NOT_FOUND because the curl plugin is not yet loaded and will never be... the code to load it is just after the FILE_NOT_FOUND return... Surely, other image plugin have the same behavior, it is not only a png problem. I have made a small modification to osgviewer to reproduce the problem, just loading a png file at line 46. With this line, loading google_maps.earth does not work, comment it and then it works... I think of different ways to fix that: - modify the Registry::read method to handle file with server adress differently - modify each image plugin to return a FILE_NOT_HANDLED when the file name contains server adress - force to load the curl plugin at the start somewhere in my code... or maybe in osgDB Not sure which is the best? Fabien Lavignotte __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ osgviewer.cpp Description: osgviewer.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying a scene in the background ofa QGraphicsView
Hi,
I have tested the integration between Qt GraphicsView and OSG too.
To have better results, don't use drawBackground() to do OSG drawing but
overload the paint event of QGraphicsView, somthing like that :
void MyGraphicsView::paintEvent( QPaintEvent* event )
{
QGLWidget* widget = dynamic_cast( viewport() );
if (widget)
{
widget->makeCurrent();
getCanvas()->frame();
}
QGraphicsView::paintEvent( event );
}
Using drawBackground() is a bad idea because Qt has already initialized
some OpenGL state for its needs.
I have much better result this way. I still have some problems when
using osgEphemeris. Mixing Qt and OSG rendering in the same OpenGL
context does not seems very robust.
Maybe it is needed to "clear" OSG state before calling
QGraphicsView::paintEvent() but i stop my investigations there.
Hope that helps
Fabien
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yvon
Halbwachs
Sent: mercredi 5 novembre 2008 15:49
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Displaying a scene in the background ofa
QGraphicsView
Hi everybody,
I managed to use osg in a Qt QGraphicsView with the information that
Eric Zeremba and Rene Molenaar posted some weeks ago. I still have some
troubles though... Things work fine when I display the "cow.osg" scene
from the OpenSceneGraph example files, but nothing is displayed when I
use "cessna.osg". The only way to display it is to enable display lists
(it is set to false by default).
Anybody has a clue about what's going on?
Yvon
___
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 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
[osg-users] AutoTransform and small feature culling again
I have been through an issue that has been discussed previously on the osg-users mailing list. I have put the previous discussion below (it was end of august). The culling traversal was never called on an AutoTransform with auto scale because of small feature culling. So Robert answers with three solutions : 1) Switch off small feature culling : i don't want to do that because other node needs it for best performance 2) Override the computeBound() of the AutoTransform so that it returns an invalid bounding sphere for the first frame : the AutoTransform::computeBound() is already doing that ! 3) Override the computeBound() of the AutoTransform so that it returns an large default bounding sphere for the first frame i try that and it works quite well In fact, solution 2) does not work when the AutoTransform has a parent with multiple children. In this case, the parent is equals to valid bound of its children. So solution 3) works quite well, except when there is a "huge" camera movement. More precisily, when you look closely at the AutoTransform nodes, and then go back instantly to a very far distance. Culling traversal will not be called again because the AutoTransform bound will be too small... Not sure how to handle this case at the AutoTransform level or if it is possible. Thanks, Fabien -- Hi Sherman, I don't think your code is in error, nor that AutoTransform or small feature culling is in error, rather it's unfortunately chicken and the egg "which came first?" type dependency. The ways to break the culling of custom node in the first frame would be: To switch off small feature culling or set its value very low. To override the computeBound() of the AutoTransform so that it returns an invalid bounding sphere for the first frame till its been through the cull traversal once, once its been set correct then let the bounding sphere be computed correctly. To override the computeBound() of the AutoTransform so that it returns an large default bounding sphere for the first frame till its been through the cull traversal once, once its been set correct then let the bounding box be computed correctly. The two later solutions could possibly be rolled into AutoTransform itself. Robert. On Mon, Aug 25, 2008 at 2:53 AM, sherman wilcox wrote: > I've attached a small demo app that illustrates an issue I've > discovered (known?) with AutoTransform nodes and small feature > culling. Briefly summarized, if I add a custom AutoTransform node (see > code for trivial example) to the scenegraph just under the root node > everything seems fine, with or without small feature culling enabled. > However, if I add this AutoTransform node as a member of a osg::Group > and then add the group to the scenegraph then this node's accept > function no longer is called after the first traversal if small > feature culling is enabled. However, if I disable small feature > culling all is well. > > Is this a bug or am I doing something wrong? > > ___ > osg-users mailing list > osg-users at 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 __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
