Hi Wojtek, I moved forward with this. Actually I made it work and it works well on the dome. The distortion is coming in realtime from their server and it is changing only the projection matrix. What I did, I saved the pre-distorted matrix in the Camera as UserData and in MinimalShadowMap::ViewData::cullShadowReceivingScene I set the clamp to use this matrix, so it is now standard matrix and all works fine
osg::RefMatrix* mx = dynamic_cast<osg::RefMatrix*>(_cv->getRenderInfo()->getCurrentCamera()->getUserData()); _clampedProjection = *mx;//*_cv->getProjectionMatrix(); But, as I mentioned this is rather workaround that works well then a real solution. Once you get back from vacation I will ping you again and if you have time and will we (you :-) ) can try to make it proper Cheers, Nick On Wed, Aug 6, 2014 at 10:57 PM, Trajce Nikolov NICK < [email protected]> wrote: > Hi again Wojtek, > > I read the code of MinimalShadowMap and tried to understand it (at least > the part of the clamping of the projection matrix). Did some hacks and got > some result. The best results I have got is that the shadows are now still > but flickering. Before they were based on the heading and were changing > with the heading. Nevermind. Here are my findings: > > It seam that you clamp the projection matrix only if you have the far > plane set for the polytope to cut the scene for shadow receival. This is > the snippet from MinimalShadowMap::ViewData::cullShadowReceivingScene: > > // Aditionally clamp far plane if shadows don't need to be cast as > // far as main projection far plane > if( 0 < *_maxFarPlanePtr ) > clampProjection( _clampedProjection, 0.f, *_maxFarPlanePtr ); > > and only there. Now in clampProjection and did some changes to force the > algorithm path to follow as this is a standard projection matrix but affect > only those parts of the matrix which are affected by the far plane. Bellow > is the hacked method. Now all seam to be good across channels only the > shadows are somewhat as very low res even the setting of the far plane is > very near (1000m) and the resolution of the texture is pretty high (2048). > When I set the the far plane to 0 I have the shadow low res again since the > polytope of the scene is not clamped. Any hints? Thanks again: > > void MinimalShadowMap::ViewData::clampProjection > ( osg::Matrixd & projection, float new_near, float > new_far ) > { > double r, l, t, b, n, f; > bool perspective = projection.getFrustum( l, r, b, t, n, f ); > perspective = true; > if( !perspective && !projection.getOrtho( l, r, b, t, n, f ) ) > { > // What to do here ? > OSG_WARN << "MinimalShadowMap::clampProjectionFarPlane failed - > non standard matrix" << std::endl; > > } else if( n < new_near || new_far < f ) { > > #if 0 > if( n < new_near && new_near < f ) { > if( perspective ) { > l *= new_near / n; > r *= new_near / n; > b *= new_near / n; > t *= new_near / n; > } > n = new_near; > } > #endif > //if( n < new_far && new_far < f ) > { > f = new_far; > } > > if( perspective ) > #if 0 > projection.makeFrustum( l, r, b, t, n, f ); > #else > { > n = 0.0; > double C = (fabs(f)>DBL_MAX) ? -1. : -(f+n)/(f-n); > double D = (fabs(f)>DBL_MAX) ? -2.*n : -2.0*f*n/(f-n); > //SET_ROW(0, 2.0*zNear/(right-left), 0.0, 0.0, 0.0 ) > //SET_ROW(1, 0.0, 2.0*zNear/(top-bottom), 0.0, 0.0 ) > //SET_ROW(2, A, B, C, -1.0 ) > //SET_ROW(3, 0.0, 0.0, D, 0.0 ) > projection(2,2) = C; > projection(3,2) = D; > } > #endif > else > projection.makeOrtho( l, r, b, t, n, f ); > } > } > > > > > On Wed, Aug 6, 2014 at 12:05 PM, Trajce Nikolov NICK < > [email protected]> wrote: > >> Hi Wojtek, >> >> thanks for the fast reply. I am going to investigate this but there is no >> source code (black box) so it is hard to say. I took very naive approach >> for the moment since I am not familiar with the code of the >> MinimalShadowMap that much and will try to force the conditions in the >> snippet as the non standard matrix is valid projection matrix and see the >> results. But will wait for you when you get back from vacation and will >> ping you again if you can give more hints. Enjoy the vacation!!!! >> >> Thanks as always! >> >> Nick >> >> >> On Wed, Aug 6, 2014 at 11:59 AM, Wojciech Lewandowski < >> [email protected]> wrote: >> >>> Hi, Trajce, >>> >>> I am on vacations. Quick answer is impossible in my opinion. I would bet >>> that projection software uses some matrix tricks and it would be hard to >>> figure it out without seeing the code and solution. There is a chance >>> though, that matrix obtained there is not a right projection matrix used to >>> render particular channels. As far as I know such solutions, there are a >>> channel passes which render each channel to offscreen texture/pixelbuffer >>> and final pass which projects those on sphere or other irregular surface >>> and then blasts this to screen and projector optics does the rest. So it >>> may be a chance that projection matrix obtained is for final pass and if >>> you obtain channel matrices they may turn out to be regular. This of course >>> brings question why the code obtained wrong perspective matrix instead of >>> right one ? And here I have no answer too, it has to be traced and debugged >>> with original code. >>> >>> Cheers, >>> Wojciech Lewandowski >>> >>> >>> 2014-08-06 0:44 GMT+02:00 Trajce Nikolov NICK < >>> [email protected]>: >>> >>>> Hi Community, >>>> >>>> My client have a setup with image distortion over a dome, multiple >>>> channels, and along with the projectors there is an API coming that is well >>>> integrated in OSG - it modifies the projection matrix somehow. And we are >>>> facing issues with shadows, in the following snippet: >>>> >>>> void MinimalShadowMap::ViewData::clampProjection >>>> ( osg::Matrixd & projection, float new_near, float >>>> new_far ) >>>> { >>>> double r, l, t, b, n, f; >>>> bool perspective = projection.getFrustum( l, r, b, t, n, f ); >>>> if( !perspective && !projection.getOrtho( l, r, b, t, n, f ) ) >>>> { >>>> // What to do here ? >>>> OSG_WARN << "MinimalShadowMap::clampProjectionFarPlane failed - >>>> non standard matrix" << std::endl; >>>> >>>> } else ....... >>>> >>>> You can see the comment // What to do here ?. >>>> >>>> Well, what is to be done there since the distorted matrix coming from >>>> the API seam to be recognized by non standard matrix? Someone have a clue? >>>> >>>> Thanks as always ! >>>> >>>> Nick >>>> >>>> -- >>>> trajce nikolov nick >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> trajce nikolov nick >> > > > > -- > trajce nikolov nick > -- trajce nikolov nick
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
