[osg-users] Question about switching between MatrixManipulator
Hi, Here just a quetion confused me: I have a KeySwitchMatrixManipulator , which served as a swithcer between 2 MatrixManipulator : a default Trackball and a MatrixManipulator that I defined(bounding to a object) . The problem is : when I hit the button to switch the above MatrixManipulator , especially when I switch the MatrixManipulator that I defined to the Trackball MatrixManipulator , the view point cannot come back to the default position when the application initiated , and I have to hit the spacebar in order to let the view back to the default positon. In all , Is there a method that could let the view point came back to its default position when using the Trackball MatrixManipulator? Could anyone give me some advice about this problem? Thank you very much! Cheers, Shiina -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18134#18134 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Restoring a Viewer's MatrixManipulator
Hi,Phil I just have met the same problem , like the switching of 2 MatrixManipulators , that the home position is not the position which is like the default position. I just look forward to anyone could give some advice. Thank you very much! Cheers, Shiina -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18132#18132 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Hi Chris, It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? Well, I think you've been with us for a while now, so you must have some idea about this. It seems to me that whenever commit rights are given to others, it's been for specialist duties. For example: - Maintenance of update branches (for example maintenance of the 2.6.x branch after 2.6.0 was done by Robert) - Development and maintenance of specific branches and parts of OSG (for example, the osgAnimation branch, the XCode projects, etc.) But no one has had commit access to the SVN repo as a whole except Robert. On one hand I can understand a certain desire to keep the core under control, but I think a good part of commits (maybe upwards of 80%) could be done by other people, since they're either easily verifiable bug fixes or changes to non-critical parts of OSG (i.e. anything other than the rendering backend). I'm wondering if Robert's request for outside assistance here is the time for some of the community to step up to the plate and contribute more effort to the administration of the project's source. I agree that, on one hand, people could volunteer, but historically Robert has been reluctant to give commit rights, preferring to review submissions himself. Instead, he told them to focus on other things like improving documentation, the wiki, answering more questions on the mailing list, etc. So it's understandable that if, in the past, people volunteered only to be told that it wouldn't happen, they're reluctant to volunteer now. I don't want to speak for him of course, just replying from what I remember since he hasn't done so himself yet. I would gladly volunteer but I have little time to devote to the task. I wouldn't want to say I'll help with submissions only to hold them up myself... Perhaps in the future I'll be able to, but right now I can't. Anyways, I agree with your point that the management of submissions needs to be decentralized. The "bus factor" on OSG (at least on commits to SVN) is too low... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Robert, I tried the 2.9 trunk code with. osg::DisplaySettings::instance()->setMaxTexturePoolSize(1); osg::DisplaySettings::instance()->setMaxBufferObjectPoolSize(2); The problem still exists. As memory usage was growing and growing. I just left the computer running and observed the linear memory consumption growth. Thanks Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18131#18131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] is the osg inventor loader broken?
Hi,
We're running 2.8.2 on a 64-bit Centos system. OSG was configured to use
Coin-3.1.1.
Not too long ago I ran an old demo using the new releases and noticed that
an Inventor file that used to load properly no longer did. Checking around,
many others also didn't.
Here's a simple example file that demonstrates the problem:
#Inventor V2.0 ascii
Material { diffuseColor 1 0 0 }
Cone { bottomRadius 1 height 2 }
Rotation { rotation 1 0 0 3.14159 }
Material { diffuseColor 0 1 0 }
Cone { bottomRadius 1 height 2 }
If you look at this with ivview, also linked with Coin-3.1.1, you see two
intersecting cones, red on the bottom and green on the top.
If you load this same file with osgviewer you just see the red cone.
If you use osgconv to create an osg file from the iv file you see both cones
in the osg file with identical vertex data and the green one isn't rotated.
I'm surprised I don't see any z-fighting in osgviewer.
Anyway, can anyone else try loading this Inventor file and see if it works
for them?
Many thanks,
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN commit bottleneck
Chris 'Xenon' Hanson wrote: > I don't think I'm qualified to nominate myself for this right now. > However, I'm wondering who does have SVN commit access, and if one of these > people is > willing to accept interim changes? I have several finished changes ready to > check in, and > I worry about them getting stale. With concurrent development, other people > could > potentially get conflicted with my changes and make more messy work for down > the road than > inf they had my changes to start from. Likewise, I dislike submitting more > than one > "change" at a time -- for example, I revised Vec3d for a particular purpose. > I would like > to get that in with the purpose/explanation before I make any new changes to > Vec3d for a > different purpose -- that way the SVN commit chain of evidence is clear that > this one > checking serves on single purpose. > Is anyone else willing to accept, screen and integrate SVN changes right > now? It seems like we don't have any capacity in this regard right now. I'll shorten the question -- other than Robert, who does have SVN commit access? Historically, one of my roles in the OSG community has been to point out the "emperor has no clothes" moments when we finally acknowledge we're again putting too much responsibility onto Robert, and call for new ways to shave some non-critical roles off his shoulders. Previously this has been the impetus for the separate submissions list, the Wiki, the Spelling Bee, and some others. I'm wondering if Robert's request for outside assistance here is the time for some of the community to step up to the plate and contribute more effort to the administration of the project's source. Are there others out here who have successfully been involved in the source repository or other significant FOSS projects? Maybe with experience with code review? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to use ImageSequence?
On 9/10/09 5:01 PM, stefan nortd wrote: I am trying to use the osg::ImageSequence without much result. Maybe somebody can point me in the right direction. Did you look at osgimagesequence.cpp? I am creating the ImageSequence object, use addImageFile(...) to populate at and then try to assign it to a texture for drawing. Then nothing shows up. Did you set a length? Is it playing? I feel like I am not quite grasping the idea behind ImageSequence. For one, how does the texture know when to reload the next image from the sequence. Is this all implicitly done or do I have to I miss something about this. ImageSequence is updated perodically which changes the internal image (based on runtime, playback speed, play mode). This change is picked up by Texture (through the ImageStream interface). HTH, Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
Hi Kim, http://code.google.com/p/osgocean/wiki/HardwareSupport Heh, did I actually make a typo in the page title? Geez... Sorry, I was in a hurry and didn't notice it. Thanks for your vigilance. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
"Jean-Sébastien Guay" wrote: > > Is there a place where I can > > get your changes? Ideally, just make an experimental branch, commit it > > there and once it is tested, merge into the trunk. That is fairly easy to > > do with SVN. > > I'll try to get that done before the end of the day. > Just drop me an e-mail off-list and I can send you a simple hack for testing it - e.g. a buoy bobbing on the water surface or something similar. Regard, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using Own CullVisitor
Hi All, I have written a custom cull visitor inheriting from the sosgUtill::stategraph, This inherited class do stat-set switching right before they are pushed onto the state graph. Im setting my cullVisitor with this line. dynamic_cast(pCamera->getRenderer())->getSceneView(0) ->setCullVisitor(pVisitor); This works fine when I have a single camera. How ever when I use multiple cameras and views that has post draw effects tings get messed up. Some how the sceneView uses the my cull visitor on cameras that I do not want it to be used. I tried to patch osg::camera to store a cullvisitor to be used for this camera but stop since I realised that cullvisitor was part of a project that osg core did not depend on. What I whant is to have full control over what cull visito that is goanna be used on different cameras. Anyone has any clue on how I can solve this issue? Regard Ragnar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak in osg 2.8.2 ?
Sebastien Nerig wrote on Friday, October 09, 2009 9:50 AM: > Hi, > > I take an osg example (I tried with the osgTeapot example project), then I > add the command > > Code: > viewer.run(); > _CrtDumpMemoryLeaks(); > return 0; > > at the end of the main function. (it dumps all the memory blocks in the > debug heap when a memory leak has occurred) > I launch it in debug mode, then I stop the application (ESC key) and I have > many memory leaks in my output debug window. ... > Where do they come from ? I tried other example and it is the same. > I use VisualC++ 2008, osg 2.8.2, on windows The short answer is: these probably aren't leaks you need to worry about. The long answer is: OSG constructs a number of Singletons as they are needed, which will not be deleted until after main() returns, so they appear to be memory leaks in your test. Technically, they could be considered leaks (since they can stick around after you're done using OSG -- but how does OSG know you're done?), but there isn't a good way to clean them up (this is an unfortunate consequence of using Singletons). There's been some discussion of this on the mailing list in the past couple months; you might want to search the archives to see what's been said. HTH, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to use ImageSequence?
Hi, I am trying to use the osg::ImageSequence without much result. Maybe somebody can point me in the right direction. I am creating the ImageSequence object, use addImageFile(...) to populate at and then try to assign it to a texture for drawing. Then nothing shows up. One problem is that imageSequence->s() and t() is still zero. I feel like I am not quite grasping the idea behind ImageSequence. For one, how does the texture know when to reload the next image from the sequence. Is this all implicitly done or do I have to I miss something about this. Any examples, hints very much appreciated, Thank you! Cheers, stefan stefan hechenberger http://linear.nortd.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18122#18122 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Neil Vass is out of the office.
I will be out of the office starting 09/10/2009 and will not return until 12/10/2009. I will respond to your message when I return. For urgent matters, contact the Warrington office - 01925 286 800. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] memory leak in osg 2.8.2 ?
Hi,
I take an osg example (I tried with the osgTeapot example project), then I add
the command
Code:
viewer.run();
_CrtDumpMemoryLeaks();
return 0;
at the end of the main function. (it dumps all the memory blocks in the debug
heap when a memory leak has occurred)
I launch it in debug mode, then I stop the application (ESC key) and I have
many memory leaks in my output debug window.
> Detected memory leaks!
> Dumping objects ->
> {21998} normal block at 0x01D633D0, 4 bytes long.
> Data: > 50 3E D4 01
> {21997} normal block at 0x01D48750, 20 bytes long.
> Data: 68 73 D2 01 28 DE D2 01 68 73 D2 01 08 FA E3 05
> {21996} normal block at 0x01D48568, 184 bytes long.
> Data: < q] > B8 71 5D 01 00 00 00 00 01 00 00 00 00 00 00 00
> {21995} normal block at 0x01D34998, 4 bytes long.
> Data: 68 03 D3 01
> ..
Where do they come from ? I tried other example and it is the same.
I use VisualC++ 2008, osg 2.8.2, on windows
Thank you!
Cheers,
Sebastien
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18121#18121
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Robert,
Yes you will be able to reproduce the valgrind output with the the code
sample in the email.
Cheers,
Cedric
--
+33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net
On Fri, 2009-10-09 at 14:24 +0100, Robert Osfield wrote:
> Hi Cedric,
>
> Thanks for keep on digging into this problem. I don't think this is a
> bug in your code, rather you've just set up a set of circumstances
> that the normal clean up is circumvented and an errors occurs. If
> possible we should find a way of avoid the problem in full range of
> usage.
>
> Does the little example app you provided in your email reproduce the
> crash on exit? Could we use this as a unit test?
>
> Robert.
>
> On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
> wrote:
> > Hi again,
> >
> > ok i found my mistake and it could help other people that have a strange
> > behaviour when quitting. I make a small code to reproduce the problem.
> > At the end i did
> > myviewer.setSceneData(0);
> > in order to remove scene. With the new texture manager it produces this
> > valgrind output in attached file. I did not think it was bad to do that.
> > anyway if this post can save time for other people...
> >
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > int main(int argc, char** argv)
> > {
> >osg::ref_ptr grp = new osg::Group;
> >osgViewer::Viewer myviewer;
> >myviewer.setSceneData(grp);
> >
> >osg::ref_ptr geode = new osg::Geode;
> >osg::ref_ptr chipsText = new osgText::Text;
> >std::string fontName = "../data/Vera.ttf";
> >int size = 20;
> >osg::Vec3 pos(0,0,0);
> >osg::ref_ptr font =
> > osgText::readFontFile(fontName.c_str());
> >chipsText->setFont(font);
> >chipsText->setText("blabla");
> >geode->addDrawable(chipsText);
> >grp->addChild(geode);
> >
> >myviewer.realize();
> >myviewer.run();
> >myviewer.setSceneData(0);
> >return 0;
> > }
> >
> >
> >
> > --
> > +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
> > http://www.plopbyte.net
> >
> >
> > On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
> >> Hi Robert,
> >>
> >> I updated to the svn trunk today, and i can notice a crash when quitting
> >> my application. To be sure it was with the new texture manager i defined
> >> USE_NEW_TEXTURE_POOL to 0 and then to 1.
> >>
> >> I dont have yet found the problem, but i guess it's linked with my
> >> texture manager, i own some static that reference texture.
> >>
> >> The segfault appear when quitting
> >> Program received signal SIGSEGV, Segmentation fault.
> >> #0 0xb6ef7ddf in ?? () from /lib/libc.so.6
> >> #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
> >> #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
> >> #3 0xb54f2008 in ?? ()
> >> #4 0xb54f2008 in ?? ()
> >> #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
> >> #6 0xb6fd0bcb in ?? () from /lib/libc.so.6
> >> #7 0xb6fd26e8 in ?? () from /lib/libc.so.6
> >> #8 0xb6fcf469 in ?? () from /lib/libc.so.6
> >> #9 0xb6fcf442 in ?? () from /lib/libc.so.6
> >> #10 0xbfc68254 in ?? ()
> >> #11 0xa7200010 in ?? ()
> >> #12 0x001d in ?? ()
> >> #13 0x in ?? ()
> >>
> >> I guess there is something wrong with my texture management and the new
> >> texture pool.
> >>
> >> I continue to dig
> >>
> >> Cheers,
> >> Cedric
> >>
> >> --
> >> +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
> >> http://www.plopbyte.net
> >>
> >>
> >> On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
> >> > Hi All,
> >> >
> >> > I've been pretty quiet and the public list/forum through September,
> >> > keeping my head down developing new functionality for the OSG... and
> >> > the new functionality I'm pleased to announce today is that we now
> >> > have a loverly new back-end implementation for texture objects and
> >> > buffer objects (VertexBufferObject, ElementBufferObjects and
> >> > PixelBufferObjects's) that provides a set of GL objects pools that
> >> > enable recycling of both orphaned GL objects and reuse of GL objects
> >> > that are still attached to the scene graph, but are stale - i.e.
> >> > haven't been rendered in the last frame.
> >> >
> >> > The benefit the GL object pools provide is that we can scale up the
> >> > scene graph in main memory without blowing OpenGL driver and GPU
> >> > memory as we would do without the new pools. This feature also
> >> > reduces the likely-hood of thrashing of OpenGL driver and GPU memory
> >> > so that where we might have previously seen frame drops due to memory
> >> > management we avoid them completely or reduce there impact. The
> >> > memory pools will come in there own once we scale down the GPU memory
> >> > size, such as embedded systems, or on desktop/workstation applications
> >> > where GPU memory can be overflowed due to massive databases being kept
> >> > in main
Re: [osg-users] [3rdparty] How to run osgOcean
Or rather: http://code.google.com/p/osgocean/wiki/HardwareSupport Without the typo.. ;) K. 2009/10/9 Jean-Sébastien Guay : > Hi again, > >> I'll look about starting that wiki page soon. > > Here you go, > > http://code.google.com/p/osgocean/wiki/HarwareSupport > > I'll add details as time passes... > > J-S > -- > __ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
Hi again, I'll look about starting that wiki page soon. Here you go, http://code.google.com/p/osgocean/wiki/HarwareSupport I'll add details as time passes... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture missing when adding slaves dynamically to osgViewer
Hi Frederic, > I tried with Texture::setUnRefImageDataAfterApply(false) and it works well. > However, as I read about this, texture memory is now duplicated (once in > OpenGL and once in OSG). Isn't there a way to do the same thing in OpenGL by > sharing the contexts or something like that? As I said, I tried to share a > single context in the traits configuration but it didn't work. For now, our > application doesn't use too much memory but this could become a problem when > we'll be generating visual data from our database! It's possible to share contexts in the OSG, I have no clue as to why it hasn't worked in your case, there is just too many unknowns - you have your code, I don't so you're the only one really in a position to debug it. As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons. There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. > As for the osgUtil::Optimizer, we're not using it anywhere in our code... Is > it called by the Viewer class during initialization or something? The Viewer doesn't run the Optimizer. Some plugins run it on their own data though. > Would there be another way to enable texture sharing for dynamically created > rendering contexts while optimizing memory usage? ?? Sounds a bit like a magic wand. OpenGL only allows you to share all OpenGL objects or none, you don't get to share some. If you want to tightly manage the OpenGL memory footprint then the new texture + buffer object pool is what you'll want to use. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture missing when adding slaves dynamically to osgViewer
Hello, I tried with Texture::setUnRefImageDataAfterApply(false) and it works well. However, as I read about this, texture memory is now duplicated (once in OpenGL and once in OSG). Isn't there a way to do the same thing in OpenGL by sharing the contexts or something like that? As I said, I tried to share a single context in the traits configuration but it didn't work. For now, our application doesn't use too much memory but this could become a problem when we'll be generating visual data from our database! As for the osgUtil::Optimizer, we're not using it anywhere in our code... Is it called by the Viewer class during initialization or something? Would there be another way to enable texture sharing for dynamically created rendering contexts while optimizing memory usage? Thanks again for your help! Frédéric Drolet -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: October-08-09 5:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture missing when adding slaves dynamically toosgViewer Hi Frederic, If you are creating new graphics contexts and applying and old scene graph to it then you can't use the Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as this will discard the imagery once it's applied to all the graphics contexts that it knows about. By default the osgUtil::Optimizer will switch this on to save memory, so try not calling the Optimizer to see if makes a difference. It's possible that the original database also has this options set, but for most databases it'll be off, which is the default. Robert. On Thu, Oct 8, 2009 at 8:21 PM, Drolet, Frederic wrote: > Hello, > > > > I'm having trouble with textures on slave cameras added to an osgViewer. > Textures won't appear if I add the slaves after a first call to > osgViewer::frame(). > > > > My application is composed of a rendering thread calling osgViewer::frame() > every 15 ms (for a 60 Hz framerate) and a main thread handling windows and > menus interactions (using MFC on Windows). One of those interactions is to > add and remove camera slaves on the go (adding a projection and camera > offset for multiple points of view). Here's the steps I follow to add a > slave camera: > > > > · Pause my rendering thread calling osgViewer::frame() and wait for > it to be idle; > > · Call osgViewer::stopThreading() to make sure the last frame is > done drawing; > > · Create a child window with its own graphics context; > > · Add a slave to osgViewer using the newly created window handle > (each slave camera uses its own osg::GraphicsContext object); > > · Call osgViewer::realize() to reinitialize the viewer and start > threading again; > > · Unpause my rendring thread which starts calling osgViewer::frame() > again. > > > > I use a similar approach to destroy slaves. Everything works fine except for > the textures which are not displayed on the slave windows (but I can see the > primitives). > > > > Note that if I add slaves before the first call to osgViewer::frame(), > textures are ok. But removing and adding them again makes the textures > disappear. > > > > I tried all the threading models in osgViewer, I also tried to share the > "master" context in the osg::GraphicsContext::Traits object of every slave. > None of those solutions is working. My comprehension of OpenGL state sets is > limited so I'm probably missing something here. > > > > What am I doing wrong? Is adding slaves dynamically to an osgViewer even > possible? > > > > Thanks for your help! > > > > Frederic Drolet, M. Sc. > > Computing Solutions and Experimentations | Solutions informatiques et > expérimentations > > Systems of Systems | Systèmes de systèmes > > DRDC Valcartier | RDDC Valcartier > > 2459, boul. Pie-XI North > > Quebec, Quebec > > G3J 1X5 CANADA > > Phone | Téléphone: (418) 844-4000 ext : 4820 > > Fax | Télécopieur: (418) 844-4538 > > E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca > > Web : www.valcartier.drdc-rddc.gc.ca > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hi Jan, Right, of course. I have a bit of code that makes an object bob on the surface, but my code is likely a bit different from Dimitrios's, so it would need to be changed based on what you have done. Likely it's just the method name that would change. I don't mind doing that. Is there a place where I can get your changes? Ideally, just make an experimental branch, commit it there and once it is tested, merge into the trunk. That is fairly easy to do with SVN. I'll try to get that done before the end of the day. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
Hi Jan, I have it running on GeForce Go 7600 (laptop) and Quadro FX 4500 (GeForce 7800 equivalent), but do not expect super high framerates on such hardware. The shaders are quite slow on those cards. On the other hand, my 8800GT runs it smoothly at 1920x1200. Interesting, thanks for the additional data. I'll look about starting that wiki page soon. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
Hi Cedric,
Thanks for keep on digging into this problem. I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs. If
possible we should find a way of avoid the problem in full range of
usage.
Does the little example app you provided in your email reproduce the
crash on exit? Could we use this as a unit test?
Robert.
On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
wrote:
> Hi again,
>
> ok i found my mistake and it could help other people that have a strange
> behaviour when quitting. I make a small code to reproduce the problem.
> At the end i did
> myviewer.setSceneData(0);
> in order to remove scene. With the new texture manager it produces this
> valgrind output in attached file. I did not think it was bad to do that.
> anyway if this post can save time for other people...
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char** argv)
> {
> osg::ref_ptr grp = new osg::Group;
> osgViewer::Viewer myviewer;
> myviewer.setSceneData(grp);
>
> osg::ref_ptr geode = new osg::Geode;
> osg::ref_ptr chipsText = new osgText::Text;
> std::string fontName = "../data/Vera.ttf";
> int size = 20;
> osg::Vec3 pos(0,0,0);
> osg::ref_ptr font =
> osgText::readFontFile(fontName.c_str());
> chipsText->setFont(font);
> chipsText->setText("blabla");
> geode->addDrawable(chipsText);
> grp->addChild(geode);
>
> myviewer.realize();
> myviewer.run();
> myviewer.setSceneData(0);
> return 0;
> }
>
>
>
> --
> +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
> http://www.plopbyte.net
>
>
> On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
>> Hi Robert,
>>
>> I updated to the svn trunk today, and i can notice a crash when quitting
>> my application. To be sure it was with the new texture manager i defined
>> USE_NEW_TEXTURE_POOL to 0 and then to 1.
>>
>> I dont have yet found the problem, but i guess it's linked with my
>> texture manager, i own some static that reference texture.
>>
>> The segfault appear when quitting
>> Program received signal SIGSEGV, Segmentation fault.
>> #0 0xb6ef7ddf in ?? () from /lib/libc.so.6
>> #1 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #2 0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #3 0xb54f2008 in ?? ()
>> #4 0xb54f2008 in ?? ()
>> #5 0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
>> #6 0xb6fd0bcb in ?? () from /lib/libc.so.6
>> #7 0xb6fd26e8 in ?? () from /lib/libc.so.6
>> #8 0xb6fcf469 in ?? () from /lib/libc.so.6
>> #9 0xb6fcf442 in ?? () from /lib/libc.so.6
>> #10 0xbfc68254 in ?? ()
>> #11 0xa7200010 in ?? ()
>> #12 0x001d in ?? ()
>> #13 0x in ?? ()
>>
>> I guess there is something wrong with my texture management and the new
>> texture pool.
>>
>> I continue to dig
>>
>> Cheers,
>> Cedric
>>
>> --
>> +33 659 598 614 Cedric Pinson mailto:cedric.pin...@plopbyte.net
>> http://www.plopbyte.net
>>
>>
>> On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
>> > Hi All,
>> >
>> > I've been pretty quiet and the public list/forum through September,
>> > keeping my head down developing new functionality for the OSG... and
>> > the new functionality I'm pleased to announce today is that we now
>> > have a loverly new back-end implementation for texture objects and
>> > buffer objects (VertexBufferObject, ElementBufferObjects and
>> > PixelBufferObjects's) that provides a set of GL objects pools that
>> > enable recycling of both orphaned GL objects and reuse of GL objects
>> > that are still attached to the scene graph, but are stale - i.e.
>> > haven't been rendered in the last frame.
>> >
>> > The benefit the GL object pools provide is that we can scale up the
>> > scene graph in main memory without blowing OpenGL driver and GPU
>> > memory as we would do without the new pools. This feature also
>> > reduces the likely-hood of thrashing of OpenGL driver and GPU memory
>> > so that where we might have previously seen frame drops due to memory
>> > management we avoid them completely or reduce there impact. The
>> > memory pools will come in there own once we scale down the GPU memory
>> > size, such as embedded systems, or on desktop/workstation applications
>> > where GPU memory can be overflowed due to massive databases being kept
>> > in main memory. In the later case this issue is more compounded on
>> > some OS's, such as Vista, that limits the amount of memory that OpenGL
>> > drivers can allocate, so here it should help make the app more stable
>> > (avoid the crashes due to out of memory errors) and faster.
>> >
>> > So... how to try out the new texture and buffer object pools? First
>> > up you'll need to update to the latest OpenScenGraph svn/trunk. Next
>> > you'll need to enable the pools by setting the env vars: (example
>> > below for bash)
>> >
>
Re: [osg-users] osg::LOD range distance Coordinate System Question
Thanks Robert, This is an odd corner-case I guess, I want the LODs to be selected based upon global distance from the eye-point. For various reasons, onscreen size is inappropriate as a selector. I think I can put together a small example/patch and send it in for review. cheers, sean _ Sean Spicer Executive Vice President & Chief Technology Officer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Oct 9, 2009 at 2:06 AM, Robert Osfield wrote: > Hi Sean, > > You are correct the range distance of LOD's are in the LOD's own local > co-coordinate system. This is appropriate as you almost aways want > LOD's to scale relative to a screen size, and doing the calc in local > coordinate allows you to decorate subgraphs with LOD's with transforms > that scale up or down the subgraph and still have the LOD ranges > computed appropriate for that new scaling. This behavior is key to > get a scene graph to be well encapsulated. > > It sounds like in your case you have transforms above your LOD's that > scale your objects, but you still want their ranges to set in world > coords, that ignore any transforms. This would present the problem > that is the transforms scale change then the LOD would choose > different children - choosing an in-apprioriate level of detail for > the on screen size. > > Robert. > > On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer wrote: >> Studying the source a bit harder, I think the range-distance is >> definitely in Object (local) coordinate. The distance calculation >> (osg::LOD.cpp) is: >> >> required_range = nv.getDistanceToViewPoint(getCenter(),true); >> >> where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp) >> >> (pos-getViewPointLocal()).length()*getLODScale(); >> >> So, this raises the question: is there a good reason why there is no >> option to specify the LOD range distance in World Coordinates? This >> would make complex LOD graphs like the one I'm working on much, much >> simpler. Perhaps there is another method that I just do not see? >> >> cheers, >> >> sean >> >> On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer wrote: >>> >>> This may be a simple question - is the LOD range distance specified in >>> object or world coordinates? I seems as if it should be in world >>> coordinates, but I've got an example with numerous LOD nodes in sub-graphs, >>> and if I sent a constant distance range in each of them (0.0, 30.0f) so >>> that each LOD node has the same range - the LOD switch only behaves as >>> expected if the transforms above each LOD node are identical. The moment I >>> have a scale matrix above the LOD the switch becomes dependent on the >>> scaling...e.g. larger LODs switch before smaller ones. This leads me to >>> think that the LOD range distance is in object coordinates, and needs to be >>> scaled by the localToWorld transform. >>> I've had a look at the source, and it seems logical (not to mention that >>> I'd be shocked if someone hadn't had a problem before this if it were >>> incorrect) Comments? Thoughts? >>> cheers, >>> sean >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released
"Jean-Sébastien Guay" wrote: >> Whether or not debug is replaced by release in the absence of the debug >> versions for the COLLADA plugin, I do not know, though. > This was the only thing I was wondering about. > > I was aware of all the rest. I've done my share of development on Linux > you know. I just use Windows at work, but I'm not for or against one or > the other. > OK, I have misunderstood then, sorry. I thought you are asking whether it is safe to mix release and debug on Linux. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] How to run osgOcean
"Jean-Sébastien Guay" wrote: > In concrete terms, I've personally tested osgOcean on nVidia cards of > the 7800, 7900, 8800 and 9800 lines. Realistically, I think anything > above 7800 should run it fine. There are even some really good deals in > the recent GTX 2xx line that will run it admirably well. Perhaps the > 6x00 line might run it as well, but I haven't tested it personally. And > I doubt the 5x00 line and below will run it at all. Those (the 5x00s) > had finicky shader support IIRC. > I have it running on GeForce Go 7600 (laptop) and Quadro FX 4500 (GeForce 7800 equivalent), but do not expect super high framerates on such hardware. The shaders are quite slow on those cards. On the other hand, my 8800GT runs it smoothly at 1920x1200. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osgOcean collision detection
Hello, "Jean-Sébastien Guay" wrote: > Hi Jan, > > While I was at it, I started integrating the changes for getting the > ocean surface height at a position. I went with a combination of > Jean-Claude's and Dimitrios' code, with a few small modifications. > > The only problem is I have no way of testing it (it builds, thus it > works by definition, right? :-) ). Would it be possible (for either you, > Dimitrios, or Jean-Claude) to make a very simple test using the > oceanExample as base code, perhaps just making the Cessna from OSG-Data > float on the water the way you want? Then I could test if the > modifications I made work. > > I really dislike committing work-in-progress code... So I'd prefer to do > it that way. Right, of course. I have a bit of code that makes an object bob on the surface, but my code is likely a bit different from Dimitrios's, so it would need to be changed based on what you have done. Is there a place where I can get your changes? Ideally, just make an experimental branch, commit it there and once it is tested, merge into the trunk. That is fairly easy to do with SVN. > I totally agree. OceanTechnique (and thus FFTOceanSurface) already had > getSurfaceHeight(), so I added this method as getSurfaceHeightAt() and > added comments explaining that the former gets the average height, > whereas the latter gets it at a specific position. Great! That will make my life simpler. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New OpenGL texture object and buffer object pool support
pankajnagarkoti80 wrote: > The benefit the GL object pools provide is that we can scale up the > scene graph in main memory without blowing OpenGL driver and GPU > memory as we would do without the new pools. I agree, that is really a great benifit especially with the GL users. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18107#18107 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
Hi All Just wantet to add that we are also using Delta3d and as a consequence we are using the composite viewer. Brgs. Ralf Stokholm 2009/10/8 Michael Bach Jensen > Hello everyone, > > We are having the exact same problem at our company for quite some time > (currently on osg 2.8.0 via Delta3D and using TerraPage terrains). I have > verified that viewing the terrain in the osgViewer works fine, but in our > app, which also uses multiple cameras, the memory-keeps-growing-until-crash > issue occurs when the cameras are not looking at the exact same thing (have > the same projection and view matrices with the same LOD scale). The more > different they are, the easier it is to trigger the issue, it seems. > > What we did to work around the issue, is to make sure that no two cameras > in the graph render the same PagedLOD node. That is, we load the terrain > multiple times using osgDB::readNodeFile and point each camera to each > instance. > > I hope this helps on shedding some light on what is going on. > > Additional info: > Delta3D design currently limits OSG to single-threaded mode. I am on > WindowsXP, using an NVidia card, not that I think that makes a difference. > > I also seem to recall, that the active lod node list in the pager starts to > grow rapidly when I put the second camera into the scene graph at runtime. > > Cheers, > Michael > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=18075#18075 > > > > > > ___ > 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] osgUtil::simplifier parameters
On Fri, Oct 9, 2009 at 10:09 AM, Vincent Bourdier wrote: > A little update, nobody can explain me the simplifier in details ? I've explained details before so have a look through the osg-users archives. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::simplifier parameters
Hi,
A little update, nobody can explain me the simplifier in details ?
Thanks.
Regards,
Vincent
Vincent Bourdier a écrit :
Hi,
I do an update on this topic, because I would like to understand well
the osgUtil::simlifier.
This implementation seems to be very complex and powerful, but I don't
know how to manage it better.
/For that I would like to know what do the following methods and how
to set the values to have the expected result :/
void setSampleRatio(float sampleRatio) { _sampleRatio =
sampleRatio; }
/** Set the maximum point error that all point removals must
be less than to permit removal of a point.
* Note, Only used when down sampling. i.e. sampleRatio <
1.0*/
void setMaximumError(float error) { _maximumError = error; }
/** Set the maximum length target that all edges must be
shorted than.
* Note, Only used when up sampling i.e. sampleRatio > 1.0.*/
Maybe this is a noob question, but I think it can help/inform other
osg users to know precisely how to configure the Simplifier...
I set the Sample ratio to values < 1, and this seems to do some good
job on my model, but not enough... I am looking at a way to destruct a
mesh from 800 Mbyte (.ive) to 100Mbyte (.ive) (for LOD usage mainly)
I know the size of the ive file is not a good reference, but it is
important for my application. And I know that if a file is lesser, the
mesh will be lighter too...
Relative to that,
/What can make an ive file heavy// or light ?/ (example : 20M
triangles in a 850Mbyts ive file, not proportional to 13M triangles in
a 710Mbytes file)
Thanks for your help.
Regards,
Vincent.
Vincent Bourdier a écrit :
Hi Andrew
Thanks for the tip on the simplifier, lower the sample ratio is,
lower the vertex number is. (I get a crash under 0.6 but I'm not sure
this is an osg crash)
Concerning the optimiser, this do not reduce the vertex number but
the inverse... on a 460k vertices model, the optimizer returns me a
480k vertices model ...
I'm looking for a destructive optimizer/simplifier for my model... Do
you have any other tips or idea ?
Thanks.
Regards,
Vincent.
2009/9/21 Andrew Burnett-Thompson <mailto:aburnettthomp...@googlemail.com>>
Hi there,
I've experimented with the simplifier, but am not using it.
I found the setSampleRatio() method affects how coarse or fine a
result you get. The simplification with a sample ratio less that
1.0 appears to be destructive (i.e. Geometry out does not equal
Geometry in). So far I've not found the right settings to be
beneficial for my needs (which is reduction of memory consumption
while keeping the mesh the same or similar).
Another way of reducing the vertex count in your scene is to use
the Optimizer. Here I have found that using the Optimizer with the
options MERGE_GEOMETRY, CHECK_GEOMETRY and TRISTRIP_GEOMETRY can
significantly reduce the number of vertices/primitives in each
Geometry object, while giving you essentially the same mesh out.
On Mon, Sep 21, 2009 at 10:10 AM, Vincent Bourdier
mailto:vincent.bourd...@gmail.com>>
wrote:
Up ?
No one does osg simplifications ?
Thanks,
Vincent.
2009/9/17 Vincent Bourdier mailto:vincent.bourd...@gmail.com>>
Hi all,
Using the osg simplifier on a geometry, I'm just surprised
to see that there is no way to set a level of
simplification or something like that.
Maybe I didn't saw it, but for the moment I just found
_sm->setDoTriStrip(true); //what for ? do triangle strip
are more optimized ?
_sm->setSampleRatio(?); //what does it mean ? what does it
changes ?
...
How can I control the simplification level ?
Is this simplifier a destructive one ? (can deform the
geometry)
Thanks.
Regards,
Vincent.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__ Information from ESET NOD32 Antivirus, version of virus
signature database 4487 (20091007) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4492 (20091009
Re: [osg-users] osg::LOD range distance Coordinate System Question
Hi Sean, You are correct the range distance of LOD's are in the LOD's own local co-coordinate system. This is appropriate as you almost aways want LOD's to scale relative to a screen size, and doing the calc in local coordinate allows you to decorate subgraphs with LOD's with transforms that scale up or down the subgraph and still have the LOD ranges computed appropriate for that new scaling. This behavior is key to get a scene graph to be well encapsulated. It sounds like in your case you have transforms above your LOD's that scale your objects, but you still want their ranges to set in world coords, that ignore any transforms. This would present the problem that is the transforms scale change then the LOD would choose different children - choosing an in-apprioriate level of detail for the on screen size. Robert. On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer wrote: > Studying the source a bit harder, I think the range-distance is > definitely in Object (local) coordinate. The distance calculation > (osg::LOD.cpp) is: > > required_range = nv.getDistanceToViewPoint(getCenter(),true); > > where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp) > > (pos-getViewPointLocal()).length()*getLODScale(); > > So, this raises the question: is there a good reason why there is no > option to specify the LOD range distance in World Coordinates? This > would make complex LOD graphs like the one I'm working on much, much > simpler. Perhaps there is another method that I just do not see? > > cheers, > > sean > > On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer wrote: >> >> This may be a simple question - is the LOD range distance specified in >> object or world coordinates? I seems as if it should be in world >> coordinates, but I've got an example with numerous LOD nodes in sub-graphs, >> and if I sent a constant distance range in each of them (0.0, 30.0f) so that >> each LOD node has the same range - the LOD switch only behaves as expected >> if the transforms above each LOD node are identical. The moment I have a >> scale matrix above the LOD the switch becomes dependent on the >> scaling...e.g. larger LODs switch before smaller ones. This leads me to >> think that the LOD range distance is in object coordinates, and needs to be >> scaled by the localToWorld transform. >> I've had a look at the source, and it seems logical (not to mention that I'd >> be shocked if someone hadn't had a problem before this if it were incorrect) >> Comments? Thoughts? >> cheers, >> sean > ___ > 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
