[osg-users] [osgPlugins] osgdb_osganimation library on OSX
Hi, I am trying to build the osgAnimationViewer example on OSX 10.6 and I am running into a problem. Apparently the osgdb_osganimation plugin isn't included in the latest svn xcode project so it just doesn't build. I am also seeing that it can't find the libosgAnimation which doesn't seem like one even in the repo. Do I just need to build the osgdb_osganimation plugin or is the libosgAnimation one required as well? Thank you, Jerry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23247#23247 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vanilla GL VBOs in OSG
Hi Simon, Actually, VBOs have the same format as vertex arrays and they are implemented using (almost) the same interface. When a buffer object is bound, glVertexPointer uses the GPU buffer and the last parameter is instead used as an offset into the buffer (in this case 0). Also, the call to glEnableClientState is needed to associate the buffer binding with the appropriate array type. Regards, Mattias -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23250#23250 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using PolytopeIntersector from the root of the scene graph instead of camera
Hi Julien-Charles, Julien-Charles Levesque schrieb: Hi, I'm trying to use a PolytopeIntersector in my scene and so far I have succeeded but only by using the camera (i.e. mCamera-accept(PolyVisitor)) with a PolytopeIntersector built from x and y coordinates in window frame. However I would rather pass the visitor the root of my scene. I am doing this in a virtual reality project, and using the camera seems to complicate things a fair bit because we modify projection matrices and viewports a whole lot. For my LineSegmentIntersector I have used 3D points in model space, which worked fine when visiting the root of the scene. For the PolytopeIntersector I am unsure how to do this... Only examples I have found so far used either coordinates in projection space or coordinates in window space. Yes, the examples do not use all available constructors of PolytopeIntersector. That is something that has been sitting on my to-do-list for a long time... Now I have seen the CoordinateFrame MODEL or VIEW in the PolytopeIntersector constructor, but I am unsure as how to use it. I have seen that the Znear plane is fixed to 0 for MODEL and VIEW coordinate frames.. Does this mean that any object behind Z=0 could not be intersected? I also have a bad feeling that building and using the PolytopeIntersector in MODEL and VIEW coordinate frames will make it just rectangular instead of pyramidal. There are two constructors that should be suitable for your use-case: /** Construct a PolytopeIntersector using specified polytope in MODEL coordinates.*/ PolytopeIntersector(const osg::Polytope polytope); /** Construct a PolytopeIntersector using specified polytope in specified coordinate frame.*/ PolytopeIntersector(CoordinateFrame cf, const osg::Polytope polytope); You can pass an arbitrary Polytope which does not have to be rectangular. To recapitulate : I am trying to build a polytpe intersector from one 3d point in model space (or world space) and it's orientation. I would prefer this polytope intersector to be independent from the cameras or viewports. I am stuck at this point. Am I assuming something wrong? Did I miss something that could make this simpler? Do you have any clue that could help me? Am I even making sense? :D Try using one of the contructors above with a polytope that you provide and use the MODEL coordinate frame. That should work. Thank a lot, Sincerely, Julien-Charles Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Rendering 3DS objects with bump maps
Hi Eduardo, not considering bumps, you can export your models using OSGExp (you'll get .osg or .ive files). In this way you will get also transparency and reflections (this is true if you use Max's standard materials, but if you use for example v-ray materials I think you won't get many materials properties...you may get also totally black looking objects). If you need also bumps then you need to write a shader and apply it to your exported model through OSG's API. Hope this helps. Kind regards. Alessandro On Wed, Jan 6, 2010 at 12:48 PM, Eduardo Pinheiro eduardo.pinheiro.pt@ gmail.com wrote: Hi, Sorry the late answer but i was out. Well I have some question, in fact: - I have my 3D Max Team How is the better way to export they're work to openscenegraphic? Imagine this simple object: A bottle of glass. They make the 3d object. They make the textures They make the bump of the bottle (bottle label for example) They make the transparency They make the reflex The make the render At this moment they are exporting to me: - The 3d object in .obj way (because the .fbx plugin its only available in 2.9.6 release - i believe) - The textures in .tga files But the rest, how can i use they're work in order to have the same object with a similar transparency, reflex and render? I have to do everything by code? I hope you can understand what i'm trying to say. Thanks. Eduardo ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22145#22145 ___ 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] altering terrain texture...
Hi Shayne, On Tue, Jan 26, 2010 at 6:42 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: Robert, In answer to your inquiry, I'm using a database based on osgTerrain::TerrainTile so the texture settings are embedded in the tiles as you asserted earlier. I wasn't planning on using linear filtering. I was just giving it as an example on how I wanted to issue a particular call programmatically. Rather than attempt to tweak the texture settings per your suggestions, I was able to change the settings on the graphics card to get what I wanted thereby overriding the settings in the database. With anisotropic filtering in the database set at 16x, it was actually adding to the problem of texture crawling at far distances when flying low. Setting the anisotropic filtering down to 2x blurred the texture a bit more out far but it got rid of the crawling artifacts. We are using high resolution texture imagery (.25m texture) in the database which exacerbates the problem. In this case, the devil is truly in the details. Thanks again for your help... Interesting results, makes me wonder if the mipmap quality of filtering quality of the driver isn't that great. I have generally got best results with a high value of max anisotropy. As for the OSG, perhaps it's time to make the max anisotropy a variable in osgTerrain::Layer so that you can set in your application. The DatabasePager variable for setting could also be then used to set the value automatically. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Publicly Available TerraPage Database
Hi Ryan, On Tue, Jan 26, 2010 at 10:37 PM, Ryan H. Kawicki ryan.h.kawi...@boeing.com wrote: I'll be talking with our database engineers in the next couple of days. I'll be seeing what we can come up with. I'm hoping to get some buildings, trees, shrubs, walls, etc into the database, but I'll have to see after speaking with them. I too would like this to be included in the OSG data set. This is great to hear. It'll be really useful to have a public TXP databases that we can all test against, hosting it up on openscenegraph.org shouldn't be a problem. I am guessing the size would probably make it a bit too big to roll into the OpenSceneGraph-Data, but we can always host it alongside this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgdb_osganimation library on OSX
Hi Jerry, The Xcode projects are deprecated, and we are moving across to using Cmake. Try using CMake to generate either Makefiles and Xcode projects, this will generate all the latest components in the right places. Robert. On Wed, Jan 27, 2010 at 5:29 AM, Jerry Stoner jerry...@gmail.com wrote: Hi, I am trying to build the osgAnimationViewer example on OSX 10.6 and I am running into a problem. Apparently the osgdb_osganimation plugin isn't included in the latest svn xcode project so it just doesn't build. I am also seeing that it can't find the libosgAnimation which doesn't seem like one even in the repo. Do I just need to build the osgdb_osganimation plugin or is the libosgAnimation one required as well? Thank you, Jerry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23247#23247 ___ 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] osgocean agressive memory leaks
Hello Hello. Did this get sorted? Or was there a genuine leak? I just had a quick look and realised that changing the sun direction doesn't actually need to dirty the scene state. It's only needed to set uniforms in the GodRays and GodRayBlendSurface shaders. Those classes already have getters and setters for sun direction so I'll make a little mod so that it just updates the uniforms rather than rebuilds everything. I think I must have just forced a rebuild because I assumed that the sun direction wouldn't change. The leak however is more worrying. Kim. 2010/1/25 Trajce Nikolov nikolov.tra...@gmail.com Ok .. I will do that. I am Window7, osg like two weeks ago from the trunk and run your test app from the code you sent me I ll try to nail it down and let you know Nick http://www.linkedin.com/in/tnick Sent from Haguenau, Alsace, France On Mon, Jan 25, 2010 at 7:10 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Nick, on windows, it does eats the memory in large chunks after 5 minutes, It reach the limit I'm on Windows... Vista (at work) to be specific. Did you just compile osgOcean and the oceanExample? Which compiler? Which version of OSG? Sorry I'm kind of out of ideas, since it works fine for me... Can you look into the code since you can reproduce it? I suggest you start with OceanScene::init() and start by commenting out the whole method, see if the leak goes away, then uncomment half of it, check again, etc. until you've found the source... The block at the start where things are being set to NULL should cause objects in ref_ptrs to be freed before they're recreated... Good luck, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgocean agressive memory leaks
Hi Kim, I havent got into debugging yet. I am planning to get into this week. WIll keep you posted Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:27 AM, Kim Bale kcb...@googlemail.com wrote: Hello Hello. Did this get sorted? Or was there a genuine leak? I just had a quick look and realised that changing the sun direction doesn't actually need to dirty the scene state. It's only needed to set uniforms in the GodRays and GodRayBlendSurface shaders. Those classes already have getters and setters for sun direction so I'll make a little mod so that it just updates the uniforms rather than rebuilds everything. I think I must have just forced a rebuild because I assumed that the sun direction wouldn't change. The leak however is more worrying. Kim. 2010/1/25 Trajce Nikolov nikolov.tra...@gmail.com Ok .. I will do that. I am Window7, osg like two weeks ago from the trunk and run your test app from the code you sent me I ll try to nail it down and let you know Nick http://www.linkedin.com/in/tnick Sent from Haguenau, Alsace, France On Mon, Jan 25, 2010 at 7:10 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Nick, on windows, it does eats the memory in large chunks after 5 minutes, It reach the limit I'm on Windows... Vista (at work) to be specific. Did you just compile osgOcean and the oceanExample? Which compiler? Which version of OSG? Sorry I'm kind of out of ideas, since it works fine for me... Can you look into the code since you can reproduce it? I suggest you start with OceanScene::init() and start by commenting out the whole method, see if the leak goes away, then uncomment half of it, check again, etc. until you've found the source... The block at the start where things are being set to NULL should cause objects in ref_ptrs to be freed before they're recreated... Good luck, 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 ___ 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] [osgPlugins] Rendering 3DS objects with bump maps
Hi, I have done this lately. Might be possible to share the work. It has the bump, parallax, environmental mapping .. no glass yet. Might be good if we make an example that have all of these in a sample. Might save some time for others. Could you post your model and make it publicly available for the OSG-Data dataset ? Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 10:57 AM, alessandro terenzi a.tere...@gmail.comwrote: Hi Eduardo, not considering bumps, you can export your models using OSGExp (you'll get .osg or .ive files). In this way you will get also transparency and reflections (this is true if you use Max's standard materials, but if you use for example v-ray materials I think you won't get many materials properties...you may get also totally black looking objects). If you need also bumps then you need to write a shader and apply it to your exported model through OSG's API. Hope this helps. Kind regards. Alessandro On Wed, Jan 6, 2010 at 12:48 PM, Eduardo Pinheiro eduardo.pinheiro.pt@ gmail.com wrote: Hi, Sorry the late answer but i was out. Well I have some question, in fact: - I have my 3D Max Team How is the better way to export they're work to openscenegraphic? Imagine this simple object: A bottle of glass. They make the 3d object. They make the textures They make the bump of the bottle (bottle label for example) They make the transparency They make the reflex The make the render At this moment they are exporting to me: - The 3d object in .obj way (because the .fbx plugin its only available in 2.9.6 release - i believe) - The textures in .tga files But the rest, how can i use they're work in order to have the same object with a similar transparency, reflex and render? I have to do everything by code? I hope you can understand what i'm trying to say. Thanks. Eduardo ... Thank you! Cheers, Eduardo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22145#22145 ___ 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] [osgOcean] osgOcean bugs(?) and questions
Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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] [osgOcean] osgOcean bugs(?) and questions
I would like to jump into this discussion with few other request. As is implemented now, it has its own viewer. To make it work in my defined viewer, I had to switch off distorsion, glare and underwaterdof. Would be nice if these works as well with a given viewer Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:42 AM, Kim Bale kcb...@googlemail.com wrote: Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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] [osgOcean] osgOcean bugs(?) and questions
Hi Nick, I'm not sure what you mean by it's own viewer could you expand? Cheers. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com I would like to jump into this discussion with few other request. As is implemented now, it has its own viewer. To make it work in my defined viewer, I had to switch off distorsion, glare and underwaterdof. Would be nice if these works as well with a given viewer Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:42 AM, Kim Bale kcb...@googlemail.com wrote: Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] osgOcean bugs(?) and questions
Hi Kim, when I load ocean scene, it shows up in a View in a window mode, and you had to specify the size for the god rays or such, dont remember the details now. Do you know what I mean ? Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:49 AM, Kim Bale kcb...@googlemail.com wrote: Hi Nick, I'm not sure what you mean by it's own viewer could you expand? Cheers. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com I would like to jump into this discussion with few other request. As is implemented now, it has its own viewer. To make it work in my defined viewer, I had to switch off distorsion, glare and underwaterdof. Would be nice if these works as well with a given viewer Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:42 AM, Kim Bale kcb...@googlemail.com wrote: Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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 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] [osgOcean] osgOcean bugs(?) and questions
You mean the post render effects don't fill the screen? Have you tried setting the screen size using the setter on OceanScene? That should resize the size of the framebuffers to fill the window. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com Hi Kim, when I load ocean scene, it shows up in a View in a window mode, and you had to specify the size for the god rays or such, dont remember the details now. Do you know what I mean ? Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:49 AM, Kim Bale kcb...@googlemail.com wrote: Hi Nick, I'm not sure what you mean by it's own viewer could you expand? Cheers. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com I would like to jump into this discussion with few other request. As is implemented now, it has its own viewer. To make it work in my defined viewer, I had to switch off distorsion, glare and underwaterdof. Would be nice if these works as well with a given viewer Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:42 AM, Kim Bale kcb...@googlemail.comwrote: Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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 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] [osgOcean] osgOcean bugs(?) and questions
let me do some screen shots to tell you what I mean Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 12:06 PM, Kim Bale kcb...@googlemail.com wrote: You mean the post render effects don't fill the screen? Have you tried setting the screen size using the setter on OceanScene? That should resize the size of the framebuffers to fill the window. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com Hi Kim, when I load ocean scene, it shows up in a View in a window mode, and you had to specify the size for the god rays or such, dont remember the details now. Do you know what I mean ? Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:49 AM, Kim Bale kcb...@googlemail.com wrote: Hi Nick, I'm not sure what you mean by it's own viewer could you expand? Cheers. Kim. 2010/1/27 Trajce Nikolov nikolov.tra...@gmail.com I would like to jump into this discussion with few other request. As is implemented now, it has its own viewer. To make it work in my defined viewer, I had to switch off distorsion, glare and underwaterdof. Would be nice if these works as well with a given viewer Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 11:42 AM, Kim Bale kcb...@googlemail.comwrote: Hi Paul, The reason why both front and back facing polys are rendered is because the waves have an average height of zero so if you're at that height you usually able to see both front facing and back facing wave polys. This was done a while back before a lot of the effects were added. It's probably not necessary any more since a lot of the under/over water effects use this height to decide which of the effects set should be turned on (above or below effects). So there isn't really a partially submerged state any more. However, what is slightly worrying is that you are seeing back facing polys above water. This suggests broken polys on the surface. I rewrote the code for tessellating the surface a while ago, but haven't managed to add it to the library yet. It will get added I just can't say when at the moment. Hopefully disabling back face culling is sufficient for you application. Regards, Kim. 2010/1/15 Paul Palumbo paul1...@yahoo.com Okay... Now that I'm understanding more of the code lately, maybe that wasn't the best of images to reference. However, I'm seeing exactly the same black dots in the image when I use the standard oceanExample case with its sky dome and viewing above the ocean surface. When I turn on back face culling, I do not see the black dots. What does it mean to have back facing polygons when above the ocean surface? I can understand this when you are under the ocean surface but above. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22689#22689 ___ 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 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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] VRML plugin
Hi, I am trying to import a VRML model, created in Webots, into OSG and was wondering how to install and use the VRML 2.0 (wrl) reader plugin, as i have never used an OSG plugin before. I am using windows 7 and VS(2008). Thank you! Cheers, James -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23266#23266 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PagedLod do not release memory with own viewer
Hi everybody, I just ran some tests and I saw that a pagedLod - based ive file have different memory usage behaviors according to the viewer : OsgViewer loads the file, use more memory when the camera goes near the model, and release memory when the camera goes far. My own viewer (Composite viewer using one view) do not release the memory going far from the model ... Are there any parameters or settings to manage that ? Thanks. Regards, Vincent __ Information from ESET NOD32 Antivirus, version of virus signature database 4809 (20100127) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light lobes and shadow maps
Hi again on this topic. here is the issue. When I have the camera static, no matter how close to the obstacles, all is rendered it should, no artifacts. When I move the camera, it shows artifact. I have set the camera to not compute znear and zfar. What can affect this change when moving and not moving? Nick http://www.linkedin.com/in/tnick On Sat, Jan 16, 2010 at 1:48 PM, Trajce Nikolov nikolov.tra...@gmail.comwrote: Hi Wojtech, thanks for the links. I will do some research. I think I have fixed that. It turned out is the order of updating entities in the scene. The lightlobe camera was updated before updating the light itself, thats why different behavior based on the direction of movement. I think I will go further with this, to implement something for number of lights. Thanks again ! Nick http://www.linkedin.com/in/tnick On Sat, Jan 16, 2010 at 9:59 AM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Google for Shadow Maps. You will come up with a number of techniques. Few of them: http://www.punkuser.net/vsm/ http://gamma.cs.unc.edu/LOGPSM/ http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_SoftShadowMapping.pdf Most of these belong to the family of soft shadow algorithms. Soft shadows usually oversample depth texel and produce some average shadow term. Clamping this term to 0 if value is below certain threshold (for example 0.25) usually removes some of self shadowing artifacts. I will have the second look on the code but not today. Wojtek *From:* Trajce Nikolov nikolov.tra...@gmail.com *Sent:* Friday, January 15, 2010 10:16 PM *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Subject:* Re: [osg-users] light lobes and shadow maps do you have some pointers, papers to the work of this guys? I am interested in learning what is that about Nick http://www.linkedin.com/in/tnick Sent from Ünalan, İstanbul, Turkey On Fri, Jan 15, 2010 at 11:01 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Nick, I may look into the code but don't expect much this time. You need to attach the code first, though ;-). Few academy guys wrote couple dissertations on rasterization and aliasing errors in shadow mapping. Unless you try to do some exotic stuff like variance or logarithmic map you will have to use polygon offset. I guess you will end up to cranking up PolygonOfset even more if current values fail at some distance. I don't really have other tricks in my sleeve. Wojtek *From:* Trajce Nikolov nikolov.tra...@gmail.com *Sent:* Friday, January 15, 2010 9:08 PM *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Subject:* Re: [osg-users] light lobes and shadow maps That is exactly what I did. Please have a look at the updated code. The uniform is updated thru a callback and it multiplies the matrices, still there is a visual artifact.I dont have compute_near_far. The projection matrix is fixed with very small far plane (100 units, with the znear of 0.01). Nick http://www.linkedin.com/in/tnick On Fri, Jan 15, 2010 at 9:47 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi, Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may clamp near plane to very small value which may impact depth resolution. Other issue maybe related to GLSL float precision. The trick with multiplying view space coord by inverse view matrix to get world coord is performed on float values inside GLSL. Precision wise it would be better to multiply light camera MVP matrix by main camera INVERSE VIEW on the CPU. Osg Matrices use doubles. Put the result of the multiplication on GLSL matrix Uniform and use it to multiply gl_Vertex in the shader. Such approach multiplies matrices with high precision and resulting matrix will be better suited to be cast on single prec. GLSL matrix. The drawback of this solution is: you need to update the uniform every frame, because main camera view changes with each move. Wojtek *From:* Trajce Nikolov nikolov.tra...@gmail.com *Sent:* Friday, January 15, 2010 7:37 PM *To:* OpenSceneGraph Users osg-users@lists.openscenegraph.org *Subject:* Re: [osg-users] light lobes and shadow maps Hi Wojtek, now I spent more time exploring this, the polyoffset seam to work, but there is still a bit of shimmering. Its interesting, I put the light source in move, when it moves backwards, the obstacles are lighten ok, but forward, when the light comes close to the obstacles, the lighting is incorrect with shimmering . Any clue how to resolve this artifact ? Nick http://www.linkedin.com/in/tnick On Fri, Jan 15, 2010 at 4:48 PM, Trajce Nikolov nikolov.tra...@gmail.com wrote: ok .. make sense. Here is updated code, if some one wants to benefit from. LightLobes with handling of obstacles :). Thanks to Wojiech, Robert and the online community Nick http://www.linkedin.com/in/tnick Sent from Devlet, Ankara, Turkey On Fri, Jan 15,
Re: [osg-users] altering terrain texture...
Robert, I think your proposal would be a great benefit and would make things more flexible. For the record, the cards we're using are Nvidia GeForce 295s so they're fairly good cards. I would assume the drivers are as good but I don't know what algorithms they're resorting to for filtering on the texture... Thanks, -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 27, 2010 2:09 AM To: OpenSceneGraph Users Subject: Re: [osg-users] altering terrain texture... Hi Shayne, On Tue, Jan 26, 2010 at 6:42 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: Robert, In answer to your inquiry, I'm using a database based on osgTerrain::TerrainTile so the texture settings are embedded in the tiles as you asserted earlier. I wasn't planning on using linear filtering. I was just giving it as an example on how I wanted to issue a particular call programmatically. Rather than attempt to tweak the texture settings per your suggestions, I was able to change the settings on the graphics card to get what I wanted thereby overriding the settings in the database. With anisotropic filtering in the database set at 16x, it was actually adding to the problem of texture crawling at far distances when flying low. Setting the anisotropic filtering down to 2x blurred the texture a bit more out far but it got rid of the crawling artifacts. We are using high resolution texture imagery (.25m texture) in the database which exacerbates the problem. In this case, the devil is truly in the details. Thanks again for your help... Interesting results, makes me wonder if the mipmap quality of filtering quality of the driver isn't that great. I have generally got best results with a high value of max anisotropy. As for the OSG, perhaps it's time to make the max anisotropy a variable in osgTerrain::Layer so that you can set in your application. The DatabasePager variable for setting could also be then used to set the value automatically. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic QuadTree on spherical terrain
Hi, Thank you for that hint! Best regards, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23275#23275 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLod do not release memory with own viewer
On 1/27/2010 7:38 AM, Vincent Bourdier wrote: Hi everybody, I just ran some tests and I saw that a pagedLod - based ive file have different memory usage behaviors according to the viewer : OsgViewer loads the file, use more memory when the camera goes near the model, and release memory when the camera goes far. My own viewer (Composite viewer using one view) do not release the memory going far from the model ... Are there any parameters or settings to manage that ? Usually this is a result of your viewer code lacking some important code. Is your viewer source copied from current OSG examples? Thanks. Regards, Vincent -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] altering terrain texture...
Hi Shayne, On Wed, Jan 27, 2010 at 3:11 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: I think your proposal would be a great benefit and would make things more flexible. I'm rather busy working on submissions, so if you can dive in and implement it would sure shorted the features time to market :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgprerendercubemap
Hi Robert,
attached is slighly modified and corrected example with multitexturing with
prerendered cubemaps. There was an issue with the uniforms that are cube
samplers. also, it has the correct OpenGL coordinate system now. I think it
should replace the existing example. I spent one day to figure things for
real application out of this example and believe some one else could benefit
from it
Nick
http://www.linkedin.com/in/tnick
/* OpenSceneGraph example, osgprerendercubemap.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osgViewer/Viewer
#include osg/Projection
#include osg/Geometry
#include osg/Texture
#include osg/TexGen
#include osg/Geode
#include osg/ShapeDrawable
#include osg/PolygonOffset
#include osg/CullFace
#include osg/TextureCubeMap
#include osg/TexMat
#include osg/MatrixTransform
#include osg/Light
#include osg/LightSource
#include osg/PolygonOffset
#include osg/CullFace
#include osg/Material
#include osg/PositionAttitudeTransform
#include osg/ArgumentParser
#include osgDB/ReadFile
#include osgUtil/SmoothingVisitor
#include osg/Camera
#include osg/TexGenNode
#include osg/Texture2D
#include iostream
using namespace osg;
unsigned int numTextures = 6;
ref_ptrGroup _create_scene()
{
ref_ptrGroup scene = new Group;
ref_ptrGeode geode_1 = new Geode;
scene-addChild(geode_1.get());
ref_ptrGeode geode_2 = new Geode;
ref_ptrMatrixTransform transform_2 = new MatrixTransform;
transform_2-addChild(geode_2.get());
transform_2-setUpdateCallback(new osg::AnimationPathCallback(Vec3(0, 0, 0),
Z_AXIS, inDegrees(45.0f)));
scene-addChild(transform_2.get());
ref_ptrGeode geode_3 = new Geode;
ref_ptrMatrixTransform transform_3 = new MatrixTransform;
transform_3-addChild(geode_3.get());
transform_3-setUpdateCallback(new osg::AnimationPathCallback(Vec3(0, 0, 0),
Z_AXIS, inDegrees(-22.5f)));
scene-addChild(transform_3.get());
const float radius = 0.8f;
const float height = 1.0f;
ref_ptrTessellationHints hints = new TessellationHints;
hints-setDetailRatio(2.0f);
ref_ptrShapeDrawable shape;
shape = new ShapeDrawable(new Box(Vec3(0.0f, 0.0f, -2.0f), 10, 10.f, 0.1),
hints.get());
shape-setColor(Vec4(0.5f, 0.5f, 0.7f, 1.0f));
geode_1-addDrawable(shape.get());
shape = new ShapeDrawable(new Sphere(Vec3(-3.0f, 0.0f, 0.0f), radius),
hints.get());
shape-setColor(Vec4(0.6f, 0.8f, 0.8f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Box(Vec3(3.0f, 0.0f, 0.0f), 2 * radius),
hints.get());
shape-setColor(Vec4(0.4f, 0.9f, 0.3f, 1.0f));
geode_2-addDrawable(shape.get());
#if 0
shape = new ShapeDrawable(new Cone(Vec3(0.0f, 0.0f, -3.0f), radius, height),
hints.get());
shape-setColor(Vec4(0.2f, 0.5f, 0.7f, 1.0f));
geode_2-addDrawable(shape.get());
#endif
shape = new ShapeDrawable(new Cylinder(Vec3(0.0f, 0.0f, 3.0f), radius,
height), hints.get());
shape-setColor(Vec4(1.0f, 0.3f, 0.3f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new ShapeDrawable(new Box(Vec3(0.0f, 3.0f, 0.0f), 2, 0.1f, 2),
hints.get());
shape-setColor(Vec4(0.8f, 0.8f, 0.4f, 1.0f));
geode_3-addDrawable(shape.get());
// material
ref_ptrMaterial matirial = new Material;
matirial-setColorMode(Material::DIFFUSE);
matirial-setAmbient(Material::FRONT_AND_BACK, Vec4(0, 0, 0, 1));
matirial-setSpecular(Material::FRONT_AND_BACK, Vec4(1, 1, 1, 1));
matirial-setShininess(Material::FRONT_AND_BACK, 64.0f);
scene-getOrCreateStateSet()-setAttributeAndModes(matirial.get(),
StateAttribute::ON);
return scene;
}
osg::NodePath createReflector()
{
osg::PositionAttitudeTransform* pat = new osg::PositionAttitudeTransform;
pat-setPosition(osg::Vec3(0.0f,0.0f,0.0f));
pat-setAttitude(osg::Quat(osg::inDegrees(0.0f),osg::Vec3(0.0f,0.0f,1.0f)));
#if 1
Geode* node = new Geode;
const float radius = 0.8f;
ref_ptrTessellationHints hints = new TessellationHints;
hints-setDetailRatio(2.0f);
ShapeDrawable* shape = new ShapeDrawable(new Sphere(Vec3(0.0f, 0.0f, 0.0f),
radius * 1.5f), hints.get());
shape-setColor(Vec4(0.8f, 0.8f, 0.8f, 1.0f));
Re: [osg-users] light lobes and shadow maps
That looks like shadow texture or shadow texcoords being out of sync by one frame. Most probably main camera view matrix from former frame is used to setup shadow coord tex generation. Wojtek - Original Message - From: Trajce Nikolov To: OpenSceneGraph Users Sent: Wednesday, January 27, 2010 4:20 PM Subject: Re: [osg-users] light lobes and shadow maps Looks like its really the order of updating things. I moved the movement from the update callback and place it outside the frame loop, so the next frame everything is in place. Attached is the latest code if someone is interested in light lobes working with obstacles Nick http://www.linkedin.com/in/tnick On Wed, Jan 27, 2010 at 4:59 PM, Trajce Nikolov nikolov.tra...@gmail.com wrote: Hi again on this topic. here is the issue. When I have the camera static, no matter how close to the obstacles, all is rendered it should, no artifacts. When I move the camera, it shows artifact. I have set the camera to not compute znear and zfar. What can affect this change when moving and not moving? Nick http://www.linkedin.com/in/tnick On Sat, Jan 16, 2010 at 1:48 PM, Trajce Nikolov nikolov.tra...@gmail.com wrote: Hi Wojtech, thanks for the links. I will do some research. I think I have fixed that. It turned out is the order of updating entities in the scene. The lightlobe camera was updated before updating the light itself, thats why different behavior based on the direction of movement. I think I will go further with this, to implement something for number of lights. Thanks again ! Nick http://www.linkedin.com/in/tnick On Sat, Jan 16, 2010 at 9:59 AM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Google for Shadow Maps. You will come up with a number of techniques. Few of them: http://www.punkuser.net/vsm/ http://gamma.cs.unc.edu/LOGPSM/ http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_SoftShadowMapping.pdf Most of these belong to the family of soft shadow algorithms. Soft shadows usually oversample depth texel and produce some average shadow term. Clamping this term to 0 if value is below certain threshold (for example 0.25) usually removes some of self shadowing artifacts. I will have the second look on the code but not today. Wojtek From: Trajce Nikolov Sent: Friday, January 15, 2010 10:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] light lobes and shadow maps do you have some pointers, papers to the work of this guys? I am interested in learning what is that about Nick http://www.linkedin.com/in/tnick Sent from Ünalan, İstanbul, Turkey On Fri, Jan 15, 2010 at 11:01 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Nick, I may look into the code but don't expect much this time. You need to attach the code first, though ;-). Few academy guys wrote couple dissertations on rasterization and aliasing errors in shadow mapping. Unless you try to do some exotic stuff like variance or logarithmic map you will have to use polygon offset. I guess you will end up to cranking up PolygonOfset even more if current values fail at some distance. I don't really have other tricks in my sleeve. Wojtek From: Trajce Nikolov Sent: Friday, January 15, 2010 9:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] light lobes and shadow maps That is exactly what I did. Please have a look at the updated code. The uniform is updated thru a callback and it multiplies the matrices, still there is a visual artifact.I dont have compute_near_far. The projection matrix is fixed with very small far plane (100 units, with the znear of 0.01). Nick http://www.linkedin.com/in/tnick On Fri, Jan 15, 2010 at 9:47 PM, Wojciech Lewandowski lewandow...@ai.com.pl wrote: Hi, Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may clamp near plane to very small value which may impact depth resolution. Other issue maybe related to GLSL float precision. The trick with multiplying view space coord by inverse view matrix to get world coord is performed on float values inside GLSL. Precision wise it would be better to multiply light camera MVP matrix by main camera INVERSE VIEW on the CPU. Osg Matrices use doubles. Put the result of the multiplication on GLSL matrix Uniform and use it to multiply gl_Vertex in the shader. Such approach multiplies matrices with high precision and resulting matrix will be better suited to be cast on single prec. GLSL matrix. The drawback of this solution is: you need to update the uniform every frame, because main camera view changes with each move. Wojtek
[osg-users] drawing in back buffer without swapping?
Hi all. I have an osg::viewer and its associated graphics context, that is a double buffered context. I need to draw in the back buffer without swapping the back and front after rendering traversal. How can I do that? I cannot find a way to disable the swapping after drawing in osgViewer::Viewer and in osg::GraphicsContext. Thanks in advance Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgdb_osganimation library on OSX
Thanks Robert, So frameworks are no longer being generated? Jerry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23294#23294 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] drawing in back buffer without swapping?
From a little code digging, there doesn't appear to be a way to turn this off. ViewerBase::startThreading always adds a SwapBuffersOperation per render thread, and SwapBuffersOperation::operator() always calls swapBUffersImplementation and clear. Maybe there's a way to delete that Operation and add your own. Or you could derive your own GraphicsContext that allows you to make swapBuffersImplementation a no-op, I guess. Or you could set up the Viewer embedded, in which case creating the context and swapping is up to you and no longer managed by osgViewer. But I guess I'd wonder why you need to do this in the first place. If you need to partially render, then do some app code, then render some more before swapping, OSG has many facilities for this already. So can you explain why you think you need to render into the back buffer but not swap? -Paul Gianluca Natale wrote: Hi all. I have an osg::viewer and its associated graphics context, that is a double buffered context. I need to draw in the back buffer without swapping the back and front after rendering traversal. How can I do that? I cannot find a way to disable the swapping after drawing in osgViewer::Viewer and in osg::GraphicsContext. Thanks in advance Gianluca ___ 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] ANN: osgEarth 1.3 Available
Hi all, We've just tagged the osgEarth 1.3 release, you can get the latest code from SVN at: http://wush.net/svn/osgearth/tags/osgearth_1.3_T2010-01-27 You can also grab tarballs from: http://wush.net/websvn/osgearth/listing.php?repname=osgearthpath=%2Ftags%2F osgEarth is a dynamic terrain-rendering toolkit for OpenSceneGraph. Just create a simple XML file, point it at your imagery and elevation data, load it into your favorite OSG application, and go! osgEarth supports all kinds of data and comes with lots of examples to help you get up and running quickly and easily. Go to http://osgearth.org for download instructions and documentation. Highlights of the osgEarth 1.3 release: Vector Feature Support *New osgEarthFeatures library for rendering vector layers *Drivers for rendering features and draping vector data on the terrain *Topological operations - buffer and resample vector datasets (using optional GEOS library) *Gridding - divide large datasets into cells for faster rendering *Styling, feature classification, SQL queries *New vector samples (repo/tests/feature_*.earth) New Tile Loading Schemes *Sequential mode - subdivides terrain without having to wait for tile content to load *Preemptive mode - loads the highest LODs first and then backfills the lower LODs *Load balancing - allocate threads to various map layers with weighting *Pre-layer updates - tiles incrementally update as layer data streams in *Cancellation support - tile downloads can be canceled when no longer needed (e.g., culling) Rendering and Data Management *Multi-pass layer rendering *No-data values for imagery/elevation *No-data images for web sources *Transparency key support *Datum override in geocentric maps Other goodness: *New OSG tile driver lets you use non-georeferenced imagery and elevation *GDAL plugin now supports palette indexed and grayscale imagery *EarthManipulator now supports offsets when tethered to a node *Upgrades to ElevationManager Thanks for your support! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Build error : CMake
Hello Robert, i got a issue with: CMake Error at src/osgWrappers/serializers/CMakeLists.txt:36 (ADD_SUBDIRECTORY): add_subdirectory given source osgParticle which is not an existing directory. /adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] smartphone like viewer control
Hi community, any idea how to implement the viewer control in smart phone like fashion? What I mean is to have two or more inputs for touch screen? Nick http://www.linkedin.com/in/tnick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] altering terrain texture...
Robert, I'll take a look and see what I can do... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 27, 2010 8:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] altering terrain texture... Hi Shayne, On Wed, Jan 27, 2010 at 3:11 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: I think your proposal would be a great benefit and would make things more flexible. I'm rather busy working on submissions, so if you can dive in and implement it would sure shorted the features time to market :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Understanding manipulator selection
Hi, I don't understand why it's OK for the Dragger, when iterating the nodepaths that were intersected, to just choose the first path. e.g: In Dragger.cpp - handle Code: for (osg::NodePath::iterator itr = _pointer._hitList.front().first.begin(); itr != _pointer._hitList.front().first.end(); ++itr) My reading of the code tells me that multiple node paths are added the the PointerInfo structure. How is it OK to then choose just the first for inspection? Or have I misunderstood? Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23306#23306 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Filename length issue using windows
Hi all, I am having an issue with writing to the OSG file cache when the filenames (including path elements) exceed 260 chars. This situation is arising when caching tiles from a relatively large paged database generated using VPB. For example, I am trying to write the following file to the cache: C:\adi_vsfz\osg-filecache/192.168.0.1/terrain/ANewBeggining/earth/earth_ root_L0_X0_Y0/../earth_subtile_L5_X29_Y6/../earth_subtile_L5_X29_Y6/eart h_subtile_L11_X1859_Y402/../../Townsville-50k/earth_subtile_L5_X29_Y6/ea rth_subtile_L11_X1859_Y402/earth_L13_X7439_Y1609_l2.dds Once this converted to an absolute path, it exceeds the 260 char limit and is truncated as follows: C:\adi_vsfz\osg-filecache\192.168.0.1\terrain\ANewBeggining\earth\Townsv ille-50k\earth_subtile_L5_X29_Y6\earth_subtile_L11_X1859_Y402\earth_L13_ X7439_ After doing some reading, it seems there is a solution (http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpat h) which will involve converting the path from relative to absolute, replacing all '/' with '\' and then prepending the magic characters '\\?\' to the start of the file name (i.e. do all the pre-processing myself then add some magic characters). I have a few questions in relation to this: 1) Does anyone know of a cleaner / better solution to this? 2) If not is there any utility functions already available to help with this? 3) What is the appropriate place within OSG to modify to have this handled internally? Ideally I would like to code a solution that works across the board. 4) When creating a fix for this, is this something that only effects windows? I believe it is but I do not have a lot of experience with the various other platforms OSG supports. 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.org
[osg-users] Looking for professional OSG consultant
Hi, I'm looking for someone doing professional consulting in OSG. Particularly useful would be someone with experience in manipulators, and video. Manipulator experience is of more relevance to me right now. If you're interested, can you please get in touch with me (Neil) at my first name at cloudnine.net.nz and I can provide more details. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23308#23308 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Small GeoTIF or DEM Terrain Options
Hello, new OSG user here. I'm currently using osgEarth to display a small patch of terrain (from a GeoTIF file) with elevation data in a Windows MFC application with a strong focus on underwater views. It works to some extent, but the end result is touchy, low-res, and difficult to maneuver through. Much of this is probably due to a lack of high resolution elevation data from the FL target site (with image data that matches resolution). But I'm also wondering if osgEarth is overkill for our needs. We don't need the whole planet or massive database of landscape. All we need is a small patch in high detail we can easily move a camera through and directly convert lat/lon/elevation positions into the scene's x/y/z. This conversion is why we went with osgEarth. But perhaps there's a simpler option? I'm just looking for a reality check on this from people in the know. I've used other scene graph engines in the past (mainly Gamebryo) so I'm still struggling with the differences in OSG. ~ Chris Innanen ~ Nonsanity -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=23305#23305 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake error from trunk this morning
Hi , I have this error when generating the project files CMake Error at src/osgWrappers/serializers/CMakeLists.txt:36 (ADD_SUBDIRECTORY): add_subdirectory given source osgParticle which is not an existing directory. Nick http://www.linkedin.com/in/tnick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
