Re: [osg-users] osg in Visual C++ Express Edition 2008
Just because the issue was encountered on Vista doesn't mean it's related to Vista. In this case, trying to run CMake 2.4.x with Visual Studio 2008 even on XP would have given the same issue, because CMake 2.4 doesn't recognize VS 2008. You need CMake 2.5. Even on XP. I 100% agree. Its non OS related - basically VS 2008 vs CMake 2.4 (or earlier) issue. I did a check on XP and this problem exists as well. Sorry for spreading missinformation earlier. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link errors in latest SVN on Windows
On Jan 6, 2008 7:36 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: I guess EdgeCollector::Point, EdgeCollector::Edge and EdgeCollector::Triangle need OSGUTIL_EXPORT as well? Looks like it, now added and checked in. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT and multipass issue
Hi Sergey, I'm not entirely clearly on your question as there was a lot of text, before anything that looked like a query. I think the answer to what I think your question was... The OSG doesn't currently support reusing the same texture/FBO between multiple Camera as the rendering backend build the FBO automatically on demand for each Camera. There is a possibility that you might be able to achieve FBO sharing by creating your own FBO an attaching it to the Camera's directly so the rendering back end simply reuses it. I have never tried this though... Robert. On Jan 6, 2008 8:04 PM, Sergey Kurdakov [EMAIL PROTECTED] wrote: Hello, I have the following application – 1) I have multiple RTT ( for blum shader ) and set them the following way Root + Camera1: draw scene, RTT to texture1 (PRE_RENDER) + Camera2: draw scene with another shader to texture2 ( on a quad covering the screen (ortho2D absolute proj matrix), textured with texture1, RTT to texture2 (PRE_RENDER) + Camera3: draw a quad covering the screen, textured with texture2, RTT to texture3 (PRE_RENDER) . + Camera(4): draw a quad covering the screen, textured with texture4, no RTT (POST_RENDER) camera1 – draws scene to texture1 camera2 draws the same scene to texture2 with shader which makes dark parts to be darker camera3 blurs texture2 ones to texture3 camera 4 – combines texture3 with texture1 this works OK. 2) now for CameraNode3 I'd like to have multipass to make several pass of blur shader. Multipass uses osg Groups and attached states so that bin2 uses as input texture from bin1 in case of such an arrangement camera3 | | | Group - new StateSet (bin 1) Group - new StateSet (bin 2 ) | | --- | SubGraph to render Only one pass is executed Now if the arrangement is Camera3 | --- | Group - new StateSet (bin 1) || Group - new StateSet (bin 2 ) | || | SubGraph to render The result is the same – only one pass is rendered ( depending how I will assign numerical values to bin 1 and bin 2 ). What could be fixed here so that I could reuse the output texture from one rtt several times ? Also as it is related I know that Ben Cain developed a code On Dec 19, 2007 11:00 PM, Ben Cain Wrote I've written some classes that implement RTT and post-filtering using OSG And this code might help me. it looks like he shared his code with some developers but it is still not in wiki, or did I miss something ? Could anyone help to get it, please ? Best regards Sergey Kurdakov sergey.forum(_AT_)gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] blend vpb osgGIS models
On Jan 7, 2008 4:12 AM, Glenn Waldron [EMAIL PROTECTED] wrote: However, it only works for areas of limited geographic size. Overlaying a geocentric model onto a geocentric globe using osgSim::OverlayNode doesn't work for projecting models that cover larger areas or the entire earth. Robert may be able to shed some light on why this is the case. The limitation comes down to use of projective texturing - it can't wrap around the globe. The view dependent OverlayNode modes can cope better as they clamp the projected region to what is visible on screen. Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Controlling cameras with different desired frame rates
On Jan 7, 2008 6:17 AM, Roni Rosenzweig [EMAIL PROTECTED] wrote: Hi Robert Thanks for the reply. My application needs cameras at different frame rates, for simulation purposes. I guess I will have to use multiple Viewers and control them manually (call frame() when needed). Is there a problem with each viewer having its own GraphicsContext? Roni No, this is fine. Its the share of a GraphicsContext's between Viewers that would cause problems as they'd all be assuming control over it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT and multipass issue
Hi Sergey, what you want to achieve can be with the library I have posted before, osgPPU. Take a look on http://projects.tevs.eu/osgppu There the problem you are speaking about is solved in another way (take a look into example). I do use only one camera, which renders the scene into an RTT texture and afterwards you reuse this texture in different FBO's (ok not really fbos but ppus with shaders which do have different fbos). As I have seen in your post you are using one perspective camera and 3 camera's just to render a quad, that is exactly what actually ppus do. The resulting solution is the same, but you do not have to handle with multiple cameras to achieve the same result. Cheers, Art --- Robert Osfield [EMAIL PROTECTED] schrieb: Hi Sergey, I'm not entirely clearly on your question as there was a lot of text, before anything that looked like a query. I think the answer to what I think your question was... The OSG doesn't currently support reusing the same texture/FBO between multiple Camera as the rendering backend build the FBO automatically on demand for each Camera. There is a possibility that you might be able to achieve FBO sharing by creating your own FBO an attaching it to the Camera's directly so the rendering back end simply reuses it. I have never tried this though... Robert. On Jan 6, 2008 8:04 PM, Sergey Kurdakov [EMAIL PROTECTED] wrote: Hello, I have the following application 1) I have multiple RTT ( for blum shader ) and set them the following way Root + Camera1: draw scene, RTT to texture1 (PRE_RENDER) + Camera2: draw scene with another shader to texture2 ( on a quad covering the screen (ortho2D absolute proj matrix), textured with texture1, RTT to texture2 (PRE_RENDER) + Camera3: draw a quad covering the screen, textured with texture2, RTT to texture3 (PRE_RENDER) . + Camera(4): draw a quad covering the screen, textured with texture4, no RTT (POST_RENDER) camera1 draws scene to texture1 camera2 draws the same scene to texture2 with shader which makes dark parts to be darker camera3 blurs texture2 ones to texture3 camera 4 combines texture3 with texture1 this works OK. 2) now for CameraNode3 I'd like to have multipass to make several pass of blur shader. Multipass uses osg Groups and attached states so that bin2 uses as input texture from bin1 in case of such an arrangement camera3 | | | Group - new StateSet (bin 1) Group - new StateSet (bin 2 ) | | --- | SubGraph to render Only one pass is executed Now if the arrangement is Camera3 | --- | Group - new StateSet (bin 1) | | Group - new StateSet (bin 2 ) | | | | SubGraph to render The result is the same only one pass is rendered ( depending how I will assign numerical values to bin 1 and bin 2 ). What could be fixed here so that I could reuse the output texture from one rtt several times ? Also as it is related I know that Ben Cain developed a code On Dec 19, 2007 11:00 PM, Ben Cain Wrote I've written some classes that implement RTT and post-filtering using OSG And this code might help me. it looks like he shared his code with some developers but it is still not in wiki, or did I miss something ? Could anyone help to get it, please ? Best regards Sergey Kurdakov sergey.forum(_AT_)gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating shapes under mouse cursor
Hi Renan, what I do for this is the following: - compute the line behind the mouse cursor perpendicular to the screen. You will ned the transformation and view matrices for this - intersect this line with a plane parallel to the screen through the origin. You can use the line computed before as a normal vector for this plane The intersection gives a point that is a) behind the mouse b) as close to the origin as possible The choice for the depth might be another, but this one makes sense in some way! Regards, Andreas Hi, Andreas. Sorry I took so long to reply. I still haven't tried your method, but that's because I didn't understand it right away. I'll read a little bit more of the documentation to see the classes and methods that I need, and when I do it, I'll let you know. Thanks, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VBO
What does fastPath mean? Is it related to VBO? There is a sentence if (_vertexData.indices.valid()) _fastPath = false; in the function Geometry::computeFastPathsUsed() It seems that i can't use fastPath when i use setVertexIndices(); I just want to use Vertex_Buffer_Object,what should i do? thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO
Hi all, I know this is slightly off-topic, but if some of you have 5 minutes to waste, please read on :) I just take the occasion to ask a question regarding Robert's latest comment: So if you want fast paths absolutely never ever ever used vertex indices. Vertex indices are there in the OSG purely for backwards compatibility and are not something I'd recommend usage today. Acknowledged. Now, what is the preferred way to render triangle strip-based geometries where all strips are parallel and share an edge ? Should we duplicate all common vertices ? e.g. I have a 1080 * 31 patch, rendered as 30 tri strips (basically, it's a 3D plot). I use indexed rendering so I have 33480 vertices. Now if I want to switch to fast-path, does it mean I'm going to need 2*1080*30 = 64800 vertices ? Given the amount of info for each vertex (color, texcoords, ...) this seems a pretty big memory impact to me (and if the TL has to be performed again, it can also be a slowdown, can't it ?). I am no cutting-edge 3D expert so please forgive my ignorance. Happy new year to everyone, Thibault ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO
On Jan 7, 2008 10:28 AM, Thibault Genessay [EMAIL PROTECTED] wrote: So if you want fast paths absolutely never ever ever used vertex indices. Vertex indices are there in the OSG purely for backwards compatibility and are not something I'd recommend usage today. Acknowledged. Now, what is the preferred way to render triangle strip-based geometries where all strips are parallel and share an edge ? Should we duplicate all common vertices ? e.g. I have a 1080 * 31 patch, rendered as 30 tri strips (basically, it's a 3D plot). I use indexed rendering so I have 33480 vertices. Now if I want to switch to fast-path, does it mean I'm going to need 2*1080*30 = 64800 vertices ? Given the amount of info for each vertex (color, texcoords, ...) this seems a pretty big memory impact to me (and if the TL has to be performed again, it can also be a slowdown, can't it ?). I am no cutting-edge 3D expert so please forgive my ignorance. If all the shared vertices share all other vertex attributes (i.e. color, normals, tex coords etc) then you should use osg::DrawElementUShort primitive sets and standard vertex arrays. If your tex coords, normals etc aren't shared across the common edges then you have to fallback to duplicating the vertices or use vertex indices. Duplicating the vertices to maintain fast paths will usually be the best way to get performance. If... performance isn't an issue, and convenience is then use of vertex indices might be considered, especially if you are using display lists as a good OpenGL driver can then make best of bad job when it comes to slow paths. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO
Hi, I am also very surprised to see that use of index arrays/buffer objects impacts performance. Is this a limitation of OSG or OpenGL ? I always thought that Hardware Vertex Buffer + Hardware Index Buffer should be the best performing scenario. I just checked GPU_Programming_Guide on NVidia Developer site and found following excerpt in Chapter 3 General GPU Performance Tips: ... 3.3 Vertex Shader 3.3.1 Use Indexed Primitive Calls Using indexed primitive calls allows the GPU to take advantage of its post-transform-and-lighting vertex cache. If it sees a vertex it's already transformed, it doesn't transform it a second time-it simply uses a cached result. ... It seems to contradict what Robert said... Cheers, Wojtek - Original Message - From: Thibault Genessay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, January 07, 2008 11:28 AM Subject: Re: [osg-users] VBO Hi all, I know this is slightly off-topic, but if some of you have 5 minutes to waste, please read on :) I just take the occasion to ask a question regarding Robert's latest comment: So if you want fast paths absolutely never ever ever used vertex indices. Vertex indices are there in the OSG purely for backwards compatibility and are not something I'd recommend usage today. Acknowledged. Now, what is the preferred way to render triangle strip-based geometries where all strips are parallel and share an edge ? Should we duplicate all common vertices ? e.g. I have a 1080 * 31 patch, rendered as 30 tri strips (basically, it's a 3D plot). I use indexed rendering so I have 33480 vertices. Now if I want to switch to fast-path, does it mean I'm going to need 2*1080*30 = 64800 vertices ? Given the amount of info for each vertex (color, texcoords, ...) this seems a pretty big memory impact to me (and if the TL has to be performed again, it can also be a slowdown, can't it ?). I am no cutting-edge 3D expert so please forgive my ignorance. Happy new year to everyone, Thibault ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO
On Jan 7, 2008 10:58 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I am also very surprised to see that use of index arrays/buffer objects impacts performance. Is this a limitation of OSG or OpenGL ? I always thought that Hardware Vertex Buffer + Hardware Index Buffer should be the best performing scenario. Don't confuse vertex indices supported by osg::Geometry with that of indices support by osg::DrawElements* (wrapper of glDrawElements(..). vertex indices lead to the slow path == BAD. vertex arrays + DrawElelemtsn lead to fast path == GOOD :-) I just checked GPU_Programming_Guide on NVidia Developer site and found following excerpt in Chapter 3 General GPU Performance Tips: ... 3.3 Vertex Shader 3.3.1 Use Indexed Primitive Calls Using indexed primitive calls allows the GPU to take advantage of its post-transform-and-lighting vertex cache. If it sees a vertex it's already transformed, it doesn't transform it a second time-it simply uses a cached result. ... It seems to contradict what Robert said... No contradication... re-read the various post given and look for the distinction between vertices indices and primitive indices. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO
vertex indices lead to the slow path == BAD. vertex arrays + DrawElelemtsn lead to fast path == GOOD :-) Thats a relief. I was afraid I will have to fix all my code ;-) Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, January 07, 2008 12:20 PM Subject: Re: [osg-users] VBO On Jan 7, 2008 10:58 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I am also very surprised to see that use of index arrays/buffer objects impacts performance. Is this a limitation of OSG or OpenGL ? I always thought that Hardware Vertex Buffer + Hardware Index Buffer should be the best performing scenario. Don't confuse vertex indices supported by osg::Geometry with that of indices support by osg::DrawElements* (wrapper of glDrawElements(..). vertex indices lead to the slow path == BAD. vertex arrays + DrawElelemtsn lead to fast path == GOOD :-) I just checked GPU_Programming_Guide on NVidia Developer site and found following excerpt in Chapter 3 General GPU Performance Tips: ... 3.3 Vertex Shader 3.3.1 Use Indexed Primitive Calls Using indexed primitive calls allows the GPU to take advantage of its post-transform-and-lighting vertex cache. If it sees a vertex it's already transformed, it doesn't transform it a second time-it simply uses a cached result. ... It seems to contradict what Robert said... No contradication... re-read the various post given and look for the distinction between vertices indices and primitive indices. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Font silently not loaded
Hello, I am trying to load a ttf font file (under win xp) using the following: osgText::Font* font = osgText::readFontFile(verdana.ttf); but all I get is a NULL pointer. This file is present in the windows fonts directory and also in the executable directory. I also get no result using the function: text-setFont(font); // 'text' is a osgText::Text Are TTF files not supported by OSG? or should I enable something somewhere? From the stdout I don't get any message regarding any font related error. As a side note I would like to add that I compiled the plugin mingw_osgdb_freetype.dll using Freetype 2.3.5. Thanks, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fonts again: ugly default font
As you might have guessed m lately very much involved in font rendering with OSG... As you can se from the small image attached I get quite ugly font rendering using the default font. The font you see drawn comes from a very simple piece of code, that is: osgText::Text* text = new osgText::Text; text-setText(Ciao); text-setAlignment(osgText::Text::CENTER_BASE_LINE); text-setColor(osg::Vec4(1,1,1,1)); text-setCharacterSize( 20 ); text-setPosition( ... ); text-setAutoRotateToScreen(true); text-setCharacterSizeMode(osgText::Text::SCREEN_COORDS); Is there something wrong with the code I produced or are there hidden options to make the text look nicer? Playing around with the texture font it looks like the text is rendered using texture mapping but without bilinear filtering, that is, font rendering seems to use nearest point sampled texture mapped quads, but it's just a guess. Thanks, Michele attachment: ugly-fonts.PNG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fonts again: ugly default font
Hi Michele, There is little you can do to improve on the DefaultFont's quality, its just a very simple inbuilt fallback for when no other fonts are found or are assigned. You'll need to assign a decent font. See osgtext example. Robert. On Jan 7, 2008 2:13 PM, Michele Bosi [EMAIL PROTECTED] wrote: As you might have guessed m lately very much involved in font rendering with OSG... As you can se from the small image attached I get quite ugly font rendering using the default font. The font you see drawn comes from a very simple piece of code, that is: osgText::Text* text = new osgText::Text; text-setText(Ciao); text-setAlignment(osgText::Text::CENTER_BASE_LINE); text-setColor(osg::Vec4(1,1,1,1)); text-setCharacterSize( 20 ); text-setPosition( ... ); text-setAutoRotateToScreen(true); text-setCharacterSizeMode(osgText::Text::SCREEN_COORDS); Is there something wrong with the code I produced or are there hidden options to make the text look nicer? Playing around with the texture font it looks like the text is rendered using texture mapping but without bilinear filtering, that is, font rendering seems to use nearest point sampled texture mapped quads, but it's just a guess. Thanks, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.1 dev release tagged.
Hi Robert, A couple of #include osgUtil/Export and OSGUTIL_EXPORT definition is probably missing in osgUtil::ReversePrimitiveFunctor in the 2.3.1 release. Thanks a lot for your work. jcl This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link errors in latest SVN on Windows
Hello again, Yep, that did it. OSG (including examples and wrappers) now compiling properly. But I get this related warning: 3C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgUtil/EdgeCollector(170) : warning C4099: 'osgUtil::EdgeCollector::Edgeloop' : type name first seen using 'struct' now seen using 'class' 3 C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgUtil/EdgeCollector(68) : see declaration of 'osgUtil::EdgeCollector::Edgeloop' I'm also getting some other warnings, especially should I send them your way? J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.1 dev release tagged.
On Jan 7, 2008 2:42 PM, Jean-Christophe Lombardo [EMAIL PROTECTED] wrote: Hi Robert, A couple of #include osgUtil/Export and OSGUTIL_EXPORT definition is probably missing in osgUtil::ReversePrimitiveFunctor in the 2.3.1 release. These are already added to SVN, so will be in the up coming 2.3.2 release. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fonts again: ugly default font
Thank you Robert and Jean, fortunately could figure out what the problem was using the god blessed OSG_NOTIFY_LEVEL=DEBUG :) In fact it seemed that the plugin could be found and used but then OSG failed to load it. This was because of course the plugin depends on the freetype DLL library itself which wasn't in the path so I just had to add it to the path and woila', fonts are loading and text is beautiful :) Thanks again, M. On Jan 7, 2008 3:34 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Michele, As you might have guessed m lately very much involved in font rendering with OSG... As you can se from the small image attached I get quite ugly font rendering using the default font. The font you see drawn comes from a very simple piece of code, that is: If you set OSG_NOTIFY_LEVEL=DEBUG, do you get messages saying that the font Arial.ttf could not be loaded? The default font that osgText::Text uses should be Arial. If you have the OpenSceneGraph-Data distribution, it's in the fonts/ subdirectory, and setting OSG_FILE_PATH to the location of the OpenSceneGraph-Data distribution on your machine, it should find it. If you get an error message that the font cannot be found, check that (with the paths). If it's that the file cannot be loaded, it can be because your freetype plugin is not compiled properly or something else... Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] blend vpb osgGIS models
Thanks Robert, that makes sense. There are still issues when using view dependent mode though. My initial thought was to grid up the geometry to be projected and then apply cluster culling to each cell, so that it would only consider projecting Visible geometry. However the cluster-culling doesn't seem to operate as I expected in this context, i.e., on the geometry to be rendered to texture. Does an RTT camera consider cluster culling the same way a normal camera does? Or am I barking upt he wrong tree? Thanks. -gw On Jan 7, 2008 4:17 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Jan 7, 2008 4:12 AM, Glenn Waldron [EMAIL PROTECTED] wrote: However, it only works for areas of limited geographic size. Overlaying a geocentric model onto a geocentric globe using osgSim::OverlayNode doesn't work for projecting models that cover larger areas or the entire earth. Robert may be able to shed some light on why this is the case. The limitation comes down to use of projective texturing - it can't wrap around the globe. The view dependent OverlayNode modes can cope better as they clamp the projected region to what is visible on screen. Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 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] Link errors in latest SVN on Windows
Hello Robert, I guess EdgeCollector::Point, EdgeCollector::Edge and EdgeCollector::Triangle need OSGUTIL_EXPORT as well? Looks like it, now added and checked in. Yep, that did it. OSG (including examples and wrappers) now compiling properly. Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::LineStipple
I'm trying to a line using the following. Now, am I missing something obvious here? as this code doesn't work. m_markerLine is a geode that contains a line drawable. osg::ref_ptrosg::LineStipple ls = new osg::LineStipple(); ls-setPattern( 0x00FF ); ls-setFactor( 2 ); m_markerLine-getOrCreateStateSet()-setAttribute( ls.get(), osg::StateAttribute::ON ); Cheers Kim* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Link errors in latest SVN on Windows
Hi J-S, Yes send the warnings in, even better fixes :-) On Jan 7, 2008 2:44 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello again, Yep, that did it. OSG (including examples and wrappers) now compiling properly. But I get this related warning: 3C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgUtil/EdgeCollector(170) : warning C4099: 'osgUtil::EdgeCollector::Edgeloop' : type name first seen using 'struct' now seen using 'class' 3 C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgUtil/EdgeCollector(68) : see declaration of 'osgUtil::EdgeCollector::Edgeloop' I'm also getting some other warnings, especially should I send them your way? J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] updating particle systems
Hello, I'm having trouble with osg::ParticleSystem and was hoping someone might have some ideas. I am using OSG 1.2 (as a component of Delta3D 1.5). First, some background. In my application the user is able to switch between multiple views of the map. In the simplest case one view is a top-down orthographic camera, the other view is a normal first-person perspective camera. Because the orthographic camera presents an abstracted map, the views are implemented as different cameras looking out onto different scenes (loaded from different files) and entities are duplicated on each scene (in many cases different graphics are used, with 2D icons in the orthographic view and 3D models used in the perspective view.) I am using particle effects for explosions, smoke and flares. These were created using the particle system editor provided in the Delta3D package, and are saved and loaded from plain osg files. The problem I am having is this: because only one view is active at a time, when a particle system is created on the inactive view, it is never updated. As a result, when user switches views (causing the formally inactive view to become active), the particle systems on the inactive view have to catch up -- for example, every pending explosion happens simultaneously (even if explosion should have happened five minutes ago) smoke clouds appear out of nowhere when they should already be thick and billowing, flares that should already be lit light up for the first time, etc. The fundamental problem that I can discern is that this a result of a (questionable?) design decision to tie updating the particle system to the culling pass of the render, instead of part of the application update pass. Camera disabled, no cull, no particle system update. I've have yet to find a satisfactory solution to this problem. So far I have tried several different approaches: - Forcing a cull of the inactive views with drawing disabled. This does work, but at a terrible cost to framerate (30 fps to 10) since it is doing a huge amount of unneccessary work culling in addition to the minor job of updating the particle effects. - Forcing an update of the particle system (and particle processors) from application code. This requires hacking the OSG code to disentangle the update logic from the culling visitor, and writing an additional application level pass that goes through the scene looking for particle systems to update. Mysteriously, when I do this the particle systems then don't show up at all (and the drawing function is never called) so I couldn't actually get this approach to work. I presume there is some secret sauce in the culler that determines whether to draw the particle system or not, and updating it outside the culling pass confuses that logic. - Fixing the particle system updater to update in small steps when it catches up, since part of the problem is that individual particles only have a lifespan of 2-3 seconds, and it is asking the particle system to update in a single 20 second step . Taking smaller steps helps, but ultimately this also doesn't work, for a more subtle reason. The particle system update phase is actually split across several objects that are updated independently, but whose effects are interrelated: the particles system itself which moves the particles and removes old ones, and the emitter, which adds new particles. It doesn't do any good to update the entire timespan of the particles system, *then* update the entire timespan of the emitter, since the newly emitted particles are not updated, and the particles are effectively created at the end of the emitter timespan rather than being evenly distributed. At this point I am at a loss for what to do. This shouldn't be so difficult, yet I've already spent three days banging my head against it. Help! Peter Amstutz Software Engineer General Dynamics Information Technology 508-647-6970 ex 225 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] updating particle systems (sorry about HTML mail)
Resending plain text. Apologies for the HTML mail (stupid Outlook.) Hello, I'm having trouble with osg::ParticleSystem and was hoping someone might have some ideas. I am using OSG 1.2 (as a component of Delta3D 1.5). First, some background. In my application the user is able to switch between multiple views of the map. In the simplest case one view is a top-down orthographic camera, the other view is a normal first-person perspective camera. Because the orthographic camera presents an abstracted map, the views are implemented as different cameras looking out onto different scenes (loaded from different files) and entities are duplicated on each scene (in many cases different graphics are used, with 2D icons in the orthographic view and 3D models used in the perspective view.) I am using particle effects for explosions, smoke and flares. These were created using the particle system editor provided in the Delta3D package, and are saved and loaded from plain osg files. The problem I am having is this: because only one view is active at a time, when a particle system is created on the inactive view, it is never updated. As a result, when user switches views (causing the formally inactive view to become active), the particle systems on the inactive view have to catch up -- for example, every pending explosion happens simultaneously (even if explosion should have happened five minutes ago) smoke clouds appear out of nowhere when they should already be thick and billowing, flares that should already be lit light up for the first time, etc. The fundamental problem that I can discern is that this a result of a (questionable?) design decision to tie updating the particle system to the culling pass of the render, instead of part of the application update pass. Camera disabled, no cull, no particle system update. I've have yet to find a satisfactory solution to this problem. So far I have tried several different approaches: - Forcing a cull of the inactive views with drawing disabled. This does work, but at a terrible cost to framerate (30 fps to 10) since it is doing a huge amount of unneccessary work culling in addition to the minor job of updating the particle effects. - Forcing an update of the particle system (and particle processors) from application code. This requires hacking the OSG code to disentangle the update logic from the culling visitor, and writing an additional application level pass that goes through the scene looking for particle systems to update. Mysteriously, when I do this the particle systems then don't show up at all (and the drawing function is never called) so I couldn't actually get this approach to work. I presume there is some secret sauce in the culler that determines whether to draw the particle system or not, and updating it outside the culling pass confuses that logic. - Fixing the particle system updater to update in small steps when it catches up, since part of the problem is that individual particles only have a lifespan of 2-3 seconds, and it is asking the particle system to update in a single 20 second step . Taking smaller steps helps, but ultimately this also doesn't work, for a more subtle reason. The particle system update phase is actually split across several objects that are updated independently, but whose effects are interrelated: the particles system itself which moves the particles and removes old ones, and the emitter, which adds new particles. It doesn't do any good to update the entire timespan of the particles system, *then* update the entire timespan of the emitter, since the newly emitted particles are not updated, and the particles are effectively created at the end of the emitter timespan rather than being evenly distributed. At this point I am at a loss for what to do. This shouldn't be so difficult, yet I've already spent three days banging my head against it. Help! Peter Amstutz Software Engineer General Dynamics Information Technology 508-647-6970 ex 225 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL version test failed for osgdem
Hi all, I got the following error while trying to use osgdem(VPB). I am using RedHatLinux and ATI X1900 graphics card. OSG applications are working normally. Error: In Texture::Extensions::setupGLExtensions(..) OpenGL version test failed, requires valid graphics context. Scaling image 'output_L0_X0_Y0.dds' from (256,256) to (0,0) Segmentation fault Thanks in advance Om ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::LineStipple
I'm trying to a line using the following. Now, am I missing something obvious here? as this code doesn't work. m_markerLine is a geode that contains a line drawable. You didn't really say HOW it's failing,m so I'm just guessing here... m_markerLine-getOrCreateStateSet()-setAttribute( ls.get(), osg::StateAttribute::ON ); That looks suspicious. Did you mean to call setAttributeAndModes? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ugly text, Nvidia vs. ATI
Hi all, i have the following problem: text rendered with osgText on ATI cards looks somewhat blurry with ugly edges. I'm also using CEGUI in conjunction with OSG and the CEGUI text looks fine on ATI cards but the osgText does not. On Nvidia cards everything looks fine. The freetype plugin is loaded correctly and osgText and CEGUI use the same freetype lib. The font file is a standard true type font, nothing extraordinary. Has anyone experienced the same problem? thanks in advance, Michael. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture loss on context ID reuse
I've encountered a bug in osg's OpenGL texture object management. The
problem appears to be that osg texture objects aren't being cleaned when
a context ID in which they are used is subsequently reused. I know this
problem has come up on the list before, and various workarounds
suggested, but it appears to me that this is a bug within osg and needs
to be fixed in the library.
The sequence of events is as follows:
1. Create context C1 with contextID 0.
2. Render a scene into context C1 using Texture T.
- T now has allocated an OpenGL texture ID for context ID 0.
3. Remove texture from scene. (Depending on how the scene was rendered,
this step may not be necessary.)
4. Destroy context C1.
5. Create context C2, reusing contextID 0.
6. Render a scene into context C2 using same Texture T.
7. Texture T believes it is still initialized for contextID 0 so does
not reload its image data.
Here is sample code to illustrate the problem. Only the first viewer
created correctly displays the red texture.
#include osg/Texture2D
#include osg/ShapeDrawable
#include osgViewer/Viewer
int main(int, char **)
{
osg::ref_ptrosg::Texture2D texture = new osg::Texture2D;
osg::Image* image = new osg::Image;
static unsigned char bytes[] = { 0xff, 0x00, 0x00, 0xff };
image-setImage(1, 1, 1, GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE,
bytes[0], osg::Image::NO_DELETE, 1);
texture-setImage(image);
for( int i = 0; i 2; ++i )
{
osgViewer::Viewer viewer;
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),1)));
viewer.setSceneData( geode );
osg::StateSet* stateset = new osg::StateSet();
stateset-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
stateset-setTextureAttributeAndModes(0, texture.get(),
osg::StateAttribute::ON);
geode-setStateSet( stateset );
viewer.run();
// If texture is removed from scene before viewer is destroyed,
// it does not get reinitialized when used in a different scene.
stateset-removeTextureAttribute(0, texture.get());
}
return 0;
}
One work around is simply not to reuse context IDs. This is unacceptable
for programs that don't create a limited number of windows during their
course of execution.
Another work around is to keep track of all textures created and
manually call releaseGLObjects when a context is destroyed. This becomes
more difficult when using plugins such as freetype that create their own
textures.
I think the best solution is to modify core osg to maintain a list much
like the _textureObjectListMap in TextureObjectManager, but have it
store all TextureObjects initialized, not just those that are no longer
used by an osg texture.
I suspect there may be similar problems with management of other OpenGL
resources such as shaders and buffer objects.
Mark
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ugly text, Nvidia vs. ATI
Indeed, osgText looks horribly jagged on ATI Radeon 9xxx but nice/smooth on Nvidia 55/76xx. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Which version of the Collada DOM does OSG use?
Ok, I'm still a bit confused about whether the Collada plugin is supposed to use the development version of the DOM or the last stable release (1.3 from 30 March 2007). It'd be more sensible to use the last stable release of the DOM, but looking at the CMakeLists.txt file leads me to believe that (at least on Linux) the plugin is using the development version of the DOM. My patch fixes the Collada plugin to work properly with the development version of the DOM, but then it won't work any longer with the last stable release. This is getting silly. Once I have DOM 2.0 released I'll submit a patch that brings OSG's Collada plugin up to date with DOM 2.0. Then the situation will be much more clear. Steve Robert Osfield wrote: Thanks Steven, I've spotted the submission in my inbox, it won't have got through to osg-submissions as it automatically reject non subscribers. It sounds like the DOM2.0 might be ready in time for OSG 2.4, but if it isn't then we'll need to stick the last stable release of the DOM and hold back your changes for OSG 2.6. Robert. On Jan 5, 2008 4:02 AM, [EMAIL PROTECTED] wrote: I fixed the Linux build of the Collada plugin and submitted the fixed files to the osg-submissions list. If that wasn't the right procedure for submitting a patch let me know. The fix requires the latest development version of the Collada DOM, including some code I just submitted today. I haven't looked at the Windows build yet. It didn't seem to be configured correctly and likely needs some work. Steve [EMAIL PROTECTED] wrote: Which version of the OSG are you interested in? I'm interested in whatever versions are going to be affected by changes I make to the development version of the Collada DOM. What I'm concerned about is that I'll make a breaking change in the DOM and then the Collada plugin for OSG will no longer compile. If OSG's Collada plugin were synced to a specific version of the DOM then it'll be shielded from changes in the latest development version of the DOM. In the next month or so I'll be releasing a DOM 2.0, and then changes are basically going to stop, except to include support for new versions of the Collada schema as they're released (the schema is currently at 1.4.1 with 1.5 expected this year). I guess for now the OSG plugin should continue to use the latest development version of the DOM, then switch to DOM 2.0 once it's released. Then people who build the OSG Collada plugin should be instructed to use DOM 2.0 and *not* the latest development version. In the meantime I'll see about getting OSG's Collada plugin building with the latest version of the DOM on all platforms again. Steve Robert Osfield wrote: Hi Steven, The SVN version of the OSG compiles just fine with 1.4.1, I'm afraid I can't recall the situation with the other versions of the OSG. Which version of the OSG are you interested in? Robert. On Jan 4, 2008 1:50 AM, [EMAIL PROTECTED] wrote: I'm trying to reply to an issue raised by someone regarding Collada support in OSG: http://sourceforge.net/forum/forum.php?thread_id=1899938forum_id=531263 I made some changes to the Collada DOM that may require a few tweaks in client applications such as OSG's Collada plugin. Dilian reported that the changes broke the plugin. This raises the question of exactly what version of the DOM you're supposed to build OSG's Collada plugin against. Is it expected that the plugin will use the last official release of the DOM (which is version 1.3 from March 2007), or does the plugin require the latest development version of the DOM? When I went looking through the OSG sources to figure things out, I found something odd: the CMakeLists.txt file for the Collada plugin seems to have the Windows build using DOM 1.3 (there's a reference to collada_STLDatabase, which no longer exists in the latest version) and the non-Windows build seems to use the latest development version of the DOM (there's a reference to libpcre, which is only required by the latest development version of the DOM). I'm confused about what I should do to fix things in the Collada plugin. Steve ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] geometry shader support submitted.
Hi all, I've just posted an initial implementation of OSG geometry shaders to the osg-submissions list. Included is a simple example osgshaders2: the app sends 8 points at corners of a cube, the geom shader generates animated line segment crosshairs at those corners. Things yet to be done (I cannot commit to these, so pls contribute): - fully implement the non-square matrices in osg::Uniform - implement the adjacency types in DrawPrimitives - .osg file read/write support - .ive file read/write support - longer term: OSG could probably do some really smart/cool stuff, above and beyond basic GL wrapping, in somehow associating geom shaders with the corresponding DrawPrimitive. Cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] decompose and osg::Quat
Hi, everyone. I've got a simple question that I'm sure everyone will be able to answer. When I have a matrix and use it in matrix.decompose (osg::Vec3 translation, osg::Quat rotation, osg::Vec3 scale, osg::Quat so), my second argument will be filled with numbers that are supposed to represent the rotation. But what exactly these four numbers relate to the rotation matrix? More specifically, how do they relate to the arguments of the constructor osg::Quat(angle1, axis1, angle2, axis2, angle3, axis3). Thanks, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdot - a tool to generate a picture of ascenegraph's structure
Robert Osfield wrote on Thursday, November 15, 2007 9:37 AM: On Nov 15, 2007 2:46 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Paul, Well, I'm not sure this is a good OSG coding example :) The point I think is that once it's in SVN we can improve it more easily. Getting the first version of something is the hard part, then it can be incrementally improved very easily. Thanks in any case, it's a useful tool. May I add my warm welcome to such a cool feature. Added an OSG example that does graph building would be very nice. I've tagged Paul's original post, but alas don't have time to play yet. If others have time I'd to create an osg style example ready for inclusion with SVN then this would be much appreciated as I could check it in without any major reworking to fit with use of CMake etc. I've converted osgdot to use osg::NodeVisitor; see http://sourceforge.net/tracker/index.php?func=detailaid=1866010group_id=139833atid=744686 It's still not up to the standard of other examples (hardcoded output file, for example), but it should be a step in the right direction :) -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] geometry shader support submitted.
Very Cool Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Monday, January 07, 2008 3:47 PM To: OpenSceneGraph Users Subject: [osg-users] geometry shader support submitted. Hi all, I've just posted an initial implementation of OSG geometry shaders to the osg-submissions list. Included is a simple example osgshaders2: the app sends 8 points at corners of a cube, the geom shader generates animated line segment crosshairs at those corners. Things yet to be done (I cannot commit to these, so pls contribute): - fully implement the non-square matrices in osg::Uniform - implement the adjacency types in DrawPrimitives - .osg file read/write support - .ive file read/write support - longer term: OSG could probably do some really smart/cool stuff, above and beyond basic GL wrapping, in somehow associating geom shaders with the corresponding DrawPrimitive. Cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] geometry shader support submitted.
Thanks Mike, Now we need some time to develop some tessalators :) /emre On Jan 7, 2008 10:47 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi all, I've just posted an initial implementation of OSG geometry shaders to the osg-submissions list. Included is a simple example osgshaders2: the app sends 8 points at corners of a cube, the geom shader generates animated line segment crosshairs at those corners. Things yet to be done (I cannot commit to these, so pls contribute): - fully implement the non-square matrices in osg::Uniform - implement the adjacency types in DrawPrimitives - .osg file read/write support - .ive file read/write support - longer term: OSG could probably do some really smart/cool stuff, above and beyond basic GL wrapping, in somehow associating geom shaders with the corresponding DrawPrimitive. Cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Emre Koc Sabanci University Faculty of Engineering and Natural Sciences ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] fate error using QOSGWidget in develop release 2.3.0
Last time, Robert recommend me to use the new QOSGWidget in development release 2.3.0, I've tried for a long time with anything I can do, but I still can't get the example working, and I don't know why. My programming environment is windows 2003 server, visual studio 2005, GeForce FX 5200. I run it under the command window with the following command: E:\osg\OpenSceneGraph\binosgviewerQTd.exe --QOSGWidget e:/osg/OpenSceneGraph-Data/cow.osg The output is: Using QOSGWidget - QWidget + osgViewer creating the graphics context. Windows Error #2000: [Screen #0] GraphicsWindowWin32::setWindow() - Unable to create OpenGL rendering context. Reason: The pixel format is invalid. And then the following fate error pops up: The instruction at 0x014c7ef1 referenced memory at 0x00a4, The memory could not be read. Click on Ok to terminate the program Click on CANCEL to debug the program However, it's absolutely fine to use the old QAdapterWidget, the window is ok, the rendering is great. E:\osg\OpenSceneGraph\binosgviewerQTd.exe --QAdapterWidget e:/osg/OpenSceneGraph-Data/cow.osg Using AdapterWidget - QGLWidget subclassed to integrate with osgViewer using its embedded graphics window support. Is there anybody who has successfully run the example with QOSGWidget which is derived directly from QWidget? Or it's just me who can't run this. Can anybody give me any clue? Thanks very much in advance. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] transparent problem
Hi, EveryOne! In my Application, I use shader just like the shader in the example osgforest to render many trees, and there is a transparent fence. Then the color of the fence will turn to other unexpected color sometimes. while, when I don't use the shader, the wrong phenomenon disappeared. The problem seems to be related with the render sequence. I have no idea to solve this problem. Any one can help one? Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
