[osg-users] osgViewer::GraphicsWindowX11 vs osgViewer::GraphicsWindowWin32 question
Guys, I am having some trouble with differences between Windows and X11 implementations. It seems that I can call realize() and makeCurrent() successfully on Windows before the osgViewer is realized ( to initialize application plugins that use OpenGL ). However, it also seems like that isn't possible to do under the X11 implementation. Is this true? Do I have to wait until the osgViewer is realized before makeCurrent will succeed? Thanks again, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowX11 vsosgViewer::GraphicsWindowWin32 question
Robert, I create my own window using XCreateWindow, and assign visuals, pixformats, etc. Then I construct a GraphicsWindowX11::WindowData and attach it to some GraphicsContext::Traits and create a new graphics context. I can realize the context, but makeCurrent keeps failing. Is there anything that you notice that I might be doing wrong? Thanks, John -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, January 12, 2009 11:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer::GraphicsWindowX11 vsosgViewer::GraphicsWindowWin32 question Hi John, You should be able to do window-realize(); window-makeCurrent() under X11 using GraphicsWindowX11, without needing to run osgViewer::Viewer::realize(). The Viewer::realize() just calls these methods itself, so they do work. Perhaps there is something specific about your usage model that is breaking things. Robert. On Mon, Jan 12, 2009 at 4:23 PM, Argentieri, John-P63223 john.argenti...@gdc4s.com wrote: Guys, I am having some trouble with differences between Windows and X11 implementations. It seems that I can call realize() and makeCurrent() successfully on Windows before the osgViewer is realized ( to initialize application plugins that use OpenGL ). However, it also seems like that isn't possible to do under the X11 implementation. Is this true? Do I have to wait until the osgViewer is realized before makeCurrent will succeed? Thanks again, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GraphicsWindowX11 : Realized and Unmapped?
Hello osg enthusiasts! I've been having trouble trying to create a GraphicsWindowX11 context that is both realized and unmapped. Does anyone know if this is currently possible in any osg version? If not, is it expected for 2.8? Thanks again! Your friend, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Windows wglShareLists and osg::GraphicsContext Sharing
Guys, wglShareLists requires that the context which IS GOING TO SHARE has no display lists existing. NOTE: See the italicized hglrc2 at this link: http://msdn.microsoft.com/en-us/library/ms537565(VS.85).aspx This creates a massive problem if we start with one window and wish to create more (sharing) later. I don't think this is an issue on other platforms. Does OSG watch for this, or do I have to code around the issue myself in my application? The examples which share contexts are great for learning, but they also neatly avoid this real-world problem by creating their windows at startup. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Depth Sorting
Folks, I want a group of objects to have GL_DEPTH_TEST disabled, BUT I want them drawn in order from farthest to nearest. I tried putting them in a SORT_BACK_TO_FRONT RenderBin, but it's not working as planned. Do I need a custom osg::Depth? I want these objects to be drawn on top of EVERYTHING except for objects of the same type that are closer to the camera. Thanks for any ideas! John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth Sorting
Sorry for the double post. It seems that the osgText::Text is the only object that refuses to be occluded. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Argentieri, John-P63223 Sent: Thursday, December 18, 2008 3:37 PM To: osg-us...@openscenegraph.org Subject: [osg-users] Depth Sorting Folks, I want a group of objects to have GL_DEPTH_TEST disabled, BUT I want them drawn in order from farthest to nearest. I tried putting them in a SORT_BACK_TO_FRONT RenderBin, but it's not working as planned. Do I need a custom osg::Depth? I want these objects to be drawn on top of EVERYTHING except for objects of the same type that are closer to the camera. Thanks for any ideas! John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems john.argenti...@gdc4s.com This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture coordinates question
Gentlemen, Is there a way to force vertex B to have a different texture coordinate in each of triangle ABC and triangle BCD? Texture coordinate indices? I don't understand how those are applied. If the binding is per_primitive, will each of my triangles be textured by a single pixel? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?
Paul, Sure enough, removing the PolygonOffset attribute and Polygon Offset Fill mode permitted me to write a valid OpenFlight file. Thank you for providing me with enough information to succeed at this task!!! I've caught up on some serious lost sleep! Just so you are aware, I think there are problems with not just the Subfaces, but with external references also. I'm not sure, but I thought I witnessed the FLT writer automatically making external references if a subtree of what it's writing was read in from a FLT. I succeeded only after converting all of my internal models to .osg format, then writing the master file in FLT format. Hope that is useful to you! Your pal, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, November 12, 2008 1:14 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? Paul, I tried to do setAttribute( m_pPolygonOffset, osg::StateAttribute::OFF ); but I suppose your code may still be able to detect that the attribute is present. I forgot there was a removeAttribute. Do you think it's worth a shot for me to code it up and try again? Thanks! John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, November 12, 2008 1:08 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? John -- Use of polygon offset controls whether the exporter uses subfaces or not. It might be the case that the subface code has some kind of problem with texture mapping. One thing you can try is to go into expGeometryRecords.cpp and disable use of subfaces by commenting out the SubfaceHelper instances at lines 934 and 1023. This will cause incorrect rendering of coplanar polygons, of course, but if it changes the behavior of your texture mapping issue, then this is a good indication of where the problem lies. Let me know how it goes. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 11:35 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? Paul, Attached is an example of a bug I found in the FLT writer. If the GL_POLYGON_OFFSET remains inside of extref.osg, then converting it to FLT using osgconv will cause the texture of the external reference to disappear. If the GL_POLYGON_OFFSET is removed from extref.osg, then extref.osg is converted to FLT using osgconv, the texture on the external reference remains. Thanks, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Guys, Has anyone used the ProxyNode in this way, in OpenFlight files? My primary file and my externally referenced file are both OpenFlight files. The externally referenced file gets loaded, but the texture is incorrect. The texture applied to the model, in my case, is the only one that is used internally in the primary OpenFlight file. For example, my terrain surface is internal and textured as grass. My externally reference tree models are shaped like trees, but also textured in grass. I've tried moving the tree's texture files around to be sure that it wasn't a path issue. It didn't work. Is there anyone that can help me to resolve the issues I am having? All I want to do is write an OpenFlight file that contains several clones of another OpenFlight file. The straightforward approach breaks -- not for the current OSG loader, but for other loaders that expect node names to be unique. Your friend, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 1:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter writes an external reference record when it encounters a ProxyNode. The importer should do the inverse operation. I searched for the error text you mentioned, but could not find any code in OSG that displays that error, so I can't really help you with that. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT
Re: [osg-users] Performance expectations
Are you working for those cyborgs with their faster-than-human robot eyes again? Trying to turn GPU's into incendiary agents? But seriously, if it doesn't have to be rendered in real-time, you can use libavcodec to write OSG output to a movie. I'm not sure exactly what frame rates it supports, but you might be able to record a movie at low Hz and play it back much much faster. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, November 13, 2008 12:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Performance expectations Hi Ed, Could you explain why you need 1000 Hz? I don't know of any display systems that work this fast, 120 Hz is typically the high end in refresh rates of monitors/projectors. Robert. On Thu, Nov 13, 2008 at 4:50 PM, Ed [EMAIL PROTECTED] wrote: As noted in past posts, I am working on porting my native GL app to OSG... But before I get to far down this path, I thought it would be a good idea to ask some questions concerning performance. I have noticed in past postings that OSG can handle thousands of objects, millions of polys and still hold a solid 60Hz on a modern machine. My requirement is to be able to render in excess of 1000 Hz. I have achieved more than double this with somewhat simple scenes in my current app. Am I expecting too much from OSG? Ed ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?
Paul, I tried to do setAttribute( m_pPolygonOffset, osg::StateAttribute::OFF ); but I suppose your code may still be able to detect that the attribute is present. I forgot there was a removeAttribute. Do you think it's worth a shot for me to code it up and try again? Thanks! John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, November 12, 2008 1:08 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? John -- Use of polygon offset controls whether the exporter uses subfaces or not. It might be the case that the subface code has some kind of problem with texture mapping. One thing you can try is to go into expGeometryRecords.cpp and disable use of subfaces by commenting out the SubfaceHelper instances at lines 934 and 1023. This will cause incorrect rendering of coplanar polygons, of course, but if it changes the behavior of your texture mapping issue, then this is a good indication of where the problem lies. Let me know how it goes. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 11:35 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? Paul, Attached is an example of a bug I found in the FLT writer. If the GL_POLYGON_OFFSET remains inside of extref.osg, then converting it to FLT using osgconv will cause the texture of the external reference to disappear. If the GL_POLYGON_OFFSET is removed from extref.osg, then extref.osg is converted to FLT using osgconv, the texture on the external reference remains. Thanks, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Guys, Has anyone used the ProxyNode in this way, in OpenFlight files? My primary file and my externally referenced file are both OpenFlight files. The externally referenced file gets loaded, but the texture is incorrect. The texture applied to the model, in my case, is the only one that is used internally in the primary OpenFlight file. For example, my terrain surface is internal and textured as grass. My externally reference tree models are shaped like trees, but also textured in grass. I've tried moving the tree's texture files around to be sure that it wasn't a path issue. It didn't work. Is there anyone that can help me to resolve the issues I am having? All I want to do is write an OpenFlight file that contains several clones of another OpenFlight file. The straightforward approach breaks -- not for the current OSG loader, but for other loaders that expect node names to be unique. Your friend, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 1:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter writes an external reference record when it encounters a ProxyNode. The importer should do the inverse operation. I searched for the error text you mentioned, but could not find any code in OSG that displays that error, so I can't really help you with that. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Paul, Is there a way that I can place multiple instances of an external .flt file into another .flt file? I'm trying to use ProxyNode, but still getting these errors: Non primary record found as child. op=19 Non primary record found as child. op=19 Non primary record found as child. op=20 Non primary record found as child. op=20 Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 12:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names
Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?
Paul, I'm not sure what the problem is, but I can see that when I create a scene graph with ProxyNodes in memory, and write that scene graph to an OpenFlight file using 2.6.1, the external references are somhow broken with respect to textures. If I convert that to an .osg and back to .flt using osgconv from the command line, it seems to work in the 2.6.1 reader, all the way down to OSG 1.2's primary reader when osgdb_flt.dll was mostly phased out. However, none of the OpenFlight files generated by 2.6.1 can be opened using the FLT reader in OSG 1.0 / osgdb_flt.dll. Do you have any idea why that is? I get a single group node, so nothing even gets drawn in this case. Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, November 11, 2008 4:32 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? Thanks, John. If you fix this, please post the fix to osg-submissions. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 11:35 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names? Paul, Attached is an example of a bug I found in the FLT writer. If the GL_POLYGON_OFFSET remains inside of extref.osg, then converting it to FLT using osgconv will cause the texture of the external reference to disappear. If the GL_POLYGON_OFFSET is removed from extref.osg, then extref.osg is converted to FLT using osgconv, the texture on the external reference remains. Thanks, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, November 11, 2008 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Guys, Has anyone used the ProxyNode in this way, in OpenFlight files? My primary file and my externally referenced file are both OpenFlight files. The externally referenced file gets loaded, but the texture is incorrect. The texture applied to the model, in my case, is the only one that is used internally in the primary OpenFlight file. For example, my terrain surface is internal and textured as grass. My externally reference tree models are shaped like trees, but also textured in grass. I've tried moving the tree's texture files around to be sure that it wasn't a path issue. It didn't work. Is there anyone that can help me to resolve the issues I am having? All I want to do is write an OpenFlight file that contains several clones of another OpenFlight file. The straightforward approach breaks -- not for the current OSG loader, but for other loaders that expect node names to be unique. Your friend, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 1:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter writes an external reference record when it encounters a ProxyNode. The importer should do the inverse operation. I searched for the error text you mentioned, but could not find any code in OSG that displays that error, so I can't really help you with that. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Paul, Is there a way that I can place multiple instances of an external .flt file into another .flt file? I'm trying to use ProxyNode, but still getting these errors: Non primary record found as child. op=19 Non primary record found as child. op=19 Non primary record found as child. op=20 Non primary record found as child. op=20 Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 12:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter dumps the Node name to the FLT record name, just
Re: [osg-users] FLT Writer Duplicate Node Names?
Guys, Has anyone used the ProxyNode in this way, in OpenFlight files? My primary file and my externally referenced file are both OpenFlight files. The externally referenced file gets loaded, but the texture is incorrect. The texture applied to the model, in my case, is the only one that is used internally in the primary OpenFlight file. For example, my terrain surface is internal and textured as grass. My externally reference tree models are shaped like trees, but also textured in grass. I've tried moving the tree's texture files around to be sure that it wasn't a path issue. It didn't work. Is there anyone that can help me to resolve the issues I am having? All I want to do is write an OpenFlight file that contains several clones of another OpenFlight file. The straightforward approach breaks -- not for the current OSG loader, but for other loaders that expect node names to be unique. Your friend, John Argentieri From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 1:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter writes an external reference record when it encounters a ProxyNode. The importer should do the inverse operation. I searched for the error text you mentioned, but could not find any code in OSG that displays that error, so I can't really help you with that. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT Writer Duplicate Node Names? Paul, Is there a way that I can place multiple instances of an external .flt file into another .flt file? I'm trying to use ProxyNode, but still getting these errors: Non primary record found as child. op=19 Non primary record found as child. op=19 Non primary record found as child. op=20 Non primary record found as child. op=20 Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 12:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter dumps the Node name to the FLT record name, just as the importer does the inverse operation. I don't believe there is any code to check for and avoid duplicate node names. I'd think it would be up to the application to specify unique Node names, as the exporter has no other way to know what text should be written to the FLT record name. I can see how it might be useful to have a I don't care what you name it, just make sure it's unique mode. Currently, this doesn't exist. You are welcome to add it. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 8:41 AM To: [EMAIL PROTECTED] Subject: [osg-users] FLT Writer Duplicate Node Names? Hello all. Does the FLT writer create duplicate node names for nodes with multiple transforms as parents? We're having trouble sharing a single model inside of multiple transforms scattered about. Some older OpenFlight software we are interfacing to does not like this. Any thoughts guys? Thank you, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FLT Writer Duplicate Node Names?
Hello all. Does the FLT writer create duplicate node names for nodes with multiple transforms as parents? We're having trouble sharing a single model inside of multiple transforms scattered about. Some older OpenFlight software we are interfacing to does not like this. Any thoughts guys? Thank you, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT Writer Duplicate Node Names?
Paul, Is there a way that I can place multiple instances of an external .flt file into another .flt file? I'm trying to use ProxyNode, but still getting these errors: Non primary record found as child. op=19 Non primary record found as child. op=19 Non primary record found as child. op=20 Non primary record found as child. op=20 Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, November 07, 2008 12:51 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT Writer Duplicate Node Names? The exporter dumps the Node name to the FLT record name, just as the importer does the inverse operation. I don't believe there is any code to check for and avoid duplicate node names. I'd think it would be up to the application to specify unique Node names, as the exporter has no other way to know what text should be written to the FLT record name. I can see how it might be useful to have a I don't care what you name it, just make sure it's unique mode. Currently, this doesn't exist. You are welcome to add it. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, November 07, 2008 8:41 AM To: [EMAIL PROTECTED] Subject: [osg-users] FLT Writer Duplicate Node Names? Hello all. Does the FLT writer create duplicate node names for nodes with multiple transforms as parents? We're having trouble sharing a single model inside of multiple transforms scattered about. Some older OpenFlight software we are interfacing to does not like this. Any thoughts guys? Thank you, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Normal bindings and triangle strips
Greetings All, Is it possible to define a normal for every triangle without using primitive type TRIANGLES? For instance, if I am using TRIANGLE_STRIP, what is the effect of setting normals with BIND_PER_PRIMITIVE? And why does BIND_PER_VERTEX seem so wrong on a triangle strip? If the triangle strip faces are not radically different I guess it works ok. But it seems impossible to declare normal vectors precisely when using triangle strips. Am I missing something obvious? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Normal bindings and triangle strips
Paul, I'm just trying to learn how it works. If the way you've described it is in fact how I can give each triangle its own normal in a triangle strip, then I thank you my friend. I hope that this is how it works in OSG when using tri strip and bind per primitive. What about bind per vertex and tri strips? Can a vertex have more than one normal in this case as well? Thanks pal, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, October 08, 2008 3:11 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Normal bindings and triangle strips Hi John -- I think normals with BIND_PER_PRIMITIVE on a N-triangle strip would mean you have N-2 normals. As we discussed previously, you'll use the OpenGL slow path (albeit stored in a display list) so the effective OpenGL calls would be: glVertex3f glVertex3f glNormal3f // normal for first triangle glVertex3f glNormal3f // normal for second triangle glVertex3f glNormal3f // normal for third triangle glVertex3f ...etc... This should result in a typical faceted appearance (with glShadeModel set to GL_FLAT). However, if you want smooth shading, you'll want to use BIND_PER_VERTEX of course. Which brings us to the next topic... I'm not sure why you are having problems with BIND_PER_VERTEX in a tri strip. It works just like BIND_PER_VERTEX with any other primitive type. Perhaps you could provide more information about the problem you're encountering. You say it works OK if the faces aren't radically different but I'm not sure why you'd use BIND_PER_VERTEX if you were not trying to get a smooth-shaded result. What type of surface are you trying to render, anyway? Do you encounter the same issue in a vanilla OpenGL app? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, October 08, 2008 12:34 PM To: [EMAIL PROTECTED] Subject: [osg-users] Normal bindings and triangle strips Greetings All, Is it possible to define a normal for every triangle without using primitive type TRIANGLES? For instance, if I am using TRIANGLE_STRIP, what is the effect of setting normals with BIND_PER_PRIMITIVE? And why does BIND_PER_VERTEX seem so wrong on a triangle strip? If the triangle strip faces are not radically different I guess it works ok. But it seems impossible to declare normal vectors precisely when using triangle strips. Am I missing something obvious? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 2.6.1?
Hey guys. I thought 2.6.1 was due out yesterday. I haven't seen any news about it. Is it available to us yet? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph 2.6.1 released
Paul, Thanks again for your efforts! John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, October 02, 2008 12:37 PM To: 'OpenSceneGraph Users' Subject: [osg-users] OpenSceneGraph 2.6.1 released Hi all -- I've tagged the OSG 2.6.1 release. Here is the svn URL: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph -2.6.1 The release contains some bug fixes made to OSG after the 2.6 release, including changes to the CMake system, osgSim::OverlayNode, osg:;OcclusionQueryNode, and the OpenFlight plugin. See the ChangeLog for a full list of the changes in this release. Robert, I'm not able to update the downloads page on the wiki, so can't place the URL there or upload a zip of the source. If you can give me login access, I'll take care of that. Or if you want to maintain control of that page, that's OK by me. Your call. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NodeVisitors and Synchronization
Folks, Once I've called Node::accept(NodeVisitor), does osgViewer::Viewer wait until the update traversal to let the NodeVisitor perform it's traversal? If I am in the GUI thread when I call accept(), does NodeVisitor::apply happen in the GUI thread? Or does it happen in an osgViewer thread based on the threading model? I'm trying to make sure my NodeVisitor's have done their work before reacting to osg::Camera's PostDraw callback. I am considering having nodes accept all visitors, waiting for a single update callback, then registering for the osg::Camera's postdraw callback. Do you guys think that will solve my synchronization problem? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeVisitors and Synchronization
Let's forget semantics then. If I run the following code: Node.accept( NodeVisitor ); Viewer.frame(); What thread calls the NodeVisitor's various accept() methods? Or at least what stage of execution? Does the accept() call block until the NodeVisitor traverses the scene graph, or does it happen in the Viewer's update traversal? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Tuesday, September 30, 2008 2:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] NodeVisitors and Synchronization Hi You should not be doing this from the GUI thread, you should be doing this typically in the OSG app thread, so you need to have some form of messaging between the GUI and APP threads, such that you can kick off your traversals at the appropriate time Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, September 30, 2008 2:09 PM To: [EMAIL PROTECTED] Subject: [osg-users] NodeVisitors and Synchronization Folks, Once I've called Node::accept(NodeVisitor), does osgViewer::Viewer wait until the update traversal to let the NodeVisitor perform it's traversal? If I am in the GUI thread when I call accept(), does NodeVisitor::apply happen in the GUI thread? Or does it happen in an osgViewer thread based on the threading model? I'm trying to make sure my NodeVisitor's have done their work before reacting to osg::Camera's PostDraw callback. I am considering having nodes accept all visitors, waiting for a single update callback, then registering for the osg::Camera's postdraw callback. Do you guys think that will solve my synchronization problem? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NodeVisitors and Synchronization
Thanks, Glenn. I must have made some other kind of mistake then :( From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Waldron Sent: Tuesday, September 30, 2008 4:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] NodeVisitors and Synchronization John, Node::accept is completely synchronous. When you call accept() it will traverse immediately and return. Glenn On Tue, Sep 30, 2008 at 4:26 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Let's forget semantics then. If I run the following code: Node.accept( NodeVisitor ); Viewer.frame(); What thread calls the NodeVisitor's various accept() methods? Or at least what stage of execution? Does the accept() call block until the NodeVisitor traverses the scene graph, or does it happen in the Viewer's update traversal? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomlinson, Gordon Sent: Tuesday, September 30, 2008 2:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] NodeVisitors and Synchronization Hi You should not be doing this from the GUI thread, you should be doing this typically in the OSG app thread, so you need to have some form of messaging between the GUI and APP threads, such that you can kick off your traversals at the appropriate time Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, September 30, 2008 2:09 PM To: [EMAIL PROTECTED] Subject: [osg-users] NodeVisitors and Synchronization Folks, Once I've called Node::accept(NodeVisitor), does osgViewer::Viewer wait until the update traversal to let the NodeVisitor perform it's traversal? If I am in the GUI thread when I call accept(), does NodeVisitor::apply happen in the GUI thread? Or does it happen in an osgViewer thread based on the threading model? I'm trying to make sure my NodeVisitor's have done their work before reacting to osg::Camera's PostDraw callback. I am considering having nodes accept all visitors, waiting for a single update callback, then registering for the osg::Camera's postdraw callback. Do you guys think that will solve my synchronization problem? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6.1 RC1 tag created
Paul, Will this release include the FLT Export fix for PositionAttitudeTransforms AND the FLT ExportOptions texture path stripping option initialization in the constructor with ReaderWriterOptions passed in? Thanks, John Argentieri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, September 26, 2008 1:53 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] 2.6.1 RC1 tag created Kubuntu 7.10, 64bit, 8800GTS, Quad core Intel. gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Compiles cleanly and examples run fine ;-) Excellent, thanks. I've tested in WinXP w/ VS8, and OSX w/ gcc 4.0.1, so the major platforms are covered. I'll aim for an Oct 1 official release. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6.1 RC1 tag created
Thanks! to Paul and the rest of the OSG devs for maintaining OSG as a great package. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, September 29, 2008 1:49 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] 2.6.1 RC1 tag created Paul, Will this release include the FLT Export fix for PositionAttitudeTransforms AND the FLT ExportOptions texture path stripping option initialization in the constructor with ReaderWriterOptions passed in? Yes, both of those are included. The other FLT fix we discussed (the BIND_PER_PRIMITIVE fix) will have to wait for a future release, such as 2.8. I hope to get around to fixing that sometime in the next couple months. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about plane intersections
Gentlemen, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. Your advice is greatly appreciated. Thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about plane intersections
Both very nice ideas. Thanks guys! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Waldron Sent: Wednesday, September 24, 2008 1:25 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Question about plane intersections On Wed, Sep 24, 2008 at 1:02 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Gentlemen, Can anyone point me to something that would be useful in OSG for solving the problem of making a set of contour lines similar to those seen on maps? I'd like to provide osg with a plane and get the shape created by the intersection with the plane. Your advice is greatly appreciated. Thanks, John Argentieri Have you looked into osgUtil::PlaneIntersector? It will return the results of an intersection at a set of polylines. You can then create osg::Geometry from the polylines to visualize it. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp
J-S, OK. Here it is. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, September 16, 2008 9:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp Hi John, Someone, please copy and paste the _stripTextureFilePath( false ) line into the second constructor and add a comma after _lightingDefault( true ). Don't forget the comma :) You could have just sent the whole modified file to osg-submissions... That way no one would have to copy and paste anything, and there would be no chance to make the mistake of forgetting the comma... And then you would be counted among the Anyone else who likes to fix OSG :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ExportOptions.cpp Description: ExportOptions.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Paul, Another FLT Export BUG.
Paul,
We are using osgUtil::DelaunayTriangulator in a real-time package from
which we'd like to export FLT.
I was able to use the workaround we discussed for geometry created by
osgUtil::DelaunayConstraint.
However, the DelaunayTriangulator itself uses BIND_PER_PRIMITIVE as a
means to bind normals to its output geometry. I could take the output
normal array and generate a new one by iterating through all the
vertices, but remember I said real-time. If I change a simple road
constraint, then no one will notice me generating a normal array. But it
I regenerate the normal array for an entire terrain on every update in a
real-time application, the user is definitely going to notice the
difference.
What I'm getting at is that it would really be nice if the FLT writer
could export the output of osgUtil::DelaunayTriangulator without having
to put a normal vector generator on top of it.
I understand the reasons why you don't like BIND_PER_PRIMITIVE -- a
vertex can be a part of any number of primitives (consider
TRIANGLE_FAN). So how do you determine the normal of a single vertex?
Well, the way I did it is this:
// types used for computing normal vectors
struct SVertexData
{
unsigned int m_unNumPrimitives;
osg::Vec3f m_vNormal;
};
typedef std::map osg::Vec3f, SVertexData TMVertexToDataMap;
Using this type of data structure, if we can find the vertex in that
map, we multiply the two struct members together, add the normal of the
current triangle, and divide by the struct member for the number of
primitives plus one. Then we increment the number of primitives struct
member.
If it's not in the map, we insert a mapping from the vertex to a struct
with this triangle's normal and a 1 for the number of primitives.
After we've seen every triangle, then the map is fully populated and we
can build the normal Vec3Array.
I don't know what the FLT writer does, but osgUtil::DelaunayTriangulator
is giving us back full triangles -- not a strip or fan. Depending on the
GL_MODE, you might have to iterate differently to get to the triangles.
John
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Monday, September 15, 2008 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] Paul, Another FLT Export BUG.
Paul,
No, I was not aware of this. However, I am using BIND_PER_PRIMITIVE with
osgUtil::DelaunayTriangulator/DelaunayConstraint as in the osgdelaunay
example. Since I can quickly get the triangles, I just have to
cross-multiply and normalize to get each primitive normal.
The other thing that I could to is calculate the normals in the same way
as above, but assign one to each vertex in a map. Then if a vertex is a
part of two triangles, I could add the new triangle's normal and divide
by two.
In fact, I'll probably use the strategy above. Thank you for your help
and your time, Paul.
Have a great week! Your pal,
John
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Sunday, September 14, 2008 4:36 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Paul, Another FLT Export BUG.
By the way, are you aware that BIND_PER_PRIMITIVE is the least efficient
way to render in OSG? There is no OpenGL vertex arrays equivalent for
this, so the best OSG can do to support it is specify slow path
glBegin/glEnd calls stored in a display list. If you can fix your data
to not use BIND_PER_PRIMITIVE, not only would you avoid this issue in
the FLT exporter, but you'd also potentially experience a performance
boost (depending on where your bottleneck is).
In fact, the reason this bug is in the exporter is probably because I
didn't test BIND_PER_PRIMITIVE, thinking that no one really uses that
binding anyway. (At least, no one who cares about performance uses it.)
-Paul
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Friday, September 12, 2008 2:49 PM
To: [EMAIL PROTECTED]
Subject: [osg-users] Paul, Another FLT Export BUG.
Paul,
We've found another FLT export BUG which happens when geometry
normal bind mode is BIND_PER_PRIMITIVE. It looks like it's trying to
convert the normal array to BIND_PER_VERTEX, but it fails. Here's our
example:
test.osg
In osgviewer, look at the surface and toggle both lighting
modes. Then convert and do the same.
I hope that helps! Your pal,
John Argentieri
General Dynamics C4 Systems
Battle Management Systems Division
Software Engineer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp
Paul/Robert/Anyone else who likes to fix OSG,
There is a problem in the file: osgPlugins\OpenFlight\ExportOptions.cpp
The initialization of _stripFileTexturePath is missing in the second
constructor. It happens to be a bool. So, if you pass in
osgDB::ReaderWriter::Options with an option string to specify the
version of flt output you want/any other options besides stripping
paths, you're also implicitly choosing to strip file paths out of your
textures, because most of the time a bool with unspecified value is
initialized to non-zero(true) because that's what most numbers (garbage
or not) are.
What should happen, is it should default to false and if it's a token in
the option string it becomes true.
Someone, please copy and paste the _stripTextureFilePath( false ) line
into the second constructor and add a comma after _lightingDefault(
true ). Don't forget the comma :)
Thanks guys. Your pal,
John Argentieri
ExportOptions::ExportOptions()
: _version( VERSION_16_1 ),
_units( METERS ),
_validate( false ),
_lightingDefault( true ),
_stripTextureFilePath( false )
{
}
ExportOptions::ExportOptions( const osgDB::ReaderWriter::Options* opt )
: _version( VERSION_16_1 ),
_units( METERS ),
_validate( false ),
_lightingDefault( true )
{
if (opt)
{
const ExportOptions* fltOpt = dynamic_castconst
ExportOptions*( opt );
if (fltOpt)
{
_version = fltOpt-_version;
_units = fltOpt-_units;
_validate = fltOpt-_validate;
_tempDir = fltOpt-_tempDir;
_lightingDefault = fltOpt-_lightingDefault;
}
setOptionString( opt-getOptionString() );
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Paul, Another FLT Export BUG.
Paul, We've found another FLT export BUG which happens when geometry normal bind mode is BIND_PER_PRIMITIVE. It looks like it's trying to convert the normal array to BIND_PER_VERTEX, but it fails. Here's our example: test.osg In osgviewer, look at the surface and toggle both lighting modes. Then convert and do the same. I hope that helps! Your pal, John Argentieri General Dynamics C4 Systems Battle Management Systems Division Software Engineer test.osg Description: test.osg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT writer and PositionAttitudeTransform
Paul, Thanks a million for taking care of this for all of us. Sincerely, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, August 22, 2008 1:19 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform There is shared code for all the Transforms that depends on a Matrix representation, and it appears that the code for converting the PositionAttitudeTransform to a Matrix is bogus. I'm working on a fix and should post it shortly. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, August 21, 2008 7:50 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform Paul, The attached file demonstrates the bug with PositionAttitudeTransform if you convert it to FLT. View it in wireframe to see the problem. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, August 20, 2008 10:03 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform Sounds like a bug. You can fix it yourself and submit a change, or post a .osg file that can be ran through osgconv to repro the issue. I'll add it to my queue, or maybe someone else will chip in and fix it. I do recall PAT was someone difficult to support during FLT export. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, August 20, 2008 3:00 PM To: [EMAIL PROTECTED] Subject: [osg-users] FLT writer and PositionAttitudeTransform All, I've built a little cube and placed it on the surface of a big square using PositionAttitudeTransform. No surprise that this works great during runtime in OSG 2.6. Then, I make a call to osgDB::writeNodeFile and save it as both IVE and FLT. In the IVE file, it looks just like it did during runtime. BUT, in the FLT file, it looks like it breaks the order of rotate/translate operations and flops the little cube way off the surface of the big square. Any thoughts? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT writer and PositionAttitudeTransform
Paul, The attached file demonstrates the bug with PositionAttitudeTransform if you convert it to FLT. View it in wireframe to see the problem. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, August 20, 2008 10:03 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform Sounds like a bug. You can fix it yourself and submit a change, or post a .osg file that can be ran through osgconv to repro the issue. I'll add it to my queue, or maybe someone else will chip in and fix it. I do recall PAT was someone difficult to support during FLT export. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, August 20, 2008 3:00 PM To: [EMAIL PROTECTED] Subject: [osg-users] FLT writer and PositionAttitudeTransform All, I've built a little cube and placed it on the surface of a big square using PositionAttitudeTransform. No surprise that this works great during runtime in OSG 2.6. Then, I make a call to osgDB::writeNodeFile and save it as both IVE and FLT. In the IVE file, it looks just like it did during runtime. BUT, in the FLT file, it looks like it breaks the order of rotate/translate operations and flops the little cube way off the surface of the big square. Any thoughts? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Test.osg Description: Test.osg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FLT writer and PositionAttitudeTransform
All, I've built a little cube and placed it on the surface of a big square using PositionAttitudeTransform. No surprise that this works great during runtime in OSG 2.6. Then, I make a call to osgDB::writeNodeFile and save it as both IVE and FLT. In the IVE file, it looks just like it did during runtime. BUT, in the FLT file, it looks like it breaks the order of rotate/translate operations and flops the little cube way off the surface of the big square. Any thoughts? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood
Paul, I tried this on OSG 2.6 RC1 built in VC7.1 using CMake 2.6. When I do the exact same thing you describe here, I get the following output repeating: Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers Right now, I am not able to dedicate any time to producing fixes for OSG. You see, I can't stop writing my own bugs! :) Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 31, 2008 11:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood First of all, fixes are gleefully accepted. :-) Secondly, which console are you referring to? If I run cmd.exe, enter 'osgviewer cow.osg', hit the 'f' key to go to windowed mode, then minimize the window, I see no messages in the cmd.exe window. Please provide steps for reproduction (or better yet, see the first paragraph...). -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, July 31, 2008 8:49 AM To: [EMAIL PROTECTED] Subject: [osg-users] GraphicsWindowWin32 Minimize Console Flood Hello osg gang. I'm sure that I'm not the only one that would like to see this -- How about fixing GraphicsWindowWin32 when it is minimized to stop flooding the console in OSG 2.6? The console currently gets flooded with makeCurrent/swapBuffers failed messages if the window is minimized. It's not as exciting as KDTree implementations, but a lot of people actually use a Microsoft OS. I'm sure you guys will fix it sooner or later, like you did with the texture compression in osgconv on windows. It's just that I'd like to see it sooner because some of our osg based projects are nearing completion. Thanks to all for a superb and free API, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood
Forgot one thing -- I'm on WinXP with Geforce 6600 and latest Nvidia drivers. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 31, 2008 11:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood First of all, fixes are gleefully accepted. :-) Secondly, which console are you referring to? If I run cmd.exe, enter 'osgviewer cow.osg', hit the 'f' key to go to windowed mode, then minimize the window, I see no messages in the cmd.exe window. Please provide steps for reproduction (or better yet, see the first paragraph...). -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, July 31, 2008 8:49 AM To: [EMAIL PROTECTED] Subject: [osg-users] GraphicsWindowWin32 Minimize Console Flood Hello osg gang. I'm sure that I'm not the only one that would like to see this -- How about fixing GraphicsWindowWin32 when it is minimized to stop flooding the console in OSG 2.6? The console currently gets flooded with makeCurrent/swapBuffers failed messages if the window is minimized. It's not as exciting as KDTree implementations, but a lot of people actually use a Microsoft OS. I'm sure you guys will fix it sooner or later, like you did with the texture compression in osgconv on windows. It's just that I'd like to see it sooner because some of our osg based projects are nearing completion. Thanks to all for a superb and free API, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood
Paul, Thanks for the workaround. I'll put your advice to good use. Sincerely, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 31, 2008 2:13 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood Looks like this code reports possibly several different errors, all using the same routine, which uses osg::notify(WARN) under the hood. As a workaround, try setting your notify level to FATAL. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, July 31, 2008 11:27 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood Paul, I tried this on OSG 2.6 RC1 built in VC7.1 using CMake 2.6. When I do the exact same thing you describe here, I get the following output repeating: Error: [Screen #0] GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers Right now, I am not able to dedicate any time to producing fixes for OSG. You see, I can't stop writing my own bugs! :) Thanks, John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, July 31, 2008 11:13 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] GraphicsWindowWin32 Minimize Console Flood First of all, fixes are gleefully accepted. :-) Secondly, which console are you referring to? If I run cmd.exe, enter 'osgviewer cow.osg', hit the 'f' key to go to windowed mode, then minimize the window, I see no messages in the cmd.exe window. Please provide steps for reproduction (or better yet, see the first paragraph...). -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, July 31, 2008 8:49 AM To: [EMAIL PROTECTED] Subject: [osg-users] GraphicsWindowWin32 Minimize Console Flood Hello osg gang. I'm sure that I'm not the only one that would like to see this -- How about fixing GraphicsWindowWin32 when it is minimized to stop flooding the console in OSG 2.6? The console currently gets flooded with makeCurrent/swapBuffers failed messages if the window is minimized. It's not as exciting as KDTree implementations, but a lot of people actually use a Microsoft OS. I'm sure you guys will fix it sooner or later, like you did with the texture compression in osgconv on windows. It's just that I'd like to see it sooner because some of our osg based projects are nearing completion. Thanks to all for a superb and free API, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Processing vertices in a subtree
Don't know where I'd be without ya, pal. Thanks, that's a great idea. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, July 16, 2008 12:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Processing vertices in a subtree On Wed, Jul 16, 2008 at 4:54 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, I've tried to write a NodeVisitor to grab all the vertices in a subtree. I'm trying to push those vertices into DelaunayTriangulator. The problem is that my NodeVisitor ends up seeing each vertex like 5 times in the subtree. Is there a way to get a set of all vertices with no repeats at the Geode/Drawable/Geometry/Primitive level? How many times things are shared is all down to your scene graph, and how you manage your scene graph in your visitor is entirely down to your code. I'd personally use a std::set or similar to keep track of what elements I've processed already but this really just a C++ programming issue, not at all something that is OSG specific. Robert/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] swapBuffers warning when window minimized
All, When an osg application is minimized, osg complains about swapbuffers failing, on every frame. This output can be overwhelming. Can we fix this somehow? Is there some kind of verbosity level? Is that even a word? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::CompositeViewer Thread Safety
Robert, We are making modifications to the scene graph from the application/GUI thread, and we create a Graphics thread that runs the frame() loop. We also have our own mutex which we lock() while frame() is being called, or while modifying the scene graph from the GUI thread. There are also times that the Graphics thread will call some of the same functions that lock() this mutex, via OSG Node Cull callbacks, camera final draw callbacks, etc. As I said before, our CompositeViewer is set to SINGLE_THREADED. My question is, if I am not calling frame() and modifying the scene in the GUI thread at the same time, is it necessary to call stopThreading/startThreading? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer::CompositeViewer Thread Safety Hi John, Could you give a bit more context to when in the frame and what thread you are doing operations from, without this info there is really no chance to help you. As a general not CompositeViewer and Viewer are identical when it comes to threading - they even share the same code for doing the rendering and threading. Robert. On Tue, Jun 24, 2008 at 4:07 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Guys, Is it safe to modify the scene graph outside of frame() with CompositeViewer with ThreadingModel SINGLE_THREADED, even if I don't call stopThreading()? We are changing the node mask of certain elements during the root node's cull callback. This turns certain draw elements on or off, but more importantly it turns the textures mapped to those elements on or off as well. The issue that I am seeing is that if I call stopThreading, the textures mapped to the draw elements are not the ones that I assigned, but random ones that exist on other elements. This might be some kind of display list corruption or something. One more question: If someone has seen this behavior before, is there a way to set up the draw elements so that this issue does not occur when I call stopThreading? I appreciate any input that you guys can provide that may help me on this issue. Sincerely, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer help needed
Gordon, When do you change the node masks? Also, node masks are limited by the number of bits they contain. In a simulation, we could have 1000 entities. Some are not selected, selected, highlighted etc in each view. We'd run out of bits pretty quickly. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Friday, June 27, 2008 2:39 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] osgViewer help needed Node Masks is the thing to look at using -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, June 27, 2008 2:28 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer help needed Robert, That will be difficult to achieve. What if each view had a unique root node, and each root node had an update callback? Would all of the update callbacks be triggered during the update traversal? This means that if I want Selection Geometry to be unique per view, that I would have to give each view a unique group to attach the selection geometry to. Am I understanding this? As far as the cull callbacks go, what are you saying is legal to perform? What is multi-buffering of internal structures? What does it mean to select from the multi-buffer? Thanks for your advice, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, June 27, 2008 12:53 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, It's sounds like you are abusing the OSG, i.e. using in ways that it's not designed to be used. Refactoring your scene graph usage slightly will probably fix the problems you have without having to fight the OSG continuously. First up some basics, the updating of the scene graph is designed to be be done wholly before the cull and draw traversals, this makes it possible to thread the scene graph without requiring complex multi-buffering that you'd find in Performer/OpenSG. You should consider updating the scene graph during cull and draw prohibited. The only exception to this is when you multi-buffer internal structures. Now given thrashing node parameters like you are doing is prohibited, so next you need to find an alternative, the hint of how to do it is in the last sentance above - you need to buffer you scene graph elements so that instead of one object that you change the state of, you have one node or one data element per view/camera. You can do this via cull callbacks that's maintain local buffer of data that is selected on the fly, or to just use separate subgraphs with the topmost node unique for each view/camera. You can set the cull masks individually for cameras, so you could use NodeMask's to select which part of the scene graph you want to use in each instance. Now if you don't want to follow this advice, we then I'm afraid I'll just stand back and stop giving you support on this topic, I really don't have time to go chasing people abusing the scene graph. Robert. On Fri, Jun 27, 2008 at 5:14 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We've created our own event processing system. We need to manage a common scene with different node masks, switch node settings, etc. The problem is that the event traversal and update traversal happens for all views before the cull/draw traversal. So if we follow your methods of processing events in the event traversal or update traversal, we end up with all views looking like the most recently created view, instead of being unique. If I change the scene graph in the camera's final draw callback, it works but OSG spits out a bunch of OpenGL errors for what I'm assuming is the current frame. Thanks for your time. Sincerely, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 26, 2008 6:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer help needed Hi John, What operation are you needing to do? Robert. On Tue, Jun 24, 2008 at 12:30 AM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. or g
[osg-users] Camera PostDraw Callback w/ OpenGL calls.
Guys, I have a camera postdraw callback on a View's camera. I want to do some OpenGL drawing via glBegin()/glEnd() and then take a screen capture. The screen capture works but the custom drawing isn't in there. It's on the screen though. I try to do glDrawBuffer( GL_BACK ) to force it into the same buffer as the camera, but no good. Any ideas? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::CompositeViewer Thread Safety
Guys, Is it safe to modify the scene graph outside of frame() with CompositeViewer with ThreadingModel SINGLE_THREADED, even if I don't call stopThreading()? We are changing the node mask of certain elements during the root node's cull callback. This turns certain draw elements on or off, but more importantly it turns the textures mapped to those elements on or off as well. The issue that I am seeing is that if I call stopThreading, the textures mapped to the draw elements are not the ones that I assigned, but random ones that exist on other elements. This might be some kind of display list corruption or something. One more question: If someone has seen this behavior before, is there a way to set up the draw elements so that this issue does not occur when I call stopThreading? I appreciate any input that you guys can provide that may help me on this issue. Sincerely, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer help needed
All, I need to have a callback from within osgViewer::CompositeViewer that happens just before each graphics context's renderer does cull_draw(). It can't be part of the cull traversal or the camera's pre-draw traversal, or the update traversal. Single threaded, and right before the cull traversal. Does anyone know of a way that this can be done without gutting osgViewer? Many thanks, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 2.4 bug - osgViewer::CompositeViewer
In OSG 2.4's osgViewer::CompositeViewer, when using an RTT setup, if you specify the RTT camera as a slave of CompositeViewer, rather than a node attached to the scene, the camera does not honor the framestamp or simulation time advance. I can tell this because osgCal stops animating characters in this case. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about osg::Fog and RTT setups
Hey Robert, I have classes that I instantiate that use GLSL, but are not automatically enabled on the scene graph. Is there a way to use RTT and PIXEL_BUFFER setup that won't break osg::Fog? What I mean is, if I don't instantiate the GLSL objects, will osg::Fog remain intact in this type of setup? If you think so, what would you guess might happen if I create and then destroy these objects, assuming proper cleanup? Thanks pal, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, June 19, 2008 12:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Question about osg::Fog and RTT setups Hi John, If you are using GLSL then osg::Fog/glFog will only provide the inbult fog uniform values will be available to the shader, but no fog will be applied unless you do something with them nothing will happen. If Fog is being applied when you are expect to that a subgraph is using GLSL then it suggests that GLSL is not being used for some reason. In you case you suggest the RTT Pbuffer you are seeing Fog, so perhaps the Pbuffer context doesn't support GLSL, or perhaps the contexts aren't being extension/manged correctly on the OSG side so that shaders aren't being applied correctly. It may also be easily a driver bug, trying your setup on different machines/drivers would help test this. Having never tried your particular usage combination I can't really provide any insight to way it's not working. As in my previously reply, I can't really do anything without a bit of code to test that reproduces the problem. Robert. On Thu, Jun 19, 2008 at 4:59 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, Why is it that osg::Fog, and maybe glFog(), work as expected in RTT setups if FRAME_BUFFER_OBJECT is chosen as the RenderTargetImplementation on your Camera, but if PIXEL_BUFFER/_RTT are chosen, you must re-load the scene? I think that people are under the impression that when GLSL shaders are used, glFog is broken, but that's not true. I think that if the osg::Fog is applied ( with Fog options ) to the Scene before setSceneData() is called, you will get fog, even in PIXEL_BUFFER type setups. BTW I have a GeForce 6 series on my box. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Suggestion for osg::Depth in RTT setups
All, We are using osgViewer::CompositeViewer. We have cases in which we switch certain things to become transparent during runtime, depending on user input and the view being drawn. In order for those things to contain other transparent elements (particles) we must disable writing to the depth buffer for those elements. And, we set the rendering hint on those element statesets to TRANSPARENT_BIN. In a typical setup this works great. When RTT is enabled, the camera that renders the texture ( a PRE_RENDER camera ) sees that osg::Depth and does apply() on it somewhere. The OpenGL state applied by this does not get re-set before the main camera draws the textured quad over the view. The way that I fix this issue is: Create a Camera::DrawCallback that does glDepthMask(GL_TRUE) and assign it to the main camera's predraw callback if RTT is used. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Question about osg::Fog and RTT setups
All, Why is it that osg::Fog, and maybe glFog(), work as expected in RTT setups if FRAME_BUFFER_OBJECT is chosen as the RenderTargetImplementation on your Camera, but if PIXEL_BUFFER/_RTT are chosen, you must re-load the scene? I think that people are under the impression that when GLSL shaders are used, glFog is broken, but that's not true. I think that if the osg::Fog is applied ( with Fog options ) to the Scene before setSceneData() is called, you will get fog, even in PIXEL_BUFFER type setups. BTW I have a GeForce 6 series on my box. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer Custom Graphics Operations
Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Custom Graphics Operations
Justin, I tried the exact same thing as this, but I did a setPostDrawCallback instead of setFinalDrawCallback. Do you think that could make the difference? We are doing all sorts of things with OSG that might interfere. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vican, Justin E. Sent: Wednesday, June 18, 2008 4:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer Custom Graphics Operations Hi John, I don't know what else you are trying to do, but as far as screen capturing goes, it is supported by the composite viewer. It is not explicitly supported by the osgViewer:CompositeViewer class, but it can be done through a derived osg::Camera::DrawCallback. The callback can be added to each osg::Camera in the osgViewer::CompositeViewer through the osg::Camera::setFinalDrawCallback() method. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 18, 2008 3:37 PM To: [EMAIL PROTECTED] Subject: [osg-users] osgViewer Custom Graphics Operations Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT, ParticleSystem, Depth
Robert, This is with osgViewer::CompositeViewer. The issue is that the last thing drawn ( highest bin ) has an osg::Depth in its StateSet. The osg::Depth disables write to depth buffer. All other settings in the osg::Depth are defaults. After the draw traversal completes, writing to the depth buffer is permanently disabled. If the thing with osg::Depth in its stateset is culled out, the behavior stops. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Sunday, June 15, 2008 1:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users] RTT, ParticleSystem, Depth Hi John, On Wed, Jun 11, 2008 at 8:17 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Any ideas? Thanks for your time and consideration! No ideas I'm afraid, too complex a set up to divine easily guess what might be up remotely. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Paul, There are several messages on the board that imply that INHERIT_RENDERBIN_DETAILS, when specified with a bin number, influences the CullVisitor to create a nested render order. I was under the impression that, if an application has a top-level rendering order over objects that it was possible to impose a rendering order over sub-elements of one of those objects. You see, we have polygons that occupy the same space, but we want the smaller ones to show up on top of the larger ones whenever possible. Is it not possible to do that, then? Seems like it would be something that OSG would want to allow. I'd prefer a solution that uses order, rather than some kind of polygon offset or funky state. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, June 10, 2008 8:05 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] INHERIT_RENDERBIN_DETAILS INHERIT_RENDERBIN-DETAILS tells the CullVisitor to ignore a StateSet's bin number and bin name, and instead simply keep using the current number/name. So, in your example, I'd think both Drawables would go into the same bin, and their order would be determined by the sorting associated with name RenderBin. Is that not what's happening? -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, June 10, 2008 3:25 PM To: [EMAIL PROTECTED] Subject: [osg-users] INHERIT_RENDERBIN_DETAILS Robert, I'm not convinced that INHERIT_RENDERBIN_DETAILS does what it's supposed to do. I've done this: _group-getOrCreateStateSet()-setRenderBinDetails( 3, RenderBin ); _geode1-getOrCreateStateSet()-setRenderBinDetails( 1, RenderBin, osg::StateSet::INHERIT_RENDERBIN_DETAILS ); _geode2-getOrCreateStateSet()-setRenderBinDetails( 2, RenderBin, osg::StateSet::INHERIT_RENDERBIN_DETAILS ); _group-addChild( _geode1 ); _group-addChild( _geode2 ); _geode1-addDrawable( _draw1 ); _geode2-addDrawable( _draw2 ); And _draw2 gets drawn before _draw1. I know how much you love to read code on this forum, so dare I ask, can you tell me what I've done wrong, or is this a bug? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RTT, ParticleSystem, Depth
Robert, I have an RTT setup, with particle systems. When I put the particle system behind a geometry which is transparent, the particles are not drawn behind the geometry. The geometry in question has setRenderingHint( TRANSPARENT_BIN ) set. The particle system draw() function sets glDepthMask( GL_FALSE ); When I create an osg::Depth that disables glDepthMask and assign it to the transparent geometry, the particles can be seen through the geometry! Wonderful. The problem is, when RTT is enabled, the whole scene flickers when VIEW_FRUSTUM_CULLING does not remove the osg::Depth from the scene. If RTT is disabled in the app it works fine. Any ideas? Thanks for your time and consideration! John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT, ParticleSystem, Depth
Robert, My RTT camera has a postdraw callback. When I call glDepthMask( GL_TRUE ) in the RTT camera's postdraw callback, the flickering stops. The whole reason this happens is that osg::StateAttributes only have an apply() method. They must not restore() the previous state. Don't you think the StateAttribute should be limited, at least to the subtree rooted at that node? osg::Depth gets applied, disables writing to the depth buffer, but glDepthMask( GL_TRUE ) never gets called before the camera/renderstage does a clear(), so the depth buffer doesn't get cleared, despite the fact that it's in the camera's clear mask. That being said, how does one utilize osg::Depth on only PART of a scene? Do I have to guess which is the next sibling node in the cull/draw traversal and add another osg::Depth to it? Is there a place that I can put another osg::Depth that will set the depth mask to true BEFORE the camera/renderstage does a clear()? I tried the camera, but I might have hit the wrong one. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 11, 2008 3:17 PM To: [EMAIL PROTECTED] Subject: [osg-users] RTT, ParticleSystem, Depth Robert, I have an RTT setup, with particle systems. When I put the particle system behind a geometry which is transparent, the particles are not drawn behind the geometry. The geometry in question has setRenderingHint( TRANSPARENT_BIN ) set. The particle system draw() function sets glDepthMask( GL_FALSE ); When I create an osg::Depth that disables glDepthMask and assign it to the transparent geometry, the particles can be seen through the geometry! Wonderful. The problem is, when RTT is enabled, the whole scene flickers when VIEW_FRUSTUM_CULLING does not remove the osg::Depth from the scene. If RTT is disabled in the app it works fine. Any ideas? Thanks for your time and consideration! John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INHERIT_RENDERBIN_DETAILS
Robert, I'm not convinced that INHERIT_RENDERBIN_DETAILS does what it's supposed to do. I've done this: _group-getOrCreateStateSet()-setRenderBinDetails( 3, RenderBin ); _geode1-getOrCreateStateSet()-setRenderBinDetails( 1, RenderBin, osg::StateSet::INHERIT_RENDERBIN_DETAILS ); _geode2-getOrCreateStateSet()-setRenderBinDetails( 2, RenderBin, osg::StateSet::INHERIT_RENDERBIN_DETAILS ); _group-addChild( _geode1 ); _group-addChild( _geode2 ); _geode1-addDrawable( _draw1 ); _geode2-addDrawable( _draw2 ); And _draw2 gets drawn before _draw1. I know how much you love to read code on this forum, so dare I ask, can you tell me what I've done wrong, or is this a bug? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting in osgViewer...
Shayne, If you really want to control lighting, you have to use osg::Light and osg::LightSource. If you look at the code for the example osglight you will see how those types of lights are set up. Say for instance, you want a constant, non-directional light. Copy the osglight example, but instead of what they do with the osg::Light, do: m_Light = new osg::Light(); m_Light-setLightNum( 0 ); // this will override the Look at me, I am the sun light. m_Light-setAmbient( osg::Vec4f( 1.0f, 1.0f, 1.0f, 1.0f ) ); m_Light-setDiffuse( osg::Vec4f( 0.0f, 0.0f, 0.0f, 0.0f ) ); and you don't have to worry about where it's located because it has 0 directional lighting. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Tuesday, June 10, 2008 6:09 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] lighting in osgViewer... This may be a silly question but can anyone enlighten me on what osgViewer::setLight() does? Does it set the attributes for a global light source in the scene? I want to change the defaults in the viewer... Thanks in advance -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT
Robert, We are using SceneView, and creating our own osg::GraphicsContexts.When I set an osg::Camera's RenderTargetImplementation to either of the PIXEL_BUFFER modes, the SceneView causes a crash on draw() -- what looks like trying to dereference a null pointer. Do you have any clues as to what this might be? Is there any way that I can force the osg::Camera to use a pbuffer context that I create, instead of trying to make on in RenderStage? I have no reason to believe that my platform does not support pbuffers. I've built OSG 2.4 in VC7 and I have a GeForce 6600 with the latest stable drivers. You should come to I/ITSEC this year. Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT
Robert, We require the ability to modify the scene graph in slight ways before each view is drawn, which I was unable to accomplish with CompositeViewer -- I tried setting one of osg's PreDrawCallbacks ( with SceneView we create our own ) and the stage at which this callback is issued does not permit us to change the StateSets of objects. As for contexts, we are using osg::GraphicsContext::createGraphicsContext( traits ) now. This gives us a osg::GraphicsContext which I set in the SceneView's camera. I also call makeCurrent and releaseContext on it manually in the render method (our code). Those are the only things I am doing with the context, but I don't really know if I missed anything. Is there an older version of OSG which uses SceneView in osgprerender.cpp? I will try to run the osgprerender example from the OSG 2.4 binary distribution and let you know whether it works or not. Any suggestions you might have are greatly appreciated, as usual. I've tried probably 100 different things. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 22, 2008 10:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT Hi John, Are you using osgViewer at all? Does you custom GraphicsContext implementation implement everything required like the ones in osgViewer do? As for the crash in RenderStage, does this happen if you using osgViewer based code? Is there a particular reason why you are using SceneView instead of osgViewer? Robert. On Thu, May 22, 2008 at 3:26 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We are using SceneView, and creating our own osg::GraphicsContexts.When I set an osg::Camera's RenderTargetImplementation to either of the PIXEL_BUFFER modes, the SceneView causes a crash on draw() -- what looks like trying to dereference a null pointer. Do you have any clues as to what this might be? Is there any way that I can force the osg::Camera to use a pbuffer context that I create, instead of trying to make on in RenderStage? I have no reason to believe that my platform does not support pbuffers. I've built OSG 2.4 in VC7 and I have a GeForce 6600 with the latest stable drivers. You should come to I/ITSEC this year. Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT
Robert, I downloaded the OSG 2.4 binaries from the distribution. I can run osgprerender --pbuffer cow.osg just fine. When I close the viewer, I see this: PixelBufferWin32::closeImplementation, wglReleasePbufferDCARB error: Error code 3221684230 PixelBufferWin32::closeImplementation, wglDestroyPbufferARB error: Error code 32 21684230 PixelBufferWin32::closeImplementation, wglReleasePbufferDCARB error: Error code 3221684230 PixelBufferWin32::closeImplementation, wglDestroyPbufferARB error: Error code 32 21684230 So, it is obviously making use of pbuffers. Weird John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Thursday, May 22, 2008 11:03 AM To: [EMAIL PROTECTED] Subject: Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT Robert, We require the ability to modify the scene graph in slight ways before each view is drawn, which I was unable to accomplish with CompositeViewer -- I tried setting one of osg's PreDrawCallbacks ( with SceneView we create our own ) and the stage at which this callback is issued does not permit us to change the StateSets of objects. As for contexts, we are using osg::GraphicsContext::createGraphicsContext( traits ) now. This gives us a osg::GraphicsContext which I set in the SceneView's camera. I also call makeCurrent and releaseContext on it manually in the render method (our code). Those are the only things I am doing with the context, but I don't really know if I missed anything. Is there an older version of OSG which uses SceneView in osgprerender.cpp? I will try to run the osgprerender example from the OSG 2.4 binary distribution and let you know whether it works or not. Any suggestions you might have are greatly appreciated, as usual. I've tried probably 100 different things. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 22, 2008 10:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT Hi John, Are you using osgViewer at all? Does you custom GraphicsContext implementation implement everything required like the ones in osgViewer do? As for the crash in RenderStage, does this happen if you using osgViewer based code? Is there a particular reason why you are using SceneView instead of osgViewer? Robert. On Thu, May 22, 2008 at 3:26 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We are using SceneView, and creating our own osg::GraphicsContexts.When I set an osg::Camera's RenderTargetImplementation to either of the PIXEL_BUFFER modes, the SceneView causes a crash on draw() -- what looks like trying to dereference a null pointer. Do you have any clues as to what this might be? Is there any way that I can force the osg::Camera to use a pbuffer context that I create, instead of trying to make on in RenderStage? I have no reason to believe that my platform does not support pbuffers. I've built OSG 2.4 in VC7 and I have a GeForce 6600 with the latest stable drivers. You should come to I/ITSEC this year. Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::CompositeViewer PreDrawCallback
Robert, I took the time to look this up, so that I wasn't pulling at straws. We have some objects which are drawn as either transparent or opaque depending on which view they are in. When we received the PreDrawCallback, we wanted to set the rendering hint to transparent -- I think the problem is that the objects are already sorted into bins at that particular time. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 22, 2008 11:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT Hi John, Trying to do things with SceneView is a bit of minefield, especially when it comes to trying to stuff like managing multiple graphics contexts. One of the keys reasons why osgViewer exists is to cut out all the hassle to users and myself associated with trying to reinvent the wheel all the time, it solves many problems for you. If you've tried to do something with osgViewer::Viewer/CompositeViewer but not been able to do it then this possibly something lacking in osgViewer that needs to fixed, or could simple be that you missed a way of solving the problem. Are you aware of the Camera::setIntialDrawCallback()? What was the problem you had with PreDrawCallback? Robert. On Thu, May 22, 2008 at 4:03 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We require the ability to modify the scene graph in slight ways before each view is drawn, which I was unable to accomplish with CompositeViewer -- I tried setting one of osg's PreDrawCallbacks ( with SceneView we create our own ) and the stage at which this callback is issued does not permit us to change the StateSets of objects. As for contexts, we are using osg::GraphicsContext::createGraphicsContext( traits ) now. This gives us a osg::GraphicsContext which I set in the SceneView's camera. I also call makeCurrent and releaseContext on it manually in the render method (our code). Those are the only things I am doing with the context, but I don't really know if I missed anything. Is there an older version of OSG which uses SceneView in osgprerender.cpp? I will try to run the osgprerender example from the OSG 2.4 binary distribution and let you know whether it works or not. Any suggestions you might have are greatly appreciated, as usual. I've tried probably 100 different things. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 22, 2008 10:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] PIXEL_BUFFER PIXEL_BUFFER_RTT Hi John, Are you using osgViewer at all? Does you custom GraphicsContext implementation implement everything required like the ones in osgViewer do? As for the crash in RenderStage, does this happen if you using osgViewer based code? Is there a particular reason why you are using SceneView instead of osgViewer? Robert. On Thu, May 22, 2008 at 3:26 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, We are using SceneView, and creating our own osg::GraphicsContexts.When I set an osg::Camera's RenderTargetImplementation to either of the PIXEL_BUFFER modes, the SceneView causes a crash on draw() -- what looks like trying to dereference a null pointer. Do you have any clues as to what this might be? Is there any way that I can force the osg::Camera to use a pbuffer context that I create, instead of trying to make on in RenderStage? I have no reason to believe that my platform does not support pbuffers. I've built OSG 2.4 in VC7 and I have a GeForce 6600 with the latest stable drivers. You should come to I/ITSEC this year. Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg
Re: [osg-users] osgViewer::CompositeViewer PreDrawCallback
That would probably do it. Thanks, Robert. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, May 22, 2008 11:59 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer::CompositeViewer PreDrawCallback Hi John, On Thu, May 22, 2008 at 4:28 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: I took the time to look this up, so that I wasn't pulling at straws. We have some objects which are drawn as either transparent or opaque depending on which view they are in. When we received the PreDrawCallback, we wanted to set the rendering hint to transparent -- I think the problem is that the objects are already sorted into bins at that particular time. Would a cull callback not do the trick. You can get the current view from the CullVisitor. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Camera, Viewport, FRAME_BUFFER, and the meaning of life
Robert, It seems I've got my pixels all up in a bunch! I have: 1) a SceneView with: View matrix = identity Projection matrix = identity Viewport = 0,0 to window width, window height 2) a pre render camera (renders texture successfully) with: RELATIVE_RF Target = FRAME_BUFFER View matrix = identity Projection matrix = ortho2d from 0,0 to texture width, texture height Viewport = 0,0 to texture width, texture height 3) a nested render camera that draws a textured quad with: ABSOLUTE_RF View matrix = identity Projection matrix = ortho2d from 0,0 to texture width, texture height Viewport = 0,0 to window width, window height Geometry = quad from 0,0 to texture width, texture height Tex coords from 0,0 to 1,1 When I resize the window, I change only the viewports of the scene view and the ABSOLUTE_RF camera. When I run this in a window ~0.25 of desktop area, I only see ~0.25 of the texture in the bottom left. When I run this in a maximized window I see ~1.0 of the texture. The biggest weirdness is that if I make the change to set the RELATIVE_RF camera to FRAME_BUFFER_OBJECT, it works 100%. Can you identify something that I've done wrong? A thousand thanks. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Camera, Viewport, FRAME_BUFFER, and the meaning of life
Robert, The problem is that I have to support multisampling and Windows. I haven't been able to use PIXEL_BUFFER modes. Is there any way that I can accomplish what I'm trying to do without reallocating a texture on every window size event? It's killing my memory. Thanks, John P.S. When is your next visit to I/ITSEC scheduled? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, May 21, 2008 12:29 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osg::Camera, Viewport, FRAME_BUFFER,and the meaning of life Hi John, Relying upon Render To Texture when using the frame bufffer is not reliable as the results are dependant on the frame buffer management of the window manager/OpenGL driver. What you are seeing is nothing out of the ordinary and there is nothing the OSG can do to prevent this problem if you insist on using the frame buffer for RTT. Robert. On Wed, May 21, 2008 at 5:20 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, It seems I've got my pixels all up in a bunch! I have: 1) a SceneView with: View matrix = identity Projection matrix = identity Viewport = 0,0 to window width, window height 2) a pre render camera (renders texture successfully) with: RELATIVE_RF Target = FRAME_BUFFER View matrix = identity Projection matrix = ortho2d from 0,0 to texture width, texture height Viewport = 0,0 to texture width, texture height 3) a nested render camera that draws a textured quad with: ABSOLUTE_RF View matrix = identity Projection matrix = ortho2d from 0,0 to texture width, texture height Viewport = 0,0 to window width, window height Geometry = quad from 0,0 to texture width, texture height Tex coords from 0,0 to 1,1 When I resize the window, I change only the viewports of the scene view and the ABSOLUTE_RF camera. When I run this in a window ~0.25 of desktop area, I only see ~0.25 of the texture in the bottom left. When I run this in a maximized window I see ~1.0 of the texture. The biggest weirdness is that if I make the change to set the RELATIVE_RF camera to FRAME_BUFFER_OBJECT, it works 100%. Can you identify something that I've done wrong? A thousand thanks. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DelaunayTriangulator's Input Point Array
All, The Delaunay triangulator still causes VS 2005's debugger to complain if my VS 2003 DLL that uses it is built in DEBUG and native code debugging is enabled for my 2005 app. I'm crossing over runtimes because of legacy code that I must mesh with. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, May 13, 2008 3:45 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] DelaunayTriangulator's Input Point Array Robert, This happenned because I forgot to choose /MD as a CRT library, in case anyone is curious. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, May 13, 2008 12:41 PM To: OpenSceneGraph Users Subject: Re: [osg-users] DelaunayTriangulator's Input Point Array On Tue, May 13, 2008 at 5:28 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Once the Delaunay triangulator has been run on the Vec3Array that I set at its input array, the array can't be deleted. The Delaunay triangulator must be putting something bad into that array. Any ideas? I can't even call clear() on the array in VS8 debugger. I have no ideas. I'm not the original author of osgUtil::DelaunayTriangulator so am in little better position than yourself w.r.t debugging it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DelaunayTriangulator's Input Point Array
Robert, This happenned because I forgot to choose /MD as a CRT library, in case anyone is curious. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, May 13, 2008 12:41 PM To: OpenSceneGraph Users Subject: Re: [osg-users] DelaunayTriangulator's Input Point Array On Tue, May 13, 2008 at 5:28 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Once the Delaunay triangulator has been run on the Vec3Array that I set at its input array, the array can't be deleted. The Delaunay triangulator must be putting something bad into that array. Any ideas? I can't even call clear() on the array in VS8 debugger. I have no ideas. I'm not the original author of osgUtil::DelaunayTriangulator so am in little better position than yourself w.r.t debugging it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer and osgDB::read's
Robert, I am experimenting a little with osgViewer::CompositeViewer in OSG 2.0. We have a thread in our application that is separate, and uses osgDB::readImageFile or readNodeFile. When it does the reading, it breaks our render loop. It looks like the osgDB::read call and the CompositeViewer.frame() call are conflicting somewhere. Any ideas? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RenderingHint and CompositeViewer
Robert, There's one thing that I haven't been able to do with CompositeViewer. Previously, we had a predraw callback that occurred before the sceneview's update(), cull(), draw() calls. In that callback, we set some states on some objects, particularly if they are opaque/transparent in that view. With CompositeViewer, I've used the Camera's PreDrawCallback, but at that point it's too late to set the object's renderinghint to transparent. Is there something else I can do to get the effect that I want? The CompositeViewer is rendering all the views, so how do I issue a callback at the time that I need to? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderingHint and CompositeViewer
Just looking around for an alternative, it looks like I'd have to set an UpdateCallback on all of the nodes, that contains a map from the osgViewer::View's Scene's UpdateVisitor to the states of the nodes in that Scene. I think this will work because the update traversal occurs before the cull traversal, and the cull traversal is the one that generates bins, no? I can check the NodeVisitor, if it is a UpdateVisitor of one of the scenes, then I apply those states to the node from the map. If I set a rendering hint to transparent at this time, then the rendering traversal should respect my setting, right? If this will work, I'll consider using osgViewer::CompositeViewer here. Can anyone confirm? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, April 09, 2008 4:14 PM To: [EMAIL PROTECTED] Subject: [osg-users] RenderingHint and CompositeViewer Robert, There's one thing that I haven't been able to do with CompositeViewer. Previously, we had a predraw callback that occurred before the sceneview's update(), cull(), draw() calls. In that callback, we set some states on some objects, particularly if they are opaque/transparent in that view. With CompositeViewer, I've used the Camera's PreDrawCallback, but at that point it's too late to set the object's renderinghint to transparent. Is there something else I can do to get the effect that I want? The CompositeViewer is rendering all the views, so how do I issue a callback at the time that I need to? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView and Multi-camera render to texture
Robert, Oh and I forgot, we are creating graphics contexts via a class that I wrote to manage context per window. I remember that I had to create a fake context along with the first real context to successfully implement sharing. Is there a nice way to use OSG to manage contexts? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, March 17, 2008 3:28 PM To: OpenSceneGraph Users Subject: Re: [osg-users] SceneView and Multi-camera render to texture Hi John, As you are rolling your own viewer its really open ended how you are doing things, so its hard to know where to start. Are you using pbuffers? frame buffer objects? How are you creating graphic contexts? Personally I'd recommend using osgViewer, it does mean that you know it'll work and providing support at our end is much more sane as we won't have to ask dozens of question trying to work out what setup you have. Rolled you own viewer is really expensive for us to support. Robert. On Mon, Mar 17, 2008 at 5:46 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert and pals, We are using osg 2.0. I am trying to duplicate the behavior of the osgdistortion example, but we are using osgUtil::SceneView and not osgViewer::Viewer. I have been unable to mimic the behavior of the example. If I set my texture camera to PRE_RENDER, all I get is a blank quad set to the color of the osg::geometry. If I set it to NESTED_RENDER, which is wrong, I think it draws the texture to the back buffer, because I can see it on the screen. Can anyone offer me some advice in this area? Thanks for your help John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geometry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 12, 2007 2:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] INHERIT_RENDERBIN_DETAILS Hi John I'm afraid there is too little info provided to know what might be up and how to fix it. StateSet::RenderBinDetails is what should be used to control overall draw order, but you make not mention of this. Robert. On Dec 12, 2007 7:08 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Hello all. We are using inherit renderbin details to assign a nested set of priorities. We have a group node with a top-level priority which contains several geodes with priorities using the inherit flag. Each of the geodes has a textured polygon geometry. We want to have the polygons depth test disabled and drawn in a certain order so that they will show the last drawn on top. OSG is not drawing these in order as it should. Any ideas what the problem might be? We haven't used the override renderbin details flag anywhere, so it is bizarre that things are happening this way. We can turn on blending and lower the alphas and see that both our polygons are there. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INHERIT_RENDERBIN_DETAILS
Paul, That's not so easy to do, but I will try to create an osgViewer app that hard-codes a scenegraph that duplicates the behaviors we're seeing over the weekend so I can provide the osg file. Right now we are using osgUtil::SceneViews, and not osgViewer. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, December 14, 2007 11:20 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] INHERIT_RENDERBIN_DETAILS Hi John -- Can you post an .osg file that demonstrates the problem in osgviewer? -Paul Robert, We are using getOrCreateStateSet()-setRenderBinDetails. What we have is this: osg::group1-osg::group2-osg::group3-osg::geode-osg::geomet ry, where group3 contains multiple geode-geometry children. group3 has setRenderBinDetails called without specifying INHERIT_RENDERBIN_DETAILS, Which means it is setting to USE_RENDERBIN_DETAILS by default, correct? geode has setRenderBinDetails called, specifying INHERIT_RENDERBIN_DETAILS. None of the other stuff has renderbin details set in the statesets, HOWEVER, there may be other statesets in the chain that do exist (I call getOrCreate). Maybe they all exist regardless of whether I call getOrCreate, but I am not sure of this. The geode/geometry subtrees also have a texture associated with them. They also have GL_DEPTH_TEST disabled, so that we should see the most recently drawn (highest renderbin #) when two geometries overlap or would normally conceal one another. This is not what's happenning however. Any ideas why this might be the case? I have been over the code and I'm quite sure that I've described the situation more accurately. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INHERIT_RENDERBIN_DETAILS
Hello all. We are using inherit renderbin details to assign a nested set of priorities. We have a group node with a top-level priority which contains several geodes with priorities using the inherit flag. Each of the geodes has a textured polygon geometry. We want to have the polygons depth test disabled and drawn in a certain order so that they will show the last drawn on top. OSG is not drawing these in order as it should. Any ideas what the problem might be? We haven't used the override renderbin details flag anywhere, so it is bizarre that things are happening this way. We can turn on blending and lower the alphas and see that both our polygons are there. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgConv RegisterWindowingSystemInterfaceProxy Win32
Robert, I'm not sure about *nix, but I know that on Windows, the osgViewer.dll will NOT get loaded unless a symbol from it gets referenced. That does not include this symbol: static RegisterWindowingSystemInterfaceProxy createWindowingSystemInterfaceProxy; From within GraphicsWindowWin32.cpp, at least by default. I'm not sure what you want to do for this. You could force osgconv to implicitly load osgViewer.dll by modifying the solution files, or create something on the stack in osgConv.cpp that is defined in osgViewer.dll. So far you've refuted both of these solutions. However, we do need to supply texture compression support to our customer, even on Windows. I'll bet that you guys need to do the same. IMHO, forcing the link is the least invasive solution. If I'm not mistaken, that's what happens on *nix anyway when you give g++ the -losgViewer.so so the statics and globals get created in this case. One other option would be to move osg::GraphicsContext into osgViewer.dll, that way when the GraphicsContext is declard in osgconv.cpp, then osgViewer.dll will be loaded, and the RegisterWindowingSystemInterfaceProxy will be created. John Argentieri Software Engineer GENERAL DYNAMICS C4S (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgconv
Robert/Luigi, In VS, there is an option under Linker-Input called Force Symbol Reference It might work if you put osgViewer::Viewer there. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, November 02, 2007 10:35 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgconv On 11/2/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Luigi, You and I both know that that will work. Since Robert doesn't like that solution, I'm not going to bother. I'm not as noble as some--I have my own software to write. Well I want to fix the problem properly that's all, adding a locally constructed Viewer object might work but its a hack that hides the real issue - why Windows/VS is not automatically constructing the proxy registration object in osgViewer/GraphicsWindowWin32.cpp. If one can fix this then osgconv should just work. It might require a different compile option. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgconv
Luigi, You and I both know that that will work. Since Robert doesn't like that solution, I'm not going to bother. I'm not as noble as some--I have my own software to write. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luigi Calori Sent: Friday, November 02, 2007 6:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgconv Argentieri, John-P63223 wrote: Robert, osgconv --compressed still doesn't work in windows. Here's the output from osg 2.2: /Failed to create pbuffer, failing back to normal graphics window./ /Error: Unable to create graphis context - cannot run compression/ /Data written to 'xxx.ive'./ John --- - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o rg I thought thiw had been addressed, see http://lists.openscenegraph.org/htdig.cgi/osg-submissions-openscenegraph .org/2007-August/000110.html If it still does not work for you try the (ugly) hack of creating a dummy viewer inside osgconv (see diff included) hope it helps. P.S. if this solve your problem , mail back to Robert Thanks Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgconv
Robert, osgconv --compressed still doesn't work in windows. Here's the output from osg 2.2: Failed to create pbuffer, failing back to normal graphics window. Error: Unable to create graphis context - cannot run compression Data written to 'xxx.ive'. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TexGenNode and projecting from inside geometry to the outside
Robert, If I want to project textures onto a PagedLOD globe, can I do so from inside the globe using a texgennode? It would be easiest to do if I could set the texgennode's matrices to look out at the surface of the earth from the origin. Would the fact that this is a paged database screw things up? It looks to me like the stateset that applies the texture must belong to the parent of both the texgennode and the geometry I am projecting onto. Is this true? How many texture attributes can this parent have in its stateset? I need a lot. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGenNode and projecting from inside geometry tothe outside
Robert, My images are in a lat/long coordinate system. How can I project them onto a globe in spherical coordinates? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, October 26, 2007 1:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] TexGenNode and projecting from inside geometry tothe outside Use the TexGenNode with eye linear coordinates. On 10/26/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, If I want to project textures onto a PagedLOD globe, can I do so from inside the globe using a texgennode? It would be easiest to do if I could set the texgennode's matrices to look out at the surface of the earth from the origin. Would the fact that this is a paged database screw things up? It looks to me like the stateset that applies the texture must belong to the parent of both the texgennode and the geometry I am projecting onto. Is this true? How many texture attributes can this parent have in its stateset? I need a lot. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture Memory Runtime Cleanliness
Folks, I really need to resolve this issue. I am using multiple windows, created not by realize(), but by our application, similar to if I were to use GraphicsWindowEmbedded. Each window has a context that shares with a dummy context. These contexts are managed by a class I wrote that makes OpenGL calls. They are also each using a SceneView object and sharing a common scene graph. I am creating and destroying textured polygons dynamically during runtime and the memory continually grows, despite the fact that I have relatively the same amount of textured polygons in the scene graph at all times. I can only assume that the textures are not being unloaded properly. I've read around on this group, and my hunch is that I might need to use osg::GraphicsContext to resolve this issue. Is that true? If it is true, then when I load textures, which context should be active? The shared context? All I am trying to do is to ensure that when I unref my ref_pointer to osg::Texture2D that the memory gets cleaned up from osg AND OpenGL. Please, some advice? Thankful osg-user, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Memory Runtime Cleanliness
Looks like the object whose stateset has the texture as an attribute must be destroyed in order to release the texture? Maybe creating a new stateset and setting it on the object will have the same effect. Regardless, it looks like my issue has been resolved. You guys make a great product. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Monday, October 15, 2007 9:44 AM To: OpenSceneGraph Users Subject: [osg-users] Texture Memory Runtime Cleanliness Folks, I really need to resolve this issue. I am using multiple windows, created not by realize(), but by our application, similar to if I were to use GraphicsWindowEmbedded. Each window has a context that shares with a dummy context. These contexts are managed by a class I wrote that makes OpenGL calls. They are also each using a SceneView object and sharing a common scene graph. I am creating and destroying textured polygons dynamically during runtime and the memory continually grows, despite the fact that I have relatively the same amount of textured polygons in the scene graph at all times. I can only assume that the textures are not being unloaded properly. I've read around on this group, and my hunch is that I might need to use osg::GraphicsContext to resolve this issue. Is that true? If it is true, then when I load textures, which context should be active? The shared context? All I am trying to do is to ensure that when I unref my ref_pointer to osg::Texture2D that the memory gets cleaned up from osg AND OpenGL. Please, some advice? Thankful osg-user, John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Memory supposed leak
To clarify, I create OpenGL contexts, not osg::GraphicsContexts, and use a sceneview per window. If switching to osg::GraphicsContext would fix my texture memory issues, I would do it. If that is the case, is there a good example of using a osgUtil::SceneView with a osg::GraphicsContext that someone can refer me to? John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Friday, October 12, 2007 10:21 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Texture Memory supposed leak Hello, I read a message concerning texture memory cleanup. Robert asked the user if he was opening and closing contexts. I am also having texture memory issues, and I AM opening and closing contexts. How are these two things related? Thanks for your help. Sincerely, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture Memory supposed leak
Hello, I read a message concerning texture memory cleanup. Robert asked the user if he was opening and closing contexts. I am also having texture memory issues, and I AM opening and closing contexts. How are these two things related? Thanks for your help. Sincerely, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SceneView and texture unloading
I manage my own OpenGL texture sharing. Each of my multiple OS-Windows has a SceneView and the scene graph is shared. When I set my smart pointers to zero, it seems as if the textures are not properly unloading. This is a big problem for us. How can I correct it? If I extend GraphicsWindowEmbedded? Are contexts that share data supposed to be unique? Are the context id's supposed to be one-to-one with each sharing context? My windows all have their own context, but the contexts are shared. This was accomplished by creating a dummy context, since you must share the contexts before loading anything. I am thoroughly confused as to why the sceneview/database pager setup is not unloading the textures when the osg::Image and osg::Texture objects are unreffed. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] WGS-84 osgTerrain
Hello again, and a good day to you. We use a lo-fi earth model generated by osgdem. When we do a terrain intersection, then convert to a 0-altitude coordinate, the location we get is inaccurate due to the fact that the model's geometry is an approximation of the shape of the earth. Is there a way to use osgTerrain to find the intersection of a vector with a WGS-84 earth? Thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Calling drawImplementation manually onaosgText::Text object
Robert,
If I have view frustum culling enabled, and I put the text on the screen
using native glOrtho() calls, but the text's transform only contains a
screen coordinate, would it get wiped out because of that? Should I be
using osg's transforms to make the HUD text? I think maybe it is being
culled when in fact it is being drawn on the screen using OpenGL
transforms. Does this sound feasible?
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Tuesday, August 28, 2007 4:48 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Calling drawImplementation manually
onaosgText::Text object
Hi John,
osgText::Text doesn't need an update traversal to sync itself after an
update, so it should be possible to update the text, draw the text,
update the text etc. As to why this doesn't work in your case I do not
know, its hardly a part of design spec for osgText.
I would however suggest if you have multiple text entries on a single
then use multiple text objects.
Robert.
On 8/27/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote:
Hi Robert.
I got it to work a little bit better. I want our user to be able to
call this multiple times on a single post-draw event. The way it is
now, I am able to call the underlying osgText object's
drawImplementation once and it looks correct. The next time I call it,
however, all I get is a series of squares where my letters should be.
I am guessing that this is because it must receive a visitor on the
update traversal or something.
Is there a way I can get around this too?
Thanks for all of your help over the last several months!
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Robert Osfield
Sent: Monday, August 27, 2007 3:33 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Calling drawImplementation manually on
aosgText::Text object
Hi John,
The closest code to what you are trying to achieve can be found in the
osgProducer projects src/osgProducer/ViewerEventHandler.cpp where is
sets up the and renders the stats and help.
In 2.x and osgViewer's stats and help I just go ahead and use a full
blown scene graph as it makes more things just more straight forward.
Robert.
On 8/27/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote:
Hello all, and long time no see!
I am trying to create an osgText::Text object and call
drawImplementation on it manually. I think it is almost working.
Here is how I am setting up the RenderInfo that I am passing in:
spState = new osg::State();
spViewState =
spSceneView-getRenderInfo().getState();
if( spViewState.valid() )
{
spState-setGraphicsContext(
spViewState-getGraphicsContext() );
spState-setContextID( spViewState-getContextID() );
}
renderInfo = osg::RenderInfo( spState.get(),
spSceneView-getView() );
The problem is, that the textures are being lost. Can anyone help me
to accomplish this without adding the osgText::Text to the
sceneview's
scene data?
Much appreciated!
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Calling drawImplementation manually on a osgText::Text object
Hello all, and long time no see!
I am trying to create an osgText::Text object and call
drawImplementation on it manually. I think it is almost working. Here
is how I am setting up the RenderInfo that I am passing in:
spState = new osg::State();
spViewState = spSceneView-getRenderInfo().getState();
if( spViewState.valid() )
{
spState-setGraphicsContext(
spViewState-getGraphicsContext() );
spState-setContextID( spViewState-getContextID() );
}
renderInfo = osg::RenderInfo( spState.get(),
spSceneView-getView() );
The problem is, that the textures are being lost. Can anyone help me
to accomplish this without adding the osgText::Text to the sceneview's
scene data?
Much appreciated!
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Calling drawImplementation manually on aosgText::Text object
Hi Robert.
I got it to work a little bit better. I want our user to be able to call
this multiple times on a single post-draw event. The way it is now, I am
able to call the underlying osgText object's drawImplementation once and
it looks correct. The next time I call it, however, all I get is a
series of squares where my letters should be. I am guessing that this is
because it must receive a visitor on the update traversal or something.
Is there a way I can get around this too?
Thanks for all of your help over the last several months!
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Monday, August 27, 2007 3:33 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Calling drawImplementation manually on
aosgText::Text object
Hi John,
The closest code to what you are trying to achieve can be found in the
osgProducer projects src/osgProducer/ViewerEventHandler.cpp where is
sets up the and renders the stats and help.
In 2.x and osgViewer's stats and help I just go ahead and use a full
blown scene graph as it makes more things just more straight forward.
Robert.
On 8/27/07, Argentieri, John-P63223 [EMAIL PROTECTED] wrote:
Hello all, and long time no see!
I am trying to create an osgText::Text object and call
drawImplementation on it manually. I think it is almost working. Here
is how I am setting up the RenderInfo that I am passing in:
spState = new osg::State();
spViewState =
spSceneView-getRenderInfo().getState();
if( spViewState.valid() )
{
spState-setGraphicsContext(
spViewState-getGraphicsContext() );
spState-setContextID( spViewState-getContextID() );
}
renderInfo = osg::RenderInfo( spState.get(),
spSceneView-getView() );
The problem is, that the textures are being lost. Can anyone help me
to accomplish this without adding the osgText::Text to the sceneview's
scene data?
Much appreciated!
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
