Re: [osg-users] OSGViewer 'o' save scene key removed?
Hi Martin, I coded up a solution using the handlers and submitted it to Robert. You can find it on the osg-submissions list. Maybe take a look at it and see how it compares to what you've done. What I did was basically replicate what was in the osgkeyboardmouse example into osgviewer. Thanks. chuck > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Martin Beckett > Sent: Thursday, March 04, 2010 5:48 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] OSGViewer 'o' save scene key removed? > > Hi, > I coded something to do this as a test of writing handlers > > It's probably not the best solution - the keyboardhandler example > describes using a single handler with loadable functions mapped to each > key. > > But this does work and should get you started. > It saves the entire scene with a filename which increments with each > save. > > Cheers, > Martin > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=25218#25218 > > > > > Attachments: > http://forum.openscenegraph.org//files/keysavehandler_394.h > > > ___ > 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] OSGViewer 'o' save scene key removed?
Hi Chris, Robert, Thanks for bringing this up. I never knew the feature existed before. And it definitely could have saved me quite a bit of work in the past. I guess I wasn't diligent enough in going over the code to see this. What I would find useful in this feature is how to write/update/tweak .osg files manually, specifically on how to format particular settings, how to nest the nodes, etc. I, unfortunately, do not have any terrain or model editing software (and Blender is way over my head). So I've found myself manually editing the .osg files to capture exactly what I need, but struggle with the formats, syntax, etc. that is required without a detailed reference. To help with this, I have typically added in a line of code in my own software to write out the model to a file, and then use it as reference. > I've removed the entry and if we do ever add it back then we can > always update the wiki again. > This feature would definitely be useful to me. If nobody has carried it through from the previous version and others view it as helpful as well, I can take a stab at putting it back in. And if there are any suggestions before I go through with this, please post them. Thanks. Chuck Cole ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi J-S, > I just realized I didn't give you actual information, just how we get > the values... The radius turns out to be around 5000m most of the time. > In our simulators, most of the time the user will stay in an area about > 100mx100m in the center of the scene, so this works well. I think if we > were to make a flight sim where the user can travel large distances > this > wouldn't work and we'd need to do it differently. Thanks again. All of my apps have been "flight sim"-like apps, so a large radius is required. But I do things differently. I may try your approach and see if I can get better performance while still keeping relevant and viewable information from being culled. chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometryconsidered in near+far plane auto computation
Hi J-S,
Thanks for keeping this post going with what you've done. I've been keeping an
eye on it with keen interest. I do have one question though out of curiosity
... what dimensions (particularly the radius) did you use to generate the
skydome? I see that you use the radius to determine the far plane value, but
didn't know what you used. I'm assuming that it has to be great enough to
still be viewed as being far field.
Thanks.
Chuck
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
> boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay
> Sent: Tuesday, April 28, 2009 10:14 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Geometryconsidered in near+far plane auto
> computation
>
> Hello Chris,
>
> >> I wonder if there were somehow a callback you could apply
> somewhere
> >> that would hork with
> >> the near/far clip, or if it's just easier to use multiple cameras at
> >> that point.
> >
> > Perhaps in a Drawable DrawCallback? Something like:
>
> OK, I've finally got this to work well, without the need to add an
> extra
> camera. It's a classic two-pronged attack:
>
> 1. Use a CullCallback that sets the compute near/far mode to off,
> traverses the skydome and resets it to the previous value.
> 2. Use a drawable DrawCallback on all the skydome's drawables that will
> calculate the maximum possible value the far plane would need to be at
> for the skydome to be visible from the current camera position, draws
> the drawable, and resets the old far plane after drawing.
>
> One thing I found I needed to do is keep the same near plane value as
> was set before, otherwise the skydome seemed to move when the camera
> moved.
>
> Here's the code I'm using:
>
> struct DoNotIncludeInNearFarComputationCallback
> : public osg::NodeCallback
> {
> virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
> {
> osgUtil::CullVisitor *cv =
> dynamic_cast< osgUtil::CullVisitor*>( nv );
>
> // Default value
> osg::CullSettings::ComputeNearFarMode oldMode =
>
> osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES;
>
> if( cv )
> {
> oldMode = cv->getComputeNearFarMode();
> cv->setComputeNearFarMode(
> osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
> }
>
> traverse(node, nv);
>
> if( cv )
> {
> cv->setComputeNearFarMode(oldMode);
> }
> }
> };
>
> struct OverrideNearFarValuesCallback
> : public osg::Drawable::DrawCallback
> {
> OverrideNearFarValuesCallback(SkyDome* skyDome)
> : m_skyDome(skyDome) {}
>
> virtual void drawImplementation(osg::RenderInfo& renderInfo,
> const osg::Drawable* drawable)
> const
> {
> osg::Camera* currentCamera = renderInfo.getCurrentCamera();
> if (currentCamera)
> {
> // Get the current camera position.
> osg::Vec3 eye, center, up;
> renderInfo.getCurrentCamera()->getViewMatrixAsLookAt(
> eye, center, up);
>
> // Get the max distance we need the far plane to be at,
> // which is the distance between the eye and the skydome's
> // center, plus the skydome's radius.
> double distance = (m_skyDome->getCenter() - eye).length()
> +
> m_skyDome->getRadius();
>
> // Save old values.
> osg::ref_ptr oldProjectionMatrix =
> new osg::RefMatrix;
> oldProjectionMatrix->set(
> renderInfo.getState()->getProjectionMatrix());
>
> // Get the individual values
> double left, right, bottom, top, zNear, zFar;
> oldProjectionMatrix->getFrustum(
> left, right, bottom, top, zNear, zFar);
>
> // Build a new projection matrix with a modified far plane
> osg::ref_ptr projectionMatrix =
> new osg::RefMatrix;
> projectionMatrix->makeFrustum(
> left, right, bottom, top, zNear, distance);
> renderInfo.getState()->applyProjectionMatrix(
> projectionMatrix.get());
>
> // Draw the drawable
> drawable->drawImplementation(renderInfo);
>
> // Reset the far plane to the old value.
> renderInfo.getState()->applyProjectionMatrix(
> oldProjectionMatrix.get());
> }
> else
> {
> drawable->drawImplementation(renderInfo);
> }
> }
>
> SkyDome* m_skyDome;
> };
>
> struct AddCallbackToDrawablesVisitor : public osg::NodeVisitor
> {
> AddCallbackToDrawablesVisitor(SkyDome* skyDome)
> : osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN),
>m_skyDo
Re: [osg-users] Geometry considered in near+far plane auto computation
Hi J-S, Although not an optimal solution, and probably more of a work-around to your question ... I use a skydome as well. In my case, I just create a sphere whose radius is that (or a little less than that) of the camera's far-field value, which I've set to be quite large (60,000-meters). This works for my use case. But again, it's not an optimal solution. I'd also be interested in a more optimal and scalable solution. chuck > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay > Sent: Tuesday, April 21, 2009 12:13 PM > To: OpenSceneGraph Users > Subject: [osg-users] Geometry considered in near+far plane auto > computation > > Hi all, > > I need some nodes to be ignored by the near+far plane auto computation. > I was wondering, is there some other way than > setReferenceFrame(ABSOLUTE_RF) to do this? > > My specific use case is a skydome. It needs to be very large, but still > be "in the world" - if I use the same trick as for a skybox (moving the > cube with the camera) it will look like the horizon moves up relative > to > the terrain if I move the camera higher in altitude... Not a desirable > effect. > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems shutting down Composite Viewer/View/Custom drawables
Hi David, Thanks for the response. It ended up being how I declared the destructor for my derived class as J-S pointed out. I was going down the path of when and if I needed to call releaseGLObjects() and nothing seemed to make a difference. And I'm still a little unsure of when that method should be called (or even if it should). But, fixing the destructor declaration stopped the crashes that I was seeing and I'm not explicitly calling releaseGLObjects() at all right now, on any object. chuck From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of David Spilling Sent: Friday, March 27, 2009 8:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems shutting down Composite Viewer/View/Custom drawables Chuck, I have had similar issues (with crashes in releaseGLObjects when views get destroyed) but can't actually recall what I did to fix them. You could try calling viewer->releaseGLObjects() before you destroy the view. (previous posts seem to suggest that this might be the right thing to do) David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems shutting down Composite Viewer/View/Custom drawables
Hi J-S, > One thing you need to be careful of when deriving classes from OSG base > classes which themselves derive from osg::Referenced ... In most cases, > the destructors of those classes should be protected. Since they're > normally protected already (as in osg::Object, osg::Drawable, etc) you > shouldn't expose them in public scope in your derived class, which > would > allow them to be (erroneously) deleted at any time by the application > instead of being deleted automatically when their ref count goes down > to 0. That was the problem. The destructor of my derived class was public. I changed it to protected and to use a ref_ptr for the class and no more crashes. I'm not sure I would have ever found this bug. I wasn't even looking in that direction. So, thanks so much! chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems shutting down Composite Viewer/View/Custom drawables
Hi J-S, When I referred to "destroy", what I'm doing is calling 'delete' on the classes that contain the ref_ptrs. For instance, I call delete on my view class, and in the view class' destructor, I (eventually) call delete on the drawables. So I'm in effect doing what you're saying, with the exception of the class containing the composite viewer. I'll change some code around to reflect that and see how it goes. Thanks. chuck > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay > Sent: Friday, March 27, 2009 1:45 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Problems shutting down Composite > Viewer/View/Custom drawables > > Hi Charles, > > > My attempted process to close is that I (1) set a flag on a render > thread to stop calling viewer->frame (very similar to setDone(true)); > (2) destroy the loaded drawables and free their associated libraries; > (3) destroy the view, and thus it's associated camera and graphics > context; and (4) destroy the composite viewer. I use reference > pointers in every case except for the composite viewer (although I've > tried a reference pointer for it as well, but still get the same > result). > > Just wondering, if you're using ref_ptrs, why don't you just let the > CompositeViewer's ref_ptr go out of scope (or delete the object that > has > the ref_ptr) and be done with it? That should cascade > down, destroying the views, then each view's scene graph. And if your > custom drawables do the right thing in their destructors, that should > be > taken care of too. You shouldn't have to manage destruction order > yourself. > > Perhaps I'm missing something here, but that generally just works. > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems shutting down Composite Viewer/View/Custom drawables
Hi all, I forgot to mention in my long-winded post that I'm using OSG 2.8.0. chuck > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- > boun...@lists.openscenegraph.org] On Behalf Of Cole, Charles E. (LARC- > B702)[RAYTHEON TECHNICAL SERVICES COMPANY] > Sent: Friday, March 27, 2009 12:51 PM > To: OpenSceneGraph Users > Subject: [osg-users] Problems shutting down Composite > Viewer/View/Custom drawables > > Hi all, > > I've been chasing an error in my code for many, many days that I'm > hoping that someone can help me track down. I'll try to explain my > application as best I can. > > I'm using a composite viewer to load multiple views. In each view, I'm > loading a database scene (generally a TXP database) and overlaying > OpenGL nodes that I load dynamically and add as drawables to the > scenegraph. I've created classes to encapsulate the composite viewer, > view, and scene nodes. For instance, I have a class that contains a > composite viewer member variable; this class then creates multiple > "View" classes that each contain an osgViewer::View member variable. > Each view then loads scene nodes as specified in a configuration file. > These nodes are contained in separate libraries and are loaded as > drawables (I've created a class derived from osg::Drawable and > overwrite the drawImplementation method for custom drawing). > Everything works great when creating the viewer, view, nodes, and even > executing. The problem comes when I try to destroy/close the window. > > My attempted process to close is that I (1) set a flag on a render > thread to stop calling viewer->frame (very similar to setDone(true)); > (2) destroy the loaded drawables and free their associated libraries; > (3) destroy the view, and thus it's associated camera and graphics > context; and (4) destroy the composite viewer. I use reference > pointers in every case except for the composite viewer (although I've > tried a reference pointer for it as well, but still get the same > result). > > When trying to follow the above process, the application crashes in the > Node::releaseGLObjects method at line 523, if (_updateCallback.valid()) > _updateCallback.releaseGLObjects(state). > > I also noticed during a debug walkthrough that the drawables > drawImplementation method (and thus the custom drawable's own custom > drawing methods) are still being called after the render thread has > been stopped and destroyed. > > So, some of my many questions are: > > (1) Is there a preferred/required means or order for shutting down a > composite viewer (and it's child nodes)? > > (2) Separately, but possibly related ... I create a camera callback > function to update the camera position per shared memory variables. > I'd like to destroy that callback function appropriately. But, in > doing so, how do I reset the camera's callback function such that it's > not called once the custom callback function is destroyed? > > (3) What's the appropriate means of stopping the rendering? I thought > that if viewer->frame() wasn't getting called, the drawImplementation > method of the drawables would no longer be called, so I could then free > those libraries. But, unfortunately, they're still being called even > though frame() is no longer called. And thus, the libraries are trying > to be freed when the viewer is still trying to draw them. > > I am running multithreaded. I'm using VS 2008 SP1 on Windows XP and > Vista. > > If anyone has any tips, pointers, something to point me in the right > direction before I end up throwing the computer through the window, I'd > greatly appreciate it. I hope I've provided enough information. > > Thanks so much in advance. > > Chuck > > ___ > 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] Problems shutting down Composite Viewer/View/Custom drawables
Hi all, I've been chasing an error in my code for many, many days that I'm hoping that someone can help me track down. I'll try to explain my application as best I can. I'm using a composite viewer to load multiple views. In each view, I'm loading a database scene (generally a TXP database) and overlaying OpenGL nodes that I load dynamically and add as drawables to the scenegraph. I've created classes to encapsulate the composite viewer, view, and scene nodes. For instance, I have a class that contains a composite viewer member variable; this class then creates multiple "View" classes that each contain an osgViewer::View member variable. Each view then loads scene nodes as specified in a configuration file. These nodes are contained in separate libraries and are loaded as drawables (I've created a class derived from osg::Drawable and overwrite the drawImplementation method for custom drawing). Everything works great when creating the viewer, view, nodes, and even executing. The problem comes when I try to destroy/close the window. My attempted process to close is that I (1) set a flag on a render thread to stop calling viewer->frame (very similar to setDone(true)); (2) destroy the loaded drawables and free their associated libraries; (3) destroy the view, and thus it's associated camera and graphics context; and (4) destroy the composite viewer. I use reference pointers in every case except for the composite viewer (although I've tried a reference pointer for it as well, but still get the same result). When trying to follow the above process, the application crashes in the Node::releaseGLObjects method at line 523, if (_updateCallback.valid()) _updateCallback.releaseGLObjects(state). I also noticed during a debug walkthrough that the drawables drawImplementation method (and thus the custom drawable's own custom drawing methods) are still being called after the render thread has been stopped and destroyed. So, some of my many questions are: (1) Is there a preferred/required means or order for shutting down a composite viewer (and it's child nodes)? (2) Separately, but possibly related ... I create a camera callback function to update the camera position per shared memory variables. I'd like to destroy that callback function appropriately. But, in doing so, how do I reset the camera's callback function such that it's not called once the custom callback function is destroyed? (3) What's the appropriate means of stopping the rendering? I thought that if viewer->frame() wasn't getting called, the drawImplementation method of the drawables would no longer be called, so I could then free those libraries. But, unfortunately, they're still being called even though frame() is no longer called. And thus, the libraries are trying to be freed when the viewer is still trying to draw them. I am running multithreaded. I'm using VS 2008 SP1 on Windows XP and Vista. If anyone has any tips, pointers, something to point me in the right direction before I end up throwing the computer through the window, I'd greatly appreciate it. I hope I've provided enough information. Thanks so much in advance. Chuck ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::readFontFile returns NULL on valid argument
Hi Jesper,
My first inclination is that the path is incorrect, or at least doesn't
match with where the font file actually is. With the code snippet you
listed, I believe that the file (and path) that you list must be
relative to your project's compiled executable. That would be the first
thing that I'd check, and Paul's tip on adding the OSG_NOTIFY_LEVEL can
help if you can run your executable from a DOS window. Another means of
checking is to place the font file in the same directory as your
executable and change the readFontFile parameter to just "arial.ttf".
If that works, then that confirms that it's a path issue.
Hope that helps.
Chuck
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jesper
D. Thomsen
Sent: Wednesday, March 18, 2009 7:57 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgText::readFontFile returns NULL on valid
argument
Hi all, I have a rather strange problem.
I'm using osgText in my project, but I'm getting null as return from
this method:
osgText::Font* t_font = osgText::readFontFile("fonts/arial.ttf");
The strange part is that when I compile and run the osgText and osgHud
examples, it works just fine (so it isn't the font-file which is
missing). It only happens in my own program.
So far I have tested it on both Vista and XP machines in the office, and
this doesn't seem to affect the problem. However, my program works just
fine on a single XP machine, but not on any of the other machines. I
have tried in both debug and release modes, and tried both copying the
executable and building it on different machines, and so far it is
consistent in that the deciding factor is which machining is running the
program and not which machine it was built on.
I'm using OSG 2.6.1 in Visual Studio 2005 sp1 on a Vista machine (but
have tested on XP also).
Since the osg examples work just fine on the same machine, I guess it is
something I have done in either the project settings or somewhere in the
code, but I'm running out of ideas. If anybody have tried something like
this, or knows what could cause this, I would very much appreciate it.
regards, and thanks in advance.
Jesper D. Thomsen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
