Thanks for this precision. Sorry I try to make a simple example to explain you my problem it's probably not the best but my real shader is not like that, it doesn't use global variable but it's the same principle. I put some value in my fragData[] in relation with the depth value, and i access to the next depth layer where I put other value and I would like the maxBlending result between this different colors.
2010/1/7 J.P. Delport <jpdelp...@csir.co.za> > Hi, > > > clement vidal wrote: > >> Thanks for the link, i will look at this. >> >> But for the shader example I gave you I think that it do the first >> treatment for the first pixel then it peel the first layer and do the >> second treatment for the second depth layer, but maybe I wrong. >> > Like you wrote it (I'm assuming no uniforms), the code would always execute > as if i=0. There is no global state in the fragment programs, your code > would execute separately for every pixel. > > > >> The code of osgoit is it available somewhere? >> > check here in the thread attachment: > > http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/6263/focus=6269 > > jp > > >> >> 2010/1/7 J.P. Delport <jpdelp...@csir.co.za <mailto:jpdelp...@csir.co.za >> >> >> >> Hi, >> >> >> clement vidal wrote: >> >> Thanks for your help. >> >> But the solution that you gave me it's not really what I want to >> do. The simple example i gave you it's just to explain what kind >> of result I need. Actually I'm trying to implement a Dual Depth >> Peeling based on the Nvidia Paper and it use this kind of >> blending. For example in my shader if I do that: >> >> int i=0; >> >> void main() >> { >> if(i=0) >> { >> gl_FragData[0 = vec4(1.0,0.0,0.0,1.0); >> >> i=1; >> return; >> } >> gl_FragData[0] = vec4(0.0,1.0,0.0,1.0); >> } >> >> I would like have yellow in my texture for now I have green. >> Here again it's just an example, but that's why i would like to >> use a blend equation, it's the same problem as the other example >> I gave you I would like do a MAX blending between the value >> previously in the texture and the new value. >> >> Have you an idea how to do that? >> >> >> Well your shader only executes once... so AFAIK you can only write >> once to the frame buffer in a render pass. >> >> If you want colours to blend with previous ones you first have to >> create the previous ones, so you will need multiple passes. >> >> Maybe also see here for inspiration: >> http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/6263/ >> >> jp >> >> >> >> 2010/1/7 J.P. Delport <jpdelp...@csir.co.za >> <mailto:jpdelp...@csir.co.za> <mailto:jpdelp...@csir.co.za >> <mailto:jpdelp...@csir.co.za>>> >> >> Hi Clement, >> >> >> clement vidal wrote: >> >> Hi JP >> >> For now I Initialize a texture with the value A, in the >> shader I >> put the value B and I would like to have a the end in the >> texture the max blending between the value A and B. >> >> Lets do an example: >> >> I create an texture Tex initialized with color red (1,0,0,1) >> >> I attach my texture to a camera >> Camera->attach(osg::Camera::COLOR_BUFFER0, Tex); >> >> I use a shader witch do this treatment: gl_FragData[0] = >> vec4(0.0,1.0,0.0,1.0); >> >> And I would like have a yellow (1.0,1.0,0.0,1.0) texture >> at the >> end of the treatment. >> >> For now using an osg::BlendEquation with RGBA_MAX blending, >> I >> have if I define a clearColor to my camera the blending >> between >> this clearColor and the color use in the shader. I think >> this is >> normal because the blendEquation define how the blending is >> doing between the color previously in the frame buffer >> and the >> added color. But it's not what i want I would like to >> have the >> blending between the color previously in the texture and the >> added color. >> >> >> OK I think I understand better now. To use your texture as >> input (in >> order to kind of make it the background (as you have working >> with >> clearcolour)) you will have to map it onto a quad (screen/camera >> projection aligned) [1]. Then you make your camera look at >> this quad >> and the fragment shader would then blend with the texture in the >> frame buffer. Reading from and writing to the same texture can >> sometimes give problems, so you might have to make a copy for >> the >> output (ping-pong, see osggameoflife). >> >> I'm also not sure why you want to use blending, do you have some >> special algorithm that needs it? If you have an initial >> texture with >> input values, you can just sample it in your shader and >> modify the >> value yourself (based on maths, input uniforms or other >> textures) >> and put it into the final texture. >> >> [1] Attachments to the camera are outputs, textures bound to >> geometry are used as inputs for RTT. >> >> cheers >> jp >> >> >> >> >> Thanks for your help >> >> Clement >> >> 2010/1/7 J.P. Delport <jpdelp...@csir.co.za >> <mailto:jpdelp...@csir.co.za> >> <mailto:jpdelp...@csir.co.za >> <mailto:jpdelp...@csir.co.za>> <mailto:jpdelp...@csir.co.za >> >> <mailto:jpdelp...@csir.co.za> >> >> <mailto:jpdelp...@csir.co.za <mailto:jpdelp...@csir.co.za >> >>>> >> >> >> >> Hi Clement, >> >> could you explain a bit more what you expect and what >> you are >> getting? Do you want to blend between the different >> textures >> (AFAIK >> you cannot do this unless you do another pass)? Are >> you expecting >> max, but getting average? >> >> jp >> >> clement vidal wrote: >> >> >> Hi, >> >> I have a problem with BlendEquations and shaders. >> That is the >> situation: >> >> I attach several textures to my camera using >> COLOR_BUFFER0, >> COLOR_BUFFER1, ... >> I use a shader to make the rendering into this >> textures. >> >> There is some values in this textures and i would >> like to >> use a >> max blending between the value wich are already in >> and the >> values i affect in the shader. >> >> When I define an osg::BlendEquation with RGBA_MAX >> blending, i >> have the blend result between the value in the >> frame buffer >> (background color or ClearColor ) and the value in >> the >> shader. >> >> What I do wrong? Somebody have a idea? >> >> Thanks for helping >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org>> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto: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. MailScanner >> thanks >> Transtec Computers for their support. >> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org>> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto: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 >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto:osg-users@lists.openscenegraph.org >> <mailto: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. MailScanner thanks >> Transtec Computers for their support. >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> <mailto:osg-users@lists.openscenegraph.org> >> <mailto: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 >> <mailto: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. MailScanner thanks >> Transtec Computers for their support. >> >> _______________________________________________ >> 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 >> > > -- > 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. MailScanner thanks Transtec > Computers for their support. > > _______________________________________________ > 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
