Switching the shader to use *2D instead of *2DRect fixed it. Thanks! Mark
Mark A. Bolstad Scientific Computing Janelia Farm Research Campus Howard Hughes Medical Institute 19700 Helix Drive, Ashburn, VA 20147 email: bolst...@janelia.hhmi.org office: +1.571.209.4623 web: http://www.hhmi.org/janelia/ On Jul 18, 2011, at 6:03 AM, Sergey Polischuk wrote: > Hi, Mark > > Afaik osgdistortion uses 2d textures not rect textures. > > Cheers, > Sergey. > > 18.07.2011, 11:42, "J.P. Delport" <jpdelp...@csir.co.za>: >> Hi, >> >> I can't follow what you expect and what is working/not? >> >> If you are using 2DRect remember that texture coords are not between 0 >> and 1, so it does not make sense to directly put them into colours then. >> >> jp >> >> On 15/07/2011 20:31, Bolstad, Mark wrote: >> >>> So I've done some testing. I've decided to go the shader route as it >>> will give the most flexibility. I've modified osgdistortion from the >>> latest svn. At the end is a short patch to show the changes. >>> >>> The main problem I'm getting is that the FBO texture doesn't appear to >>> be passing to the shader properly. All I'm getting is a black screen. If >>> I swap the shader to color based on texture coordinates, the output is >>> correct. I'm sure that I'm probably missing something simple in the >>> setup/texture binding, and any help is appreciated. >>> >>> Mark >>> >>> 34,36d33 >>> < #include <osg/Program> >>> < #include <osg/Shader> >>> < #include <osg/Uniform> >>> 58,80d54 >>> < >>> /////////////////////////////////////////////////////////////////////////// >>> < // in-line GLSL source code for the "microshader" example >>> < >>> < static const char *shaderVertSource = { >>> < "// passthru - Simple pass through vertex shader\n" >>> < "void main(void)\n" >>> < "{\n" >>> < " gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;\n" >>> < " gl_Position = ftransform();\n" >>> < "}\n" >>> < }; >>> < >>> < static const char *shaderFragSource = { >>> < "uniform sampler2DRect textureIn;\n" >>> < "void main(void)\n" >>> < "{\n" >>> < // " gl_FragColor = vec4( gl_TexCoord[0].s, gl_TexCoord[0].t, 0.0, 1.0 >>> );\n" >>> < " gl_FragColor = texture2DRect( textureIn, gl_TexCoord[0].st );\n" >>> < "}\n" >>> < }; >>> < >>> < >>> /////////////////////////////////////////////////////////////////////////// >>> < >>> 94,98d67 >>> < osg::Program* program = new osg::Program; >>> < program->setName( "texture_shader" ); >>> < program->addShader( new osg::Shader( osg::Shader::VERTEX, >>> shaderVertSource ) ); >>> < program->addShader( new osg::Shader( osg::Shader::FRAGMENT, >>> shaderFragSource ) ); >>> < >>> 156,157d124 >>> < osg::Vec3 cursor = bottom; >>> < osg::Vec2 texcoord = bottom_texcoord; >>> 198,201c165,166 >>> < stateset->setTextureAttributeAndModes( 0, texture, >>> osg::StateAttribute::ON ); >>> < stateset->addUniform( new osg::Uniform( "textureIn", 0 ) ); >>> < stateset->setAttributeAndModes( program, osg::StateAttribute::ON ); >>> < stateset->setMode(GL_LIGHTING,osg::StateAttribute::ON); >>> --- >>>> stateset->setTextureAttributeAndModes(0, >>> texture,osg::StateAttribute::ON); >>>> stateset->setMode(GL_LIGHTING,osg::StateAttribute::OFF); >>> 391d355 >>> < osg::Vec3 cursor = bottom; >>> 393,394d356 >>> < >>> < >>> 705c667 >>> < if (!loadedModel) loadedModel = osgDB::readNodeFile("cow.osg"); >>> --- >>>> if (!loadedModel) loadedModel = osgDB::readNodeFile("cow.osgt"); >>> 786d747 >>> < viewer.setUpViewOnSingleScreen( 0 ); >>> >>> */Mark A. Bolstad/* >>> Scientific Computing >>> Janelia Farm Research Campus >>> Howard Hughes Medical Institute >>> 19700 Helix Drive, Ashburn, VA 20147 >>> email:*bolst...@janelia.hhmi.or <mailto:bolst...@janelia.hhmi.or>**g* >>> office: +1.571.209.4623 >>> web: http://www.hhmi.org/janelia/ >>> >>> On Jul 14, 2011, at 10:45 AM, J.P. Delport wrote: >>>> Hi, >>>> >>>> On 14/07/2011 16:37, Jason Daly wrote: >>>>> On 07/14/2011 10:08 AM, Bolstad, Mark wrote: >>>>>> I like the idea of combining the passes into one, but if I had a blue >>>>>> object and had to mask it into the red channel, wouldn't it just be >>>>>> black? >>>>> Yes, it would be black on the red and green passes, but it would show up >>>>> on the blue pass. When you combined the three passes of the image to an >>>>> RGB texture, you'd have your blue object. The flow would look something >>>>> like this: >>>>> >>>>> - set the camera to draw to an RGB texture >>>>> - set camera's color mask to red only >>>>> - draw the first object >>>>> - set camera's color mask to green only >>>>> - draw the second object >>>>> - set camera's color mask to blue only >>>>> - draw the third object >>>>> - fetch the texture from the camera and use it however you need it >>>>> >>>>> as J-S said, you save the combine pass and you don't even need any >>>>> special shader magic. >>>>>> I had talked to a professor who had suggested a one-line fragment >>>>>> shader to do RGB-> Luminance and use Color Masking to write into the >>>>>> appropriate channel. Would rendering straight into a Luminance texture >>>>>> with Color Masking work? >>>>> Maybe I'm not understanding you correctly, but I don't think this would >>>>> work. You'd end up with a luminance image (effectively, a grayscale >>>>> image) at the end and not a color image. >>>> I think prof meant he must stick the calculated luminance value into >>>> all three channels. >>>> >>>> jp >>>>>> In reality, this is actually more complicated in that it's not three >>>>>> objects, but three separate frames of animation. So the main loop is: >>>>>> >>>>>> while(1) >>>>>> { >>>>>> advance sim >>>>>> frame(); // Render to red >>>>>> advance sim >>>>>> frame(); // Render to green >>>>>> advance sim >>>>>> frame(); // Render to blue >>>>>> Render RTT texture to display. >>>>>> } >>>>> Maybe if you explained what you're trying to do at a higher level, we'd >>>>> be able to better help. What is the problem you're trying to solve? >>>>> >>>>> --"J" >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> _______________________________________________ >>>> 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. >> >> _______________________________________________ >> 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
