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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
