Hi Wojtek, Thanks for the suggestions. I''ve gone through these. osgprerender does indeed render with the suggested artifacts when the FBO depth buffer is switch off.
Wth the osgshadow --lipsm settings everything works until I disable the color buffer, in which case the shadow disappears, so it does look like the ATI Linux drivers still require a colour buffer?! Robert. On Thu, Nov 19, 2009 at 4:35 PM, Wojciech Lewandowski <[email protected]> wrote: > Hi Robert, > > You've asked for testing cases. When few months ago we were trying to not > force buffer attachments we noticed following problems: > cessna model in osgprerender exampe was having z-sorting issues and looked > like swiss cheese, > osgshadow example with --lispsm had trouble without color buffer on your ATI > setup > > I suppose we could use the same cases to verify if implicit buffer masks are > properly set through DisplaySettings. Proposed tests: > setenv OSG_IMPLICIT_BUFFER_ATTACHMENT_RENDER_MASK=OFF > or > setenv OSG_IMPLICIT_BUFFER_ATTACHMENT_RENDER_MASK=~DEPTH > or > setenv OSG_IMPLICIT_BUFFER_ATTACHMENT_RENDER_MASK=DEFAULT|~DEPTH > or > setenv OSG_IMPLICIT_BUFFER_ATTACHMENT_RENDER_MASK=COLOR|~DEPTH > and run > osgprerender > output should be broken and look like attached prerender.jpg image. If it > does the test succeded ;-) > > osgshadow should work flawlessly without color buffer attachments. It could > be verifiable by hitting shadow map resolution limits. It may be possible to > set 8kx8k shadow map when color buffers are not enforced. For example, > on my GeForce 8800 GTS 320 MB following command does not work due to > insufficient memory: > osgshadow -4 --screen 0 --SingleThreaded --mapres 8192 --lispsm > but > osgshadow -4 --screen 0 --SingleThreaded --mapres 8192 --lispsm > --implicit-buffer-attachment-render-mask ~COLOR > does work. > So I assume it could be treated as proof options are processed correctly and > color buffers are not applied. > You also mentioned that you had problems with above lispsm example on ATI > without COLOR buffers, so you may now check if the same problem is now > present, when you pass option --implicit-buffer-attachment-render-mask > ~COLOR or set enviroment var > OSG_IMPLICIT_BUFFER_ATTACHMENT_RENDER_MASK=~COLOR. > I made above tests on OSG SVN trunk with my today submitted changes in > RenderStage.cpp, Windows XP 32, GF 8800 GTS 320 MB, driver ver: 191.07. > HTH & Cheers, > > Wojtek > > > > > > ----- Original Message ----- > From: "Wojciech Lewandowski" <[email protected]> > To: "OpenSceneGraph Submissions" <[email protected]> > Sent: Thursday, November 19, 2009 2:23 PM > Subject: Re: [osg-submissions] DisplaySettings > masksforimplicitbufferattachments > > >> Robert, Paul >> >> My most recent changes to RenderStage are attached. Modifications were >> done >> vs current SVN. Main difference between previous change Robert merged is >> selective setting of depthAttached, stencilAttached, colorAttached flags >> after proper buffers were attached due to IMPLICIT_BUFFER_ATTACHMENT >> policy. >> In initial Paul Martz proposal these flags were also set when such buffers >> were set for auxiliary msfbo. I believe its not correct as msfbo and main >> fbo could enforce different buffer attachments and msfbo should have their >> separate flags if neccessary. I wrote about this in the 3rd submission on >> Oct 29 asking Paul for comments and fixes but did not get response. Below >> is >> excerpt from that post: >> >>> Paul, I noticed one issue that may not appear in practice but seems >>> theoretically possible. One could turn off implicit >>> COLOR_BUFFER_ATTACHEMENT >>> for main fbo but leave it activated for multisample fbo. When no color >>> attachment is present its neccessary to make sure that OSG will not try >>> to >>> change DrawBuffer or ReadBuffer to other value than GL_NONE. This >>> condition >>> was satisfied in RenderStage.cpp lines 497-507. Once you made your tweaks >>> for msfbo you chose to set colorAttached to true when msfbo had color >>> buffer >>> attached. I believe its incorrect and will not work if main fbo will not >>> have color buffer attachment. colorAttached variable should be used only >>> for >>> main fbo. And I have removed all the lines where it was set with msfbo. >> >>> You may need to define similar but indepent variable for msfbo if you >>> expect >>> to have independent resolve & render color masks. I am afraid that proper >>> handling may also require spearate set of methods similar to >>> setDrawBuffer >>> and setReadBuffer for use with msfbo (DrawBuffer and ReadBuffer do not >>> belong to global GL context but are Framebuffer dependent states). On the >>> other hand I suspect that using msfbo with color and main fbo without >>> color >>> buffer may not make sense, so I did not attempt to solve the case myself. >>> Doubts scared me enough and I do not really understand all what is done >>> for >>> msfbo. I leave the solution for you . >> >> >> One extra note: Robert's patch also contained a piece of code that was >> submitted later amnong number of GL3 changes by Paul. I removed this part >> current submission because it was not present in current SVN codebase and >> it >> was not intended in my submission. If I have added them to earalier >> submissions it was by my mistake probalby after some testing of Paul >> submissions. Exact changes I have skipped are here: (as taken from Robert >> patch) >> >> START OF EXCERPT >> -------------------------- >> @@ -904,29 +941,12 @@ >> >> if (fbo_supported && _resolveFbo.valid() && >> fbo_ext->glBlitFramebuffer) >> { >> - GLbitfield blitMask = 0; >> + // OpenGL 3.1 spec says: "If a buffer is specified in mask and >> does >> not >> + // exist in both the read and draw framebuffers, the >> corresponding >> bit >> + // is silently ignored." So there is no need to iterate over >> buffer >> + // attachments to determine the value of mask; just blit all. >> + const GLbitfield blitMask( GL_DEPTH_BUFFER_BIT | >> GL_STENCIL_BUFFER_BIT | GL_COLOR_BUFFER_BIT ); >> >> - //find which buffer types should be copied >> - for (FrameBufferObject::AttachmentMap::const_iterator >> - it = _resolveFbo->getAttachmentMap().begin(), >> - end =_resolveFbo->getAttachmentMap().end(); it != end; ++it) >> - { >> - switch (it->first) >> - { >> - case Camera::DEPTH_BUFFER: >> - blitMask |= GL_DEPTH_BUFFER_BIT; >> - break; >> - case Camera::STENCIL_BUFFER: >> - blitMask |= GL_STENCIL_BUFFER_BIT; >> - break; >> - case Camera::PACKED_DEPTH_STENCIL_BUFFER: >> - blitMask |= GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT; >> - default: >> - blitMask |= GL_COLOR_BUFFER_BIT; >> - break; >> - } >> - } >> - >> // Bind the resolve framebuffer to blit into. >> _fbo->apply(state, FrameBufferObject::READ_FRAMEBUFFER); >> _resolveFbo->apply(state, FrameBufferObject::DRAW_FRAMEBUFFER); >> >> -------------------------- >> END OF EXCERPT >> >> >> Wojtek Lewandowski >> >> ----- Original Message ----- >> From: "Robert Osfield" <[email protected]> >> To: "OpenSceneGraph Submissions" >> <[email protected]> >> Sent: Thursday, November 19, 2009 11:13 AM >> Subject: Re: [osg-submissions] DisplaySettings masks >> forimplicitbufferattachments >> >> >> Hi Wojtek, >> >> On Thu, Nov 19, 2009 at 10:08 AM, Robert Osfield >> <[email protected]> wrote: >>> Thanks. I think what I'll do is check in the changes to include/osg >>> and src/osg as they are passive changes - i.e. they won't effect >>> functionality. The changes to RenderStage I'll leave till after >>> further clarification from yourself. >> >> I have now checked in the changes to include/osg and src/osg, the >> changes to RenderStage.cpp I've reverted, the diff against svn/trunk >> to apply these changes is attached. >> >> Robert. >> >> >> >> >> -------------------------------------------------------------------------------- >> >> >>> _______________________________________________ >>> osg-submissions mailing list >>> [email protected] >>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> >> > > > >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
