Re: [osg-users] retrieve texture id
Hi, I've just recently compiled osgCuda with CUDA 4.0 on 64-bit with gcc/g++ 4.4 (which is a requirement for nvcc). I had to make only minor changes and most of these are already checked into the trunk of osgCuda. See thread here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/71107 cheers jp On 05/10/2011 15:10, Conan Doyle wrote: 64 bit. I modified this post after your reply to say that I am using Cuda 4.0, which is a requirement. I have a feeling there may need to be some mods made to osgCuda to support 4.0. CD J.P. Delport wrote: Hi, I think it should work, 32/64 bit? What compiler do you have? If you supply some error messages maybe someone can help. cheers jp On 05/10/2011 14:58, Conan Doyle wrote: osgCuda was my first choice, but I will not compile on my machine. I am using OSG 3.0.1 and the SVN version of osgCuda, on RHEL 5.4. Is that a workable combination? CD J.P. Delport wrote: Hi, an alternative to doing this manually would be to look at osgCompute/osgCuda. Even if you don't use osgCuda you can learn from there how to do what you want. cheers jp On 05/10/2011 01:28, Conan Doyle wrote: Hi, [dumbquestion] I am integrating some cuda into my osg app and one call requires the texture name/id. How do I get that from my texture object? I look through the source code and only found and id method in TextureObject, but my attempts to retrieive this bit of data eludes me. [/dumbquestion] Thank you! Cheers, Conan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43179#43179 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43201#43201 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43205#43205 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] What is the proper way/place to call cudaGLSetGLDevice in OSG?
I'll give that a try... CD Mick wrote: > Hi Conan, > > my first guess is that the Cmake-Scripts did not find Cuda on your system. > Cuda 4.0 is not a problem in general. Thus try to build osgCompute again from > scratch and take a look at the advanced variable "CUDA_RUNTIME_LIBRARY". If > it is not available correctly you will have to set it manually to your > cudart-library (this may be the case on 64-Bit machines since we still have > to adapt the FindCuda script for Cmake). > > Good luck! > > > > > sholmes wrote: > > Hi, > > > > I am in a bind, and need to add some cuda to my OSG app quickly, as in by > > the end of hte day. I had hoped to use osgComputer/Cuda, but I am having > > problems getting it to build on my machine. I suspect it is due to my > > using CUDA 4.0. ...so... I am trying to add it "manually" through the code > > as needed. My first, seemingly insurmountable hurdle, is that I can seem > > to set the cuda device to use... If I call cudaGLSetGLDevice before I > > instantiate the viewer, I get an error stating the all cuda capable devices > > are busy or unavailable... I thought perhaps this was a graphics context > > issue, so I moved this call to after I instantiate the viewer. If I call > > cudaGLSetGLDevice after I instantiate the viewer, I get an error stating > > that setting the device when a process is active is not allowed. > > > > What is the proper way/place to call cudaGLSetGLDevice in OSG? > > > > CD > > > > Thank you! > > > > Cheers, > > Conan > > > Best regards, > Mick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43219#43219 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] FBO RTT -> CUDA Kernel -> FBO RTT Setup
Hi, My schedule lightened up a bit... I have an extra 24 hours to work on my osg/cuda problem, so I would like to incorporate CUDA into osg the "correct" way, which I think may be osgCUDA. Here's what I am currently doing Step 1 App renders scene to a FLOAT texture via a FBO/RTT camera Step 2 This texture is used as input to a shader on a second pass/RTT camera. The shader does some calibration stuff then renders it to a full screen quad. Step 3 Final render pass renders quad from step 2. Here's what I NEED to do... Step 1.5 Pass texture from Step 1 to a cuda kernel for processing before the calibration pass (Step 2) Questions: 1. Is this something I can use osgCUDA to do? 2. Would it be similar to the osgTexDemo? 3. Can I use an FBO, or do I have to switch to a PBO RTT? CUDA 4.0 is not necessary but would be cool as I have to use it eventually, but to get past this proof of principal step I can use 3.2... or 2.3... CD Thank you! Cheers, Conan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43220#43220 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake INSTALL target and vc10
Hi Mattias, Thanks for your hints, I certainly don't want to bother you with testing anything, just having a look and giving me some hints is useful. I'll check out what you said tomorrow. Thanks, J-S On 05/10/2011 2:50 PM, Mattias Helsing wrote: Hi J-S, I'm not at windows computer so can't get into testing, but I think you might find some magic in the HANDLE_MSVC_DLL macro. I'm guessing that the young osgPPU build system was inspired by the osg one and in the last months I think there were some substantial changes to OsgMacroUtils.cmake including the HANDLE_MSVC_DLL macro. Hmm. Looking at the file you attached. Doesn't osg's ModuleInstall.cmake call HANDLE_MSVC_DLL only if the MSVC_VERSIONED_DLL (or similar) is defined? I might be mistaken. Will check tomorrow. Mattias On Tue, Oct 4, 2011 at 7:23 PM, Jean-Sébastien Guay wrote: Hi Mattias, The osgPPU.dll it's trying to copy is actually in C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\lib\Release Actually I was wrong, that was an old one. The one it's building now is correctly in C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\bin So it seems that the problem is the install, which tries to find it in C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin/../../bin (it could just remove the ../../bin and find it there) How can I control where the install target tries to find stuff? Here is the ModuleInstall.cmake file that comes with osgPPU source. Thanks in advance, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ 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 -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake INSTALL target and vc10
Hi J-S, I'm not at windows computer so can't get into testing, but I think you might find some magic in the HANDLE_MSVC_DLL macro. I'm guessing that the young osgPPU build system was inspired by the osg one and in the last months I think there were some substantial changes to OsgMacroUtils.cmake including the HANDLE_MSVC_DLL macro. Hmm. Looking at the file you attached. Doesn't osg's ModuleInstall.cmake call HANDLE_MSVC_DLL only if the MSVC_VERSIONED_DLL (or similar) is defined? I might be mistaken. Will check tomorrow. Mattias On Tue, Oct 4, 2011 at 7:23 PM, Jean-Sébastien Guay wrote: > Hi Mattias, > >> The osgPPU.dll it's trying to copy is actually in >> >> C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\lib\Release > > Actually I was wrong, that was an old one. The one it's building now is > correctly in > > C:\Dev\OSG_Nodekits\osgPPU\build_vc10sp1_osg283\bin > > So it seems that the problem is the install, which tries to find it in > > C:/Dev/OSG_Nodekits/osgPPU/build_vc10sp1_osg283/bin/../../bin > > (it could just remove the ../../bin and find it there) > > How can I control where the install target tries to find stuff? Here is the > ModuleInstall.cmake file that comes with osgPPU source. > > Thanks in advance, > > J-S > -- > __ > Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.dyndns-web.com/ > > ___ > 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] [osgCompute] What is the proper way/place to call cudaGLSetGLDevice in OSG?
Hi Conan, my first guess is, that the Cmake-Scripts did not find Cuda on your system. Cuda 4.0 is not a problem in general. Thus try to build osgCompute again from scratch and take a look at the advanced variable "CUDA_RUNTIME_LIBRARY". If it is not available correctly you will have to set it manually to your cudart-library (this may be the case on 64-Bit machines since we still have to adapt the FindCuda script for Cmake). Good luck! sholmes wrote: > Hi, > > I am in a bind, and need to add some cuda to my OSG app quickly, as in by the > end of hte day. I had hoped to use osgComputer/Cuda, but I am having > problems getting it to build on my machine. I suspect it is due to my using > CUDA 4.0. ...so... I am trying to add it "manually" through the code as > needed. My first, seemingly insurmountable hurdle, is that I can seem to set > the cuda device to use... If I call cudaGLSetGLDevice before I instantiate > the viewer, I get an error stating the all cuda capable devices are busy or > unavailable... I thought perhaps this was a graphics context issue, so I > moved this call to after I instantiate the viewer. If I call > cudaGLSetGLDevice after I instantiate the viewer, I get an error stating that > setting the device when a process is active is not allowed. > > What is the proper way/place to call cudaGLSetGLDevice in OSG? > > CD > > Thank you! > > Cheers, > Conan Best regards, Mick SVT Group -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43216#43216 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] What is the proper way/place to call cudaGLSetGLDevice in OSG?
Hi, I am in a bind, and need to add some cuda to my OSG app quickly, as in by the end of hte day. I had hoped to use osgComputer/Cuda, but I am having problems getting it to build on my machine. I suspect it is due to my using CUDA 4.0. ...so... I am trying to add it "manually" through the code as needed. My first, seemingly insurmountable hurdle, is that I can seem to set the cuda device to use... If I call cudaGLSetGLDevice before I instantiate the viewer, I get an error stating the all cuda capable devices are busy or unavailable... I thought perhaps this was a graphics context issue, so I moved this call to after I instantiate the viewer. If I call cudaGLSetGLDevice after I instantiate the viewer, I get an error stating that setting the device when a process is active is not allowed. What is the proper way/place to call cudaGLSetGLDevice in OSG? CD Thank you! Cheers, Conan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43215#43215 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgParticle variables causing objects to disappear
Thanks for the input guys. I can't replicate the bug because I replaced the code with working code, but I'll be sure to come back to this thread if it happens again! Andy, I'm afraid I'm working on Windows with an ATI card (Mobility Radeon 3650 to be exact), and I'm not using osg::Point at all! Thanks again, Si. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43214#43214 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] "hide" objects from manipulators
Hi, I found the problem : when handling event, the Dragger instance look for itself in the NodePath of the FIRST intersection : (from Dragger.cpp, line 320) Code: for (osg::NodePath::iterator itr = _pointer._hitList.front().first.begin(); itr != _pointer._hitList.front().first.end(); ++itr) So I made a modification to use a node mask when looking for intersections -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43210#43210 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLODs under an RTT camera - how to use the proper viewpoint?
Robert, That works, thank you! However... I found that the ClusterCullingCallback doesn't cooperate. It looks like the CCC uses getEyePoint() to do its test. I changed it to use getViewPoint() and it seems to work properly. Let me know whether you concur, and if so I will submit the change. Glenn Waldron / Pelican Mapping / @glennwaldron On Wed, Oct 5, 2011 at 3:48 AM, Robert Osfield wrote: > HI Glenn, > > The osg::Camera/RTT mechanism has explict support for inheriting the > parents view point for the purpose of LOD calculations. Simple use: > > camera->setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); > > This is what osgShadow does for making sure the shadows use the same > LOD's as the master camera. > > Robert. > > > On Tue, Oct 4, 2011 at 10:10 PM, Glenn Waldron wrote: > > Hi friends, > > I have a graph under an RTT camera. That graph contains PagedLODs. Of > > course, I want the cull traversal to load the PagedLODs based on my > "main" > > scene camera, and NOT based on the RTT camera's location. > > I've tried a couple of things: > > 1) Calling CullVisitor::pushReferenceViewPoint on the RTT subgraph ... to > no > > effect > > 2) Creating a new RenderStage and traversing the RTT subgraph a second > time > > with it; that works in terms of properly activating the PagedLODs, but > not > > for rendering - the still switch in/out relative to the RTT camera. > > I'd appreciate some pointers on this one. Thanks. > > > > > Glenn Waldron / Pelican Mapping / @glennwaldron > > > > ___ > > 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] [osgCompute] Experiences with osgCompute
Hi Bart, sorry again that it took so long to write an answer. Thanks a lot for your support to improve osgCompute. > > The thing that bothers me most is the class you have to make when you inherit > from > the osgCompute::Module class (TestModule in the example program). First of > all, all > your examples use this META_Object macro in the class that inherits from > Module, so I > went along at first. This macro, however, forces me to declare a constructor > with no > parameters. Removing the macro gave me other errors, which, at that time, I > did not want > to solve also, so I complied with the no-parameters constructor. > Perhaps this macro has some great use that I am unaware of (probably it has). > ... > Secondly, inheriting from Module requires me to use an init- and > launch-function. > In this init-function I seem to be allowed to do CUDA stuff and no sooner. > ... > If I move the CUDA stuff to the init-function, everything is fine again. But > this > is not what I want, I want the constructor for setting up and initializing > everything > and not use an additional init-function. Now I also have to store the > constructor's > arguments, so I can use them again in the init-function. > As we use the runtime version of CUDA it is absolutely necessary to include a class which encapsulate CUDA programs. However, if you just want to add a simple CUDA operation use a osgCompute::LaunchCallback with your kernels, similar to for OpenGL calls within OSG. We tried a lot of times to allow a developer to use CUDA stuff everywhere in a module. The point is that OSG initializes an OpenGL-Context during the first traversal of the scene graph (See osgViewer class). However, the constructor of a module is called beforehand. One solution would be to write a new viewer class which handles the OpenGL-contexts differently (We thought about it but we currently have no time). If you have another solution for the problem that would be great. Another thing is that you can call osgViewer::Viewer::realize() and osgCompute::GLMemory::bindToContext( viewerContext ). with that new context of the root camera. After this you can call your CUDA code everywhere. Please see the following source files: http://www.cg.informatik.uni-siegen.de/data/Downloads/svt/osgCUDAEverywhere.zip Here we have included these calls at the start of Main.cpp. Just use CMake to build the application or copy your files back to your project. The Macro META_Object will not be necessary in the next version of osgCompute. However, in the current vesion it defines the library name and class name of an osg::Object as all osg::Objects have to define it. We will change the init() and the launch() function to a non-abstract function in the next version of osgCompute as well. > > As far as I understand is a map from memory of an osgCuda::Geometry to CUDA > context a > simple pointer copy of GL-context to CUDA context. If I map from GPU to a CPU > or vice > versa, would osgCompute do a complete copy or provide a pointer and then each > time > transfer a data element over the PCI-express bus when requested? It would be > nice if > this somehow could be included in the documentation. > A real copy operation is only applied if you map something with osgCompute::MAP_XXX_TARGET. With the TARGET specifier you tell osgCompute that it will be changed. For all other mappings no copy operation is applied afterwards as no data has changed. We will extend the documentation, thank you very much. For us it is clear now but that is only because we u se it all the time. > > My problem is not with the design here, it's name 'Module' that does not > convey concrete information > what the class is about. The term 'Module' is a very general term that can > represent a lot > of things, so it's not clear to the user what this class is about, unless he > investigates > the class in detail. > Would it be helpful to rename it to osgCompute::Program? Please make a suggestion. > > Then why use memcpy() in all your examples to fill a Memory object? Normally, > your data > is present in some Vec2Array, Vec3Array, etc. And it would be nice if you > could simply > pass this array to a function of a Memory object, which would then fill the > Memory with > the data of the array, instead of doing memcpy's. Besides the term 'setImage' > is again > very misleading, because it is also used for non-image things. In the > osgEndianess > example you use setImage to fill a Memory object (not with image data). > We have implemented such a functionality in a earlier version of osgCompute. We moved towards osg::Image objects as these objects are better serializeable and one can provide plugins to load or store them. The osgCompute example was designed to show the flexibility to do things in osgCompute. I will change the functionality as it seems to be confusing instead. > > But if I want to
Re: [osg-users] OsgParticle variables causing objects to disappear
Maybe far off, but something I've seen: Do you happen to be working on a mac? We've seen something on one particular graphics card on the mac, where drawing with points sometimes seems to affect clipping on other objects. It seems really weird. I think that when we didn't set the osg::Point state attribute, it didn't happen. And when we turned off clipping, it didn't happen. And it only happened on one particular graphics card on a mac. I didn't look at the near and far settings at the time, but I don't see why that would be affected by the card/driver. andy -Original Message- Not to worry, I redesigned the min and max values to give a better looking fire, and now the problem has gone. Still don't know what caused it though, gonna worry about that in the future D: Simon. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgParticle variables causing objects to disappear
On 10/05/2011 07:26 AM, Simon White wrote: Not to worry, I redesigned the min and max values to give a better looking fire, and now the problem has gone. Still don't know what caused it though, gonna worry about that in the future D: Your problem might have been caused by small feature culling. You can try disabling it: mode = camera->getCullingMode(); camera->setCullingMode(mode & ~osg::CullSettings::SMALL_FEATURE_CULLING); --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] retrieve texture id
64 bit. I modified this post after your reply to say that I am using Cuda 4.0, which is a requirement. I have a feeling there may need to be some mods made to osgCuda to support 4.0. CD J.P. Delport wrote: > Hi, > > I think it should work, 32/64 bit? What compiler do you have? If you > supply some error messages maybe someone can help. > > cheers > jp > > On 05/10/2011 14:58, Conan Doyle wrote: > > > osgCuda was my first choice, but I will not compile on my machine. I am > > using OSG 3.0.1 and the SVN version of osgCuda, on RHEL 5.4. Is that a > > workable combination? > > > > CD > > > > > > J.P. Delport wrote: > > > > > Hi, > > > > > > an alternative to doing this manually would be to look at > > > osgCompute/osgCuda. Even if you don't use osgCuda you can learn from > > > there how to do what you want. > > > > > > cheers > > > jp > > > > > > On 05/10/2011 01:28, Conan Doyle wrote: > > > > > > > > > > Hi, > > > > > > > > [dumbquestion] > > > > > > > > I am integrating some cuda into my osg app and one call requires the > > > > texture name/id. How do I get that from my texture object? I look > > > > through the source code and only found and id method in TextureObject, > > > > but my attempts to retrieive this bit of data eludes me. > > > > > > > > [/dumbquestion] > > > > > > > > Thank you! > > > > > > > > Cheers, > > > > Conan > > > > > > > > -- > > > > Read this topic online here: > > > > http://forum.openscenegraph.org/viewtopic.php?p=43179#43179 > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > osg-users mailing list > > > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > > > > > > > > -- > > > This message is subject to the CSIR's copyright terms and conditions, > > > e-mail legal notice, and implemented Open Document Format (ODF) standard. > > > The full disclaimer details can be found at > > > http://www.csir.co.za/disclaimer.html. > > > > > > This message has been scanned for viruses and dangerous content by > > > MailScanner, > > > and is believed to be clean. > > > > > > ___ > > > osg-users mailing list > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > -- > > > Post generated by Mail2Forum > > > > > > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=43201#43201 > > > > > > > > > > > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > This message is subject to the CSIR's copyright terms and conditions, e-mail > legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > This message has been scanned for viruses and dangerous content by > MailScanner, > and is believed to be clean. > > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43205#43205 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ComputeIntersections and traversal mask
Hi, I use the following graph : Code: Root | | Group_1 (node mask 0x7FFF) | | Group_2 (node mask 0x8000) Group_1 and Group_2 have childs, with node mask 0x : Code: Group_1 | | Child_11 (node mask 0x) | | Child_12 (node mask 0x) Code: Group_2 | | Child_21 (node mask 0x) | | Child_22 (node mask 0x) But when I use osgViewer::View::computeIntersections like this : pView->computeIntersections(x, y, intersections, 0x8000) Child objects of Group_1 are intersected... like if Group_1 children are traversed by the intersector Is there any reason ? or did I miss something ? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43204#43204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] retrieve texture id
Hi, I think it should work, 32/64 bit? What compiler do you have? If you supply some error messages maybe someone can help. cheers jp On 05/10/2011 14:58, Conan Doyle wrote: osgCuda was my first choice, but I will not compile on my machine. I am using OSG 3.0.1 and the SVN version of osgCuda, on RHEL 5.4. Is that a workable combination? CD J.P. Delport wrote: Hi, an alternative to doing this manually would be to look at osgCompute/osgCuda. Even if you don't use osgCuda you can learn from there how to do what you want. cheers jp On 05/10/2011 01:28, Conan Doyle wrote: Hi, [dumbquestion] I am integrating some cuda into my osg app and one call requires the texture name/id. How do I get that from my texture object? I look through the source code and only found and id method in TextureObject, but my attempts to retrieive this bit of data eludes me. [/dumbquestion] Thank you! Cheers, Conan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43179#43179 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43201#43201 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] retrieve texture id
Perhaps the problem is that I am doing this before viewer.run()... I'll move the code and see if that fixes my problem. CD Skylark wrote: > Hello Conan, > > > > I create my gc manually then create viewer/window etc... so my code looks > > like this: > > > > unsigned int contextID = gc.get()->getState()->getContextID() > > unsigned int textureID = texture[0]->getTextureObject(contextID)->id(); > > > > Upon executing the "textureID = " I get a seg fault, and upon further > > checking, texture[0]->getTextureObject(contextID) = 0. > > > > (you don't need gc.get() above, ref_ptr has an overloaded operator-> > that takes care of that for you so you can just do gc->... ) > > As with any pointer access in C++ programming, you have to be sure that > when you do something, you're not dereferencing a null pointer. > > What you're doing is perfectly fine, as long as you do it after the > first frame has rendered. The getTextureObject(...) call will return > NULL before that, because OSG uses lazy initialization to only allocate > objects once they're needed. OpenGL objects and the OSG objects that > hold them are examples of this. > > So the safest way is to just let OSG render one frame, and then you can > get your texture object (for example, check if the result of > getTextureObject() is NULL, if not then get your texture ID, and then do > your thing). > > If you really want to, you can force OSG to allocate all objects in your > scene at startup by doing this: > > viewer->realize(); > viewer->stopThreading(); > > gc->makeCurrent(); > > osgUtil::GLObjectsVisitor glov; > glov.setState(gc->getState()); > viewer->getCamera()->accept(glov); > > gc->releaseContext(); > > viewer->startThreading(); > > Hope this helps, > > J-S > -- > __ > Jean-Sebastien Guay > http://www.cm-labs.com/ > http://whitestar02.dyndns-web.com/ > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43202#43202 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] retrieve texture id
osgCuda was my first choice, but I will not compile on my machine. I am using OSG 3.0.1 and the SVN version of osgCuda, on RHEL 5.4. Is that a workable combination? CD J.P. Delport wrote: > Hi, > > an alternative to doing this manually would be to look at > osgCompute/osgCuda. Even if you don't use osgCuda you can learn from > there how to do what you want. > > cheers > jp > > On 05/10/2011 01:28, Conan Doyle wrote: > > > Hi, > > > > [dumbquestion] > > > > I am integrating some cuda into my osg app and one call requires the > > texture name/id. How do I get that from my texture object? I look through > > the source code and only found and id method in TextureObject, but my > > attempts to retrieive this bit of data eludes me. > > > > [/dumbquestion] > > > > Thank you! > > > > Cheers, > > Conan > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=43179#43179 > > > > > > > > > > > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > -- > This message is subject to the CSIR's copyright terms and conditions, e-mail > legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > This message has been scanned for viruses and dangerous content by > MailScanner, > and is believed to be clean. > > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43201#43201 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass render to texture order again
Okay, I'm just to stupid 1. JP is right about the render order, it works flawlessly if you place the camera nodes one after another 2. Setting the camera transform in a camera drawcallback will give you the matrices of the former frame. 3. RELATIVE_RF is working fine ... I was just using gl_ModelViewProjection instead of gl_ModelView in my shader, so things got screwed up, and seemed fixed with the callback, which was my error. Thank you JP for your suggestions, at least I now know a bit more about render-order and camera transforms ;-) Hi, On 05/10/2011 12:12, Sebastian Messerschmidt wrote: Okay, I've tried all the stuff, and I might have found the real problem. It is not that the cameras are rendered in the wrong order, it is more the way I handle the camera view matrices. Some days ago I've stumbled upon the question how to set the camera of a second pass in a way it renderes the scene from the exact same view as the first one. To solve this I've done the following: viewer.getCamera()->setInitialDrawCallback(new CameraUpdateCallback(viewer.getCamera()->getOrCreateStateSet())); and in the CameraUpdateCallback:: operator (const osg::Camera& camera) const I tried to achieve this via: pass_2_cam->setViewMatrix(camera.getViewMatrix()); pass_2_cam->setProjectionMatrix(camera.getProjectionMatrix()); I guess this is not the way to do it. Are there any options? Because setting the camera to RELATIVE_RF didn't really work. sorry, I'm not sure how to do it either. Someone with knowledge about slave cameras might be able to help you. I suggest posting another question with that as topic. rgds jp cheers Sebastian Hi, On 05/10/2011 11:39, Sebastian Messerschmidt wrote: Hi JP I've tried single and multithreaded, but this doesn't seem to change anything. OK, running singlethreaded can sometimes show if stateset variance is not correctly set to dynamic. So first camera attached should be the first one to be rendered If I understood you correctly? Yes, we build some image processing chains with FBO cameras and our execution order is only specified using the order of attachment to the same parent (we don't specify render_order). Can you give me a pointer on how to force it with the renderbin approach? I've only set render bin on transparent objects, but see the code in /include/RenderBin. One of the options in SortMode is TRAVERSAL_ORDER. HTH jp cheers Sebastian Hi, are you running SingleThreaded? Cameras (siblings) under the same node are normally rendered in the order they have been attached (you can force this with TRAVERSAL_ORDER bin too). jp On 05/10/2011 11:05, Sebastian Messerschmidt wrote: Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table Input Cam Output Tex1 Cam1 Tex2 Tex2 Cam2 Tex3 Tex3 Cam3 Tex4 ... and so on TexN OutCam FrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ 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] [osgCompute] trunk compile
Hi, On 05/10/2011 14:04, Mick Keller wrote: ...I just committed the changes to the trunk. Thank you. The FindCuda-script has not been updated yet. Best regards, Mick thanks. Tt appears that the latest CMake versions (at least 2.8.5 that I have on Debian Sid) includes a FindCUDA script as well, maybe you can check that out. regards jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] trunk compile
Code: $ svn diff Index: src/osgCuda/Computation.cpp === --- src/osgCuda/Computation.cpp (revision 426) +++ src/osgCuda/Computation.cpp (working copy) @@ -1,4 +1,4 @@ -#include +#include #include #include #include Index: examples/osgGeometryDemo/src/Warp.cpp === --- examples/osgGeometryDemo/src/Warp.cpp (revision 426) +++ examples/osgGeometryDemo/src/Warp.cpp (working copy) @@ -12,6 +12,7 @@ * * The full license is in LICENSE file included with this distribution. */ +#include #include #include #include ...I just committed the changes to the trunk. Thank you. The FindCuda-script has not been updated yet. Best regards, Mick [/code] SVT Group -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43196#43196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] trunk compile
Hi JP, thanks a lot for the diff. We will include it into the source soon. The problem with the FindCuda-script is that we actually just tested it with 32 Bit machines. We need to take a closer look at this. Thank you! Best regards, Mick SVT Group -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43195#43195 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgParticle variables causing objects to disappear
Not to worry, I redesigned the min and max values to give a better looking fire, and now the problem has gone. Still don't know what caused it though, gonna worry about that in the future D: Simon. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43194#43194 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] trunk compile
I also made a comment on the 'gl -> GL' and the '#include ' in my post at http://forum.openscenegraph.org/viewtopic.php?t=9112 The reply of one of the developers is: "The most recent test we did is with OSG Library 3.1.0 (developer version). It runs with no problems." > Also, I had to manually set the path to the cudart library to point to > lib64 (/usr/local/cuda/lib64/libcudart.so) on my machine instead of lib. > I think this probably needs to be fixed in FindCUDA, but I can't look at > it now. Setting the CUDA evironment variables to the correct directories before installing osgCompute should also fix the problem. It concerns the following variables: CUDADIR, CUDA_BIN_PATH, CUDA_INC_PATH, and CUDA_LIB_PATH -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43192#43192 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass render to texture order again
Hi, only other option I can think of is that some cameras don't get rendered because of culling. Try camera->setCullingActive(false); jp On 05/10/2011 11:47, Sebastian Messerschmidt wrote: Am 05.10.2011 11:39, schrieb Sebastian Messerschmidt: Hi JP I've tried single and multithreaded, but this doesn't seem to change anything. So first camera attached should be the first one to be rendered If I understood you correctly? Can you give me a pointer on how to force it with the renderbin approach? Okay found the last one: stateset->setRenderBinDetails(num, "TraversalOrderBin") I've also checked if my cameras are attached in an appropriate order, but still no luck. cheers Sebastian Hi, are you running SingleThreaded? Cameras (siblings) under the same node are normally rendered in the order they have been attached (you can force this with TRAVERSAL_ORDER bin too). jp On 05/10/2011 11:05, Sebastian Messerschmidt wrote: Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table Input Cam Output Tex1 Cam1 Tex2 Tex2 Cam2 Tex3 Tex3 Cam3 Tex4 ... and so on TexN OutCam FrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipass render to texture order again
Am 05.10.2011 11:39, schrieb Sebastian Messerschmidt: Hi JP I've tried single and multithreaded, but this doesn't seem to change anything. So first camera attached should be the first one to be rendered If I understood you correctly? Can you give me a pointer on how to force it with the renderbin approach? Okay found the last one: stateset->setRenderBinDetails(num, "TraversalOrderBin") I've also checked if my cameras are attached in an appropriate order, but still no luck. cheers Sebastian Hi, are you running SingleThreaded? Cameras (siblings) under the same node are normally rendered in the order they have been attached (you can force this with TRAVERSAL_ORDER bin too). jp On 05/10/2011 11:05, Sebastian Messerschmidt wrote: Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table Input Cam Output Tex1 Cam1 Tex2 Tex2 Cam2 Tex3 Tex3 Cam3 Tex4 ... and so on TexN OutCam FrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ 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] Multipass render to texture order again
Hi JP I've tried single and multithreaded, but this doesn't seem to change anything. So first camera attached should be the first one to be rendered If I understood you correctly? Can you give me a pointer on how to force it with the renderbin approach? cheers Sebastian Hi, are you running SingleThreaded? Cameras (siblings) under the same node are normally rendered in the order they have been attached (you can force this with TRAVERSAL_ORDER bin too). jp On 05/10/2011 11:05, Sebastian Messerschmidt wrote: Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table Input Cam Output Tex1 Cam1 Tex2 Tex2 Cam2 Tex3 Tex3 Cam3 Tex4 ... and so on TexN OutCam FrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ 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] Multipass render to texture order again
Hi, are you running SingleThreaded? Cameras (siblings) under the same node are normally rendered in the order they have been attached (you can force this with TRAVERSAL_ORDER bin too). jp On 05/10/2011 11:05, Sebastian Messerschmidt wrote: Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table Input Cam Output Tex1 Cam1 Tex2 Tex2 Cam2 Tex3 Tex3 Cam3 Tex4 ... and so on TexN OutCam FrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multipass render to texture order again
Hi, I know this has been discussed more then once before, but I still don't get the details. In my setup I'd like to use something like (this is supposed to be a table InputCamOutput Tex1Cam1Tex2 Tex2Cam2Tex3 Tex3Cam3Tex4 ... and so on TexN OutCamFrameBuffer I've setup the cameras to be PRE_RENDER with increasing render_order exept for the last which is POST_RENDER. All cameras have are in a separate Group which are all attached to the root. The root is given to the viewer and a TrackballManipulator is attached to the viewer. Now if I move the scene, I can clearly see, that e.g. Tex2 is from a previous frame when processed in Cam2. (I'm doing blending of different scene parts here, and you can clearly see that some parts are from the previous frame, as if the rendering is done in wrong order). How do I have to place the cameras in the scene graph? All under root like this: root --cam1 --cam2 ... or rather hierarchical? root --cam2 --cam1 Or do I have to add them to the viewer in a different way? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLODs under an RTT camera - how to use the proper viewpoint?
HI Glenn, The osg::Camera/RTT mechanism has explict support for inheriting the parents view point for the purpose of LOD calculations. Simple use: camera->setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); This is what osgShadow does for making sure the shadows use the same LOD's as the master camera. Robert. On Tue, Oct 4, 2011 at 10:10 PM, Glenn Waldron wrote: > Hi friends, > I have a graph under an RTT camera. That graph contains PagedLODs. Of > course, I want the cull traversal to load the PagedLODs based on my "main" > scene camera, and NOT based on the RTT camera's location. > I've tried a couple of things: > 1) Calling CullVisitor::pushReferenceViewPoint on the RTT subgraph ... to no > effect > 2) Creating a new RenderStage and traversing the RTT subgraph a second time > with it; that works in terms of properly activating the PagedLODs, but not > for rendering - the still switch in/out relative to the RTT camera. > I'd appreciate some pointers on this one. Thanks. > > Glenn Waldron / Pelican Mapping / @glennwaldron > > ___ > 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