[osg-users] Ray Tracing a BRLCAD model in Openscenegraph
Watkins, Steven M CIV NSWCDD, G24
Jean-Sébastien Guay
> 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?
If all you need is to ray trace an image, you could use a textured quad
instead of glWritePixels. I would probably be faster, especially if you
can somehow render to the same memory buffer as you use for the OpenGL
texture. But in any case, displaying the result of the raytrace is not
likely to be your bottleneck...
Note that in that case (as with glWritePixels), all you get is a 2D
image of your render. So if the user changes the point of view, you have
to re-render. Whereas your previous method, rendering to a point cloud,
at least gave you some 3D positions which you could orbit around and
examine. As long as you don't need specular shading (reflections, etc)
and your scene doesn't change, you don't need to re-render. Diffuse
shading is view independent, and with static geometry, the resulting 3D
points would stay valid even if the viewpoint changes.
It's a case of what you want to do at a higher level. I guess I don't
see the point of rendering to an image to display that image in OSG...
What do you use OSG for in that case? Is the viewpoint fixed? (just
curious...)
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Watkins, Steven M CIV NSWCDD, G24
>It's a case of what you want to do at a higher level. I guess I don't
>see the point of rendering to an image to display that image in OSG...
>What do you use OSG for in that case? Is the viewpoint fixed? (just
>curious...)
The viewpoint in the simulation is not fixed. The "point cloud" was for interactive mode with the mouse. One of the main demo functions of the simulation is to create avi's, that can directly incorporated in PowerPoint (ie. you can show bright, shiny objects to manager types during presentations). I have various view scripts that can be set up to move the view during the simulation run /movie capture. The reasoning behind raytrace rendering is that "point cloud" objects do not really fit in with other lit and/or textured objects in the scene. Since avi's are being created, horrific frame rates during the capture, are not that big of an issue. I was just looking for other techniques before I went ahead and brute forced it with glReadPixels and glDrawPixels.
Thanks
hesicong2006
You should try volume rendering technology here instead of "point cloud". See osgVolume example for a good start, which provides two methods - native texture based algorithm and use shader to do ray trace.
The viewpoint in the simulation is not fixed. The "point cloud" was for interactive mode with the mouse. One of the main demo functions of the simulation is to create avi's, that can directly incorporated in PowerPoint (ie. you can show bright, shiny objects to manager types during presentations). I have various view scripts that can be set up to move the view during the simulation run /movie capture. The reasoning behind raytrace rendering is that "point cloud" objects do not really fit in with other lit and/or textured objects in the scene. Since avi's are being created, horrific frame rates during the capture, are not that big of an issue. I was just looking for other techniques before I went ahead and brute forced it with glReadPixels and glDrawPixels. Thanks __________ Information from ESET NOD32 Antivirus, version of virus signature database 3172 (20080610) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
_______________________________________________ osg-users mailing list osg-...@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3172 (20080610) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
hait...@gdls.com
I am at GDLS in Sterling Hts, MI.
I have been loosely associated with our guys that run BRLCAD, but know that
they would love to find better ways to convey results.
I would be very interested in hearing more about what you are doing, if you
are able to discuss.
Stephen Haithcock
General Dynamics Land Systems
38500 Mound Rd.
Sterling Heights, MI 48310
MZ 436-40-15
(586) 825-8573
"Watkins, Steven
M CIV NSWCDD,
G24" To
<steven.m.watkins <osg-...@lists.openscenegraph.org
@navy.mil> >
Sent by: cc
osg-users-bounces
@lists.opensceneg Subject
raph.org [osg-users] Ray Tracing a BRLCAD
model in Openscenegraph
06/10/2008 07:36
AM
Please respond to
OpenSceneGraph
Users
<osg-users@lists.
openscenegraph.or
g>
Hi All
Thanks
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
Adrian Egli OpenSceneGraph (3D)
--
********************************************
Adrian Egli
Robert Osfield
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.
Watkins, Steven M CIV NSWCDD, G24
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
________________________________
Robert Osfield
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
Watkins, Steven M CIV NSWCDD, G24
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
Robert Osfield
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
Donald Tidrow
> 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.
>
from the BRLCAD raytracer (not sure if rt already provides depth output,
but you should be able to easily add that), load them as textures in
OSG, then use a fragment shader on a screen-sized poly to composite the
BRLCAD images into the OSG scene. Should be a lot faster than trying to
use the IntersectionVisitor to find where the OSG scene obscured the
BRLCAD output, though you're still limited by how long rt takes to run.
Don
>
>
> 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
>
>
>
_______________________________________________