HI Wojtek, Excellent detective work. I'll have to raise my hand as the culprit of the change to CullVisitor::apply(Camera&), done is response to a discussion between Mathias Froehlich and myself about inheritance of settings. I believe the inheritance of settings is now correct, but obviously in my testing after applying this change I didn't spot the regression in osgshadow and the unforseen consequences.
Since I think the actual rules of inheritance of settings are correct, and things worked before because of bug in the inheritance of settings, so its a matter of either changing the defaults in CullSettings so that less of the inherited state comes down into the local Camera, or we override the defaults locally. I'd suggest we change the defaults locally and review the defaults in light of how many changes we make. Robert. On Tue, Mar 18, 2008 at 9:18 AM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I think I have found the cause of the problem. Problem is not only related > to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar issue > (SM, SSM, & PSSM). And it looks like problem could be wider and affected > other examples as well. > > Problem appeared when SVN changelist 7912 was added . This submission > changes Cameras cull settings inheritance policy during Cull traversal. > After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets > overriden with main camera COMPUTE_NEAR_FAR setting . This in effect > desynchronizes texgen and depth map. Texgen is calculated using not adjusted > Shadow camera projection. Shadow depth map is rendered using Shadow camera > projection that was additionaly near/far adjusted. > > Problem could be avoided by adding following line to shadow camera > initialization. > _camera->setInheritanceMask( _camera->getInheritanceMask() & > ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); > > But this topic brings another question: up till 7912 changelist, we were > simply using setComputeNearFar( false ) to avoid clamping of projection > matrix. Does it mean that from now we will also need to add above aditional > line to protect it from inheritance overriding ? If yes then we got a lot of > code to review and adjust ...;-( > > > Cheers, > Wojtek > > ----- Original Message ----- > From: "Wojciech Lewandowski" <[EMAIL PROTECTED]> > To: "OpenSceneGraph Users" <[email protected]> > > > Sent: Monday, March 17, 2008 12:29 PM > Subject: Re: [osg-users] osgShadow example and gerneral question > > > Robert, > > I replicated the problem with osgShadow::ShadowMap. I will try to find the > cause... > > Cheers, > Wojtek > > ----- Original Message ----- > From: "Wojciech Lewandowski" <[EMAIL PROTECTED]> > To: "OpenSceneGraph Users" <[email protected]> > Sent: Monday, March 17, 2008 11:57 AM > Subject: Re: [osg-users] osgShadow example and gerneral question > > > Hi Robert, > > There are few versions from 2000-2002. I found earlier 2000 version on > NVidia site. But 2002 version has the PolygonOffset section extended in > comparison to 2000. It looks like siggraph 2002 presentation could be found > under this link: > > http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt > > Slides 20-27 refer to PolygonOffset topic. > > Cheers, > Wojtek > > ----- Original Message ----- > From: "Robert Osfield" <[EMAIL PROTECTED]> > To: "OpenSceneGraph Users" <[email protected]> > Sent: Monday, March 17, 2008 11:26 AM > Subject: Re: [osg-users] osgShadow example and gerneral question > > > Hi Wojtek, > > Could you post a link, or the actual presentation, or put it up on the > wiiki, of Mark Kilgrads paper discussing PolygonOffset. > > It would nice to isolate the actual differences in implementation of > PolygonOffset across hardware so we can pick appropriate settings for > different hardware. There are already some factors set in > PolygonOffset itself to try and cope with this but the values where > just set from basic experience with osgText, and not done is rigorous > way. I would to roll this back and do a rigorous testing of different > hardware so we can get more consistent results across and models > sizes. > > Robert. > > On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski > <[EMAIL PROTECTED]> wrote: > > Hi Robert and All, > > > > I am back from vacations. Ready to take the responsibility for my changes > > in > > osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with > > PSSM or standard ShadowMap as well ? Its not obvious from forum emails > > and I > > am unable to replicate it with standard ShadowMap. > > > > I looked once again at the my submitted osgShadow::ShadowMap code and I > > have > > NOT changed polygon offset. > > PolygonOffset remains untoched in several latest revisions. > > > > However, I do have my objections against default ShadowMap > > cullface/polygon > > offset settings. I remember that former (pre 2.0 osgShadow nodekit) > > DepthShadowMap example was using frontface culling and polygon offset > > factor=1.1 and units = 4. These were the settings that were also > > recommended > > by NVidia ShadowMaping presentations ("ShadowMapping with Today's OpenGL > > Hardware" Mark J. Kilgard NVidia). I use this as defaults in my work and > > I > > am quite happy with them. I also noticed that Terry Welsh PSSM example > > also > > used similar defaults. > > > > But for some reason these recommended settings were changed when > > osgShadow::ShadowMap was introduced. Whats more, I don't know in which > > version exactly, but at some moment self shadowing and negative offset > > was > > added (front face culling remained). See line 210 in > > osgShadow::ShadowMap.cpp. In my opinion this is bit unusual method but I > > understand that different databases and different render approaches may > > benefit from different cull face/polygon offset settings. > > > > Currently I work only with NVidia boards but I know that ATI may require > > different settings. I used to play with Direct3D DepthBias on NVidia and > > ATI > > some time ago and results were significantly different for the same depth > > bias values. I guess its the same situation with PolygonOffset in OpenGL. > > > > I am afraid that completely getting rid of PolygonOffset is impossible > > because there is no substitute for slope bias (PolygonOffset factor). No > > Depth range nor Perspective matrix tricks could replace it. MJ. Kilgard > > Presentation I mentioned earlier has nice expalanation of this topic. (I > > can > > send it if anyone wants to have a look) > > > > Cheers, > > Wojtek Lewandowski > > > > > > > > ----- Original Message ----- > > From: "Robert Osfield" <[EMAIL PROTECTED]> > > To: "OpenSceneGraph Users" <[email protected]> > > Sent: Sunday, March 16, 2008 2:31 PM > > Subject: Re: [osg-users] osgShadow example and gerneral question > > > > > > HI Sebastian, > > > > I see the artificate on Nvidia hardware so this rules out an ATI bug. > > So far it I looks like an osgShadow bug, exactly what's gone amiss I > > don't know though... > > > > Robert. > > > > On Sun, Mar 16, 2008 at 10:15 AM, Sebastian Messerschmidt > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > Hi Adrian, > > > > > > > > > > > > As I've pointed out in the osg-users list, there seems to be a bug in > > > recent > > > ATI drivers where the t-coordinate in the generated shadow texture is > > > screwed up, i.e. inversed. Your screenshots don't look exactly like the > > > artefacts I've seen but it might be related I reckon. > > > > > > To check this I recommend replacing the fixed function vertex shader by > > > your > > > own code which does the EYE_PLANE projection and play around with the > > > coordinates. > > > > > > > > > > > > Cheers > > > > > > Sebastian > > > > > > > > > > > > ________________________________ > > > > > > > > > Von: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Im Auftrag von > > Adrian > > > Egli OpenSceneGraph (3D) > > > Gesendet: Donnerstag, 13. März 2008 21:57 > > > An: OpenSceneGraph Users > > > Betreff: Re: [osg-users] osgShadow example and gerneral question > > > > > > > > > > > > > > > > > > some screenshots of the bug > > > > > > /adi > > > > > > > > > 2008/3/13, Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]>: > > > > > > Since the OSG 2.2 or event some version before, osgShadow is broken. I > > > don't > > > yet know why. but it doesn't work on ATI based computers as far as i > > could > > > test it. > > > > > > > > > 2008/3/13, Raymond de Vries <[EMAIL PROTECTED]>: > > > > > > > > > > > > Hi, > > > > > > All I know that the PSSM implementation was not changed, the last I > > > looked at the svn version (some weeks ago), compared to 2.2.0. I will > > > test the svn version example also asap, and let you know. > > > > > > Now that you mention PSSM, I've send a (small) patch some months ago > > and > > > suggested to change the interface a little so that parameters can be > > > changed at runtime (where it is currently only possible at startup). > > > > > > Also I've send a bug report to the list in which I showed an artifact, > > > incl source code. > > > > > > Within some weeks I would like to dive into PSSM again, so hopefully > > we > > > can join forces. > > > > > > Cheers > > > > > > Raymond > > > > > > > > > > > > Jean-Sébastien Guay wrote: > > > > Hi Adrian, > > > > > > > > > > > >> i have retested osgShadow and get some really strange behaviour. > > event > > > >> PSSM doesn't work on my ATI x1600 based pc. was there changes and > > did > > > we > > > >> really test all options of osgshadow / implementation, or do > > > >> i only have such a problem > > > >> > > > > > > > > I remarked a while ago that osgshadow --pssm did not work for me on > > my > > > > nVidia card (even with the --NVidea (sic) switch, I see no shadows). > > No > > > > idea what's wrong, as I have no time to go into the details... > > > > > > > > I know I'm not much help, but at least you know you're not alone. > > > > > > > > J-S > > > > > > > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > > > > > > > -- > > > ******************************************** > > > Adrian Egli > > > > > > > > > > > > > > > -- > > > ******************************************** > > > Adrian Egli > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
