[osg-users] R: R: multiple matrix transfromations cause severe slowness in performance
Hi Chris, first of all, thanks for helping. Each of those 200 objects is simply the shape of an arrow (basically a cone and a cylinder), whose geometry takes no more than 100 vertices. The drawable that renders each arrow is a custom drawable that I derived from osg::drawable, where I’ve overridden the drawImplementation. Internally my drawable allocates a VBO for the geometry, and sends it directly to OpenGL for rendering in drawImplementation. My drawable provides a consistent bounding box that OSG uses to cull the drawable when outside of the viewing volume. Each drawable is inserted in a geode, that in its turn is attached to an autotransform matrix, because I need those shapes to be rendered at constant size on screen (70 pixels). So, it is OSG that during rendering traversal computes the scale factors of that autotransform, to keep the constant size. Note that I’m not using shaders at the moment, but still the ffp. At the beginning I had thought that my drawImplementation was the bottleneck in redrawing, but even if I comment its code completely (making drawImplementation an empty function), still the redraw takes a considerable time. It looks like most of the time was taken to traverse the scenegraph, apply the transformation and culling the drawables. I’m still investigating, and trying to isolate the issue. Thanks, Gianluca Da: osg-users Per conto di Chris Hanson Inviato: martedì 8 ottobre 2019 15:51 A: OpenSceneGraph Users Oggetto: Re: [osg-users] R: multiple matrix transfromations cause severe slowness in performance I believe most computations you could imagine doing could be performed in the vertex shader during draw rather than by the CPU during cull. To describe more we'd need a better idea of what those 200 objects are, how they behave, what they represent, and how auto transform is being used. On Tue, Oct 8, 2019 at 7:36 AM Gianluca Natale mailto:nat...@europe.altair.com>> wrote: As I said, I’d like to use auto-transformations for those 200 objects, so I need 200 transformations for sure, and those transformations are updated by OSG at rendering time. So, the transformation has to be computed by OSG out of my vertex shader. Am I wrong? Da: osg-users mailto:osg-users-boun...@lists.openscenegraph.org>> Per conto di Chris Hanson Inviato: martedì 8 ottobre 2019 14:42 A: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org>> Oggetto: Re: [osg-users] multiple matrix transfromations cause severe slowness in performance Can you find a way to perform the transform on each object in a vertex shader and not have a unique state have to be calculated for each of the 200 objects? On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale mailto:nat...@europe.altair.com>> wrote: Hi all, I have a performance issue in my scenegraph that I cannot completely understand. My scenegraph is made by a main matrix transform, with these 2 children: * One geode that renders a big object on screen (the geometry in the drawable can take up to several thousands vertices); * One group node that in its turn has 200 children, each made by a matrix transform and a geode. The drawable in each of those geodes is very simple (no more than 100 vertices) It seems that this configuration allows me to have at most 50 fps. I feel that this should be rendered much faster. So I made some experiment. If I remove the 200 matrix transform attached to the group node I mentioned above, and directly apply the transformations to the vertices of the geometries in the 200 drawables of the small objects, performance improves a lot, till 100 fps. I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and apparently the only overhead due to the additional matrix transformations is a call to glLoadMatrix (I’m using the old ffp). How can you explain such an improvement? My real problem is that I would like to replace the 200 matrix transfromations with 200 auto-transform matrices, since I’d like those small objects to keep constant size on screen. But if I do that, I cannot remove the 200 transformations at all, and I’ll end up with a bad performance. Any idea about what I can try to make rendering of my scenegraph faster? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org<mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openscenegraph.org%2Flistinfo.cgi%2Fosg-users-openscenegraph.org=02%7C01%7Cnatale%40europe.altair.com%7Ce5a56a1a983b485f984b08d74bf68ed2%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061394638653731=Ucr17caFSHVZXJ58aCuCaXtIqEPR55rEX68o8iGCX04%3D=0> -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com<mailto:xe...@alphapixel.com> http://www.alphapixel.com/<https://nam02.safelinks.protection.outloo
[osg-users] R: multiple matrix transfromations cause severe slowness in performance
As I said, I’d like to use auto-transformations for those 200 objects, so I need 200 transformations for sure, and those transformations are updated by OSG at rendering time. So, the transformation has to be computed by OSG out of my vertex shader. Am I wrong? Da: osg-users Per conto di Chris Hanson Inviato: martedì 8 ottobre 2019 14:42 A: OpenSceneGraph Users Oggetto: Re: [osg-users] multiple matrix transfromations cause severe slowness in performance Can you find a way to perform the transform on each object in a vertex shader and not have a unique state have to be calculated for each of the 200 objects? On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale mailto:nat...@europe.altair.com>> wrote: Hi all, I have a performance issue in my scenegraph that I cannot completely understand. My scenegraph is made by a main matrix transform, with these 2 children: * One geode that renders a big object on screen (the geometry in the drawable can take up to several thousands vertices); * One group node that in its turn has 200 children, each made by a matrix transform and a geode. The drawable in each of those geodes is very simple (no more than 100 vertices) It seems that this configuration allows me to have at most 50 fps. I feel that this should be rendered much faster. So I made some experiment. If I remove the 200 matrix transform attached to the group node I mentioned above, and directly apply the transformations to the vertices of the geometries in the 200 drawables of the small objects, performance improves a lot, till 100 fps. I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and apparently the only overhead due to the additional matrix transformations is a call to glLoadMatrix (I’m using the old ffp). How can you explain such an improvement? My real problem is that I would like to replace the 200 matrix transfromations with 200 auto-transform matrices, since I’d like those small objects to keep constant size on screen. But if I do that, I cannot remove the 200 transformations at all, and I’ll end up with a bad performance. Any idea about what I can try to make rendering of my scenegraph faster? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org<mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openscenegraph.org%2Flistinfo.cgi%2Fosg-users-openscenegraph.org=02%7C01%7Cnatale%40europe.altair.com%7C4277c3a3317c429c8c3908d74bed0380%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061353649078100=wRjZjylQHKREez2RZjd5t7oLqrVqVRTUVqaClnYY0Xg%3D=0> -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com<mailto:xe...@alphapixel.com> http://www.alphapixel.com/<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.alphapixel.com%2F=02%7C01%7Cnatale%40europe.altair.com%7C4277c3a3317c429c8c3908d74bed0380%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061353649078100=%2FsWNcjNZU7xqGmMPFK%2FQm2dbKcdtLvR%2FqNBS1q%2Ba3i8%3D=0> Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Falphapixel=02%7C01%7Cnatale%40europe.altair.com%7C4277c3a3317c429c8c3908d74bed0380%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061353649078100=nh8x2T%2BlM3Q58TeIfeqPdugq16NJxyoXSSRoNaByu48%3D=0> facebook.com/alphapixel<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffacebook.com%2Falphapixel=02%7C01%7Cnatale%40europe.altair.com%7C4277c3a3317c429c8c3908d74bed0380%7C2bae5b570eb848fbba47990259da89d2%7C0%7C0%7C637061353649088059=5P6h%2BVA717zJwn4Qgw%2BriEQmSIRxyp1j5v%2Fxcv2lmsw%3D=0> (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multiple matrix transfromations cause severe slowness in performance
Hi all, I have a performance issue in my scenegraph that I cannot completely understand. My scenegraph is made by a main matrix transform, with these 2 children: * One geode that renders a big object on screen (the geometry in the drawable can take up to several thousands vertices); * One group node that in its turn has 200 children, each made by a matrix transform and a geode. The drawable in each of those geodes is very simple (no more than 100 vertices) It seems that this configuration allows me to have at most 50 fps. I feel that this should be rendered much faster. So I made some experiment. If I remove the 200 matrix transform attached to the group node I mentioned above, and directly apply the transformations to the vertices of the geometries in the 200 drawables of the small objects, performance improves a lot, till 100 fps. I investigatd a bit inside OSG code (I'm using OG ver.3.4.1), and apparently the only overhead due to the additional matrix transformations is a call to glLoadMatrix (I'm using the old ffp). How can you explain such an improvement? My real problem is that I would like to replace the 200 matrix transfromations with 200 auto-transform matrices, since I'd like those small objects to keep constant size on screen. But if I do that, I cannot remove the 200 transformations at all, and I'll end up with a bad performance. Any idea about what I can try to make rendering of my scenegraph faster? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rendering order
Hi all, I have an issue with order of rendering. I do know that OSG has rendering bins to provide the order of rendering, and that, inside a rendering bin, it optimizes drawing by sorting objects to render WRT the state sets. That's fine. But now I have an use case that I don't know how to implement. My graphic object is made by a 2D rectangular box with a text on top, as shown in the picture a). Well, I do have many of them, which can overlap. I do disable depth test when I render them, because I want the last one to cover completely the others, when overlapping. The visualization that I want to achieve is that shown in picture b). In order to do that, my scenegraph is made by these nodes: Main root node | | Transf1 Transf2 | | | | Box1 |Box2| | | Text1 Text2 Transf1 sets the position of Object1 Trasnf2 sets the position of Object2. Box1 is a geode that contains a drawable that render the rectangular box for Object1. Text1 is a text drawable for the text on top of the box1. Box2 is a geode that contains a drawable that render the rectangular box for Object2. Text2 is a text drawable for the text on top of the box2. So, my objects should be rendered in this order, to draw what I want: Box1, Text1, Box2, Text2, ... I do have hundreds of graphic objects like those. So, how can I do this? I cannot set the same rendering bin for all Boxes, and a different rendering bin for all Texts, because OSG would render first all the boxes, and then all texts, which would overlap each other, like in picture c). Orrible!!! So, I thought that I have to assign the same rendering bin to all Transf, in order to make it render all my objects in the same bin, but I have to specify somehow that it has to render Box and Text in that order for each sub-graph, instead of optimizing rendering by state set order, which breaks my requirement. I would need to set some "offset" in rendering bins for Boxes and Texts (1 and 2 respectively), to force OSG to render the Box and Text in that order, for each subgraph connected to Transf. It seems an easy thing to do, and mine seems a silly question, but I cannot do that. Any help is appreciated. Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] found memory leak in OSG 3.0.1
Never mind, I forwarded an old message! :) From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Gianluca Natale Sent: Monday, October 23, 2017 12:34 PM To: Osg Users <osg-us...@openscenegraph.org> Subject: [osg-users] FW: found memory leak in OSG 3.0.1 Hi all, In my application I'm using OSG 3.0.1 (I do know it is old, but I do not have the time now to move to a newer version). I think I have a memory leak, and I don't know if it's my fault or a bug in OSG. Using the task manager (on Win 8.1 Pro), I see this. When I call: GraphicsContext* GraphicsContext::createGraphicsContext(Traits* traits); memory allocated in my application increases of about 2.5 MB. Then, when I call: GraphicsContext::close(bool callCloseImplementation); // I pass true to this function memory allocated in my application decreases of about 1.5 MB. So, there is always about 1 MB that is not deallocated. I tried to investigate a bit, and noticed that the problem seems to happen inside this function: bool GraphicsWindowWin32::setWindow( HWND handle ). Specifically, there are 2 calls in that function where memory is allocated: 1) bool GraphicsWindowWin32::setPixelFormat(); // increases about 1 MB 2) HGLRC GraphicsWindowWin32::createContextImplementation(); // increases about 1.5 MB So, it looks like the memory allocated at point 1 is never released. Is there anything I have to call, when I want to destroy a graphic context, other than close()? Or, if you do know that it is a memory leak, has it been fixed in a newer version of OSG? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FW: about using HTC VIVE VR in OSG
Hi all, We have the requirement to implement VR in our applicaton, that is currently completely based upon OSG 3.0.1 (I do know that it is a bit old, yes!). Specifically, we would need to support HTC VIVE VR displays. I do know we have to allocate a quad buffer for that, I mean let OSG allocate a quad buffer. Did anybody already try to develop an OSG based application for VIVE VR display? Is there an example that I can look at, as a good starting point? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FW: found memory leak in OSG 3.0.1
Hi all, In my application I'm using OSG 3.0.1 (I do know it is old, but I do not have the time now to move to a newer version). I think I have a memory leak, and I don't know if it's my fault or a bug in OSG. Using the task manager (on Win 8.1 Pro), I see this. When I call: GraphicsContext* GraphicsContext::createGraphicsContext(Traits* traits); memory allocated in my application increases of about 2.5 MB. Then, when I call: GraphicsContext::close(bool callCloseImplementation); // I pass true to this function memory allocated in my application decreases of about 1.5 MB. So, there is always about 1 MB that is not deallocated. I tried to investigate a bit, and noticed that the problem seems to happen inside this function: bool GraphicsWindowWin32::setWindow( HWND handle ). Specifically, there are 2 calls in that function where memory is allocated: 1) bool GraphicsWindowWin32::setPixelFormat(); // increases about 1 MB 2) HGLRC GraphicsWindowWin32::createContextImplementation(); // increases about 1.5 MB So, it looks like the memory allocated at point 1 is never released. Is there anything I have to call, when I want to destroy a graphic context, other than close()? Or, if you do know that it is a memory leak, has it been fixed in a newer version of OSG? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about using HTC VIVE VR in OSG
Hi all, We have the requirement to implement VR in our applicaton, that is currently completely based upon OSG 3.0.1 (I do know that it is a bit old, yes!). Specifically, we would need to support HTC VIVE VR displays. I do know we have to allocate a quad buffer for that, I mean let OSG allocate a quad buffer. Did anybody already try to develop an OSG based application for VIVE VR display? Is there an example that I can look at, as a good starting point? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mirror transformation
Happy to hear that it works. BTW, actually the check is a bit more complicated, because you might want to apply mirroring against several axes in sequence. Once you have the global transformation of the mirrored object, the correct check is the following. Get the determinant of that global transformation, and check the sign: - if < 0.0, it means that there is an odd number of negative scale factors in the matrix, so winding has to be reverted: set FrontFace mode to CLOCKWISE; - if > 0.0, it means that there is no or an even number of negative scale factors, so winding has to be left as COUNTERCLOCKWISE. Just for completeness. Gianluca -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ale Maro Sent: Wednesday, September 13, 2017 7:12 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Mirror transformation Hi Gianluca, I tried your suggestion and it worked. It is a little tricky for me becouse I need to analyze on the fly the transformation matrix and apply osg::FrontFace by consequence but it works. Thank you. Ale -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71712#71712 ___ 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] Mirror transformation
IMO, it happens that, because of the mirror transformation (i.e. a negative scale factor in the global transformation), back facets do appear as front facets on the projection plane, and viceversa. And because of the 2-sided model lighting, normals are reverted when rendering the front facets (as they appear as back facets). It should be fixed by reverting the front face definition for object transformed by the mirror transform. I mean, I would apply a state set to that mirror transformation with this state attribute: osg::FrontFace(CLOCKWISE); It worked for me for a similar issue I had in the past. Gianluca -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ale Maro Sent: Wednesday, September 13, 2017 4:23 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Mirror transformation I forgot to mention that the geode inherit from the root node a 2-sided lighting with different materials in front and back side. Cheers, Ale -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=71707#71707 ___ 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] about showing an animated .gif onto a rectangle in my model
Hi all, I have a rectangle in my 3D model, and I'd like to show an animated .gif on it. I guess I should extract every frame of the animation from the .gif file, and at every step of the animation attach those pictures as textures onto my rectangle. Do you have some example about how to do that? BTW, do I need only the .gif plugin? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] found memory leak in OSG 3.0.1
Hi Robert, thanks for your reply. This is what I do in my application: 1) create my own Qt widget (and get its window handle, HWND); 2) allocate an osgViewer::Viewer; 3) allocate Traits and set requirements (new osg::GraphicsContext::Traits(); ) 4) set the window handle gotten at point 1 in the Traits (traits->inheritedWindowData = new WindowData((HWND)window); ) 5) create a graphic context using such Traits (osg::GraphicsContext::createGraphicsContext(traits.get()); ) internally that function calls this: 5.1) osg::GraphicsContext::createGraphicsContext(traits.get()); that in its turn calls this: 5.1.1) GraphicsWindowWin32::init(); // SO FAR, NO MEMORY HAS BEEN ALLOCATED YET (OR JUST UNNOTICEABLE AMOUNT) that internally makes this call: GraphicsWindowWin32::setWindow( HWND handle ) // handle is the one I passed at step 4 that in its turn performs this 2 calls: 5.1.1.1) GraphicsWindowWin32::setPixelFormat(); // THIS ALLOCATES ABOUT 1 MB 5.1.1.2) _hglrc = createContextImplementation(); // THIS ALLOCATES ABOUT 1.5 MB NO MORE MEMORY IS ALLOCATED FROM NOW ON 6) set the graphics context for my viewer (p_viewer->getCamera()->setGraphicsContext(p_graphicsContext); ) // where p_ graphicsContext is that created at step 5, and stored in my class as a reference pointer I DO NOT DO ANYTHING ELSE NOW, BUT SOON DESTROY WHAT I'VE ALLOCATED, IN REVERSE ORDER (BY DESTRUCTING MY OWN CLASS, WHERE I HAD PERFORMED THE CREATION OF EVERYTHING). THAT IS TO SAY, I FORCE THE DESTRUCTION OF MY OWN CLASS, AND IN THE DESTRUCTOR: 7) release the graphic context (p_graphicsContext->releaseContext(); ) 8) close the graphics context (p_graphicsContext->close(true);) // MEMORY IS DECREASED BY 1.5 MB 9) delete the viewer. 10) destruction of the graphics context happens automatically when my class is destroyed, since I had stored 'p_graphicsContext' as a reference pointer. I put a breakpoint and verified that the following destructor is called: 10.1) GraphicsWindowWin32::~GraphicsWindowWin32(); This internally performs 2 calls: 10.1.1) close(); // NO MEMORY DEALLOCATED, I GUESS BECAUSE I HAD ALREADY CALLED THIS AT STEP 8 10.1.2) destroyWindow();// NO MEMORY DEALLOCATED That's it. Do you feel that I made something wrong, Robert? Or is there something else that I have to call to force some deallocation? As I mentioned here above, in the whole process the memory is allocated in 2 points, but it looks like only second allocation is removed. I've also investigated a bit inside the function at step 5.1.1.1). This seems to be the call that allocates an amount of memory that it is not released at the end of the process: Win32WindowingSystem::getInterface()->getSampleOpenGLContext(openGLContext, _hdc, _screenOriginX, _screenOriginY); Any idea about that? Thank you very much for your support, Robert. Gianluca Natale -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, January 19, 2017 6:53 PM To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org> Subject: Re: [osg-users] found memory leak in OSG 3.0.1 Hi Gianluca, How you are measuring the memory usage? It could simply be that the memory tracking isn't properly handling deallocations. As a general note, close will just close the graphics context, it won't delete the osg::GraphicsWindowWin32. Try testing the creation of a viewer within a well defined scope and then see what memory has been deallocated or not on leaving the scope where all the viewer related objects should be cleaned up. Robert. On 19 January 2017 at 17:02, Gianluca Natale <nat...@europe.altair.com> wrote: > Hi all, > > In my application I’m using OSG 3.0.1 (I do know it is old, but I do > not have the time now to move to a newer version). > > I think I have a memory leak, and I don’t know if it’s my fault or a > bug in OSG. > > Using the task manager (on Win 8.1 Pro), I see this. > > > > When I call: > > > > GraphicsContext* GraphicsContext::createGraphicsContext(Traits* > traits); > > > > memory allocated in my application increases of about 2.5 MB. > > > > Then, when I call: > > > > GraphicsContext::close(bool callCloseImplementation); // I pass true > to this function > > > > memory allocated in my application decreases of about 1.5 MB. > > So, there is always about 1 MB that is not deallocated. > > > > I tried to investigate a bit, and noticed that the problem seems to > happen inside this function: > > > > bool GraphicsWindowWin32::setWindow( HWND handle ). > > > &g
[osg-users] found memory leak in OSG 3.0.1
Hi all, In my application I'm using OSG 3.0.1 (I do know it is old, but I do not have the time now to move to a newer version). I think I have a memory leak, and I don't know if it's my fault or a bug in OSG. Using the task manager (on Win 8.1 Pro), I see this. When I call: GraphicsContext* GraphicsContext::createGraphicsContext(Traits* traits); memory allocated in my application increases of about 2.5 MB. Then, when I call: GraphicsContext::close(bool callCloseImplementation); // I pass true to this function memory allocated in my application decreases of about 1.5 MB. So, there is always about 1 MB that is not deallocated. I tried to investigate a bit, and noticed that the problem seems to happen inside this function: bool GraphicsWindowWin32::setWindow( HWND handle ). Specifically, there are 2 calls in that function where memory is allocated: 1) bool GraphicsWindowWin32::setPixelFormat(); // increases about 1 MB 2) HGLRC GraphicsWindowWin32::createContextImplementation(); // increases about 1.5 MB So, it looks like the memory allocated at point 1 is never released. Is there anything I have to call, when I want to destroy a graphic context, other than close()? Or, if you do know that it is a memory leak, has it been fixed in a newer version of OSG? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] missing /opt/X11/lib/libGL.1.dylib
Hi all, I'm not a Mac expert, at all. I had to port my graphic application, based upon OSG, and completely developed on Win, to Mac. After struggling for a long time, I finally did it. And it works fine on my Mac. But when I try to run on another Mac, there is a missing library. Specifically, this is the error: Library not loaded: /opt/X11/lib/libGL.1.dylib I guess it is OSG that requires such dependency. And it should be XQuartz that provides the library. So, it's likely that XQuartz has not been installed on that machine. Anyway, I would like to notify the user in advance, with a popup, that the required library is not installed. Is there a way to know programmatically if XQuartz has been installed on the system? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FW: issue about getting the material properties from the current state in rendering info
Thanks Sebastian, I'm simply trying to get the alpha value of the diffuse component of the material properties, because I have to pass it to an underlying graphic library that I use for rendering that custom drawable. BTW, I further investigated. In the following function: State::captureCurrentState(StateSet stateset) The _attributeMap actually contains as MATERIAL attribute exactly the pointer to the osg::Material property that I created. But in the attribute stack it appears as the 'last_applied_attribute', and 'changed' is set to true. For all other attributes the pointers stored in 'last_applied_attribute' are correct as well, but 'changed' is set to false. Also, in that AttributeStack the member attributeVec contains just one element, that is not the correct one (it points to a different osg::Material). While for all the other attributes, which have 'changed' set to false, last_applied_attribute coincides with the first element in attributeVec. I don't know anything of that code, but I don't understand why osg::Material appears to be changed, while other attributes not. Or should I use a different API to get the current osg::Material? I found this in State header file: /** Get the current specified attribute, return NULL if one has not yet been applied.*/ const StateAttribute* getLastAppliedAttribute(StateAttribute::Type type, unsigned int member=0) const; So, it looks like the current value of an attribute is actually the last applied!?! That is how the API is described. So, what captureCurrentState should do instead? Thanks, Gianluca Natale From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sebastian Messerschmidt Sent: martedì 23 giugno 2015 18:15 To: OpenSceneGraph Users; Osg Users Subject: Re: [osg-users] issue about getting the material properties from the current state in rendering info Am 23.06.2015 18:05, schrieb Gianluca Natale: Hi all, I'm using OSG 3.0.1. I have an issue when I try to retrieve the material properties from the rendering info, in my custom drawable. To be clearer: I have a custom drawable, for which I implemented a myDrawable::drawImplementation(osg::RenderInfo osgRenderInfo). When I try to get the material properties inside that function, by following code: osg::StateSet drwbStateSet; osg::State *state = osgRenderInfo.getState(); state-captureCurrentState(drwbStateSet); the returned material properties is invalid. Specifically, I put a breakpoint in following function: StateSet::setAttribute(StateAttribute *attribute, StateAttribute::OverrideValue value) that is called inside captureCurrentState. When the attribute is an osg::Material, the _ptr is different from the one allocated when the material has been set, in the state set associated to a parent node of that drawable. Furthermore, _userDataContainer is 0x, so no valid osg::Material is returned in the captured state set. User data defaults to nullptr. So if you're not setting it up that is expected. As you don't explain why you are trying to inspect state during draw it is hard to guess what you are after. I simply guess that your state is set up somewhere further up in the stategraph (i.e. in one of the parents) and that state is set up lazy. Maybe Robert can give some insights here. Any idea of the possible cause of the issue? Where did I go wrong? BTW, all other attributes (polygon offset, polygon mode, etc...) are returned correctly. Are you sure you are setting up an osg::Material state attribute somewhere? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] issue about getting the material properties from the current state in rendering info
Thanks Sebastian, I'm simply trying to get the alpha value of the diffuse component of the material properties, because I have to pass it to an underlying graphic library that I use for rendering that custom drawable. BTW, I further investigated. In the following function: State::captureCurrentState(StateSet stateset) The _attributeMap actually contains as MATERIAL attribute exactly the pointer to the osg::Material property that I created. But in the attribute stack it appears as the 'last_applied_attribute', and 'changed' is set to true. For all other attributes the pointers stored in 'last_applied_attribute' are correct as well, but 'changed' is set to false. Also, in that AttributeStack the member attributeVec contains just one element, that is not the correct one (it points to a different osg::Material). While for all the other attributes, which have 'changed' set to false, last_applied_attribute coincides with the first element in attributeVec. I don't know anything of that code, but I don't understand why osg::Material appears to be changed while other attributes not. Or should I use a different API to get the current osg::Material? Thanks, Gianluca Natale From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sebastian Messerschmidt Sent: martedì 23 giugno 2015 18:15 To: OpenSceneGraph Users; Osg Users Subject: Re: [osg-users] issue about getting the material properties from the current state in rendering info Am 23.06.2015 18:05, schrieb Gianluca Natale: Hi all, I'm using OSG 3.0.1. I have an issue when I try to retrieve the material properties from the rendering info, in my custom drawable. To be clearer: I have a custom drawable, for which I implemented a myDrawable::drawImplementation(osg::RenderInfo osgRenderInfo). When I try to get the material properties inside that function, by following code: osg::StateSet drwbStateSet; osg::State *state = osgRenderInfo.getState(); state-captureCurrentState(drwbStateSet); the returned material properties is invalid. Specifically, I put a breakpoint in following function: StateSet::setAttribute(StateAttribute *attribute, StateAttribute::OverrideValue value) that is called inside captureCurrentState. When the attribute is an osg::Material, the _ptr is different from the one allocated when the material has been set, in the state set associated to a parent node of that drawable. Furthermore, _userDataContainer is 0x, so no valid osg::Material is returned in the captured state set. User data defaults to nullptr. So if you're not setting it up that is expected. As you don't explain why you are trying to inspect state during draw it is hard to guess what you are after. I simply guess that your state is set up somewhere further up in the stategraph (i.e. in one of the parents) and that state is set up lazy. Maybe Robert can give some insights here. Any idea of the possible cause of the issue? Where did I go wrong? BTW, all other attributes (polygon offset, polygon mode, etc...) are returned correctly. Are you sure you are setting up an osg::Material state attribute somewhere? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] issue about getting the material properties from the current state in rendering info
Hi all, I'm using OSG 3.0.1. I have an issue when I try to retrieve the material properties from the rendering info, in my custom drawable. To be clearer: I have a custom drawable, for which I implemented a myDrawable::drawImplementation(osg::RenderInfo osgRenderInfo). When I try to get the material properties inside that function, by following code: osg::StateSet drwbStateSet; osg::State *state = osgRenderInfo.getState(); state-captureCurrentState(drwbStateSet); the returned material properties is invalid. Specifically, I put a breakpoint in following function: StateSet::setAttribute(StateAttribute *attribute, StateAttribute::OverrideValue value) that is called inside captureCurrentState. When the attribute is an osg::Material, the _ptr is different from the one allocated when the material has been set, in the state set associated to a parent node of that drawable. Furthermore, _userDataContainer is 0x, so no valid osg::Material is returned in the captured state set. Any idea of the possible cause of the issue? Where did I go wrong? BTW, all other attributes (polygon offset, polygon mode, etc...) are returned correctly. Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] compilation error on Linux
Hi all. I'm building my application based upon OSG 3.0.1, on a Linux Red hat 5.9 (DevTool 1.1, gcc 4.7.2), and I have this error: /users/fdmbld/projects/InspRegular/hw/unity/third_party/OSG3.0.1/linux64/include/osg/Math: In function 'bool osg::isNaN(double)': /users/fdmbld/projects/InspRegular/hw/unity/third_party/OSG3.0.1/linux64/include/osg/Math:216:53: error: call of overloaded 'isnan(double)' is ambiguous /users/fdmbld/projects/InspRegular/hw/unity/third_party/OSG3.0.1/linux64/include/osg/Math:216:53: note: candidates are: In file included from /usr/include/math.h:71:0, from /opt/rh/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/cmath:46, from /opt/rh/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/random:38, from /opt/rh/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:67, from /opt/rh/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/algorithm:63, It appears that two system include files, mathcalls.h (default OS) and cmath (from RH DevToolKit) both have definitions of functions isnan, and OSG's Math header uses it in an ambiguous manner. Any idea about how to fix this? Thanks Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to set the model view projection matrix for my own vertex shader
Hi all. First of all, sorry if mine is a silly question, I'm quite new to using shaders in OSG. My scenario is this: I have a vertex shader that gets as uniform in-variable the model view projection matrix, MVP_matrix is the name of that variable in my shader. The shader is written in GL4.3, so I cannot rely upon the deprecated built-in variable gl_ModelViewProjection matrix. Now, I have to attach such shader in a program that is set in a state set used to render my geometry (that state set is attached to the geode that contains my drawable, where the geometry is defined). So, I would like that OSG automatically passes the model view projection matrix to my shader during rendering traversal. I've seen in some OSG code that there is a predefined in-variable called osg_ModelViewProjectionMatrix that I think is filled by OSG during rendering traversal with the current model view projection matrix. Is that correct? So, should I rely upon it in my shader, basically replacing my MVP_matrix with osg_ModelViewProjectionMatrix? Further question: unfortunately the shader I have to use is shared among other applications in my company, and not all of them use OSG for rendering (some use pure OpenGL) :( So it's likely that I cannot modify it (otherwise I should ask all developers to change the name of the in-variable they pass directly to the shader to osg_ModelViewProjectionMatrix). Hence the question: if I'm forced to use MVP_matrix, is there a way I can tell OSG to set automatically the value of osg_ModelViewProjectionMatrix to MVP_matrix at run-time, i.e. during rendering traversal? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: how to set the model view projection matrix for my own vertex shader
Oh yes, Robert, that's the most obvious and quickest solution, sorry for the silly question! Once loaded my shader source code from the file, I'll replace all the occurrences of MVP_matrix with osg_ModelViewProjectionMatrix, and OSG will update it for me during rendering traversal. Thanks a lot! :) Gianluca Da: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 2 settembre 2014 13:56 A: OpenSceneGraph Users Oggetto: Re: [osg-users] how to set the model view projection matrix for my own vertex shader Hi Gianluca, osg_ModelViewProjectionMatrix is the OSG's equivilant to gl_ModelViewProjectMatrix, and there is a mechanism in osg::State that can replace gl_ModelViewMatrixProjectMatrix usage in shaders with the osg_ equivalent at runtime. There isn't however a general customizable support for setting and substituting your own uniforms in this role. In your own application I'd suggest when you set up your osg::Shader with the shader source you replace the MVP_matrix usage with gl_ or osg_ equivalent. Robert. On 2 September 2014 10:59, Gianluca Natale nat...@europe.altair.commailto:nat...@europe.altair.com wrote: Hi all. First of all, sorry if mine is a silly question, I'm quite new to using shaders in OSG. My scenario is this: I have a vertex shader that gets as uniform in-variable the model view projection matrix, MVP_matrix is the name of that variable in my shader. The shader is written in GL4.3, so I cannot rely upon the deprecated built-in variable gl_ModelViewProjection matrix. Now, I have to attach such shader in a program that is set in a state set used to render my geometry (that state set is attached to the geode that contains my drawable, where the geometry is defined). So, I would like that OSG automatically passes the model view projection matrix to my shader during rendering traversal. I've seen in some OSG code that there is a predefined in-variable called osg_ModelViewProjectionMatrix that I think is filled by OSG during rendering traversal with the current model view projection matrix. Is that correct? So, should I rely upon it in my shader, basically replacing my MVP_matrix with osg_ModelViewProjectionMatrix? Further question: unfortunately the shader I have to use is shared among other applications in my company, and not all of them use OSG for rendering (some use pure OpenGL) :( So it's likely that I cannot modify it (otherwise I should ask all developers to change the name of the in-variable they pass directly to the shader to osg_ModelViewProjectionMatrix). Hence the question: if I'm forced to use MVP_matrix, is there a way I can tell OSG to set automatically the value of osg_ModelViewProjectionMatrix to MVP_matrix at run-time, i.e. during rendering traversal? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] issue related to display lists
Hi All, I have this very strange behavior in my application based upon OSG 2.8.0. I derived my own drawable, MyDrawable, from osg::Drawable, and implemented the drawImplementation, to be called by OSG during draw rendering traversal. It works correctly, the geometry in my drawable is rendered correctly on the screen. Internally MyDrawable::drawImplementation has to bound the geometry in a display list, to speed up drawing of complex geometry, but I cannot use the automatic OSG mechanism to wrap it (I mean, I cannot simply call MyDrawable::setUseDisplayList(true)). So, I have to call something like: p_listID = glGenLists(1); on my own, and fill the display list by glNewList(...), etc... Once the display list is created, I simply call glList(p_listID); in MyDrawable::drawImplementation(...). It works fine, even if for some complex model I have this strange behavior. In one case I have 2 objects of type MyDrawable instantiated. The first time drawImplementation is called for obj1, a p_listID = 6 is returned from glGenLists(1); Then, the first time drawImplementation is called for obj2, glGenLists(1) still return 6 as the first available ID. What happens actually is that the first rendering does not render obj2, because it is out of viewing volume. In second rendering, after the camera has been moved, both objects fall in the viewing volume. As soon as drawing traversal encounters MyDrawable for obj1, I checked the availability of ID for display lists, by calling: GLboolean isList[1000]; int i; for (i=0; i1000; ++i) isList[i] = glIsList(i); And discovered that available display list IDs are from 1 to 5. So, my display list #6 has been deleted, but I cannot understand who has done that. I put a breakpoint in the place I delete the display list: glDeleteLists(p_listID, 1) but that is never reached between the first and second rendering. So, I wonder if OSG somehow deletes some display lists, and why. I looked in the code, and see the osg::Drawable actually calls glDeleteLists(...) in several places, so I can only guess that it deletes it there. Even if I cannot understand how that is possible, since OSG does not know the ID that has been returned to MyDrawable from glGenLists(1). I should rebuild OSG 2.8.0 and debug it, to see if the deletion happens there. But before doing that, I would like to hear from you if there is any chance that OSG might have been deleted a wrong display list (at least, if that is an issue already reported by someone else, or even better if there is a fix for that). Thanks in advance, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] transparency issue when reading svg files through svg plugin
Hi all, I'm having this issue when reading an SVG file using the OSG svg plugin: the alpha values in the osg::image created by the plugin seem all wrong. RGB values instead are all correct. Is this a known issue? Any idea how to fix it? Did I miss some optional flag to the reader? Thanks Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: Multisampling
Hi, I was about to ask the same question. And I tried what you suggest to remove multisampling from one node, but it does not work. I mean, once you set the number of samples in the display settings, and create a rendering context based upon such display settings, then it is impossible to disable multisampling. BTW, I also tried to directly call in the DrawImplementation of my own drawables this statement: glDisable(GL_MULTISAMPLE); but it does not work either. I mean, once set, multisampling seems not to be controllable. Did I miss something? Does it depend on OSG? Or driver bug? Thanks, Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Sergey Polischuk Inviato: lunedì 28 gennaio 2013 18:01 A: osg-users@lists.openscenegraph.org Oggetto: Re: [osg-users] Multisampling Hi, Filip you can create MSAA context and enable\disable multisampling at runtime with GL_MULTISAMPLE mode on camera or scene stateset. Note that with disabled multisampling you will get lower fps than with non-MSAA context. Cheers, Sergey. 28.01.2013, 20:24, Filip Arlet fili...@seznam.cz: Hi, Is it possilbe to disable (or enable) Multisampling ? I can create context with MSAA and without it, but I have no idea how can I disable or enable it with existing context ? Is it even posible or do I have to recreate Context ? Thank you! Cheers, Filip -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52245#52245 ___ 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] R: GL_RENDERER string
Out of OSG/Qt, I think you should: 1) Create a very simple rendering context (associated to the window created by your application); 2) Make that rendering context as the current one; 3) Call glGetString(GL_RENDERER, ...); Steps 1 and 2 are required, since all gl calls need a current rendering context to work with. About steps 1 and 2, you should look at how OSG create the rendering context. Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Alistair Baxter Inviato: martedì 15 gennaio 2013 10:47 A: osg-users@lists.openscenegraph.org Oggetto: [osg-users] GL_RENDERER string I'm wanting to get the GL_RENDERER string out of my OpenSceneGraph / Qt application for debug purposes, and potentially for showing to users for technical support purposes. I can get the likes of GL and GLSL version from the osg::GL2Extensions object, and I can see the renderer string being queries in the source code, but I'm having difficulty figuring out how to get it out. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about the OSG SVG plugin
Hi all, I'm trying to use the OSG SVG plugin to read some .svg file, to be used as textures on some surfaces. Since .svg is a 'vector' graphic format, it could be rasterized at any resolution. So, I should be able to ask any desired size for the image read by the plugin. I'm using following call: osgDB::readImageFile(fileName) but I don't see any way to pass such options to the reader. Is that possible? I took a quick look at implementation (ReaderWriterSVG.cpp), and found this in virtual ReadResult readImage(const std::string file, const osgDB::ReaderWriter::Options* options) const: RsvgDimensionData dimensionData; RsvgHandle* handle = rsvg_handle_new_from_file (fileName.c_str(), NULL); rsvg_handle_get_dimensions( handle, dimensionData); So, it seems to me that there is no way to set the size of the image, since dimensions are gotten from the handle, whose constructor just takes the name of the file. Is this a limitation of the plugin? So, how does the RsvgHandle choose those dimensions? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: about the OSG SVG plugin
Sorry for that silly question, I just realized that I have to pass the required dimensions in 'options' in osgDB::readImageFile(filename, options). Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Gianluca Natale Inviato: giovedì 10 gennaio 2013 11:47 A: OpenSceneGraph Users Oggetto: [osg-users] about the OSG SVG plugin Hi all, I'm trying to use the OSG SVG plugin to read some .svg file, to be used as textures on some surfaces. Since .svg is a 'vector' graphic format, it could be rasterized at any resolution. So, I should be able to ask any desired size for the image read by the plugin. I'm using following call: osgDB::readImageFile(fileName) but I don't see any way to pass such options to the reader. Is that possible? I took a quick look at implementation (ReaderWriterSVG.cpp), and found this in virtual ReadResult readImage(const std::string file, const osgDB::ReaderWriter::Options* options) const: RsvgDimensionData dimensionData; RsvgHandle* handle = rsvg_handle_new_from_file (fileName.c_str(), NULL); rsvg_handle_get_dimensions( handle, dimensionData); So, it seems to me that there is no way to set the size of the image, since dimensions are gotten from the handle, whose constructor just takes the name of the file. Is this a limitation of the plugin? So, how does the RsvgHandle choose those dimensions? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: R: a couple of questions about svg plugin (OSG 3.0.1)
Unfortunately it crashed with any version of cairo library (gotten from
http://ftp.acc.umu.se/pub/gnome/binaries/win32), and any .svg file I tested.
I ended up looking deeper at documentation of cairo library.
Specifically, since the crash happened (as shown here below in yellow) when it
tries to free the memory allocated for a cairo_surface_t,
I looked at cairo.h, and found this comment:
* Memory management of #cairo_surface_t is done with
* cairo_surface_reference() and cairo_surface_destroy().
So, I tried to replace the call (at yellow line here below):
free(cairo_surface);
with a:
cairo_surface_destroy(cairo_surface);
I rebuilt osgdb_svg.dll, and now it seems to work. I can load any .svg file and
use as a texture with no crash.
But I still wonder if that replacement really deallocates the memory allocated
for the cairo surface.
Anyway, it seems quite strange to me that the svg plugin could work without
crashes for all of you who tried it (on Win32), without the hack that I had to
do,
since the hack is actually in osg and not in third party libraries.
So, again, I would appreciate if any of you who successfully built and used the
osg svg plugin as it was, i.e. without my replacement,
could let me know where he got the required libraries for svg.
BTW, I built OSG 3.0.1 in win32 debug, with VisualStudio 2010 on Win7.
Thanks,
Gianluca
Da: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Gianluca Natale
Inviato: giovedì 13 dicembre 2012 16:02
A: OpenSceneGraph Users
Oggetto: [osg-users] R: a couple of questions about svg plugin (OSG 3.0.1)
Thanks Robert,
I'll try with different versions of libraries and different .svg test files, to
see if the crash disappears.
Gianluca
Da:
osg-users-boun...@lists.openscenegraph.orgmailto:osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield
Inviato: giovedì 13 dicembre 2012 15:51
A: OpenSceneGraph Users
Oggetto: Re: [osg-users] a couple of questions about svg plugin (OSG 3.0.1)
Hi Guanluca,
I've only used librsvg from the Ubunutu/debian repositories and haven't come
across problems before. Perhaps there is a version issue, or perhaps an issue
with librsvg handling the .svg you are passing on. As you are working under
Windows I think it may well be simply down to the libs and the OSG being built
with different options, this is a very common issue for Windows programmers and
comes with the territory am I afraid, it's another one of the reasons that I
haven't touched windows development for a decade.
As for rendering svg using the scene graph/OpenGL rather than rendering to a
CPU based image then texturing this, we'll it's possible but a for more complex
issue than just relying upon a 3rd party lib to the handle all the specifics of
vector graphics. NVidia do have a library that does vector graphics ontop of
OpenGL so this is probably the way one would tackle it.
Robert.
On 13 December 2012 12:11, Gianluca Natale
nat...@europe.altair.commailto:nat...@europe.altair.com wrote:
Hi all,
I have a couple of issues/questions about the osg plugin for svg file format.
1.
I got win32 prebuilt versions of the library librsvg, and all required
dependencies (glib, gdk-pixbuf, cairo, libcroco, fontconfig, libpng, freetype,
gettext-runtime, libxml2, expat, pango), from this website:
http://ftp.acc.umu.se/pub/gnome/binaries/win32.
And rebuilt the osgdb_svg.dll plugin (in OSG 3.0.1).
When I try to read an svg image in my application, I have a crash in the yellow
line in following function inside ReaderWriterSVG.cpp:
osg::Image* createImage(RsvgHandle *handle, unsigned int width,
unsigned int height) const
{
RsvgDimensionData dimensionData;
rsvg_handle_get_dimensions( handle, dimensionData);
// If image resollution 128, cairo produces some artifacts.
// I don't know why, but we check the size...
if (width 128) width = 128;
if (height 128) height = 128;
width = osg::Image::computeNearestPowerOfTwo(width);
height = osg::Image::computeNearestPowerOfTwo(height);
osg::Image *image = new osg::Image();
image-allocateImage(width, height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
image-setPixelFormat(GL_BGRA);
cairo_surface_t *cairo_surface =
cairo_image_surface_create_for_data(image-data(),
CAIRO_FORMAT_ARGB32, width, height,
image-getRowSizeInBytes());
cairo_t *cr = cairo_create(cairo_surface);
cairo_scale(cr,((float)width)/dimensionData.width,
((float)height)/dimensionData.height);
rsvg_handle_render_cairo(handle, cr);
cairo_destroy(cr);
free(cairo_surface);
image-flipVertical
[osg-users] a couple of questions about svg plugin (OSG 3.0.1)
Hi all,
I have a couple of issues/questions about the osg plugin for svg file format.
1.
I got win32 prebuilt versions of the library librsvg, and all required
dependencies (glib, gdk-pixbuf, cairo, libcroco, fontconfig, libpng, freetype,
gettext-runtime, libxml2, expat, pango), from this website:
http://ftp.acc.umu.se/pub/gnome/binaries/win32.
And rebuilt the osgdb_svg.dll plugin (in OSG 3.0.1).
When I try to read an svg image in my application, I have a crash in the yellow
line in following function inside ReaderWriterSVG.cpp:
osg::Image* createImage(RsvgHandle *handle, unsigned int width,
unsigned int height) const
{
RsvgDimensionData dimensionData;
rsvg_handle_get_dimensions( handle, dimensionData);
// If image resollution 128, cairo produces some artifacts.
// I don't know why, but we check the size...
if (width 128) width = 128;
if (height 128) height = 128;
width = osg::Image::computeNearestPowerOfTwo(width);
height = osg::Image::computeNearestPowerOfTwo(height);
osg::Image *image = new osg::Image();
image-allocateImage(width, height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
image-setPixelFormat(GL_BGRA);
cairo_surface_t *cairo_surface =
cairo_image_surface_create_for_data(image-data(),
CAIRO_FORMAT_ARGB32, width, height,
image-getRowSizeInBytes());
cairo_t *cr = cairo_create(cairo_surface);
cairo_scale(cr,((float)width)/dimensionData.width,
((float)height)/dimensionData.height);
rsvg_handle_render_cairo(handle, cr);
cairo_destroy(cr);
free(cairo_surface);
image-flipVertical();
return image;
}
It looks like a memory corruption. Any idea about what might be wrong?
Could anyone of you build and use the svg plugin successfully? If yes, where
did you get the librsvg library? What version? What versions for required
dependencies?
2.
I looked into ReaderWriterSVG.cpp, and saw that the plugin can read an svg as
an image. Since the svg is a vector file format, isn't there a way in OSG to
directly construct a scene graph from that file, returning for example the root
node of that scene graph? Also, I saw that there is no 'writeImage'
implementation. Is there any way to write an svg file, starting from a scene
graph (i.e. passing the root node of such a graph)? Or can it only manage the
svg files as raster images?
Thanks
Gianluca
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: a couple of questions about svg plugin (OSG 3.0.1)
Thanks Robert,
I'll try with different versions of libraries and different .svg test files, to
see if the crash disappears.
Gianluca
Da: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield
Inviato: giovedì 13 dicembre 2012 15:51
A: OpenSceneGraph Users
Oggetto: Re: [osg-users] a couple of questions about svg plugin (OSG 3.0.1)
Hi Guanluca,
I've only used librsvg from the Ubunutu/debian repositories and haven't come
across problems before. Perhaps there is a version issue, or perhaps an issue
with librsvg handling the .svg you are passing on. As you are working under
Windows I think it may well be simply down to the libs and the OSG being built
with different options, this is a very common issue for Windows programmers and
comes with the territory am I afraid, it's another one of the reasons that I
haven't touched windows development for a decade.
As for rendering svg using the scene graph/OpenGL rather than rendering to a
CPU based image then texturing this, we'll it's possible but a for more complex
issue than just relying upon a 3rd party lib to the handle all the specifics of
vector graphics. NVidia do have a library that does vector graphics ontop of
OpenGL so this is probably the way one would tackle it.
Robert.
On 13 December 2012 12:11, Gianluca Natale
nat...@europe.altair.commailto:nat...@europe.altair.com wrote:
Hi all,
I have a couple of issues/questions about the osg plugin for svg file format.
1.
I got win32 prebuilt versions of the library librsvg, and all required
dependencies (glib, gdk-pixbuf, cairo, libcroco, fontconfig, libpng, freetype,
gettext-runtime, libxml2, expat, pango), from this website:
http://ftp.acc.umu.se/pub/gnome/binaries/win32.
And rebuilt the osgdb_svg.dll plugin (in OSG 3.0.1).
When I try to read an svg image in my application, I have a crash in the yellow
line in following function inside ReaderWriterSVG.cpp:
osg::Image* createImage(RsvgHandle *handle, unsigned int width,
unsigned int height) const
{
RsvgDimensionData dimensionData;
rsvg_handle_get_dimensions( handle, dimensionData);
// If image resollution 128, cairo produces some artifacts.
// I don't know why, but we check the size...
if (width 128) width = 128;
if (height 128) height = 128;
width = osg::Image::computeNearestPowerOfTwo(width);
height = osg::Image::computeNearestPowerOfTwo(height);
osg::Image *image = new osg::Image();
image-allocateImage(width, height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
image-setPixelFormat(GL_BGRA);
cairo_surface_t *cairo_surface =
cairo_image_surface_create_for_data(image-data(),
CAIRO_FORMAT_ARGB32, width, height,
image-getRowSizeInBytes());
cairo_t *cr = cairo_create(cairo_surface);
cairo_scale(cr,((float)width)/dimensionData.width,
((float)height)/dimensionData.height);
rsvg_handle_render_cairo(handle, cr);
cairo_destroy(cr);
free(cairo_surface);
image-flipVertical();
return image;
}
It looks like a memory corruption. Any idea about what might be wrong?
Could anyone of you build and use the svg plugin successfully? If yes, where
did you get the librsvg library? What version? What versions for required
dependencies?
2.
I looked into ReaderWriterSVG.cpp, and saw that the plugin can read an svg as
an image. Since the svg is a vector file format, isn't there a way in OSG to
directly construct a scene graph from that file, returning for example the root
node of that scene graph? Also, I saw that there is no 'writeImage'
implementation. Is there any way to write an svg file, starting from a scene
graph (i.e. passing the root node of such a graph)? Or can it only manage the
svg files as raster images?
Thanks
Gianluca
___
osg-users mailing list
osg-users@lists.openscenegraph.orgmailto: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] how about high quality transparency in OSG?
Hi all. I took a (very quick) look at OSG 3.0.1 APIs, to see if there is some technique for high quality transparency implemented, but I couldn't find anything. So, is there anything already implemented for such stuff? I mean, something like the order independent depth peeling, or the more expensive triangle sorting? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] building OSG 3.0.1 on Mac Snow Leopard
Hi all, I'm trying to build OSG 3.0.1 on Mac OSX 10.6 using the procedure well-described on OSG website. But when I clicked on Configure in CMake-gui, after setting Where is the source code and Where to build the binaries, I gotten many red-highlighted options. I could fix most of them (actually I didn't set my build folder as suggested, i.e. the prebuilt packages for dependencies are not in OpenSceneGraph/3rdParty), but I have some doubt for some of them, I hope anyone can give me some tip. Sorry if these are all silly questions! CURL LIBRARY: CURL_INCLUDE_DIR points to /usr/include, instead of pointing to /myBuildfolder/3rdParty/include, where I unzipped the prebuilt packages. So, curl is already installed on my system, and the version I have there is 4. But in prebuilt packages there is version 4.1. Should I use the newest one? FREETYPE LIBRARY: Same as CURL, it is already installed on my system. Should I use in any case that provided in the prebuilt packages, or can I leave that gotten from the system? OSG_WINDOWING_SYSTEM defaults to Carbon on my machine. Isn't it deprecated? Should I change it to Cocoa? ZLIB LIBRARY: Same question as curl, should I use in any case the version provided in the prebuilt packages? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] issues with drawing of drawables in different colors
Hi All, I have a very weird issue that seems related to a problem in the driver of my graphic board (nVidia Quadro M3000 on a Dell Precision M6600, Win7 Professional SP1). I tried to update to newest one, but the issue is still there. I hope anyone of you has some idea about the possible cause of the issue, and how to fix it. What I have is a scene graph whose geometry nodes are made by multiple instances of the same drawable in different positions in the model. That is to say: __ transform1 __ geode 1__ DerDrawable 1 / Root ___ transform2__ geode 2 __ DerDrawable 2 \___... \___ transform3__ geode 3__ DerDrawable 3 Basically I have derived my own DerDrawable from osg::drawable, and implemented a drawImplementation that simple defines some easy geometry (100 vertices) by using vertex arrays. Then I set different state sets for geodes (basically material properties). All geodes, but one, have the same material properties (i.e. the same color). Let's suppose all geodes are drawn in red, but one in yellow. What happens is that all drawables are draw in red :( Anyway, if I exclude all of them, but the yellow one, from drawing (for example by zooming into the one that should be showed in yellow) it actually appears yellow. As soon I zoomed out, everything appears red. If, anyway, I add a glFinish(); as the last statement in my drawImplementation, the issue suddenly disappears. I mean, all drawables drawn in red, and one in yellow. It looks like the material properties are not updated properly before drawing the last object (I know that OSG orders drawables by state sets, in order to minimize changes in OpenGL states, so I guess that the yellow drawable is drawn at the end, but my suspicious is that the geometry is rendered before the material properties are set to yellow). Unfortunately adding glFinish() slows down my application noticeable (I tried with glFlush(), but this does not solve the problem). Any idea? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: Depth test and RenderBin details
What I would do in standard OpenGL is this: 1) Draw your whole model first (with depth test enabled); 2) Clean the depth buffer only (glClear(GL_DEPTH_BUFFER_BIT);); 3) Draw the dragger (with depth test enabled). In this way the dragger would always appear on top of the model, no matter its position in the world. How can you achieve this in a scene graph using OSG? 1) I would set the rendering bin for the whole model to the lowest value, to force it to be drawn first. Keeping depth test enabled during drawing. 2) I would define a CleanDrawable, derived from osg::drawable, whose drawImplementation is just a glClear(GL_DEPTH_BUFFER_BIT). And assign the rendering bin for such drawable to a value greater than the one assign to the whole model. Then, I would attach a geode containing such drawable somewhere in your scenegraph. 3) I would set for the dragger a rendering bin even greater than that assigned to the CleanDrawable. Keeping the depth test enabled in this case also. I did do it in my application and it seems to work. But I don't know if there is a better and more elegant solution. Just my 2 cents. -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Bob Slobodan Inviato: lunedì 11 giugno 2012 10:15 A: osg-users@lists.openscenegraph.org Oggetto: Re: [osg-users] Depth test and RenderBin details Hi guys, First of all, thank you for the answers. Unfortunately, I couldn't solve my problem. I already tried the first solution that consisted in giving different render bin to the axis and the sphere, but then I either have the sphere always on top of the axis, or the axis always on top of the sphere. This image illustrates my problem : [Image: http://img15.hostingpics.net/pics/490598Sanstitre4.png ] (http://www.hostingpics.net/viewer.php?id=490598Sanstitre4.png) The image 1 illustrates what i have when the sphere has a lower render bin than the axis. The images 2 and 3 illustrates the opposite. The image 4 illustrates a shading problem that I have in both situation. So what I want is a mix between the image 2 and 5. This is basically what I have when I don't deactivate the depth test and don't use render bin details. But then, if I have anything (like a plane for example) between my dragger and the camera, I won't see it anymore. Thank you so much for helping me. Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48156#48156 ___ 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] animation from one projection type to the other one
Hi all, I'm trying to implement an animation from a perspective projection to an orthographic one. What I'm computing at each step is a weighted linear combination of 2 projection matrices (the start, that refers to a perspective projection, and the end, which is an orthographic projection). So, supposing the whole animation in N steps, at step n my projection matrix is defined by: Proj(n) = startProjMat * (1 - n/N) + endProjMat * n/N. The animation looks fine, but in the last step there is a noticeable jump on the screen. What did I go wrong? Is there any unpredictable or invalid result in the linear combination I computed, or is it a well defined projection matrix? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NAN detected by OSG during cull traversal.
Hi,
recently my OSG based application starts printing a warning/error
message, saying:
CullVisitor::apply(Geode) detected NaN,
depth=-1.#IND, center=(0 0.0658239 0),
matrix={
1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
1.#QNAN 1.#QNAN 1.#QNAN 1.#QNAN
0 0 0 1
}
It happens when I try to move the camera too near the nearest object in
the frustum.
Actually I'm sure that the near/far ratio is satisfied, because I get it
from the cull settings of the camera,
and I stop moving the camera when the near clipping plane is reached.
Any idea where that message is originated from? I mean, what should I
check to find my mistake?
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] R: R: about the front clipping plane
I still have another question about it. The front and back clipping planes are updated by OSG during the cull traversal, based upon the bounding volumes of all the objects in the scene. What happens if the farthest object (WRT the eye position) in the scene is out of the viewing volume? Is it still taken into count to determine the far clipping plane, or is it excluded since out of the frustum? Same question for the nearest object. If out the viewing volume, is it ignored for computing the near clipping plane? Thanks Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Gianluca Natale Inviato: lunedì 30 maggio 2011 16:53 A: OpenSceneGraph Users Oggetto: [osg-users] R: about the front clipping plane Thank you Robert, you are always clear and precise! That's the info I need. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: lunedì 30 maggio 2011 16:50 A: OpenSceneGraph Users Oggetto: Re: [osg-users] about the front clipping plane Hi Gianluca, The OSG by default will use COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES settings for osg::Camera which tells the cull traversal to compute the depth range of scene for each frame based on the extents of the bounding boxes of the drawables in the scene. Often the computed near position will be very close to the eye point or even behind it both of which are not usage values for settings up the projection matrix, so the cull travesal automatically clamps the near distances if it's too low. The minimum near distance the OSG uses as a cut off is computed from NearFarRatio * compute_zfar, you can reset this ratio to a lower value via osg::Camera::setNearFarRatio(double). Robert. On Mon, May 30, 2011 at 3:40 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an empty bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I'm sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn't OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, Gianluca Natale ___ 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] R: R: R: about the front clipping plane
Thanks Robert. -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 31 maggio 2011 12:04 A: OpenSceneGraph Users Oggetto: Re: [osg-users] R: R: about the front clipping plane Hi Gianluca, On Tue, May 31, 2011 at 10:58 AM, Gianluca Natale nat...@europe.altair.com wrote: The front and back clipping planes are updated by OSG during the cull traversal, based upon the bounding volumes of all the objects in the scene. What happens if the farthest object (WRT the eye position) in the scene is out of the viewing volume? Is it still taken into count to determine the far clipping plane, or is it excluded since out of the frustum? Same question for the nearest object. If out the viewing volume, is it ignored for computing the near clipping plane? If the a drawables bounding box intersections with the view frustum then it will be treated as though the whole object intersections and the computation of the near/far planes will use it whole extents. Drawables that a completely outside the view frustum will be culled and won't take any part in the computation of the near/far planes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about the front clipping plane
Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an empty bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I'm sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn't OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: about the front clipping plane
Thank you Robert, you are always clear and precise! That's the info I need. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: lunedì 30 maggio 2011 16:50 A: OpenSceneGraph Users Oggetto: Re: [osg-users] about the front clipping plane Hi Gianluca, The OSG by default will use COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES settings for osg::Camera which tells the cull traversal to compute the depth range of scene for each frame based on the extents of the bounding boxes of the drawables in the scene. Often the computed near position will be very close to the eye point or even behind it both of which are not usage values for settings up the projection matrix, so the cull travesal automatically clamps the near distances if it's too low. The minimum near distance the OSG uses as a cut off is computed from NearFarRatio * compute_zfar, you can reset this ratio to a lower value via osg::Camera::setNearFarRatio(double). Robert. On Mon, May 30, 2011 at 3:40 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi, I have an issue with the distance of the front clipping plane of the viewing frustum. I mean that my scene is made only of two isolated points, each with an empty bounding box (i.e. the bb is defined as the 8 vertices coinciding with the point). Also, I set: setComputeNearFarMode(COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES) for my osg::camera, in order to have osg update automatically the front and back clipping planes. But sometimes it happens that the nearest point (in my scene) to the camera is not drawn on the screen, even if I'm sure that it is placed in front of the camera and not behind. It looks like the front clipping plane cuts away that point since it is too near the camera. Shouldn't OSG update the front clipping plane to include such point in the viewing volume, since it has a valid bb and it is in front of the camera? I tried to print out the zNear when this happens, and obtained values 1e-5. Also, if later I try to move the camera even nearer to that point, I see an error message of OSG (CullVisitor::apply(Geode) detected NAN). So, where am I wrong? Is there any threshold to be taken into count when moving the camera near the nearest point my scene? Thanks, Gianluca Natale ___ 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] how to create a fade effect?
Hi everybody, I'm developing an osg based application that needs to fade some objects out of the scene when it is destroyed. So, instead of a sudden disappearing, I would like to make it slowly disappear from the screen, let's say for example in 1 second. I think that I could: 1) draw the final image (object completely removed) in a separate pixel buffer, then get that image and create a texture with it; 2) copy the content of the front buffer (the initial image) in another texture; 3) create a temporary scenegraph made only by a geode containing 2 drawables, each of which draws a rectangle with the same size of the screen. And attach the texture created at step 1 in one drawable, and the texture created at step 2 in the other one. 4) finally draw that simple geode in n steps, using at each step a different blending factor for plane 1 (copy of the front buffer) and 2 (final image). I mean, starting from alpha1 = 1.0 and alpha2 = 0.0 at step 1, till alpha1 = 0.0 and alpha2 = 1.0 at step n. It should give me the effect I want. Or not? Do you think it is doable? Do you think it might be also fast? Finally, do you have some example in osg about writing to a texture, copying the front buffer into a texture, etc...? I know that for sure there are things already implemented there. Actually I'm also quite sure that osg is so powerful that I could accomplish what I want with no more the 30-40 lines of code. But I don't know how to do that quickly. Thanks in advance. Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: how to create a fade effect?
Hi Chris, I'm using FFP, and I guess that I could do this effect without using GLSL and with minimal effort. I already tried what you suggest, i.e. blending the object being destroyed with the background. There are some disadvantages in doing that: 1) that object would show its back faces during fading, even if it is completely opaque at the beginning. I don't want that, because the initial steps would show the object completely messed up (since there is no sorting of triangles from farthest to nearest, so farther triangles might be drawn later than nearer, and the blending would give wrong result). I could cull the back faces, yes, but only if that object is a completely closed surface, otherwise visible back faces would disappear immediately. 2) I would implement a general solution that is based not upon the objects that have to fade in/out, but on the global scene. I mean, I would just need to draw the final image elsewhere (no matter which object fade in, which other fade out, which one changes color or appearance, etc...), not in back buffer, and blend from the initial image (currently shown in the front buffer) to that final image. So actually, yes, my effect is more a morphing than a fading effect. My concerns are about: 1) How to read the content of the front buffer and store it in a texture. 2) How to draw in a separate pixel buffer and create a texture with it. 3) If this method might be fast or slow (some years ago I could experience that copying the content of the front buffer on a ATI graphic card was so slow!), and if it would work in general. 4) Last, but not least, if there is already some code ready to be used! :) Thanks Gianluca On 5/7/2011 8:58 AM, Gianluca Natale wrote: Hi everybody, I'm developing an osg based application Are you using GLSL shaders, or only basic FFP? Why not move the fading objects into a TRANSPARENT_BIN and adjust the alpha value of the geometry down progressively? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glFlush and osg
Hi there, I have an issue with glFlush, and I don't know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn't, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What's even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: glFlush and osg
Thanks Robert, I'll try to replace my drawables with those provided by osg. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 19 aprile 2011 17:26 A: OpenSceneGraph Users Oggetto: Re: [osg-users] glFlush and osg Hi Gianluca, There isn't much we can probably suggest given you are using a custom Drawable implementation. General comments would be that glFlush shouldn't affect the quality of the results, only the speed at which handled. Using glFlush forces the GL driver to pause the application thread calling GL to wait until all the commands and data in GL drivers' fifo buffer have been passed to the graphics card. glFlush doesn't itself change any OpenGL state so in principle should not effect results. Given glFlush shouldn't have the effect you are describing perhaps it's just co-incidence and that a threading issue in your application is causing problems. I would also suggest replacing your custom Drawable with code based on osg::Geometry, this may or may not be possible, but trying this would at least give you a test using code that others have access to, and is known to work. Robert. On Tue, Apr 19, 2011 at 4:03 PM, Gianluca Natale nat...@europe.altair.com wrote: Hi there, I have an issue with glFlush, and I don't know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn't, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What's even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ 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] about latest stable version released for OSG
Hi, I just visited the website of OSG, searching for the newest stable version. It looks like it is the 2.8.3 (it's the latest available on the download page), is it correct? But in the home page the version 2.9.7 is mentioned (and even 3.0 is going to be released). So, what's the newest, and how can I get it? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about drawing only in the front buffer
Hi there, I hope someone of you can help me on this issue. I have a very complicated scene graph, that takes a very long time to be completely redrawn (200 ms). But the most frequent use case I have is to redraw only a very small part of the model at a time (suppose for example that I would need to redraw only the object under the mouse). So, I could increase performances a lot by simply redrawing that object in the front buffer without clearing the depth buffer, in order to keep it in the right position WRT the other object of the model. And without swapping front and back buffers at the end of drawing. Is this possible? If I'm not wrong, sometimes ago I received an email from you saying that the drawing traversal of OSG always clean the depth and back buffers, redraws the complete scene graph and then swap the buffers. This works pretty well when the scene changes dynamically, but in my case where there is a static drawing for a long time, I would need a way to tell the drawing traversal to draw in the front buffer, and not to perform the swapping of buffers at the end. Is there a way to do that? Thanks in advance Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: about drawing only in the front buffer
Thanks Sergey, actually my case is exactly the exception you mentioned. I mean, I know exactly the object to redraw (so, its main node in the scene-graph), it is opaque and doesn't change size and position (mine is a static scene). When the mouse is moved over that object, I just need to change its color. That's it. Thanks, Gianluca Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Sergey Polischuk Inviato: martedì 22 febbraio 2011 16:14 A: OpenSceneGraph Users Oggetto: Re: [osg-users] about drawing only in the front buffer Hi, Gianluca Natale In order to get correct results you cant just go and draw changed object on top of previous frame (there are one exception that is if object in question dont change size and position and is completely opaque). You will get depth buffer issues and parts of old object position can still remain visible. To get it work you need to redraw all region where old object was + draw changed object on top of that. If this exception applies - you can draw each frame to textures (storing color and depth), then in next frame if you need to redraw only some objects, then, considering you know what objects need redraw, you first draw previous frame textures with screen aligned quads to color and depth, and after that you draw objects on top of that with depth func set to equal. With transparent geometry you still need to redraw background as in previous case. So in general case you can do the following: Draw from previous frame textures with screen aligned quads to color and depth like in previous case. Get screen coords of regions that needs to be redrawed with transforming changed objects bboxes to screen coords. Draw quads with depth set to 1.0 and depth test set to always covering regions where changed objects were. Search you graph for objects that after transforming to screen coords will overlap with that regions. Draw them as usual along with changed objects. I dont think that you will be able to gain sufficient speedup with that though. Cheers, Sergey. 22.02.2011, 16:47, Gianluca Natale nat...@europe.altair.com: Hi there, I hope someone of you can help me on this issue. I have a very complicated scene graph, that takes a very long time to be completely redrawn (200 ms). But the most frequent use case I have is to redraw only a very small part of the model at a time (suppose for example that I would need to redraw only the object under the mouse). So, I could increase performances a lot by simply redrawing that object in the front buffer without clearing the depth buffer, in order to keep it in the right position WRT the other object of the model. And without swapping front and back buffers at the end of drawing. Is this possible? If I'm not wrong, sometimes ago I received an email from you saying that the drawing traversal of OSG always clean the depth and back buffers, redraws the complete scene graph and then swap the buffers. This works pretty well when the scene changes dynamically, but in my case where there is a static drawing for a long time, I would need a way to tell the drawing traversal to draw in the front buffer, and not to perform the swapping of buffers at the end. Is there a way to do that? Thanks in advance Gianluca Natale ___ 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] performance issue
Hi there! I have some performance issue when trying to draw objects whose geometry contains millions of vertices. I want to try everything to improve it (LOD, exclude back faces for closed surfaces, use strips and fans, vertex buffer objects, etc.), but I wonder if OSG already uses occlusion queries (provided by OpenGL) during rendering traversal, applied to the bounding boxes of the geodes/drawables, to quickly exclude the complete drawing of that part. Or at least, if there is a way to enable it. I'm using OSG 2.8.0. For my models that would help me a lot, since each geometry has millions of vertices, but occlusion queries for bounding boxes would involve only 8 vertices at a time. 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] about node mask
Hi All.
I'm setting node masks so that I can use different node visitors with
different traversal masks
to exclude some node from traversal.
But I'm a bit confusing for the description of the tutorial NodeMaskDemo
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/NodeMaskDe
mo
and the real implementation.
I mean that in the tutorial I read this:
During the pre-render traversal of the scene graph a logical OR comparison
of the current node mask and camera's node mask is made.
If the comparison is non-zero, the traversal will continue and if there is
geometry associated with the node it will be sent to the render graph for
rendering.
If the logical OR is zero, traversal will not continue further down the
scene. Any associated geometry will not be rendered.
While in the implementation of the nodeVisitor I see:
inline bool validNodeMask(const osg::Node node) const
{
return (getTraversalMask() (getNodeMaskOverride() |
node.getNodeMask()))!=0;
}
So, I guess that the tutorial meant AND comparison and not OR comparison.
Am I wrong?
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] drawing in back buffer without swapping?
Thank you Paul. The reason why I need to render in background is this: I need to save an image of my model with a different camera position and orientation than that currently visible to the user on the screen (i.e. in the front buffer). So, I thought that I could draw my model from a different point of view in the back buffer, without swapping. Then get it by reading pixels from the back buffer, and saving the pixmap in an image file. Finally, restore the camera position and orientation, and resume in swapping back and front buffers after drawing. So, the complete operation would be completely hidden to the user. I always did it using standard OpenGL calls (glDrawBuffers(...), glReadPixels(...), etc...) since I could control whether and when swapping the buffers or not. I wondered why OSG does not allow such an operation, I thought it is a limitation. But now you're saying that OSG provides a better way to do that. Could anyone give me some more tips and suggestions (I'm still a newbie to OSG)? Thanks in advance Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: mercoledì 27 gennaio 2010 19.25 To: OpenSceneGraph Users Subject: 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 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?
Thank you Robert, I like the idea of a pixel buffer completely behind the scenes, especially since I can use a different size (that was the worst disadvantage of my implementation using OGL). So, I should create a osgViewer::Viewer associated to a graphics context with the desired pixel format and size, and set the sceneData of the viewer with the root node of my model. Then make that graphics context the current context, render the model in that viewer, and read the pixels of the pixel buffer after drawing. Create an osg::Image with the content of the buffer and write it in my desired file format (as OSG supports many different graphic file format). Finally release the graphics context. Does it work? Thanks Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: giovedì 28 gennaio 2010 11.07 To: OpenSceneGraph Users Subject: Re: [osg-users] drawing in back buffer without swapping? Hi Gianluca, The OSG allows you to create graphics context, make the context current and then dispatch rendering and do swap buffers yourself but this requires you to individually set everything up yourself. What osgViewer does is provide all the basic functionality that 99% of users need out of the box, including handling context creation, multiple contexts, handling of database threading, viewer threading, event handling etc. It makes what would be a complicated task trivial, but with encapsulating all this functionality it has to make some assumptions about the way it's used, and I'm afraid your specific case isn't handled out of the box. You could if you want roll your own mini view with a pbuffer and do what you want completely behind the scenes so that the user doesn't know about it. This has the advantage that the pbuffer size can be different than the on screen size, it also avoid issues with other windows/toolboxes overlapping the window. The other route would be to stop the viewers threading, then make the context current and then insticate your won cull and draw to do the rendering, then release the context, and then start the viewer threading once more. Another route would be to use a viewer slave camera that sole job is to the render the screenshot, it has a NodeMask of 0x0 for all frames except the one you want to capture the screen shot, then you just switch it on for this frame. The slave camera would be rendered prior to the main frame - so you'd set the RenderOrder on this slave Camera to pre render. This approach would still require you to rendering a normal frame and have the extra cost of the rendering the scene, but for most apps you should be hit 60Hz anyway so it'd wouldn't be anything a viewer would notice, at most you'd get a frame drop when you added in the extra slave camera's rendering work. Robert. On Thu, Jan 28, 2010 at 9:46 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Paul. The reason why I need to render in background is this: I need to save an image of my model with a different camera position and orientation than that currently visible to the user on the screen (i.e. in the front buffer). So, I thought that I could draw my model from a different point of view in the back buffer, without swapping. Then get it by reading pixels from the back buffer, and saving the pixmap in an image file. Finally, restore the camera position and orientation, and resume in swapping back and front buffers after drawing. So, the complete operation would be completely hidden to the user. I always did it using standard OpenGL calls (glDrawBuffers(...), glReadPixels(...), etc...) since I could control whether and when swapping the buffers or not. I wondered why OSG does not allow such an operation, I thought it is a limitation. But now you're saying that OSG provides a better way to do that. Could anyone give me some more tips and suggestions (I'm still a newbie to OSG)? Thanks in advance Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: mercoledì 27 gennaio 2010 19.25 To: OpenSceneGraph Users Subject: 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
[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
[osg-users] is there any limitation in the possible values for rendering hint?
Hi, I used the rendering hint to draw different objects in different order in my scene graph. In short, I set a rendering hint = 0 for the state set associated to a geode containing an opaque object (the depth test is enabled). Then, since I want to draw anti-aliased lines over that object, I set a state set for a geode containing a line. This state set basically has the blending enabled, and the depth test enabled but with the depth mask = false (to avoid visual artifacts in the junctions of adjacent segments of the line). This is the issue: If I used a rendering hint = 99 for such a state set, all would work fine (the opaque object partially hides the line). But if I used a rendering hint = 100 for the same state set, the line would appear over the opaque object, even if it is behind (it looks like the depth test has been disabled). So, my question is: is the value for a rendering hint limited to 99? If so, what happens if I used higher values? Unpredictable results? 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] global bounding sphere with autotransformed objects
Thanks, that's what I'll do. And about my second question: is there a way to avoid the implicit swapping of the back and front buffers at the end of redraw? I mean, by some settings on the camera. Furthermore, is there also a way to force a glFinish(); before swapping, in order to be sure that the whole drawing is done? I have a problem with a graphic board (nVidia GeForce 6800) on mac. It looks like the swap operation comes too fast (before the rendering pipeline has finished to process all the geometry), and in consequence some parts of the model are missing, and in different times, giving a very bad flickering effect. Thanks Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 14 agosto 2009 12.59 To: OpenSceneGraph Users Subject: Re: [osg-users] global bounding sphere with autotransformed objects Hi Gianluca, The AutoTransform adjusts it's internal settings based on the eye position, which is acquired during the cull traversal. Have a look at the implementation of the AutoTransform::accept() to see what is going. If you want to find the value of the AutoTransform for a given camera position prior to the cull traversal then you'll need to do a dummy cull traversal by creating your own cull visitor. Robert. On Mon, Aug 10, 2009 at 11:42 AM, Gianluca Natalegianluca.nat...@adstorino.it wrote: Hi All. I have this problem, with OSG 2.8.0. In my scenegraph there is some object attached as a child of an Autotransform matrix (I need to keep its size constant on the screen, wherever is the camera). I have also to fit the model in the screen, using the global bounding sphere of the model. Ive seen that the bounding sphere is computed during the rendering traversal. And that the bounding sphere of auto-transformed objects changes as the camera position changes, while the bounding sphere of the other objects is constant. This is what I expected, since the size on the screen must be constant. So, I thought that I can compute the global bounding sphere of my model by multiple iterative redraws, until the global bounding sphere at step n is almost the same as that at step n-1. And it works. Is there a way to update the bounding sphere of autotransformed object without redrawing? I mean, I would need to show directly the model fit in the screen, without showing the user all the single steps. Or, at least, may I avoid the swap of back and front buffers at the end of redraw? In this way I could make the back and front buffers be swapped only at the end of fit. Thanks in advance Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.55/2301 - Release Date: 08/13/09 18:16:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about the bounding sphere of a geode computed by OSG
Hi All, I'm having problem computing the global bounding sphere of my model. I debugged OSG (2.8.0) and discovered that the bounding sphere of a geode (BoundingSphere Geode::computeBound()) is computed as the bounding sphere of the bounding box that includes all its drawables !?! Why that? Shouldn't it be the global bounding sphere of the drawables, merging the single bounding spheres of all the drawables? So, a drawable that represents a sphere should have as bounding sphere itself, but this is not true with the computation OSG performs. It is larger than strictly required. Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] about the bounding sphere of a geode computed by OSG
I cannot completely agree. I mean that I know that the real perfect bounding sphere is computationally expensive, but in many cases (solid objects) it should be computed just once (since BoundingSphere node::getBound() checks if the bounding sphere has been already computed), when the object is created. The global bounding sphere might affect the fitting operation a lot. In case of objects like spheres or discs, the bounding sphere computed by OSG might be much greater than strictly required. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: martedì 11 agosto 2009 12.00 To: OpenSceneGraph Users Subject: Re: [osg-users] about the bounding sphere of a geode computed by OSG Calculating the perfect bounding sphere is an expensive operation. You need to calc the convex hull which is O(n log n). osg uses a fast approximation which is generally good enough. 2009/8/11 Gianluca Natale gianluca.nat...@adstorino.it: Hi All, Im having problem computing the global bounding sphere of my model. I debugged OSG (2.8.0) and discovered that the bounding sphere of a geode (BoundingSphere Geode::computeBound()) is computed as the bounding sphere of the bounding box that includes all its drawables !?! Why that? Shouldnt it be the global bounding sphere of the drawables, merging the single bounding spheres of all the drawables? So, a drawable that represents a sphere should have as bounding sphere itself, but this is not true with the computation OSG performs. It is larger than strictly required. Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.49/2295 - Release Date: 08/10/09 18:19:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] global bounding sphere with autotransformed objects
Hi All. I have this problem, with OSG 2.8.0. In my scenegraph there is some object attached as a child of an Autotransform matrix (I need to keep its size constant on the screen, wherever is the camera). I have also to fit the model in the screen, using the global bounding sphere of the model. I've seen that the bounding sphere is computed during the rendering traversal. And that the bounding sphere of auto-transformed objects changes as the camera position changes, while the bounding sphere of the other objects is constant. This is what I expected, since the size on the screen must be constant. So, I thought that I can compute the global bounding sphere of my model by multiple iterative redraws, until the global bounding sphere at step n is almost the same as that at step n-1. And it works. Is there a way to update the bounding sphere of autotransformed object without redrawing? I mean, I would need to show directly the model fit in the screen, without showing the user all the single steps. Or, at least, may I avoid the swap of back and front buffers at the end of redraw? In this way I could make the back and front buffers be swapped only at the end of fit. Thanks in advance Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Osg/OpenGL flickering on Solaris Sparc 5.10
I have the same problem with a Mac. It does happen only on certain machine/graphic cards, and only when the cmd/ctrl key is pressed. Is there someone who knows if that Key has a special function on Mac? Thanks, Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: martedì 30 giugno 2009 20.56 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Osg/OpenGL flickering on Solaris Sparc 5.10 Hi Yuen, By default the OSG will try to allocate a double buffered window, if you are seeing flickering then it is likely to be a driver issue. Try a different machine, also try different examples like osgviewerGLUT or osgviewerSDL to see if GLUT or SDL exhibits the problems. Robert. On Tue, Jun 30, 2009 at 6:24 PM, Yuen Helbigyuen_hel...@mentor.com wrote: Hello, I'm working on porting my application to Solaris Sparc 5.10 and I'm seeing a flickering screen when viewing my osg models. It looks like a double-buffering issue but I don't know how to confirm or fix this. Any ideas? Is it a Osg problem or a graphics card/driver problem? Looking for any suggestions, Thank you, Yuen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14709#14709 ___ 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 Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.0/2209 - Release Date: 06/29/09 14:43:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] missed state set for a scene node
Hi All. I've forgotten to set a state set to a node (and it shouldn't be necessary, since it is just a switch, with any children that define its own state set; and in fact the state set for that switch should be a simple set that just sets a rendering bin to the default for opaque, 0), but I got strange visualization. Does a node need a state set, always? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] missed state set for a scene node
Thanks, I should have messed up some state set elsewhere. Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: mercoledì 27 maggio 2009 10.49 To: OpenSceneGraph Users Subject: Re: [osg-users] missed state set for a scene node Hi Gianluca, On Wed, May 27, 2009 at 9:42 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Does a node need a state set, always? No, in fact you can have scene graphs where no nodes or drawables have StateSet assigned to them, it's still a perfectly valid scene graph. Such a naked scene graph would have to rely on the viewer's camera for it's state, and wouldn't be that useful, but it's still valid. For most scene graphs you'll find the StateSet's on the Geode's or Drawable leaves. StateSet's on internal nodes of the scene graph tend to be used for decorating the subgraph with some new or overridden state. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.39/2134 - Release Date: 05/26/09 20:20:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] autotransform and fit
Hi All, I have a scene graph with an autotransform in it (I want the size of an arrow be preserved from any change that might happen on window size). So, to fit my model in that window, I would need to get the whole bounding sphere. Is there a visitor that does what I need, without redrawing the model (I saw that the cull visitor does it, but I don't want to repaint anything)? Or do I have to write it on my own? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] update of zNear and zFar during drawing
Hi all. I have a strange behavior when I let OSG update the near and far clipping planes during drawing. When I use a perspective projection, and I move the camera inside the model (I mean, inside the global bounding sphere of the model), the near clipping plane is placed very near to the camera, so to clip as few objects as possible. I like this behavior, and I would like to use it also for Orthogonal projections. But in that case, when I move the camera into the model, the near clipping plane becomes negative, so the viewing volume includes always the whole model. And I don't like this now. Is this the right behavior, or did I miss something/make some mistake? If this is the way it works for orthogonal projections, is there a way to make it work like perspective one? Thanks in advance. Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
Thank you again, Robert. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.54 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing On Fri, Apr 24, 2009 at 10:39 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) You can do what you want with the near + far clipping planes in orthographic and perspetive projections simply by switch off the automatic compute of the near and planes via camera-setComputeNearFar(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); But this won't make othrographic magically appropriate for doing internal views. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) Thanks, Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.02 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing HI Gianluca, Arggghhg... You can't use orthographic projects in the same way that you use perspective projections, it simply doesn't work. Use orthographic projections for external views of the scene where clipping is not used. Do *not* use it for internal views where clipping is critical. Try to do this on and you'll just waste lots of your time and lots of the communities time trying to explain to you why it won't work. Robert. On Fri, Apr 24, 2009 at 9:44 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Hi all. I have a strange behavior when I let OSG update the near and far clipping planes during drawing. When I use a perspective projection, and I move the camera inside the model (I mean, inside the global bounding sphere of the model), the near clipping plane is placed very near to the camera, so to clip as few objects as possible. I like this behavior, and I would like to use it also for Orthogonal projections. But in that case, when I move the camera into the model, the near clipping plane becomes negative, so the viewing volume includes always the whole model. And I dont like this now. Is this the right behavior, or did I miss something/make some mistake? If this is the way it works for orthogonal projections, is there a way to make it work like perspective one? Thanks in advance. Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update of zNear and zFar during drawing
Robert, is there a quick way to simply update near and far clipping planes for perspective projection, without calling an explicitly redraw (I mean, some visitor that computes for example the bounding box of the model and updates near and far clipping plane also)? Thanks, Gianluca -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Gianluca Natale Sent: venerdì 24 aprile 2009 12.29 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] update of zNear and zFar during drawing Thank you again, Robert. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: venerdì 24 aprile 2009 11.54 To: OpenSceneGraph Users Subject: Re: [osg-users] update of zNear and zFar during drawing On Fri, Apr 24, 2009 at 10:39 AM, Gianluca Natale gianluca.nat...@adstorino.it wrote: Thank you Robert, I apologize for my ignorance. Actually I don't want to make any zoom in, I just want to clip objects behind the camera (is there any problem in clipping a sphere against a rectangular box?) You can do what you want with the near + far clipping planes in orthographic and perspetive projections simply by switch off the automatic compute of the near and planes via camera-setComputeNearFar(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); But this won't make othrographic magically appropriate for doing internal views. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.4/2077 - Release Date: 04/23/09 19:21:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] multisampling antialiasing in OSG
Hi all. I'm using OSG 2.8, I'd like to know if it supports multisampling antialiasing, and how I can enable it. Thanks, Gianluca Natale P.S.= I tried to search for GL_MULTISAMPLE in the whole OSG source code, but I couldn't find it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multisampling antialiasing in OSG
Thank you so much, Ill try. Gianluca From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: lunedì 30 marzo 2009 11.55 To: OpenSceneGraph Users Subject: Re: [osg-users] multisampling antialiasing in OSG Hi Gianluca; I recommend you to use multisampling to implement antialiasing. You can enable multisample while creating GraphicsContext. // Init the GraphicsContext Traits. osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits; // Setup the traits parameters. traits-samples = 4; // to make anti-aliased. HTH. Best Regards. 2009/3/30 Gianluca Natale gianluca.nat...@adstorino.it Hi all. Im using OSG 2.8, Id like to know if it supports multisampling antialiasing, and how I can enable it. Thanks, Gianluca Natale P.S.= I tried to search for GL_MULTISAMPLE in the whole OSG source code, but I couldnt find it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.31/2029 - Release Date: 03/29/09 16:56:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 2D drawing over a 3D drawing
Hi All. I need to draw a 2D drawing (a single wireframe rectangle) over a 3D drawing of a scene. Basically I need it to show a window selection in the scene. In OpenGL, I would set a perspective projection like glFrustum(.), draw the scene, then set a glOrtho2D(.), and draw the rectangle. Finally I would call a swap buffers. How can I do it with OSG? I mean, in OSG the projection matrix is associated with a camera. So, should I use two cameras, one for the 3D scene, the other just for the 2D rectangle? In camera::frame there is the swap of the back and front buffers. But I would like to swap those buffers just at the end, after drawing everything. So, should I call the drawing of the 3D camera without swapping, then the drawing of the 2D camera with swapping at the end? I read in the quick start guide of OSG of the thread for draw traversal. Since I call camera::Frame twice, does OSG create 2 different threads? Is there any conflict between those threads, since they draw with different projection matrices? Thanks in advance Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2D drawing over a 3D drawing
Thanks a lot, this is the answer I needed. Just another question: suppose that I need to draw different 2D drawings onto the same 3D scene, how can I set the desired rendering order for those slave cameras? I mean, I want to make sure that a text will always appear over a 2D rectangle created onto the 3D scene. Should I set the camera for the rectangle as cameraforRectangle::setRenderOrder(osg::Camera::POST_RENDER, 0); and cameraforText::setRenderOrder(osg::Camera::POST_RENDER, 1); ??? Does it work that way? Thanks, Gianluca From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: lunedì 23 marzo 2009 12.09 To: OpenSceneGraph Users Subject: Re: [osg-users] 2D drawing over a 3D drawing HI Gianluca, Please have a look at the osghud example. Robert. 2009/3/23 Gianluca Natale gianluca.nat...@adstorino.it Hi All. I need to draw a 2D drawing (a single wireframe rectangle) over a 3D drawing of a scene. Basically I need it to show a window selection in the scene. In OpenGL, I would set a perspective projection like glFrustum( ), draw the scene, then set a glOrtho2D( ), and draw the rectangle. Finally I would call a swap buffers. How can I do it with OSG? I mean, in OSG the projection matrix is associated with a camera. So, should I use two cameras, one for the 3D scene, the other just for the 2D rectangle? In camera::frame there is the swap of the back and front buffers. But I would like to swap those buffers just at the end, after drawing everything. So, should I call the drawing of the 3D camera without swapping, then the drawing of the 2D camera with swapping at the end? I read in the quick start guide of OSG of the thread for draw traversal. Since I call camera::Frame twice, does OSG create 2 different threads? Is there any conflict between those threads, since they draw with different projection matrices? Thanks in advance Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.24/2018 - Release Date: 03/23/09 06:52:00 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] antialiased 3D lines
Hi All. I have to draw antialiased lines in different colors in 3D space. So, in order to have them antialiased, I need to disable the update of the depth buffer, to avoid cracks in the junctions of the polylines that approximate curved lines. In this way unfortunately farther lines could appear over nearer lines. On the other hand, if I enable the update of the depth buffer, I would have the cracks. I tried with a double pass algorithm (both methods in sequence), but I still see some crack at the junctions. And it also slows down performance. Any better idea? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] projection matrix and viewport
I'm trying to set the projection matrix by the camera, just before calling a camera-frame. But, as soon as frame returns, the projection matrix is changed in the left and right clipping planes. Since the redraw is called as a consequence of a resize event, and the viewport is updated consequently, is there a relationship between the projection matrix and the viewport? In OpenGL there isn't any relationship, I mean that I can set the viewport independently of the projection matrix. But it seems that OSG doesn't want to distort the original scene. If so, is it the default behavior? How can I disable such a behavior? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] projection matrix and viewport
I forgot to say that I'm still using Producer::Camera
(I would like to update to OSG 2.x, but I cannot do it soon),
and I couldn't find such a function.
Is there something similar that I can try?
Thanks a lot.
Gianluca
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: mercoledì 19 novembre 2008 12.49
To: OpenSceneGraph Users
Subject: Re: [osg-users] projection matrix and viewport
Hi Gianluca,
By default the OSG automatically updates the projection matrix when
window is resized, but you can disable this using the Camera method:
enum ProjectionResizePolicy
{
FIXED, /** Keep the projection matrix fixed, despite
window resizes.*/
HORIZONTAL, /** Adjust the HORIZOTNAL field of view on
window resizes.*/
VERTICAL /** Adjust the VERTICAL field of view on window
resizes.*/
};
/** Set the policy used to determine if and how the projection
matrix should be adjusted on window resizes. */
inline void setProjectionResizePolicy(ProjectionResizePolicy
policy) { _projectionResizePolicy = policy; }
Robert.
On Wed, Nov 19, 2008 at 11:24 AM, Gianluca Natale
[EMAIL PROTECTED] wrote:
I'm trying to set the projection matrix by the camera,
just before calling a camera-frame.
But, as soon as frame returns, the projection matrix
is changed in the left and right clipping planes.
Since the redraw is called as a consequence of a resize event,
and the viewport is updated consequently, is there
a relationship between the projection matrix and the viewport?
In OpenGL there isn't any relationship, I mean that I can
set the viewport independently of the projection matrix.
But it seems that OSG doesn't want to distort the
original scene. If so, is it the default behavior?
How can I disable such a behavior?
Thanks,
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
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.4/1789 - Release Date: 11/18/2008
8:59 PM
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] material properties and primary color in OSG ver 1.3
Hi All. I'm using an old version of OSG, ver 1.3. I noticed a very strange behavior. I set the material props (actually just the DIFFUSE component) in the state set of a geode. But, by mistake, I had also disabled lighting. So, I would have expected that the object was drawn using the default primary color of OpenGL, but it wasn't. The object was drawn using as the primary color what I set as the diffuse component of the material props. How is it possible? Obviously if I did it using pure OpenGL, when lighting is disabled it always uses the primary color. Thanks, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] material properties and primary color in OSG ver 1.3
and if I get the primary color and the state of lighting, inside the draw function of the drawable, these are the results: primary color = what I set as the diffuse material props; LIGHTING is OFF. It seems a contradiction, since the primary color should be used if the LIGHTING is disabled, and the material props only if the LIGHTING is enabled. Am I wrong? Thanks From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gianluca Natale Sent: martedì 18 novembre 2008 11.27 To: Osg Users Subject: [osg-users] material properties and primary color in OSG ver 1.3 Hi All. Im using an old version of OSG, ver 1.3. I noticed a very strange behavior. I set the material props (actually just the DIFFUSE component) in the state set of a geode. But, by mistake, I had also disabled lighting. So, I would have expected that the object was drawn using the default primary color of OpenGL, but it wasnt. The object was drawn using as the primary color what I set as the diffuse component of the material props. How is it possible? Obviously if I did it using pure OpenGL, when lighting is disabled it always uses the primary color. Thanks, Gianluca Natale No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.4/1789 - Release Date: 11/14/2008 7:32 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] need to port an application from OSG v1.2 (OSG::Producer based) to OSG 2.0 (OsgViewer based)
Is there any tutorial that explains how to do that without any pain? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] asymmetrical viewing volume
Hi all. I need to set a projection matrix for an asymmetrical viewing volume. Settings for the scene view associated with the camera are: osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES. I tried with camera.SetProjectionMatrixAsFrustum(.), but it resets left and right clipping planes to a symmetrical frustum, when I call camera.frame(.). Is it because the near and far clipping planes need to be updated during redraw? Is there a way to prevent this behavior, having only near and far clipping planes updated? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] draw and projection matrix
Thank you so much. I'll try. Gianluca. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: mercoledì 22 ottobre 2008 10.32 To: OpenSceneGraph Users Subject: Re: [osg-users] draw and projection matrix Hi Gianluca, The OSG by default recomputes the near and far distances during the cull traversal to optimize the precision of depth buffer/avoid clipping out of far objects/near objects. While this is a useful facility most of the time, if you are relying upon specifc values of near/far that you have set up in your app then you can see problems. The way to disable this recompute of the near/far is to do in your osgProducer based app: // get the SceneView from the SceneHandler then... sceneView-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR) ; Or if you upgrade to a OSG-2.x series of the OSG and use osgViewer you'd do: viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_ NEAR_FAR); Robert. On Wed, Oct 22, 2008 at 9:02 AM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All. I have to debug an application based upon OSG (actually I'm still a novice of OSG). I found this strange behavior, in this fragment of code: Let's define: --- osgProducer::OsgSceneHandler * sh = new osgProducer::OsgSceneHandler; osg::ref_ptrosgUtil::SceneView sceneView = sh-getSceneView(); Producer::ref_ptrProducer::Camera camera; camera-setSceneHandler(sh); . Then: --- double fovy, aspectRatio, zNear, zFar; sceneView-getProjectionMatrixAsPerspective(fovy,aspectRatio,zNear,zFar); camera-frame(true); sceneView-getProjectionMatrixAsPerspective(fovy,aspectRatio,zNear,zFar); -- Well, I get different zNear, zFar before and after the call to camera-frame. How is it possible? Is there a setting in SceneView that allows to update the projection matrix during draw traversal, using the bounding sphere of the whole model? Thank you. Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1733 - Release Date: 10/19/2008 6:02 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bounding box issue
Thank you Robert, it does work! Gianluca P.S.=I will pass to newer OSG version ASAP. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: giovedì 25 settembre 2008 13.11 To: OpenSceneGraph Users Subject: Re: [osg-users] bounding box issue Hi Gianluca, I don't recall the exact details, but you'll need to get the OsgSceneHandler form the Producer::Camera, then from this get it's osgUtil::SceneView and then CullingMode on this SceneView. It's a bit convoluted but it's possible. You other route would be to just port to osgViewer, there are other examples like this one that you'll find more straight forward when using osgViewer than Producer as osgViewer doesn't need an abstraction layer ontop the OSG to integrate it - it's all native OSG code. Robert. On Thu, Sep 25, 2008 at 10:18 AM, Gianluca Natale [EMAIL PROTECTED] wrote: Actually I'm using the old Producer::camera, and I cannot find such a way to disable the SMALL FEATURE CULLING. Is there a way to do that with Producer, or the default cannot be changed at all! Thanks, Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gianluca Natale Sent: mercoledì 24 settembre 2008 16.28 To: 'OpenSceneGraph Users' Subject: Re: [osg-users] bounding box issue Thank you Robert, I will try. Gianluca. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: mercoledì 24 settembre 2008 16.02 To: OpenSceneGraph Users Subject: Re: [osg-users] bounding box issue Hi Gianluca, The OSG by defaults has small feature culling enabled, try disabling this: viewer.getCamera()-setCullingMode( viewer.getCamera()-getCullingMode() ~ osg::CullSettings::SMALL_FEATURE_CULLING); Robert. On Wed, Sep 24, 2008 at 2:52 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.1/1687 - Release Date: 9/23/2008 6:32 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.1/1687 - Release Date: 9/23/2008 6:32 PM ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.2/1689 - Release Date: 9/24/2008 6:51 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bounding box issue
Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bounding box issue
Thank you Robert, I will try. Gianluca. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: mercoledì 24 settembre 2008 16.02 To: OpenSceneGraph Users Subject: Re: [osg-users] bounding box issue Hi Gianluca, The OSG by defaults has small feature culling enabled, try disabling this: viewer.getCamera()-setCullingMode( viewer.getCamera()-getCullingMode() ~ osg::CullSettings::SMALL_FEATURE_CULLING); Robert. On Wed, Sep 24, 2008 at 2:52 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All. I have this very strange issue related to bounding boxes. I derived a class MyDrawable, from osg::Drawable. And I'm trying to make some experiments with it. I have a model containing two objects: - a cylinder, made by a bunch of points, defined as an instance of MyDrawable; - an object made by just one vertex, defined as an instance of MyDrawable. When I try to draw the model, just the cylinder is shown. I implemented the method GetBoundingBox()in MyDrawable. So, obviously, it returns a void BB for the second drawable. Does it depend on the void BB? I mean, does OSG check the dimension of the BB of an object before drawing it, and discard the object if its BB, in screen coords, becomes less than some threshold (expressed in pixels)? I suspect this behavior because, if I try to artificially enlarge the BB of the second drawable, once I zoom in I can see it on the screen. And disappear when I zoom out again. Thank you in advance. Regards, Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.1/1687 - Release Date: 9/23/2008 6:32 PM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] is there a way to select an invisible object?
Hi All! I'm using OSG to implement my own scene graph to draw my scene on the screen. Sometimes I would need to select an object even if it is invisible (I mean that the switch node it is attached to is set to off). But this seems impossible to me, because I don't want to draw the object, so I have to disable that switch. On the other hand, if I disable the switch, how can I select it (with the standard OpenGL picking mechanism)? Do I have to duplicate the scene graph, one for selection and the other for drawing? Thank you in advance for your suggestions. Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] is there a way to select an invisible object?
Hi Robert. What I mean is: I have a scene made of 3 spheres, each attached under a different switch node. The first two spheres are visible (their switches are turned on), while the third is not (so its switch is turned off). I would like to select also the third sphere (imagine for example that I want the third sphere to be visible only when the mouse is over it), even when it is invisible. Thanks, Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: lunedì 7 luglio 2008 11.35 To: OpenSceneGraph Users Subject: Re: [osg-users] is there a way to select an invisible object? Hi Gianluca, What do you mean by select and object? What type of object? Robert. On Mon, Jul 7, 2008 at 10:24 AM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All! I'm using OSG to implement my own scene graph to draw my scene on the screen. Sometimes I would need to select an object even if it is invisible (I mean that the switch node it is attached to is set to off). But this seems impossible to me, because I don't want to draw the object, so I have to disable that switch. On the other hand, if I disable the switch, how can I select it (with the standard OpenGL picking mechanism)? Do I have to duplicate the scene graph, one for selection and the other for drawing? Thank you in advance for your suggestions. Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.4.5/1536 - Release Date: 7/5/2008 10:15 AM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] is there a way to select an invisible object?
I'll try. Thank you. Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: lunedì 7 luglio 2008 15.54 To: OpenSceneGraph Users Subject: Re: [osg-users] is there a way to select an invisible object? Hi Gianulca, If you want your subgaphs to respond to different traversals in different ways then it's best to use node-setNodeMask(mask) and nodevisitor-setTraversalMask(mask) in combination. In your case you could set your invsible subgraphs to 0x1, and pick these out with an intersect visitor a mask of 0x, and a cull mask of 0x2. Robert. On Mon, Jul 7, 2008 at 1:22 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi Robert. What I mean is: I have a scene made of 3 spheres, each attached under a different switch node. The first two spheres are visible (their switches are turned on), while the third is not (so its switch is turned off). I would like to select also the third sphere (imagine for example that I want the third sphere to be visible only when the mouse is over it), even when it is invisible. Thanks, Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: lunedì 7 luglio 2008 11.35 To: OpenSceneGraph Users Subject: Re: [osg-users] is there a way to select an invisible object? Hi Gianluca, What do you mean by select and object? What type of object? Robert. On Mon, Jul 7, 2008 at 10:24 AM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi All! I'm using OSG to implement my own scene graph to draw my scene on the screen. Sometimes I would need to select an object even if it is invisible (I mean that the switch node it is attached to is set to off). But this seems impossible to me, because I don't want to draw the object, so I have to disable that switch. On the other hand, if I disable the switch, how can I select it (with the standard OpenGL picking mechanism)? Do I have to duplicate the scene graph, one for selection and the other for drawing? Thank you in advance for your suggestions. Gianluca Natale ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.4.5/1536 - Release Date: 7/5/2008 10:15 AM ___ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.4.5/1536 - Release Date: 7/5/2008 10:15 AM ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] antialiased lines
Hi OSG developers! I'm trying to draw antialiased lines with OSG ver .2.2, but I'm having problems. This is my code: osg::ref_ptrosg::Hint antialiasHint = new osg::Hint(GL_LINE_SMOOTH_HINT, GL_NICEST); StateSet-setAttributeAndModes(antialiasHint.get(), osg::StateAttribute::ON); Obviously I've also set a blending function. Is there something wrong in my code, or a well-known bug in OSG 2.2? Note that in OSG ver. 1.2 I obtained the same effect just by calling: StateSet-setMode(GL_LINE_SMOOTH, osg::StateAttribute::ON); This still does work in OSG ver 2.2, but I wanted to update my code to the correct use of glHint under OSG. Thank you in advance. Gianluca Natale ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] antialiased lines
Thank you. So, the filter specified via osg::Hint can be set only from OSG ver. 2.0, isn't it? Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, April 24, 2008 12:35 PM To: OpenSceneGraph Users Subject: Re: [osg-users] antialiased lines Hi Gianluca, The OSG just passes state along to the OpenGL, the glHint support is just another means to setting OpenGL state. How the OpenGL driver responds to the that State is down to the driver/hardware. In the case of line smoothing I believe that you still need to enable GL_LINE_SMOOTH even when using the hints, the mode simply enables the use of filtering that the hints specify. Robert. On Thu, Apr 24, 2008 at 11:20 AM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi OSG developers! I'm trying to draw antialiased lines with OSG ver .2.2, but I'm having problems. This is my code: osg::ref_ptrosg::Hint antialiasHint = new osg::Hint(GL_LINE_SMOOTH_HINT, GL_NICEST); StateSet-setAttributeAndModes(antialiasHint.get(), osg::StateAttribute::ON); Obviously I've also set a blending function. Is there something wrong in my code, or a well-known bug in OSG 2.2? Note that in OSG ver. 1.2 I obtained the same effect just by calling: StateSet-setMode(GL_LINE_SMOOTH, osg::StateAttribute::ON); This still does work in OSG ver 2.2, but I wanted to update my code to the correct use of glHint under OSG. Thank you in advance. Gianluca Natale ___ 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 -- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.4/1394 - Release Date: 23/04/2008 19.16 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] polytopeIntersector
Hi, I went deeply in debug into my code, and I discovered that the problem is in OSG v.2.2. Actually it returns the object with the shortest node path among those in the intersection vector. Was it a known bug? Thanks in advance Gianluca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, January 10, 2008 9:05 PM To: OpenSceneGraph Users Subject: Re: [osg-users] polytopeIntersector HI Gianluca, In the 2.3.x dev release and SVN of the OSG there are improvements to the PolytopeIntersector that might help you so it'd be worth trying out over using 2.2 Robert. On Jan 10, 2008 5:46 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi all! I'm trying to use a osgUtil::PolytopeIntersector to find the closest object in my 3D scene graph (with OSG ver.2.2). I read on the OSG QSG that it should return the closest object as the first in the list of intersections. But it is not like that! I mean that the array of intersections correctly contains all of the objects hit by the intersection volume, but the first of those is not necessary the closest. BTW, it seems to be the object with the shortest node path. Might it be? Any idea of my mistake? Thank you in advance. Gianluca P.S.=attached is the source file (look into the class PickHandler, in the method pick; first I tried getting directly the first intersection in the list, picker-getFirstIntersection(); then I tried to sort the intersection on my own. But I pick always the background rectangle!) ___ 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] changing colors of a geode
Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] changing colors of a geode
Thank you very much, that should solve my problem. This way I need to duplicate just osg::Geometry objects, but they still share VertexArrays, NormalsArrays, etc. via ref_ptr. So I'm also sure that they are destroyed only when the last geometry is destroyed. Thank you Gianluca Natale _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, December 18, 2007 3:34 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] changing colors of a geode The best way to do this in OSG is to create two Geometry objects. Make them both share the same VertexArrays, NormalArray, TexCoordArray (if you're texture mapping), and PrimitiveSets. Then give each of them different color arrays and specify a color binding of BIND_OVERALL. Primary color, normal, texcoord, edge flag, etc., are not StateAttributes in OSG. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gianluca Natale Sent: Tuesday, December 18, 2007 7:20 AM To: Osg Users Subject: [osg-users] changing colors of a geode Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
