Hi Steven, I really can't tell what you really need, but the OSG does support render to texture pretty seamlessly, but I'd be surprised if weren't already familar with this support i.e. osg::Camera's RTT support is used all over the place, and demonstrated by osgprerender example and may more besides.
Robert. On Mon, Jun 16, 2008 at 2:44 PM, Watkins, Steven M CIV NSWCDD, G24 <[EMAIL PROTECTED]> wrote: > Hi Robert > > I am using the glReadPixels just before the swapbuffers to capture the > "screen view" (the pixel rgb values) after all OpenSceneGraph draw operations > have completed. I am not aware of any other method to do this, hence the > question. There are comments in osg::Image.readPixels that this also uses > glReadPixels. > > If there is another method for getting the screen pixel values (render the > entire screen to a texture image?) then I could avoid the glDrawPixels and > try the osg::PixelBufferObject method. But then I think I would have to use > some type of multi pass technique. My current method is a simple, brute force > method which was quick to implement (a proof of concept), however, it is slow > in execution. > > No, the OpenSceneGraph application using all this is not a simulator. I > warned the users of the program that requested BRLCAD inclusion that ray > tracing was going to be slow. > > Thanks > > Steve > > > > > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Robert Osfield > Sent: Mon 6/16/2008 8:26 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Ray Tracing a BRLCAD model in Openscenegraph > > > > Hi Steven, > > Thanks for the overview, it kinda makes a but more sense. > > As general notes, if you can avoid glReadPixels and glDrawPixels calls > as these are both very slow, if you can avoid glReadPixels in your > alogirithm - try to use an algorithm that doesn't require this. In > you explanation it's not clear why you are doing a glReadPixels, and > what is in the frame buffer before you do the glReadPixels, so I can't > really comment on whether this is doable. Secondly a glDrawPixels is > really expensive, you are better off using an > osg::Texture2D/TextureRectangle with an > osg::Image/osg::PixelBufferObject combination for maximizing copy rate > from CPU to GPU. > > I can't reconcile the word "simulation" with using ray tracing, I > presume this isn't a simulator you are developing, and not expect a > solid 60Hz. > > Robert. > > On Mon, Jun 16, 2008 at 12:42 PM, Watkins, Steven M CIV NSWCDD, G24 > <[EMAIL PROTECTED]> wrote: >> Hi Robert >> >> I am probably much more confused than you are at this point! I am working >> on a simulation where it was required to incorporate BRLCAD models. BRLCAD >> are CSG models, though there are some tools to convert these models to >> polygonized formats (ie. STL), these tools generally produce errors on the >> more complex geometries. So by including these models into OpenSceneGraph I >> am mixing apples with oranges! What I have done so far: >> >> 1) Incorporated the BRLCAD pre-build libs and dll's in an OpenSceneGraph >> app. The BRLCAD is old "C" code that you can not even think about running >> the .h files through the C++ compiler. Just use void * pointers and move on. >> >> 2) Load a BRLCAD model, and generate a "point cloud" to display in >> OpenSceneGraph. The points are all determined using the native BRLCAD ray >> tracer. The "point cloud" is just to show the model and move around in the >> scene with a decent frame rate. Because the next step just kills the frame >> rate. >> >> 3) Once I get the model into the position I want, I toggle into a BRLCAD >> ray trace mode, where prior to the swapbuffers: >> >> - Grab the frame buffer with a glReadPixels call. >> - Generate a ray from each pixel location using the SceneView projection >> matrix. >> - Using the BRLCAD ray tracer determine where/if the ray hit and come up >> with a rgb value for the model (simple diffuse lighting model). >> - Intersect the OSG scene with the same ray. If there are no intersections >> before the BRLCAD intersection, replace the pixel values with BRLCAD derived >> rgb values. >> - Overwrite the frame buffer with a glDrawPixels. >> - Drink lots of coffee, waiting for the scene to render. >> >> >> This works, in that the BRLCAD model is displayed as a "lit" model in the >> OpensceneGraph scene. Close up views occasionally show some subpixel? >> error. I was looking for a "better" method than above. I do realize that I >> am out in the wilderness with this one! >> >> Thanks >> >> >> >> >> ________________________________ >> >> From: [EMAIL PROTECTED] on behalf of Robert Osfield >> Sent: Mon 6/16/2008 5:34 AM >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] Ray Tracing a BRLCAD model in Openscenegraph >> >> >> >> Hi Steven, >> >> I'm confused by what you are actually need to do on the OSG side. You >> talk about ray tracing on the OSG side, point clouds, and then talk >> about glReadPixels/glDrawPixels, to me they seem un-related so >> obviously I'm missing something key to what you are trying to do. >> Could you explain for a high level what steps you are taking to create >> the scene graph, what operations you need to do on it on the CPU/GPU >> and how you need to present/get the results. >> >> Robert. >> >> On Tue, Jun 10, 2008 at 12:36 PM, Watkins, Steven M CIV NSWCDD, G24 >> <[EMAIL PROTECTED]> wrote: >>> Hi All >>> >>> I have implemented BRLCAD, which is a CSG based ray tracing api, into an >>> Openscenegraph application. I am currently displaying BRLCAD models in the >>> Openscenegraph world by generating a "point cloud" using the native BRLCAD >>> ray tracer and rendering that as Osg point geometry. >>> >>> I would like to display these BRLCAD models by ray trace in Openscenegraph >>> (yes, it will be slow!). I have done some searches through the archives and >>> have not found a lot of info. It appears that I am going to have to use >>> glReadPixels and glWritePixels prior to the swapbuffers (I am not using >>> osgViewer yet). Does anyone know of a better method to render via ray trace >>> in Openscenegraph? >>> >>> Thanks >>> >>> _______________________________________________ >>> 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 >> >> > _______________________________________________ > 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
