Re: [osg-users] How to get all visible nodes
HI Artem,
Just write a NodeVisitor that has it's traversal mode set to
TRAVERSE_ALL_CHILDREN i.e.
class FindAllNodes : public osg::NodeVisitor
{
public:
FindAllNodes():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHIILDREN) {}
void apply(osg::Node& node)
{
std::cout<<"Visiting node "<<&node Hi,
>
> I'm new to OSG, so I think I have simple question, but I cannot find
> answer for it.
> Actually I'm working with osgEarth and have some osgEarth::PlaceNodes on
> the terrain, some models and so on.
> So, I have lots of views.
>
> For some needs, I need a mechanism which will allow me to get all the
> views inside a screen
> (I mean which are visible to me at the moment and which are inside my
> screen).
> I didn't find any information about the way I can implement this.
>
> I'm sure that I've missed something.
> I would appreciate any help with this.
>
> Thank you!
>
> Cheers,
> Artem
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65244#65244
>
>
>
>
>
> ___
> 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] OSG and NVX_gpu_memory_info
HI Garth, I'd use a RealizerOperation. Have a look at the osgvolume example to an example of using a RealizerOperation to get information from the graphics context. Robert. On 30 September 2015 at 03:49, Garth D wrote: > Hi all, > > I was wondering if anyone has been successful in using the > NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to > call glGetIntegerv to get the associated values. > > Details on the extension here: > https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt > > I'm using Linux, OSG 3.2.1, and a card that supports the > NVX_gpu_memory_info extension. > > I have tried querying the current and total memory using > GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and > GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the > values reported back are zero. > > The only success I have had thus far has been querying the values via an > osg::Operation set with ViewerBase::setRealizeOperation() on my viewer > (osg::Viewer). The values returned appear to be correct. This allows me to > get the correct values *once* at the start of the program. Unfortunately I > need to query them periodically, and I have been unable to do this. > > So far, I have tried hooking the calls into: > - An osg::Camera::DrawHandler, set via > osg::Camera::setInitialDrawCallback(). > - An osg::Node::NodeHandler, hooked into the root node via > osg::Node::setUpdateCallback. > - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root > of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via > osg::Drawable::setDrawCallback. > - An osg::Drawable::CullCallback , hooked into a dummy chain off the root > of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via > osg::Drawable::setCullCallback. > - An osg::Camera::DrawHandler, set via > osg::Camera::setFinalDrawCallback(). Only partly-tested due to a > race-condition that occurs in my code, but appears to fail. > > I have experimented with osg::GraphicsContext::makeCurrent() with each. > > Can anyone suggest a better place to hook these calls into? Or > alternatively confirm that they have the extension working with one of the > above, so I can change or experiment with my existing setup to try to make > it work? > > Cheers, > Garth > ___ > 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] Threads leakage with late use of osgViewer::setThreadingModel()
Hello list, we are experiencing a situation on OSG 3.2.x on Linux where we are unable to create new instances of osgViewer because pthread_create() suddenly fails with ENOMEM. Our investigation showed that this was due to calling osgViewer::setThreadingModel(osgViewer::Viewer::SingleThreaded) after osgViewer::realize() on a machine that has a default threading model different to osgViewer::Viewer::SingleThreaded. This caused the thread to be created, but not yet running and thus not stopped and destroyed in osgViewer::setThreadingModel(), leaking the thread's allocated memory. Is it a known convention that one should not call setThreadingModel() after realize() or did we hit a bug? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi Robert, Thanks for having a look at things and for the suggestion. On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, > I'd use a RealizerOperation. Have a look at the osgvolume example to an > example of using a RealizerOperation to get information from the graphics > context. I was unfortunately unable to solve the problem. Here is what I tried: I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a RealizerOperation in either. I did notice that osgvolume does also use viewer.setRealizeOperation() for TestSupportOperation, defined earlier. Is this what you are referring to? Assuming yes: This is the way I was able to successfully query the information once only at the start of the program. Unfortunately I need to query the information periodically, ie. over the course of the program, rather than just at initialisation. Unless I am mistaken, the target of setRealizeOperation is only called the one time, on viewer realization. Is this right? If so: Is there a corresponding call that I can use to attach an osg::Operation or similar to in order to make the required calls periodically? If not: Is there a way to indicate that the operation should be repeatedly called? Or is there another part of osgvolume.cpp that I should be looking at? The only glGet* call in the file is in TestSupportOperation, which is set using setRealizeOperation(), so I think I am looking in the right place? I'll continue to experiment. Thanks again for the suggestion. Is there anything else I should try? Cheers, Garth > > Robert. > > On 30 September 2015 at 03:49, Garth D > wrote: > >> Hi all, >> >> I was wondering if anyone has been successful in using the >> NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to >> call glGetIntegerv to get the associated values. >> >> Details on the extension here: >> https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt >> >> I'm using Linux, OSG 3.2.1, and a card that supports the >> NVX_gpu_memory_info extension. >> >> I have tried querying the current and total memory using >> GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and >> GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the >> values reported back are zero. >> >> The only success I have had thus far has been querying the values via an >> osg::Operation set with ViewerBase::setRealizeOperation() on my viewer >> (osg::Viewer). The values returned appear to be correct. This allows me to >> get the correct values *once* at the start of the program. Unfortunately I >> need to query them periodically, and I have been unable to do this. >> >> So far, I have tried hooking the calls into: >> - An osg::Camera::DrawHandler, set via >> osg::Camera::setInitialDrawCallback(). >> - An osg::Node::NodeHandler, hooked into the root node via >> osg::Node::setUpdateCallback. >> - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via >> osg::Drawable::setDrawCallback. >> - An osg::Drawable::CullCallback , hooked into a dummy chain off the root >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via >> osg::Drawable::setCullCallback. >> - An osg::Camera::DrawHandler, set via >> osg::Camera::setFinalDrawCallback(). Only partly-tested due to a >> race-condition that occurs in my code, but appears to fail. >> >> I have experimented with osg::GraphicsContext::makeCurrent() with each. >> >> Can anyone suggest a better place to hook these calls into? Or >> alternatively confirm that they have the extension working with one of the >> above, so I can change or experiment with my existing setup to try to make >> it work? >> >> Cheers, >> Garth >> ___ >> 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] OSG and NVX_gpu_memory_info
HI Garth, Sorry for the typo, the setRealizeOperation is what I was referring to. If you want to check periodically then just use a Camera::DrawCallback attached to the main camera attached to the GraphicsContext/Window of interest. This will be called every frame, but within this callback you could have your own check to see if the GL calls are required for that frame. Robert. On 30 September 2015 at 10:56, Garth D wrote: > > Hi Robert, > > Thanks for having a look at things and for the suggestion. > > On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, > > I'd use a RealizerOperation. Have a look at the osgvolume example to an > > example of using a RealizerOperation to get information from the graphics > > context. > > I was unfortunately unable to solve the problem. Here is what I tried: > > I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a > RealizerOperation in either. > > I did notice that osgvolume does also use viewer.setRealizeOperation() for > TestSupportOperation, defined earlier. Is this what you are referring to? > Assuming yes: This is the way I was able to successfully query the > information once only at the start of the program. Unfortunately I need to > query the information periodically, ie. over the course of the program, > rather than just at initialisation. Unless I am mistaken, the target of > setRealizeOperation is only called the one time, on viewer realization. Is > this right? If so: Is there a corresponding call that I can use to attach > an osg::Operation or similar to in order to make the required calls > periodically? If not: Is there a way to indicate that the operation should > be repeatedly called? > > Or is there another part of osgvolume.cpp that I should be looking at? The > only glGet* call in the file is in TestSupportOperation, which is set using > setRealizeOperation(), so I think I am looking in the right place? > > I'll continue to experiment. Thanks again for the suggestion. Is there > anything else I should try? > > Cheers, > Garth > > > > > > Robert. > > > > On 30 September 2015 at 03:49, Garth D > > wrote: > > > >> Hi all, > >> > >> I was wondering if anyone has been successful in using the > >> NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to > >> call glGetIntegerv to get the associated values. > >> > >> Details on the extension here: > >> https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt > >> > >> I'm using Linux, OSG 3.2.1, and a card that supports the > >> NVX_gpu_memory_info extension. > >> > >> I have tried querying the current and total memory using > >> GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and > >> GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, > the > >> values reported back are zero. > >> > >> The only success I have had thus far has been querying the values via an > >> osg::Operation set with ViewerBase::setRealizeOperation() on my viewer > >> (osg::Viewer). The values returned appear to be correct. This allows me > to > >> get the correct values *once* at the start of the program. > Unfortunately I > >> need to query them periodically, and I have been unable to do this. > >> > >> So far, I have tried hooking the calls into: > >> - An osg::Camera::DrawHandler, set via > >> osg::Camera::setInitialDrawCallback(). > >> - An osg::Node::NodeHandler, hooked into the root node via > >> osg::Node::setUpdateCallback. > >> - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root > >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via > >> osg::Drawable::setDrawCallback. > >> - An osg::Drawable::CullCallback , hooked into a dummy chain off the > root > >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via > >> osg::Drawable::setCullCallback. > >> - An osg::Camera::DrawHandler, set via > >> osg::Camera::setFinalDrawCallback(). Only partly-tested due to a > >> race-condition that occurs in my code, but appears to fail. > >> > >> I have experimented with osg::GraphicsContext::makeCurrent() with each. > >> > >> Can anyone suggest a better place to hook these calls into? Or > >> alternatively confirm that they have the extension working with one of > the > >> above, so I can change or experiment with my existing setup to try to > make > >> it work? > >> > >> Cheers, > >> Garth > >> ___ > >> 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] osgAndroid - Deploying and Debugging
Hi Just an update. I managed to make osgAndroidExampleGLES1 work based on the Android.mk settings for osgSimple and am able to load cessna.osg or any other osg models. However, i am still not able to make osgSimple work based on the predefined setting. If anyone is interested then I can provide a complete step by step guide for making osgAndroid compile and run the osgAndroidExampleGLES1 example on an Android device (with development environment on both Windows 10 and Ubuntu 14.0.4) regards Shamim On Tue, Sep 29, 2015 at 3:12 PM, Akhtar Shamim wrote: > Hi Rafa > > Thank you for the pointer. I managed to compile and run the application in > an Android device successfully. > I have also managed to compile and run the osgAndroidExampleGLES1 on my > mobile device. I can see the blue background for the example together with > three buttons. > > However, now when i try to load a model (cessna.osg) it shows error: > dlopen failed: library osgPlugins-3.4.0/osgdb_osg.so" not found. > DynamicLibrary::failed loading "osgPlugins-3.4.0/osgdb_osg.so". It is > strange because the build is static build yet it is looking for .so file. > > I am not too sure why this is happening. Any pointer will be very helpful. > > regards > Shamim > > > On Mon, Sep 28, 2015 at 5:08 PM, Rafa Gaitan > wrote: > >> Hi Shamim, >> >> I added glustl_shared to be loaded dynamically before loading any >> osgAndroid jni library, because linking it statically was giving a lot of >> problems. >> >> I don't recall having problems before, but I usually work on linux or mac >> when I have to develop in android and OSG. Maybe is something related to >> the r10e NDK?. >> >> Anyway, could you check if you have in your >> org.openscenegraph.android/libs/armeabi/ the library libgnustd_shared.so?, >> if not, probably you need to copy it there from the NDK. >> >> I don't recall if I copied it by myself that or it's automated somehow by >> the NDK build system. But if you have it there along the libjni-osggles*.so >> libraries it will be deployed within the apk. >> >> Regards, >> Rafa. >> >> >> El lun., 28 sept. 2015 a las 9:34, Akhtar Shamim () >> escribió: >> >>> Hi >>> >>> Recently we had a requirement to build OSG for Android and load a >>> OpenFlight MetaFight file. This is what I did: >>> >>> - Checkout the 3.4.0 stable release of OSG >>> - Installed Android NDK, SDK and Eclipse. >>> - Used the toolchain to compile OSG for GLES1 >>> - Downloaded OSGAndroid from GitHub >>> - Imported to Eclipse >>> - Build all the four projects >>> >>> So far there is no problem at all. Everything went smooth. >>> >>> However, when I am trying to deploy the osgsimple application using >>> eclipse or trying to debug the application it throws an error saying: >>> >>> "Couldn't load gnustl_shared from loader dalvik.system.PathClassLoader". >>> >>> This is what I did: >>> - Modified Android.mk to have the correct OSG_SDK path >>> - Modified Android.mk to have the correct plugins (osgPlugins-3.4.0) >>> >>> Note: >>> >>> (a) No other changes made to any files downloaded from GitHub for >>> osgAndroid. >>> (b) The command used to configure cmake is <<< >>> >>> > set ANDROID_NDK=C:\Android\android-ndk-r10e >>> > "c:\Program Files (x86)\CMake 2.8\bin\cmake.exe" .. -G"MinGW >>> Makefiles" -DANDROID_NDK=C:/Android/android-ndk-r10e >>> -DCMAKE_TOOLCHAIN_FILE=../PlatformSpecifics/Android/android.toolchain.cmake >>> -DCMAKE_MAKE_PROGRAM="%ANDROID_NDK%\prebuilt\windows-x86_64\bin\make.exe" >>> -DOPENGL_PROFILE="GLES1" -DDYNAMIC_OPENTHREADS=OFF >>> -DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NATIVE_API_LEVEL=15 >>> -DANDROID_ABI=armeabi -DCMAKE_INSTALL_PREFIX=C:/Android/OSG_ES1-3.4.0 >>> >>> > make -j 8 >>> > make install >>> >>> >>> >>> I tried the above in Windows 10. >>> >>> Any help to get this resolved will be greatly appreciated. >>> >>> regards >>> Shamim >>> >>> >>> >>> >>> >>> >>> >>> ___ >>> 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] OSG and NVX_gpu_memory_info
Hi Robert, On 30/09/15 19:50, Robert Osfield wrote:> HI Garth, > Sorry for the typo, the setRealizeOperation is what I was referring to. Not a problem, thanks for the clarification. > If you want to check periodically then just use a Camera::DrawCallback > attached to the main camera attached to the GraphicsContext/Window of > interest. This will be called every frame, but within this callback you > could have your own check to see if the GL calls are required for that > frame. Thanks. This was one of the configurations I had tried (with setInitialDrawCallback() and setFinalDrawCallback()), and the one I had the best hopes for. Unfortunately the calls failed. I'm not certain, but I seem to remember that other GL calls worked fine in this setup, and that it was only the calls related to NVX_gpu_memory_info that were failing. Perhaps this is all an oddity relating to NVX_gpu_memory_info specifically? I also want to try this the setup you describe here *exactly*, in case this changes the result. At this point I think I'm going to have to put something minimalistic together and have an further experiment with it. I'll post a follow-up when I've got some results. Cheers, Garth > On 30 September 2015 at 10:56, Garth D > wrote: >> Thanks for having a look at things and for the suggestion. >> >> On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, >>> I'd use a RealizerOperation. Have a look at the osgvolume example to an >>> example of using a RealizerOperation to get information from the graphics >>> context. >> >> I was unfortunately unable to solve the problem. Here is what I tried: >> >> I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a >> RealizerOperation in either. >> >> I did notice that osgvolume does also use viewer.setRealizeOperation() for >> TestSupportOperation, defined earlier. Is this what you are referring to? >> Assuming yes: This is the way I was able to successfully query the >> information once only at the start of the program. Unfortunately I need to >> query the information periodically, ie. over the course of the program, >> rather than just at initialisation. Unless I am mistaken, the target of >> setRealizeOperation is only called the one time, on viewer realization. Is >> this right? If so: Is there a corresponding call that I can use to attach >> an osg::Operation or similar to in order to make the required calls >> periodically? If not: Is there a way to indicate that the operation should >> be repeatedly called? >> >> Or is there another part of osgvolume.cpp that I should be looking at? The >> only glGet* call in the file is in TestSupportOperation, which is set using >> setRealizeOperation(), so I think I am looking in the right place? >> >> I'll continue to experiment. Thanks again for the suggestion. Is there >> anything else I should try? >> >>> On 30 September 2015 at 03:49, Garth D >>> wrote: >>> Hi all, I was wondering if anyone has been successful in using the NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to call glGetIntegerv to get the associated values. Details on the extension here: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt I'm using Linux, OSG 3.2.1, and a card that supports the NVX_gpu_memory_info extension. I have tried querying the current and total memory using GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, >> the values reported back are zero. The only success I have had thus far has been querying the values via an osg::Operation set with ViewerBase::setRealizeOperation() on my viewer (osg::Viewer). The values returned appear to be correct. This allows me >> to get the correct values *once* at the start of the program. >> Unfortunately I need to query them periodically, and I have been unable to do this. So far, I have tried hooking the calls into: - An osg::Camera::DrawHandler, set via osg::Camera::setInitialDrawCallback(). - An osg::Node::NodeHandler, hooked into the root node via osg::Node::setUpdateCallback. - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setDrawCallback. - An osg::Drawable::CullCallback , hooked into a dummy chain off the >> root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setCullCallback. - An osg::Camera::DrawHandler, set via osg::Camera::setFinalDrawCallback(). Only partly-tested due to a race-condition that occurs in my code, but appears to fail. I have experimented with osg::GraphicsContext::makeCurrent() with each. Can anyone suggest a better place to hook these calls into? Or alternatively confir
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi all, > - An osg::Camera::DrawHandler... > - An osg::Node::NodeHandler... I just noticed some mistakes in my original post: DrawHandler should be DrawCallback, and NodeHandler should be NodeCallback. Sorry about that. I'm writing the emails on one machine and reading from another, and these mistakes snuck through. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Avoiding texture release
Hi, I have a switch node with two geodes containing one geometry each, shallow-copied from the same geometry but with different state sets having different textures. The textures are large (8192x8192) and this causes a massive frame drop when switching between the two geodes at runtime. I know it's the textures causing the hickup since it doesn't happen when not setting the texture attributes. I have tried applying a GLObjectsVisitor before adding the geodes to the switch, and after adding them, setting a 0x node mask. I have tried applying a TextureVisitor with changeAutoUnref and valueAutoUnref. I have also tried setting an IncrementalCompileOperation although I don't really know why. Nothing helps, how can I avoid these frame drops? I guess I want to avoid a releaseGLObjects happening somewhere? Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Avoiding texture release
Hi Andreas, I suspect just letting the OSG do it's thing with be just fine, and it's simply the amount of memory on the GPU that these textures take is fundamental problem you need to address. Try texture compression on the textures, or try a small pixel format. The other approach would be to tile that data up so you have a set of smaller textures each applied to it's own Geode. Robert. On 30 September 2015 at 14:25, Andreas Ekstrand < andreas.ekstr...@remograph.com> wrote: > Hi, > > I have a switch node with two geodes containing one geometry each, > shallow-copied from the same geometry but with different state sets having > different textures. The textures are large (8192x8192) and this causes a > massive frame drop when switching between the two geodes at runtime. I know > it's the textures causing the hickup since it doesn't happen when not > setting the texture attributes. > > I have tried applying a GLObjectsVisitor before adding the geodes to the > switch, and after adding them, setting a 0x node mask. I have tried > applying a TextureVisitor with changeAutoUnref and valueAutoUnref. I have > also tried setting an IncrementalCompileOperation although I don't really > know why. Nothing helps, how can I avoid these frame drops? I guess I want > to avoid a releaseGLObjects happening somewhere? > > Regards, > Andreas > > > ___ > 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] [osgPlugins] How to use osg to record screen
Hi, I have build osg 3.5 with ffmpeg support on ubuntu.I want to record the screen .i have gone through osgmovie and osgscreencapture examples.Please help me how it can be done. Thank you! Cheers, y -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64231#64231 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] BK patches to osgOcean for stability, up to osg 3.4.0 compilation and more
Hi, we are an Italian software company working with OSG and osgOcean in simulation scenarios. We currently have some minor/major changes to c++ code and shaders to take into account several aspects in osgOcean we had troubles with. We would like to give back to the community by submitting our code, and some of you has already found messages posted on various forum topics by one of our employee, Paradox (dr. Dario Maggiari). We understand this has to be taken into account via an evaluation process and we're ready to afford the evaluation and discussion on that. Now, how to submit these code changes? Thank you! Cheers, Fabrizio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65260#65260 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] How to use osg to record screen
See the FAQ: http://www.openscenegraph.com/index.php/support/faq#HowdoIcaptureascreengrab If you want to record a video, just record the individual frames into files and then use ffmpeg utilities to combine these into a video. If you don't want to do that, use Google - there are plenty of screen capture tools around (Fraps, BandiCam ...). J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] How to use osg to record screen
I just actually finished a work with ffmpeg and streaming videos from OSG rendering. You just capture the single images as Jan suggested - based on the osgscreencapture example, and then pass the captured osg::Image to ffmpeg - you dont have to do it frame by frame into file and use he offline ffmpeg utilities, you can do it directly from the code - see online samples for this, there are plenty Nick On Wed, Sep 30, 2015 at 6:09 PM, Jan Ciger wrote: > See the FAQ: > > > http://www.openscenegraph.com/index.php/support/faq#HowdoIcaptureascreengrab > > If you want to record a video, just record the individual frames into > files and then use ffmpeg utilities to combine these into a video. > > If you don't want to do that, use Google - there are plenty of screen > capture tools around (Fraps, BandiCam ...). > > J. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] BK patches to osgOcean for stability, up to osg 3.4.0 compilation and more
Hi Fabrizio, For changes to the core OSG just send them along to the osg-submissions mailing list. The best way to post them are as whole modified files. I don't know what the current development status of osgOcean is so can't comment on the best way to progress with this. One route might be to create a github repository and let others pull the changes from there. Robert. On 30 September 2015 at 15:33, Fabrizio Sciarra wrote: > Hi, > > we are an Italian software company working with OSG and osgOcean in > simulation scenarios. > We currently have some minor/major changes to c++ code and shaders to take > into account several aspects in osgOcean we had troubles with. > We would like to give back to the community by submitting our code, and > some of you has already found messages posted on various forum topics by > one of our employee, Paradox (dr. Dario Maggiari). > > We understand this has to be taken into account via an evaluation process > and we're ready to afford the evaluation and discussion on that. > > Now, how to submit these code changes? > > Thank you! > > Cheers, > Fabrizio > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=65260#65260 > > > > > > ___ > 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] OSG and NVX_gpu_memory_info
Hi Robert, On 30/09/15 19:50, Robert Osfield wrote:> If you want to check periodically then just use a Camera::DrawCallback > attached to the main camera attached to the GraphicsContext/Window of > interest. This will be called every frame, but within this callback you > could have your own check to see if the GL calls are required for that > frame. I've put together a test application that tries out a bunch of simple configurations based on the exact setup you describe. The calls worked correctly and consistently with either an Operation (or GraphicsOperation) attached with setRealizeOperation(), or a Camera::DrawCallback attached with setInitialDrawCallback(), or both. If I had to guess, I am doing something in my project at some point after the setRealizeOperation operation is called that causes it to fail by the time it gets around to the first call to the callback set by setInitialDrawCallback() in the Camera. Many thanks for pointing me in the right direction. Both techniques you mention work perfectly in the simple test application. The actual issue must be something I am doing differently between the minimal example and the full project. I'll have to experiment with the two to figure out what the difference is. Cheers, Garth > On 30 September 2015 at 10:56, Garth D wrote: Hi Robert, Thanks for having a look at things and for the suggestion. On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, I'd use a RealizerOperation. Have a look at the osgvolume example to an example of using a RealizerOperation to get information from the graphics context. I was unfortunately unable to solve the problem. Here is what I tried: I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a RealizerOperation in either. I did notice that osgvolume does also use viewer.setRealizeOperation() for TestSupportOperation, defined earlier. Is this what you are referring to? Assuming yes: This is the way I was able to successfully query the information once only at the start of the program. Unfortunately I need to query the information periodically, ie. over the course of the program, rather than just at initialisation. Unless I am mistaken, the target of setRealizeOperation is only called the one time, on viewer realization. Is this right? If so: Is there a corresponding call that I can use to attach an osg::Operation or similar to in order to make the required calls periodically? If not: Is there a way to indicate that the operation should be repeatedly called? Or is there another part of osgvolume.cpp that I should be looking at? The only glGet* call in the file is in TestSupportOperation, which is set using setRealizeOperation(), so I think I am looking in the right place? I'll continue to experiment. Thanks again for the suggestion. Is there anything else I should try? Cheers, Garth Robert. On 30 September 2015 at 03:49, Garth D wrote: Hi all, I was wondering if anyone has been successful in using the NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to call glGetIntegerv to get the associated values. Details on the extension here: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt I'm using Linux, OSG 3.2.1, and a card that supports the NVX_gpu_memory_info extension. I have tried querying the current and total memory using GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the values reported back are zero. The only success I have had thus far has been querying the values via an osg::Operation set with ViewerBase::setRealizeOperation() on my viewer (osg::Viewer). The values returned appear to be correct. This allows me to get the correct values *once* at the start of the program. Unfortunately I need to query them periodically, and I have been unable to do this. So far, I have tried hooking the calls into: - An osg::Camera::DrawHandler, set via osg::Camera::setInitialDrawCallback(). - An osg::Node::NodeHandler, hooked into the root node via osg::Node::setUpdateCallback. - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setDrawCallback. - An osg::Drawable::CullCallback , hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setCullCallback. - An osg::Camera::DrawHandler, set via osg::Camera::setFinalDrawCallback(). Only partly-tested due to a race-condition that occurs in my code, but appears to fail. I have experimented with osg::GraphicsContext::makeCurrent() with each. Can anyone suggest a better place to hook these calls into? Or alternatively confirm that they have the extension working with one of the above, so I can change or experiment with my existing setup to try to make it work? Cheers, Garth ___ osg-users mailing list o
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi all, On 01/10/15 10:12, Garth D wrote: If I had to guess, I am doing something in my project at some point after the setRealizeOperation operation is called that causes it to fail by the time it gets around to the first call to the callback set by setInitialDrawCallback() in the Camera. ... and solved. There was an unfortunate interaction between the threading system in my project and the one used in OSG. The particular interaction is something I have not seen before, and did not think was possible. The bug will be somewhere in my project code. As a test, I put a Camera::DrawCallback in a small piece of code fully isolated from the threading in the rest of my project doing nothing but dumping the reported values. I then attached it with setInitialDrawCallback() in a similar, isolated piece of code. It worked perfectly. Thanks again Robert for pointing me in the right direction. Being able to concentrate on just two established working approaches made finding the actual bug feasible. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] EventQueue::userEvent
Hello, I've tried to use the EventQueue::userEvent method which takes a "time" argument but no matter what value I put in for time the event always fires immediately. Is there any documentation on this? Thanks, Aaron ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroid - Deploying and Debugging
Hi Shamim, I'm glad you made it work, but I'm concerned about the osgsimple sample in osgAndroid not working for you. Could you tell me if the logcat says something?, maybe the model you tried to load is not in the expected path? If you have any improvements to the OSG sample you can send a submission using the osg-submissions list. If you have any modification to osgAndroid, just send a pull request in github and I'll review the changes and merge them. Regards, Rafa El mié., 30 sept. 2015 a las 12:24, Akhtar Shamim () escribió: > Hi > > Just an update. > > I managed to make osgAndroidExampleGLES1 work based on the Android.mk > settings for osgSimple and am able to load cessna.osg or any other osg > models. However, i am still not able to make osgSimple work based on the > predefined setting. > > If anyone is interested then I can provide a complete step by step guide > for making osgAndroid compile and run the osgAndroidExampleGLES1 example on > an Android device (with development environment on both Windows 10 and > Ubuntu 14.0.4) > > regards > Shamim > > On Tue, Sep 29, 2015 at 3:12 PM, Akhtar Shamim wrote: > >> Hi Rafa >> >> Thank you for the pointer. I managed to compile and run the application >> in an Android device successfully. >> I have also managed to compile and run the osgAndroidExampleGLES1 on my >> mobile device. I can see the blue background for the example together with >> three buttons. >> >> However, now when i try to load a model (cessna.osg) it shows error: >> dlopen failed: library osgPlugins-3.4.0/osgdb_osg.so" not found. >> DynamicLibrary::failed loading "osgPlugins-3.4.0/osgdb_osg.so". It is >> strange because the build is static build yet it is looking for .so file. >> >> I am not too sure why this is happening. Any pointer will be very helpful. >> >> regards >> Shamim >> >> >> On Mon, Sep 28, 2015 at 5:08 PM, Rafa Gaitan >> wrote: >> >>> Hi Shamim, >>> >>> I added glustl_shared to be loaded dynamically before loading any >>> osgAndroid jni library, because linking it statically was giving a lot of >>> problems. >>> >>> I don't recall having problems before, but I usually work on linux or >>> mac when I have to develop in android and OSG. Maybe is something related >>> to the r10e NDK?. >>> >>> Anyway, could you check if you have in your >>> org.openscenegraph.android/libs/armeabi/ the library libgnustd_shared.so?, >>> if not, probably you need to copy it there from the NDK. >>> >>> I don't recall if I copied it by myself that or it's automated somehow >>> by the NDK build system. But if you have it there along the >>> libjni-osggles*.so libraries it will be deployed within the apk. >>> >>> Regards, >>> Rafa. >>> >>> >>> El lun., 28 sept. 2015 a las 9:34, Akhtar Shamim () >>> escribió: >>> Hi Recently we had a requirement to build OSG for Android and load a OpenFlight MetaFight file. This is what I did: - Checkout the 3.4.0 stable release of OSG - Installed Android NDK, SDK and Eclipse. - Used the toolchain to compile OSG for GLES1 - Downloaded OSGAndroid from GitHub - Imported to Eclipse - Build all the four projects So far there is no problem at all. Everything went smooth. However, when I am trying to deploy the osgsimple application using eclipse or trying to debug the application it throws an error saying: "Couldn't load gnustl_shared from loader dalvik.system.PathClassLoader". This is what I did: - Modified Android.mk to have the correct OSG_SDK path - Modified Android.mk to have the correct plugins (osgPlugins-3.4.0) Note: (a) No other changes made to any files downloaded from GitHub for osgAndroid. (b) The command used to configure cmake is <<< > set ANDROID_NDK=C:\Android\android-ndk-r10e > "c:\Program Files (x86)\CMake 2.8\bin\cmake.exe" .. -G"MinGW Makefiles" -DANDROID_NDK=C:/Android/android-ndk-r10e -DCMAKE_TOOLCHAIN_FILE=../PlatformSpecifics/Android/android.toolchain.cmake -DCMAKE_MAKE_PROGRAM="%ANDROID_NDK%\prebuilt\windows-x86_64\bin\make.exe" -DOPENGL_PROFILE="GLES1" -DDYNAMIC_OPENTHREADS=OFF -DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NATIVE_API_LEVEL=15 -DANDROID_ABI=armeabi -DCMAKE_INSTALL_PREFIX=C:/Android/OSG_ES1-3.4.0 > make -j 8 > make install I tried the above in Windows 10. Any help to get this resolved will be greatly appreciated. regards Shamim ___ 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] Avoiding texture release
Hi Robert, You're right, it was the sheer amount of texels that was the problem. By adding polygons using both set of textures in both switch children, I saw that performance was bad all the time instead, due to constant swapping. Guess I thought I used a better graphics card. :-) I had to scale down to 4096x4096 which was fine. Regards, Andreas > 30 sep 2015 kl. 16:56 skrev Robert Osfield : > > Hi Andreas, > > I suspect just letting the OSG do it's thing with be just fine, and it's > simply the amount of memory on the GPU that these textures take is > fundamental problem you need to address. > > Try texture compression on the textures, or try a small pixel format. > > The other approach would be to tile that data up so you have a set of smaller > textures each applied to it's own Geode. > > Robert. > >> On 30 September 2015 at 14:25, Andreas Ekstrand >> wrote: >> Hi, >> >> I have a switch node with two geodes containing one geometry each, >> shallow-copied from the same geometry but with different state sets having >> different textures. The textures are large (8192x8192) and this causes a >> massive frame drop when switching between the two geodes at runtime. I know >> it's the textures causing the hickup since it doesn't happen when not >> setting the texture attributes. >> >> I have tried applying a GLObjectsVisitor before adding the geodes to the >> switch, and after adding them, setting a 0x node mask. I have tried >> applying a TextureVisitor with changeAutoUnref and valueAutoUnref. I have >> also tried setting an IncrementalCompileOperation although I don't really >> know why. Nothing helps, how can I avoid these frame drops? I guess I want >> to avoid a releaseGLObjects happening somewhere? >> >> Regards, >> Andreas >> >> >> ___ >> 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
