Re: [osg-users] [osgCompute] Problem with postfilter/rtt setup
Hi, this has actually already been fixed soon after I had posted it. I simply didn't know I had to attach those additional observers so it's known when the texture is updated. After adding this, it works flawlessly. OsgCompute is really just what I've been looking for :) ... Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51713#51713 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] Problem with postfilter/rtt setup
Hi, I have a slight problem with my tries to get some post processing working with osgCompute (most recent trunk version from today). I have several textures attached to my cameras in a RTT manner, e.g. like this: Code: textures.colorTex = new osgCuda::Texture2D; textures.colorTex-setName(color texture); textures.colorTex-setTextureWidth(__m_width); textures.colorTex-setTextureHeight(__m_height); textures.colorTex-setInternalFormat(GL_RGBA32F_ARB); textures.colorTex-setSourceFormat(GL_RGBA); textures.colorTex-setSourceType(GL_FLOAT); textures.colorTex-addIdentifier(SRC_COLORTEX); imageCamera-attach(osg::Camera::COLOR_BUFFER0, textures.colorTex); All textures have the same format (GL_RGBA32F_ARB). What i want to do is the following: Put all textures in a osgCompute::Computation and use this to pass everything to our CUDA-based post-processing framework. Everything is rendered to a single screen-filling quad with an according target texture in the end. Now to first check if everything works as it should, I just tried to play around a little with the memory mapping, but they didn't quite work as I expected them to do. To make this more clear: If I map something with MAP_XXX_TARGET, it seems to work alright (I can write to it and the result is also displayed later on). The problem arises when mapping as source, e.g. like this: Code: float* d_srcBuffer_color = (float*) _m_srcBuffer_color-map(osgCompute::MAP_HOST_SOURCE); When I try to copy the values over to the target buffer (mapped with MAP_HOST_TARGET), it turns out that the whole d_srcBuffer_color seems to be filled with zeroes. I also tried to loop over the source buffer and tell me if there's any non-zero value, but no, there isn't. So maybe you guys have some idea what's going wrong here. Could it also be a version conflict? Here are the versions I am currently using: - OpenSceneGraph 3.0.1 - CUDA 5.0.35 - latest osgCompute trunk version (rev 509) The examples work flawlessly, btw. Thanks in advance :) ... Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51537#51537 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Postprocessing framework GrIP attached to OSG application :)
Hey guys, thought I'd just keep you updated on my postprocessing framework I developed during my Master Thesis. I used OSG for a basic application I attached my framework to, so this is why i think it could be interesting for the list :-) ...data is currently still passed via the host and then processed by CUDA filter plugins, which can be organized in a graph. The GPU-CPU copying stuff explains the relatively low framerate, as color, depth, normal and position information per pixel are passed each frame. The videos only show filter chains, but graphs with multiple dependencies per node are also possible, seriously! ;-) ..I am currently working on direct buffer mapping between CUDA and OpenGL, just to try how many frames I can squeeze out of my unoptimized filters. So here we go: http://www.youtube.com/watch?v=J7BUtzFfVfs http://www.youtube.com/watch?v=4rpIYYn5mMY http://www.youtube.com/watch?v=a_76-w78rHA If anyone is interested, the thesis will probably be available to the public soon (though it's in german, which could be a problem...). I'm always thankful for ideas and suggestions, by the way :) Regards Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Postprocessing framework GrIP attached to OSG application :)
Hey J-S, Am 25.02.2011 18:05, schrieb Jean-Sébastien Guay: Hello Thorsten, thought I'd just keep you updated on my postprocessing framework I developed during my Master Thesis. Wow, that's great work! I look forward to reading your thesis (through Google Translate I guess :-) ) Thanks, it's always nice to hear that people like things you do :) Any relation to osgPPU? I guess the comparison between the two is inevitable, what are the differences between that and what you're doing? I guess by reading your thesis I'll find out. You will find out ;) ..the main and most important difference is of course that it's not tied to a specific application. I have tried my best to design it so you can easily use it in any application (which provides the necessary data). It also explicitly supports the combination of filters executed on different devices (CPU, GPU, whatever) through some (still rudimentary, but subject to change/enhancements) internal memory management. Keep up the great work! J-S I will try to do so :) Regards Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU CUDA Example - slower than expected?
Thanks for the answers. Actually I also know that there are new interoperability features in CUDA 3, but I didn't have the time to check them out yet, though if I find the time for it, I will let you know about the results :) Regards -Thorsten Am 07.01.2011 22:23, schrieb Jason Daly: On 01/07/2011 03:34 PM, Art Tevs wrote: Hi Thorsten, the problem which you experience is because of lacking direct memory mapping between OpenGL and CUDA memory. Even if CUDA (at least it was in version 2 so) supports GPU-GPU memory mapping, whenever you access to OpenGL textures there is a full memory copy performed. I am not aware if this was solved in CUDA3, maybe you should check it out. CUDA2 definitively doesn't perform direct mapping between GL textures and CUDA textures/arrays. regards, art I know that OpenCL 1.1 added a bunch of OpenGL interoperability features (clCreateFromGLBuffer(), clCreateFromGLTexture2D(), etc.), and I thought I heard that the newer versions of CUDA supported similar features. OpenGL 4.1 added some CL interop features, too. --J ___ 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] osgPPU CUDA Example - slower than expected?
Hi, as I explained in some other mail to this list, I am currently working on a graph based image processing framework using CUDA. Basically, this is independent from OSG, but I am using OSG for my example application :-) For my first implemented postprocessing algorithm I need color and depth data. As I want the depth to be linearized between 0 and 1, I used a shader for that and also I render it in a separate pass to the color. This stuff is then fetched from the GPU to the CPU by directly attaching osg::Images to the cameras. This works perfectly, but is quite a bit slow, as you might already have suspected, because the data is also processed in CUDA kernels later, which is quite a back and forth ;-) In fact, my application with three filter kernels based on CUDA (one gauss blur with radius 21, one image subtract and one image pseudo-add (about as elaborate as a simple add ;-)) yields about 15 fps with a resolution of 1024 x 1024 (images for normal and absolute position information are also rendered transferred from GPU to CPU here). So with these 15 frames, I thought it should perform FAR better when avoiding that GPU - CPU copying stuff. That's when I came across the osgPPU-cuda example. As far as I am aware, this uses direct mapping of PixelBuferObjects to cuda memory space. This should be fast! At least that's what I thought, but running it at a resolution of 1024 x 1024 with a StatsHandler attached shows that it runs at just ~21 fps, not getting too much better when the cuda kernel execution is completely disabled. Now my question is: Is that a general (known) problem which cannot be avoided? Does it have anything to do with the memory mapping functions? How can it be optimized? I know that, while osgPPU uses older CUDA memory mapping functions, there are new ones as of CUDA 3. Is there a difference in performance? Any information on this is appreciated, because it will really help me to decide wether I should integrate buffer mapping or just keep the copying stuff going :-) Best Regards -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU CUDA Example - slower than expected?
By the way: There are two CUDA-capable devices in the computer, but I have tried using the rendering device as well as the CUDA-only device - no difference! -Thorsten Am 16.12.2010 12:25, schrieb Thorsten Roth: Hi, as I explained in some other mail to this list, I am currently working on a graph based image processing framework using CUDA. Basically, this is independent from OSG, but I am using OSG for my example application :-) For my first implemented postprocessing algorithm I need color and depth data. As I want the depth to be linearized between 0 and 1, I used a shader for that and also I render it in a separate pass to the color. This stuff is then fetched from the GPU to the CPU by directly attaching osg::Images to the cameras. This works perfectly, but is quite a bit slow, as you might already have suspected, because the data is also processed in CUDA kernels later, which is quite a back and forth ;-) In fact, my application with three filter kernels based on CUDA (one gauss blur with radius 21, one image subtract and one image pseudo-add (about as elaborate as a simple add ;-)) yields about 15 fps with a resolution of 1024 x 1024 (images for normal and absolute position information are also rendered transferred from GPU to CPU here). So with these 15 frames, I thought it should perform FAR better when avoiding that GPU - CPU copying stuff. That's when I came across the osgPPU-cuda example. As far as I am aware, this uses direct mapping of PixelBuferObjects to cuda memory space. This should be fast! At least that's what I thought, but running it at a resolution of 1024 x 1024 with a StatsHandler attached shows that it runs at just ~21 fps, not getting too much better when the cuda kernel execution is completely disabled. Now my question is: Is that a general (known) problem which cannot be avoided? Does it have anything to do with the memory mapping functions? How can it be optimized? I know that, while osgPPU uses older CUDA memory mapping functions, there are new ones as of CUDA 3. Is there a difference in performance? Any information on this is appreciated, because it will really help me to decide wether I should integrate buffer mapping or just keep the copying stuff going :-) Best Regards -Thorsten ___ 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] osgPPU CUDA Example - slower than expected?
Ok..I correct this: There is a difference of ~1 frame ;) ...now I will stop replying to my own messages :D Am 16.12.2010 12:31, schrieb Thorsten Roth: By the way: There are two CUDA-capable devices in the computer, but I have tried using the rendering device as well as the CUDA-only device - no difference! -Thorsten Am 16.12.2010 12:25, schrieb Thorsten Roth: Hi, as I explained in some other mail to this list, I am currently working on a graph based image processing framework using CUDA. Basically, this is independent from OSG, but I am using OSG for my example application :-) For my first implemented postprocessing algorithm I need color and depth data. As I want the depth to be linearized between 0 and 1, I used a shader for that and also I render it in a separate pass to the color. This stuff is then fetched from the GPU to the CPU by directly attaching osg::Images to the cameras. This works perfectly, but is quite a bit slow, as you might already have suspected, because the data is also processed in CUDA kernels later, which is quite a back and forth ;-) In fact, my application with three filter kernels based on CUDA (one gauss blur with radius 21, one image subtract and one image pseudo-add (about as elaborate as a simple add ;-)) yields about 15 fps with a resolution of 1024 x 1024 (images for normal and absolute position information are also rendered transferred from GPU to CPU here). So with these 15 frames, I thought it should perform FAR better when avoiding that GPU - CPU copying stuff. That's when I came across the osgPPU-cuda example. As far as I am aware, this uses direct mapping of PixelBuferObjects to cuda memory space. This should be fast! At least that's what I thought, but running it at a resolution of 1024 x 1024 with a StatsHandler attached shows that it runs at just ~21 fps, not getting too much better when the cuda kernel execution is completely disabled. Now my question is: Is that a general (known) problem which cannot be avoided? Does it have anything to do with the memory mapping functions? How can it be optimized? I know that, while osgPPU uses older CUDA memory mapping functions, there are new ones as of CUDA 3. Is there a difference in performance? Any information on this is appreciated, because it will really help me to decide wether I should integrate buffer mapping or just keep the copying stuff going :-) Best Regards -Thorsten ___ 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] Clearing two Color Buffers separately
Hi, Am 09.12.2010 08:07, schrieb J.P. Delport: It need not be a slave camera, it can just be a camera in your scene. We have some initial code for an image processing lib here: http://code.google.com/p/flitr/source/checkout Quite interesting, as I am also working on an image processing library in course of my Master Thesis :) (more precisely, as you might already assume from my questions, it's more an image SPACE processing library ;)) ..though mine is not explicitly based on OpenGL/GLSL and is designed to easily allow to tie together several filters with different implementation details (e.g. one uses CUDA, another one uses OpenCL, another one is completely CPU-based...). I'll have a look at your stuff. Thanks again! :-) Regards -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clearing two Color Buffers separately
Hi, Am 08.12.2010 11:14, schrieb J.P. Delport: Hi, On 07/12/10 18:47, Thorsten Roth wrote: Hi, I have multiple render targets attached to separate color buffers in my application. One of them is used to store linearized, normalized depth values as well as absolute depth values and some additional information. My problem now is that this color buffer should in fact be cleared with the value 1 for the normalized depth component instead of the background color component which is set for the viewer camera. So, is there any (easy?) way to do this? If you consider a fragment shader running prior to you rendering easy, then yes :) In which way exactly? You mean as a separate rendering pass? Well, I believe at least I could live with it...though it's not yet quite clear to me ;) Can i use separate clear colors for separate color buffers? I don't think so. Would be really important, as I do not really want to be forced to do a further normalization of my buffer afterwards... ;-) How are you writing to the buffers? glFragData? Yup. Currently, the problem is only solved by having a -1 in the alpha channel where there is an object. Everything else is then considered as background. Of course this is not really satisfying, as I need to run a filter on it afterwards, so I still need to change the background pixels to the maximum depth (far plane) value... jp -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clearing two Color Buffers separately
Hi, Am 08.12.2010 12:19, schrieb J.P. Delport: Yes, a pass where the camera looks at a screen aligned quad. You just fill in whatever you want into all the MRT buffers using glFragData. You attach the same textures as for the second pass. Let me know if you need more info. rgds jp Best thing would be a code snippet, if you have one at hand ;-) ..tried several things such as using a slave camera with a different clear color today, but somehow that didn't seem to do the job, so I am quite interested in your approach :) Thank you! -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Clearing two Color Buffers separately
Hi, I have multiple render targets attached to separate color buffers in my application. One of them is used to store linearized, normalized depth values as well as absolute depth values and some additional information. My problem now is that this color buffer should in fact be cleared with the value 1 for the normalized depth component instead of the background color component which is set for the viewer camera. So, is there any (easy?) way to do this? Can i use separate clear colors for separate color buffers? Would be really important, as I do not really want to be forced to do a further normalization of my buffer afterwards... ;-) Thanks! -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shader Update Latency?!
Hi,
I currently have a problem with a shader update callback I do not
understand. I have a vertex and fragment shader which calculate linear
depth in [0,1] for me, also respecting dynamic clipping planes. To
achieve this, I pass zNear and zFar as uniform parameters to the shader.
To have them updated, I have the following callback methods (zFar is
looking accordingly):
class UpdateShaderZNear: public osg::Uniform::Callback {
public:
virtual void operator()(osg::Uniform* uniform, osg::NodeVisitor* nv) {
double x, zNear;
viewer-getCamera()-getProjectionMatrixAsPerspective(x,x,zNear,x);
uniform-set((float)zFar);
}
};
Now when I move my camera towards and away from the object, it seems
like the shader update is one frame (or so) too late, as I get values
that do not correspond to the [0,1]-normalization and the problem
disappears as soon as the camera stops.
Is there any reason for that/does anyone have an idea what I'm doing
wrong? If more information or code is necessary, just tell me :-)
-Thorsten
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shader Update Latency?!
I have actually tried it now, but it made no difference :-(
-Thorsten
Am 01.12.2010 19:22, schrieb Tim Moore:
Have you set the data variance of the Uniform object -- and the
containing StateSet object -- to Object::DYNAMIC?
Tim
On Wed, Dec 1, 2010 at 7:15 PM, Thorsten Roth thorsten.r...@alsvartr.de
mailto:thorsten.r...@alsvartr.de wrote:
Hi,
I currently have a problem with a shader update callback I do not
understand. I have a vertex and fragment shader which calculate
linear depth in [0,1] for me, also respecting dynamic clipping
planes. To achieve this, I pass zNear and zFar as uniform parameters
to the shader. To have them updated, I have the following callback
methods (zFar is looking accordingly):
class UpdateShaderZNear: public osg::Uniform::Callback {
public:
virtual void operator()(osg::Uniform* uniform,
osg::NodeVisitor* nv) {
double x, zNear;
viewer-getCamera()-getProjectionMatrixAsPerspective(x,x,zNear,x);
uniform-set((float)zFar);
}
};
Now when I move my camera towards and away from the object, it seems
like the shader update is one frame (or so) too late, as I get
values that do not correspond to the [0,1]-normalization and the
problem disappears as soon as the camera stops.
Is there any reason for that/does anyone have an idea what I'm doing
wrong? If more information or code is necessary, just tell me :-)
-Thorsten
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto: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] Shader Update Latency?!
Hi Robert,
thank you for this information. I did not know that I could do this, as
I'm an absolute newbie concerning shader stuff and was happy that I just
got it to work somehow ;)
I will try the approach with gl_ProjectionMatrix tomorrow, thank you :)
-Thorsten
Am 01.12.2010 20:51, schrieb Robert Osfield:
Hi Thorsten,
By default the OSG computes the near/far planes on the fly during the
cull traversal on every single frame. You can disable this.
Alternatively you could just use the gl_ProjectionMatrix directly on
the GPU to get the near/far planes - this is how I'd do it, far more
flexible and never needs any additional uniforms or callbacks.
Robert.
On Wed, Dec 1, 2010 at 6:15 PM, Thorsten Roththorsten.r...@alsvartr.de wrote:
Hi,
I currently have a problem with a shader update callback I do not
understand. I have a vertex and fragment shader which calculate linear depth
in [0,1] for me, also respecting dynamic clipping planes. To achieve this, I
pass zNear and zFar as uniform parameters to the shader. To have them
updated, I have the following callback methods (zFar is looking
accordingly):
class UpdateShaderZNear: public osg::Uniform::Callback {
public:
virtual void operator()(osg::Uniform* uniform, osg::NodeVisitor* nv)
{
double x, zNear;
viewer-getCamera()-getProjectionMatrixAsPerspective(x,x,zNear,x);
uniform-set((float)zFar);
}
};
Now when I move my camera towards and away from the object, it seems like
the shader update is one frame (or so) too late, as I get values that do
not correspond to the [0,1]-normalization and the problem disappears as soon
as the camera stops.
Is there any reason for that/does anyone have an idea what I'm doing wrong?
If more information or code is necessary, just tell me :-)
-Thorsten
___
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] Problem with render to texture (RTT)
Hi guys, I currently have a problem with a simple experiment with RTT. I am using osgviewerGLUT as a base for this. What I am trying is to render my scene view to a texture and display this afterwards. To achieve this, I first setup a camera which renders to the texture and then another one which renders the textured quad to the screen. The scene root contains these two cameras as a child, while the camera which renders to the texture has the loaded object as a child. What happens now seems a little weird to me, because I am completely new to OSG. The application starts with a view behind the object, and this view does not change when I try to rotate the object. Instead, the camera stays behind the object in that exact position, which I can tell because the light seems to be moving, which it is of course not. Now my question is, how can I decouple the camera from the object movement, so I can freely rotate the object without the camera following it? Thanks in advance :) Regards -Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
