[osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
Hi all, I have some kind of quality problem with the textured glyphs from osgText. For a display I would like to have text on every node in the scene, with the text staying on top. So I disabled the depth test for all text geodes. Looks good. But when I start to change the text with setText() every second, the textured glyphs get somewhat "dirty"... (See attached picture with GL_DEPTH_TEST off/on) Thanks for any help! Tim. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54604#54604 <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg support for fast pixel readback from FBOs?
2013/6/11 Robert Osfield
> You can use osg::PixelBufferObject to assist with transferring data to and
> from the GPU. The
> OpenSceneGraph/osgscreencapture example illustrates the use of PBO's
> including buffering.
>
Hmm, strange. The osgscreencapture sample does not use the
osg::PixelBufferObject class at all. For example it creates the pbo's like
this:
if (pbo==0)
{
ext->glGenBuffers(1, &pbo);
ext->glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, pbo);
ext->glBufferData(GL_PIXEL_PACK_BUFFER_ARB,
image->getTotalSizeInBytes(), 0, GL_STREAM_READ);
Is there any particular reason why it's done this way, instead of relying
on the osg PixelBufferObject?
Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
HI Tim, You don't say how you are disabling the depth test, or how this might be affecting the result, so I'm rather left grasping at straws at what might be going on. The only thing I can think of that you are modifying the state attached to the osgText::Text drawable, but as Text plays games with multiple StateSet associated with the osgText::Font as it needs to handle the glyphs spilling out over multiple Texture. This unusually handling of StateSet in Text means that you can't just directly manipulator the Text's StateSet as you'd do with normal osg::Drawable. Instead if you want to modify state for a Text then you should do it via the StateSet attached to the osg::Geode that is the Text's parent. Whether this is the issue in your case I can't say. Robert. On 14 June 2013 11:45, Tim Rambau wrote: > Hi all, > > I have some kind of quality problem with the textured glyphs from osgText. > For a display I would like to have text on every node in the scene, with the > text staying on top. So I disabled the depth test for all text geodes. Looks > good. > > But when I start to change the text with setText() every second, the textured > glyphs get somewhat "dirty"... (See attached picture with GL_DEPTH_TEST > off/on) > > Thanks for any help! > > Tim. > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=54604#54604 > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
Hi Robert, here is my code so far: _font = osgText::readFontFile( "fonts/arial.ttf" ); _text = new osgText::Text; _text->setFont( _font ); _text->setAxisAlignment( osgText::Text::XZ_PLANE ); _textGeode = new osg::Geode; _textGeode->addDrawable( _text ); _textGeode->getOrCreateStateSet()->setMode( GL_DEPTH_TEST, osg::StateAttribute::OFF ); addChild( _textGeode ); _text->setDataVariance( osg::Object::DYNAMIC ); I think I tried everything I found about this topic: different bins, different GlyphImageMargins, etc.. It looks like a problem with the alpha values in combination with small text. Text three times the size does not show this "dirt"... Thanks, Tim. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54607#54607 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg support for fast pixel readback from FBOs?
On 14 June 2013 11:56, Christian Buchner wrote: > Is there any particular reason why it's done this way, instead of relying on > the osg PixelBufferObject? I don't recall the specific decision when osgscreencapture was written, but in sometimes for very specific purposes it's lighter weight and more convinient to just use OpenGL directly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
On 14 June 2013 12:11, Tim Rambau wrote: > I think I tried everything I found about this topic: different bins, > different GlyphImageMargins, etc.. It looks like a problem with the alpha > values in combination with small text. Text three times the size does not > show this "dirt"... It could be a lack of alpha blending for some reason. I can't think of anything in your usage which would break the alpha blending. Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pre-built dependencies for Visual Studio 2012
Hi Jan, I have a reasonable package compiled with visual studio express 2012, currently I have 64 bit versions only, a x86 version for winXP is still on my todo list. also still todo is to clean up my the modifications to the sources. the include and relase lib files take 21.7 MB in .7z format, the debug lib files 34.5 MB. The url's below are time limited, I am still looking for a more permanent way to distribute files. Regards, Laurens. |download url :http://bars.rug.nl/download/11d4c8670473bb45| avalable until: 2013-06-28 debug libs: url:http://bars.rug.nl/download/27d449612e669533 filename : vc11_debug.7z size: 34.5MB avalable until: 2013-06-28 00_bzip2 01_zlib 02_openssl 03_expat 04_png 05_jpeg 06_freetype 07_curl 08_pcre 09_glut 10_tiff 11_gif 12_gettext 12_iconv 13_gdal 14_libxml2 15_boost 16_collada_dom 17_proj 18_FFTSS 19_nvidia-texture-tools On 6/13/2013 8:53 PM, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/13/2013 08:19 PM, Chris Hanson wrote: We're working on this ourselves, but we were hampered because our Windows build system was an old Vista box and VS2012 doesn't work on Vista, so we had to roll a new build system... I have managed to build the basic stuff like libpng, zlib, libjpeg and freetype, but it would help to have some of the other libs too. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFRuhUxn11XseNj94gRAiqbAKC3I2PWXdDBhbM8x9mRfp1FwgAdzwCg3z4f 8grzZl9ysH/bjF/Ct8LdqrY= =FJTK -END PGP SIGNATURE- ___ 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] Deprecating vertex indices in osg::Geometry
Hi All, My opinions about what to do in about osg::Geometry and the old deprecated functionality is continuing to evolve. I'm starting to feel that have an osg::GeometryDeprecated is going to be awkward to maintain and for end users, while the new cleaned up osg::Geometry is clearly much better from an internal implementation and performance point of view it might be best in the short term to maintain support for the old deprecated functionality. For the old deprecated usage, while keep the clean fast path only implementation I am think about having an internal osg::Geometry that is generated from the parent osg::Geometry that is fully fast path complient and automatically generated from the parent osg::Geometry's data. This fallback could be optionally compiled out, as could the public API for the old deprecated functionality. One could also at runtime disable the fallback and possible emit an std::exception to help users who want to migrate across. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pre-built dependencies for Visual Studio 2012
Hi Laurens On Fri, Jun 14, 2013 at 2:04 PM, Laurens Voerman wrote: > Hi Jan, > I have a reasonable package compiled with visual studio express 2012, > currently I have 64 bit versions only, a x86 version for winXP is still on > my todo list. > also still todo is to clean up my the modifications to the sources. > the include and relase lib files take 21.7 MB in .7z format, the debug lib > files 34.5 MB. > The url's below are time limited, I am still looking for a more permanent > way to distribute files. > > Regards, Laurens. Excellent, thanks a lot! It would be great to put these up on the Dependencies page on the wiki once you have a bit more permanent hosting for them. Regards, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
Hi Robert, I found a dirty hack... I use the good looking version with GL_DEPTH_TEST enabled, but apply a vertex shader for all text nodes with gl_Position.z = 0.0 >=D Tim. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54613#54613 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
Hi Tim, On 14 June 2013 13:40, Tim Rambau wrote: > I found a dirty hack... > I use the good looking version with GL_DEPTH_TEST enabled, but apply a vertex > shader for all text nodes with gl_Position.z = 0.0 Glad to hear that you've found a workaround, it still sounds like a rather odd combination to get things to work, making it sound like something else is amiss that you are just working around. However, given you are providing a workaround, rather than use a shader you could just use the osg::Depth state attribute to change the depth range of the text labels generated, this would avoid the need for the shader. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgText with disabled GL_DEPTH_TEST
Hi Robert, you are right. I do not like this "solution" either. I think I have to look deeper inside the osgText::Text.cpp, because the dirty textures only happen, if you change the text. I have two text nodes added to an object, one changes its text, the other does not. The first one gets "more dirty" over time, the second stays clean. :( If I change the fragment shader to Code: gl_FragColor.rgb *= TextureColor.a; I get perfect letters in black boxes. Are the glyph textures mipmaped? Maybe it is an alpha-mipmap problem? Thanks! Tim. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54615#54615 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, On Friday, June 14, 2013 13:08:43 Robert Osfield wrote: > My opinions about what to do in about osg::Geometry and the old > deprecated functionality is continuing to evolve. I'm starting to > feel that have an osg::GeometryDeprecated is going to be awkward to > maintain and for end users, while the new cleaned up osg::Geometry is > clearly much better from an internal implementation and performance > point of view it might be best in the short term to maintain support > for the old deprecated functionality. > > For the old deprecated usage, while keep the clean fast path only > implementation I am think about having an internal osg::Geometry that > is generated from the parent osg::Geometry that is fully fast path > complient and automatically generated from the parent osg::Geometry's > data. This fallback could be optionally compiled out, as could the > public API for the old deprecated functionality. One could also at > runtime disable the fallback and possible emit an std::exception to > help users who want to migrate across. I really like the idea of GeometryDeprecated. It takes somehow more work to make this happen for users. But at very first it's just about changing a single datatype. Once it compiles with osg::Geometry again you know that you will nowhere have a slow path geometry anymore. You do not need to rely on your test coverage and an exception then. I know, this is against what you usually do with your api. If we really start to optimize geometries under the hood, when would you do this then? You cannot rely on anything in osgDB since you have to account for in application generated geometries. The only non concurrent opportunity is the update stage so far. Ok, let's assume that happens there. But then we at least have *huge* geometries. Processing them with this kind of optimization to get rid of the indices and that can take a long time. We experience this as of today with non fast path geometries where the driver is doing this work under the hood. And in contrast to osg these drivers have a long histroy of optimizing this code paths and are well optimized. Also update is currently empty. And for applications that do not need an additional graph traversal this should stay like that IMO. Depending on the structure of your graph - most probably for viz sim applications - you might need to traverse way more nodes in update than you need for cull, since you might have loaded much more geometry than you currently have in the current view. So having update walk the whole present tree can itself take a noticable time. Rather than that I would prefer to have this explicitly stated in the API what is sensible to use and what not. At least a compile switch which only allows me to use fast path stuff would be helpful IMO. So I would vote for GeometryDeprecated. May be you can call the two classes also FastGeometry vs. Geometry indstead of Geometry vs. DeprecatedGemetry. Anyway thanks for all you work! Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pre-built dependencies for Visual Studio 2012
Hi Jan, and whomever else it may concern, For VC++ builds, it is also important to keep track of the iterator debugging settings for the build. Otherwise you may end up with incompatible binaries. Relevant flags are _SECURE_SCL and newer _ITERATOR_DEBUG_LEVEL. This is a bit of a wrinkle when it comes to distributing DLLs for Windows. See http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.110%29.aspx Regards, Judson On 6/14/2013 8:15 AM, Jan Ciger wrote: Hi Laurens On Fri, Jun 14, 2013 at 2:04 PM, Laurens Voerman wrote: Hi Jan, I have a reasonable package compiled with visual studio express 2012, currently I have 64 bit versions only, a x86 version for winXP is still on my todo list. also still todo is to clean up my the modifications to the sources. the include and relase lib files take 21.7 MB in .7z format, the debug lib files 34.5 MB. The url's below are time limited, I am still looking for a more permanent way to distribute files. Regards, Laurens. Excellent, thanks a lot! It would be great to put these up on the Dependencies page on the wiki once you have a bit more permanent hosting for them. Regards, Jan ___ 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] Pre-built dependencies for Visual Studio 2012
On Fri, Jun 14, 2013 at 4:36 PM, Judson Weissert wrote: > Hi Jan, and whomever else it may concern, > > For VC++ builds, it is also important to keep track of the iterator > debugging settings for the build. Otherwise you may end up with incompatible > binaries. Relevant flags are _SECURE_SCL and newer _ITERATOR_DEBUG_LEVEL. > This is a bit of a wrinkle when it comes to distributing DLLs for Windows. > > See http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.110%29.aspx Yep, I am aware of those. Nothing like Microsoft making things easier for everyone :( Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] Refraction Map issue: isn't visible...
Hi, I'm using still now OsgOcean rev 208. I'm update to the last rev 258. Refraction seems don't work. I have a scene with refraction enabled, withe rev208 I can see the refraction, not with the rev258. Someone has reported this issue? I'm looking now around the refracition code, but is a bit expansive... Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54620#54620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] setLightColor and dynamic sun problems.
Hi kcbale I've fixed the problem implementing a simple setLightColor with no stateSet dirty: i've updated the uniform value only. This work. Right now, I look around another issue on the last ocean revision (258). Your ideas are really appreciated: http://forum.openscenegraph.org/viewtopic.php?t=12313 many thanks again bye! kcbale wrote: > Hey Dario, > > Ah Ok i understand. I'll check over the code tomorrow, it does sound like it > might need some minor changes to accommodate your needs. > > Regards, > > Kim. > > Sent from my iPhone > > On 13 Jun 2013, at 22:45, "Dario Minieri" <> wrote: > > > > Hi kcbale > > > > The light is a uniform and it is used to compute the wave top/bottom color. > > Because the setLightColor set a statSetDirty, ocean is instructed tu reload > > all stuffs. This cause a "freeze" at any time this reload is called. I'm > > planning to setup directly the uniform without dirty the stateSet...I'm try > > some ideas tomorrow... > > > > > > kcbale wrote: > > > > > Hi Dario, > > > > > > I'm not sure I understand what you mean by a 'latch', could you describe > > > the symptoms a little more? I can't remember if the light variable is a > > > uniform or a #define and I'm not in front of a pc to check. > > > > > > Regards > > > > > > Kim. > > > > > > Sent from my iPhone > > > > > > On 13 Jun 2013, at 17:04, "Dario Minieri" <> wrote: > > > > > > > > > > > > > Hi, > > > > > > > > I'm implementing a simple sun walk into skydome, calculating the light > > > > color during day. I'm using osgocean. To setup the ocean scene > > > > accordingly with the light color variation, I have to set the light > > > > color in osgocean itself via setLightColor. This works but > > > > setLightColor dirty the shader anytime and I see a "latch" into the > > > > scene when this happens. > > > > > > > > You can suggest to me a workaround to avoid the latch? Obviously I > > > > don't sets the ocean light color any microsecond, I update the light > > > > any 5 secs. > > > > > > > > Thank you! > > > > > > > > Cheers, > > > > Dario > > > > > > > > -- > > > > Read this topic online here: > > > > http://forum.openscenegraph.org/viewtopic.php?p=54595#54595 > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > osg-users mailing list > > > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > ___ > > > osg-users mailing list > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > -- > > > Post generated by Mail2Forum > > > > > > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=54600#54600 > > > > > > > > > > > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54621#54621 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB terrain to OpenFlight...
All, This question may have already been asked, but has anyone successfully converted/exported a VPB terrain (*.ive file) to an OpenFlight (*.flt) file? Is this possible to do? If so, is it better to use osgconv or to do it programmatically? Thanks, -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB terrain to OpenFlight...
Hi Shayne, On 14 June 2013 18:35, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > This question may have already been asked, but has anyone successfully > converted/exported a VPB terrain (*.ive file) to an OpenFlight (*.flt) > file? Is this possible to do? > > If so, is it better to use osgconv or to do it programmatically? Features like PagedLOD don't map to OpenFlight and an integral part of VPB generated databases so you won't be able to simply convert to OpenFlight. You could export the geometry and perhaps convert PagedLOD to LOD's, but this will require a custom visitor to do the job and the bits you end up with won't be particularly useful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB terrain to OpenFlight...
Robert, Thanks for the timely reply. That's basically what I needed to know. I'm assuming if I had a database with a single LOD (e.g. a heightfield) then that might come across okay? Thanks, -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, June 14, 2013 11:52 AM To: OpenSceneGraph Users Subject: Re: [osg-users] VPB terrain to OpenFlight... Hi Shayne, On 14 June 2013 18:35, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > This question may have already been asked, but has anyone successfully > converted/exported a VPB terrain (*.ive file) to an OpenFlight (*.flt) > file? Is this possible to do? > > If so, is it better to use osgconv or to do it programmatically? Features like PagedLOD don't map to OpenFlight and an integral part of VPB generated databases so you won't be able to simply convert to OpenFlight. You could export the geometry and perhaps convert PagedLOD to LOD's, but this will require a custom visitor to do the job and the bits you end up with won't be particularly useful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB terrain to OpenFlight...
Hi Shayne, On 14 June 2013 19:05, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > Thanks for the timely reply. That's basically what I needed to know. > > I'm assuming if I had a database with a single LOD (e.g. a heightfield) then > that might come across okay? Actually the osgTerrain components including the height filed won't be supported by OpenFlight either... so all you'd get would be the LOD's... You can build databases that contain just LOD's and osg::Geometry based tiles but you'll need to explicitly select this when you do the VPB build. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Mattias et. al, On 14 June 2013 14:23, Mathias Fröhlich wrote: > I really like the idea of GeometryDeprecated. It takes somehow more work to > make this happen for users. But at very first it's just about changing a > single > datatype. Once it compiles with osg::Geometry again you know that you will > nowhere have a slow path geometry anymore. You do not need to rely on your > test coverage and an exception then. > I know, this is against what you usually do with your api. My clean up work today has focused on sliming down osg::ArrayDispatchers and as a knock on effect implementing GeometryDeprecated has become a bit more complicated as it'll need to take on more of the work that ArrayDispatchers used to handle. I don't think it's right for us to bloat the core OSG just to maintain deprecated functionality so my current inclination is to perhaps even go further and not provide GeometryDeprecated at all. I'm currently toying with the idea of leaving the deprecated slow path methods in osg::Geometry and have flag that gets set to declare this osg::Geometry in invalid condition that can't be rendered or handled in any osg::Geometry processing, to make this osg::Geometry usable you'd then call an optimize method that converts all the indices and per primitive usage into OpenGL fast path compliant usage. My current implementation has the valid fast path version of this osg::Geometry nested within the invalid one and used in it's place when rendering, but this feels a bit cludgy and potentially inefficient when it comes to updates. The awkwardness with this nested osg::Geometry is why I'm starting to wonder if just labelling these problem osg::Geometry as invalid and let them be ignored unless the uses runs the optimize method. For the .osg, .ive loaders and new serilizers and thinking that by default we could automatically run the optimizer on the any problem osg::Geometry that have been loaded. > If we really start to optimize geometries under the hood, when would you do > this then? You cannot rely on anything in osgDB since you have to account for > in application generated geometries. The only non concurrent opportunity is > the update stage so far. Ok, let's assume that happens there. > But then we at least have *huge* geometries. Processing them with this kind of > optimization to get rid of the indices and that can take a long time. It can, so I'm inclined to push this back to user and do a one time convert after they have created the osg::Geometry. When could possible have a contains invalid osg::Geometry flag in the whole scene graph so that the update traversal knows it needs to hunt down and convert them, this does add complexity though. The other alternative might be to have a linked list of invalid osg::Geometry that need to be dealt with. Having this invalid/deprecated osg::Geometry be updated each frame would be very costly, but then they are any way. What we really want users to do is migrate away from ever creating these bad osg::Geometry in the first place, so having to jump through an extra hoop or two to make it explicit about what is happening might be the best way, even if it does mean that end users can't just recompile and run with the latest OSG and expect everything including there old deprecated usage to still work. Offically array Indices and BIND_PER_PRIMTIVE have been deprecated for several releases, every time the topic is mentioned I try to persuade users to use fast paths. The inline docs have long been clear that they are deprecated so perhaps I needn't be so accommodating. > We > experience this as of today with non fast path geometries where the driver is > doing this work under the hood. And in contrast to osg these drivers have a > long histroy of optimizing this code paths and are well optimized. OpenGL drivers have been better at replicating the glBegin/glEnd than the OSG equivalent found in the osg::GLBeginEndAdapter, as much as I tried to optimize the later I could never get the same performance as what the OpenGL driver was doing. By contrast fast path osg::Geometry are relatively easy to just push out to OpenGL without a big CPU overhead. > Also update is currently empty. And for applications that do not need an > additional graph traversal this should stay like that IMO. Depending on the > structure of your graph - most probably for viz sim applications - you might > need to traverse way more nodes in update than you need for cull, since you > might have loaded much more geometry than you currently have in the current > view. So having update walk the whole present tree can itself take a noticable > time. If we did an update traversal then one would have to limit it to just the slow path geometry that is being updated on that frame. If you don't have much slow path geometry this needn't be too slow. If you have lots of slow path geometry then well perhaps you deserve to do the work to correct or suffer a slow app... > Rather than tha
Re: [osg-users] VPB terrain to OpenFlight...
Got it. I'll give that a try and see how things shake out. Thanks for the help... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, June 14, 2013 12:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VPB terrain to OpenFlight... Hi Shayne, On 14 June 2013 19:05, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > Thanks for the timely reply. That's basically what I needed to know. > > I'm assuming if I had a database with a single LOD (e.g. a > heightfield) then that might come across okay? Actually the osgTerrain components including the height filed won't be supported by OpenFlight either... so all you'd get would be the LOD's... You can build databases that contain just LOD's and osg::Geometry based tiles but you'll need to explicitly select this when you do the VPB build. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using osg::Camera without a view
Hiya, This is a bit of a strange question. I want to use an osg::Camera purely as a shell object to use some of its handy methods (ie. all the setters and getters for the various view/model/projection matrices). Can I do this without setting up a viewer or invoking any OpenGL code (assume inactive context)? If I do something like: // note there's no osgViewer here osg::Camera cam; cam.setViewport(...); cam.setViewMatrixAsLookAt(...); cam.setProjectionMatrixAsPerspective(...); osg::Matrixd viewMatrix = cam.getViewMatrix(); Will this 'just work'? Or is there internal stuff in osg::Camera that needs the object to belong to a viewer / have a proper view/context/etc setup? Preet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osg::Camera without a view
Hi Preet, On 15 June 2013 07:44, Preet wrote: > Will this 'just work'? Or is there internal stuff in osg::Camera that needs > the object to belong to a viewer / have a proper view/context/etc setup? I can't see any reason why it wouldn't work. The osg::Camera is essentially just a data container, it doesn't have any active role in rendering, it just tells the rendering backend what it needs to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
