Hi Adrian,
I did a test of recent code. Biggest issue, in my opinion, flickering in scene
-3 still remains. Shadows with chess.ive indeed look correct, exactly like in
the movie you linked. But scene -3 show serious flickering problem. Quite often
bottom square gets autoshadowed. Various polygon offsets do not fix this so I
would not expect that NVidia will be much different than ATI here. Almost the
same results could be obtained with zero polygon offsets. If front culling is
used for shadow generation, polygon offset may not be so important. So you
should be able to reproduce this issue on ATI as well.
Cheers,
Wojtek
----- Original Message -----
From: Adrian Egli OpenSceneGraph (3D)
To: David Roger ; OpenSceneGraph Users
Sent: Friday, May 16, 2008 12:01 PM
Subject: Re: [osg-users] Suggestions regarding OSG pssm
Please check out and test,
problems, i working on:
flickering, angle depend bug (camera does not cover all correct)
...
NVidia, ATI should work without choosing right plattform
2008/5/15 Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]>:
Hello David,
Great to get you email, in fact the current PSSM implementation is still
buggy, and i would like to solve the bugs for a long time. but unfortunately i
don't get the free time slot to solve all the bugs inside the pssm. may we can
work out all problems. so let's start by discussing your comments/questions....
2008/5/15 David Roger <[EMAIL PROTECTED]>:
Hello Adrian,
Thank you for the nice work on pssm.
I have looked a little in your pssm implementation, and I have some
suggestions and questions.
It would be great if you had a little time to read them, I would like to
have your feedback on those.
Then, if we agree on some modifications, I may be able to help you with
their implementation if you wish.
1) There are problems with transparency in the shader: shadows should not
affect it. I propose the following change:
This isn't a really problem of PSSM or common SM algorithm, this is more a
design question based on your database / or how you like to render the scene.
so i don't like to get this shader directly into pssm, but what we could to is
to add something like this,
if ( transparent_and_opac_shadow) my code else your code, and the
transparent_and_opac can be a class / instance variable set before generating
the pssm glsl shader. so we can append then a flag to osgshadow or your own
programm to enable or disable the "correct" shadow :-)
=> Just to implement, you could append this
replace the line :
sstr << " gl_FragColor = (color*(1.0-enableBaseTextureFilter) +
colorTex*enableBaseTextureFilter)*(1.0-0.30*v); "<< std::endl;
by:
// correct alpha support
sstr << " color = (color*(1.0-enableBaseTextureFilter) +
colorTex*enableBaseTextureFilter); "<< std::endl;
sstr << " gl_FragColor = vec4(color.xyz*(1.0-0.3*v),color.a); "<<
std::endl;
2) there is a serious bug when the camera is oriented in some directions.
The shadow map frustums seems to be off, and don't cover all the view frustum.
I believe this come from your vector product:
top = lightDir ^ camLeft;
If you handle the case where lightDir and camLeft are parallel or near
parallel, the bug might disappear. However I have not implemented any fix yet.
I'have included some screenshots of the bug, and it seems to correspond
to that case: you can see a gap between the shadow maps.
=> we need a bugfix for that, i tried just a workaround (sqrt(2) : point 6
) to avoid this, but there is a bug inside, this is true, because i believe we
don't need sqrt(2)=1.41... as factor to enlarge the shadow map range. we need
to work out this bug, and also to fix it (of course)
3) when several shadow map overlap, you do the sum of the shadows.
sstr << " float v = clamp(";
for (unsigned int i=0;i<_number_of_splits;i++) {
sstr << "term" << i;
if ( i+1 < _number_of_splits ){
sstr << "+";
}
}
sstr << ",0.0,1.0);" << std::endl;
I think it would be better to do the average, or select one of them.
The best would be picking the closest one (more precise) but I had some
bugs at the transition, and my fix is not very elegant.
Another option would be picking the maximum value :
sstr << " float v = term0;" << std::endl;
for(unsigned int i = 1; i<_number_of_splits;i++) {
sstr << " v = max(v,term" << i << " );" << std::endl;
}
exactly this is also another problem, we still have in pssm, may first we
should solve the (2) than we can decide to solve this one, may there will be a
"trick" doing that automatically with
set depth value range, but i don't know yet
4) in my tests, the randomness in the filtering did more bad than good,
as it introduced a lot of flickering in the shadow when the camera moves. I
think there should be an option to disable the use of the random texure.
flickering come from the openscenegraph based, near - far recalcuation (i
guess) depends on the view angle and the cull visitor updates each frame the
near far,so may we can fix this also. ( i don't know yet how :-( )
5) I am not really sure about this one but when you compute the
lightCameraSource, you should update zNear and zFar:
if ( zNear <= _split_min_near_dist ){
osg::Vec3 dUpdate = -
pssmShadowSplitTexture._lightDirection*(fabs(zNear)+_split_min_near_dist);
pssmShadowSplitTexture._lightCameraSource =
pssmShadowSplitTexture._lightCameraSource + dUpdate;
}
maybe you should add:
zNear += dUpdate;
zFar += dUpdate;
and then replace :
pssmShadowSplitTexture._lightNear = 0.1;//zNear;
by
pssmShadowSplitTexture._lightNear = zNear;
I have not tested this change.
this is just to calculate the zFar value , camera positon outside the
frustum (splitted) and the center of frustum (splitted) is the look at (Center)
, may you can test it, and may we get better quality of shadow, may not. but
important is to do such a calculation otherwise we have a clipping issue.
6) I don't see where the factor 1.41425 comes from at the end. I'd like
some explanations on this one if you can.
(and btw sqrt(2) = 1.41421356)
see (2)
so i suggest that we should work out the issue (2) then an point by other,
to see how the pssm would be.
have a look at the latest .cpp class i submitted this morning.
adrian
--
********************************************
Adrian Egli
--
********************************************
Adrian Egli
------------------------------------------------------------------------------
_______________________________________________
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
