[osg-users] Camera Eye psotion in scenes with large terrain

Hi all, I have a scene with large terrain where a node starts moving from a given arbitrary location on the terrain. As the starting location of the node is known, i set the camera's target to look as the node's starting position. My problem is I want to set the initial camera eye to get a

Re: [osg-users] Creating a glowing sun in scene

Hi David, Thanks for the clues to achieve the effect i needed. I have already attempted textured quad, with transparency on it. But it gives, as u said, a cheap look. Being new to multi-pass rendering with blur filter and read the link you shared. Any example on how to get started with this

[osg-users] Running OSG in a trhead on Mac OSX

Hi, I am working on a project which requires me to put my OSG updates into a thread so that the main thread can continue for integration into another process. All OSG events are done in the thread and locked with mutexes when i need to add new nodes. This works perfectly on Linux and Windows

Re: [osg-users] ReadImage not routing to plugin?

HI Rob, The OSG uses a chain of responsibility pattern for the plugins and will first attempt to load file by calling all of the currently loaded plugins first, then if it fails then look for the plugin named the same as the file extension, in your case .ogr. There are also some built in aliases

Re: [osg-users] Creating a glowing sun in scene

There are a few ways of doing this. What you most likely want to do is to look up information on high dynamic range rendering. This involves multi-pass rendering where you use some kind of blur filter to make the brighest parts of your scene bleed out. This is a resonable example:

[osg-users] ReadImage not routing to plugin?

I am trying to understand why osgDB::readImageFile( "abc.ogv" ) does not get routed to the ffmpeg plugin. I get no image loaded and I see that the readImage method of the plugin is not even called. If I call osgDB::readImageFile( "abc.ogv.ffmpeg" ) it works, but that is not going to be an

Re: [osg-users] Problematic call of flushDeletedGLObjects

Hi Robert. Thanks for your reply. People here are so helpful I tend to forgot they are not omniscient. I'm working with OSG 3.4.0, QT 5.4, and for the rest, I'll try to make a small example. -- Read this topic online here:

Re: [osg-users] Problematic call of flushDeletedGLObjects

Hi Valerian, It's not possible to know what might be amiss as you don't provide enough details about how you are doing what you are doing. You don't mention which OSG version you are using, so again it's not possible to know if this might be related. The best way to test things and make it

[osg-users] Problematic call of flushDeletedGLObjects

Hi, I can't figure out how to properly manage my composite viewer creation and destruction. My main problem is when I close one of my view and destroy my composite viewer, flushDeletedGLObjects isn't called. Then when I create a new one, I create the shaders, OSG links them to the context.

[osg-users] OSG and Qt

Hi, I have started working on Qt5.7 and OSG 3.4. Is it safe to use osg with Qt without any issue like specially Event handling . ... Thank you! Cheers, InnaReddy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68695#68695

[osg-users] Draw text on osg Sphere

Hi, I am very beginner for OSG and my first post in Forum. Currently , I am able to draw the text on the Ellipsoid , suing the lat , log and height. How I achieve the same with sphere instead of Ellipsoid. Code: osgText::Text* createText(osg::EllipsoidModel* ellipsoid, double latitude,

Re: [osg-users] SingleThreaded leading to whole application just running on one core

Hi Chris, On 23 September 2016 at 09:19, Christoph Weiss wrote: > This actually has a very bad side effect that I only noticed now. Since it > explicitly sets the affinity to core zero, any other application that does > so will share its CPU entirely with it. In particular

Re: [osg-users] SingleThreaded leading to whole application just running on one core

Hi Robert, When running SingleThread the OSG just sets the affinity of the current thread. That's it, that's all it's doing. This actually has a very bad side effect that I only noticed now. Since it explicitly sets the affinity to core zero, any other application that does so will share

Re: [osg-users] SingleThreaded leading to whole application just running on one core

On 23 September 2016 at 08:42, Christoph Weiss wrote: > Thank you so much for pointing this out, Pete. So in > ViewerBase::setUpThreading() osg decides the whole application should be > confined to a single core. When running SingleThread the OSG just sets the affinity of the

Re: [osg-users] SingleThreaded leading to whole application just running on one core

Hi Robert, wouldn't it be a better approach to give the user the option to change such a setting for their application? But thanks for pointing out the subclassing option, that's what I'll go for! Still it took me half a day to track down what was going on. (I didn't suspect OSG in the

Re: [osg-users] SingleThreaded leading to whole application just running on one core

Thank you so much for pointing this out, Pete. So in ViewerBase::setUpThreading() osg decides the whole application should be confined to a single core. Judging by your comment, this has already been discussed and not deemed a fault that should be fixed? Also, I suppose there is no way to

Re: [osg-users] SingleThreaded leading to whole application just running on one core

On 23 September 2016 at 05:25, Pete Black wrote: > This is, bizarrely, by design. > > In single-threaded mode, OpenSceneGraph silently sets CPU affinity to a > single core by default. Personally I think this is incredibly obtrusive on > the programmer, and the reasons