tag:blogger.com,1999:blog-5683237053150646122.post1346123787642877212..comments2020-04-13T19:07:32.712+03:00Comments on What your mother never told you about graphics development: Robust unit cube clipping for shadow mappingArseny Kapoulkinehttp://www.blogger.com/profile/18310595345818946666noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-5683237053150646122.post-52445183556793586372010-08-09T17:40:21.061+04:002010-08-09T17:40:21.061+04:00Tanks for your fast response and for your attentio...Tanks for your fast response and for your attention.<br /><br />It is very important for me to have some help from a matematician because it is very difficult for me to understand projective spaces.<br /><br />Sorry also for my confusion ( i am Italian and sometimes i do not understand well the english )<br /><br />Bye<br />Livio CicalaAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-74060055441093516822010-08-09T16:15:20.157+04:002010-08-09T16:15:20.157+04:00First of all - you're confusing me with the al...First of all - you're confusing me with the algorithm author. While I'm happy to try to help you with your issues, I'm not him :)<br /><br />Your version of ZRotation matrix is indeed slightly more correct. However, the only difference is in the direction of post-projected Y axis, and, since there is a unit cube normalization step, the quality should not differ noticeably. I can not verify this since I can't build the demo, and I do not have access to my own XPSM implementation - I'll post an update here once I can check this.<br /><br />Taking the absolute value of w does not make sense from the mathematic standpoint; I think that you're just lucky to get bounds that are large enough to accomodate everything that is necessary. If I remember correctly, there were indeed some rare clipping issues even after the TransformWithWClip correction; again, I'll check this and post here.<br /><br />As for the donation (again, it's not my site, but anyway) the problem is that the domain has expired. I'm not sure if the e-mail specified in the paper works, but you can try it (btw, the most up-to-date XPSM page now is http://xmvlad.110mb.com/).Arseny Kapoulkinehttps://www.blogger.com/profile/18310595345818946666noreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-23634335640800362942010-08-09T15:30:03.670+04:002010-08-09T15:30:03.670+04:00Dear Arseny,
the last message was bad formatted
an...Dear Arseny,<br />the last message was bad formatted<br />and difficult to read... <br /><br />so I repeat now the two matrices<br /><br />======================= 1<br />D3DXMATRIX ZRotation(<br /> unitP.x,unitP.y,0.0f,0.0f,<br /> unitP.y,-unitP.x,0.0f,0.0f,<br /> 0.0f,0.0f, 1.0f, 0.0f,<br /> 0.0f,0.0f,0.0f,1.0f);<br /><br />======================= 2<br />D3DXMATRIX ZRotation(<br /> unitP.x,unitP.y,0.0f,0.0f, <br /> -unitP.y,unitP.x,0.0f,0.0f,<br /> 0.0f,0.0f, 1.0f, 0.0f,<br /> 0.0f,0.0f,0.0f,1.0f);<br /><br /><br />In addition i have found that:<br />with the matrix (2) also the Zacne is more<br />regular ( exactly the same as the "uniform shadow map" ) <br /><br />In other words:<br />the zbias regulation is the same and does not changes when changing from "XPSM" to "uniform shadow map"<br /><br />I do not know if the matrix (2) is correct but<br />visual results in my implementation are very best looking with this matrix.<br /><br />----------------------------------------<br /><br />Regard to the function : "TransformWithWClip"<br /><br />I have found that:<br />if I transform "w" to "absolute value of w" before to compare and use it then all the shadow clippings are gone<br /><br />In every situation, also with the original "TransformWithWClip" function, this ABS produces always shadows without any clipping.<br /><br />Another time I do not know if my correction is matematically correct, but, in my implementation it works very well.<br /><br />--------------------------------------<br /><br />another little problem...<br /><br />I have tried to send to you some euro ( for now i can contribute only with a little donation ) but the donation page is in russian language...<br /><br />maybe i can send to you some money with PayPal ?<br /><br />--------------------------------------<br /><br />bye<br />Livio CicalaAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-66161434468444004982010-08-08T18:20:47.605+04:002010-08-08T18:20:47.605+04:00Anonymous said...
Dear Arseny,
YES, i am using m...Anonymous said... <br />Dear Arseny,<br /><br />YES, i am using my own vector-like container with slightly different operation semantics.<br />Thanks for your attention.<br /><br />------------------------------------------<br /><br />Now i have found another little problem.<br /><br />With your Zrotation matrix composed as shown in (1) i get the rear side of some object not shadowed and with some shadowed part that comes from the other side.<br />But if i change the composition as in (2) all the objects are with the rear side completely shadowed and the final visual result is better.<br /><br /><br />======================= 1<br />D3DXMATRIX ZRotation(unitP.x,unitP.y,0.0f,0.0f, unitP.y,-unitP.x,0.0f,0.0f, 0.0f,0.0f, 1.0f, 0.0f,<br /> 0.0f,0.0f,0.0f,1.0f);<br /><br />======================= 2<br />D3DXMATRIX ZRotation(unitP.x,unitP.y,0.0f,0.0f, -unitP.y,unitP.x,0.0f,0.0f, 0.0f,0.0f, 1.0f, 0.0f,<br /> 0.0f,0.0f,0.0f,1.0f);<br /><br />DirectX manual says that Z-rotation is:<br />cos sin 0 0<br />-sin cos 0 0<br />0 0 1 0<br />0 0 0 1<br /><br />What do you think of this ?<br /><br />bye<br />Livio Cicala (lc@freetw.net)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-54555889801552390982010-08-02T15:18:13.199+04:002010-08-02T15:18:13.199+04:00The term +8 is indeed redundant; however, with con...The term +8 is indeed redundant; however, with conforming STL implementation there is no harm in extra space reservation - you are either confusing reserve() with resize(), or you're using your own vector-like container with slightly different operation semantics.Arseny Kapoulkinehttps://www.blogger.com/profile/18310595345818946666noreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-15110933675145131262010-08-01T11:03:40.871+04:002010-08-01T11:03:40.871+04:00Dear Arseny,
I have found a little error in the f...Dear Arseny,<br /><br />I have found a little error in the function: PracticalPSM::BuildXPSMProjectionMatrix()<br /><br />The following lines are over dimensionaed:<br />===========================================<br />shadowCasters.reserve<br />( m_ShadowCasterPoints.size()*8 + 8 );<br />shadowReceivers.reserve<br />( m_ShadowReceiverPoints.size()*8 + 8 );<br />===========================================<br /><br />It is better to remove the term "+8" <br /><br />This error adds some caster and receiver points at 0,0,0 and it degrades the algorithm.<br />I suspect also that, in some implementations, it can collect garbage values and produce unpredictable results.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-13459129036658202882008-04-09T04:40:00.000+04:002008-04-09T04:40:00.000+04:00@arseny:Great post! I haven't run across a nice s...@arseny:<BR/><BR/>Great post! I haven't run across a nice straight to the point explanation about how to compute the orthographic projection for a directional light until now.<BR/><BR/>@andrew:<BR/><BR/>Probably way too late at this point. The issue is that when the .w coordinate is negative, projection "flips" your resulting x and y coordinates and screws up the bounding box calculation. If you think about the perspective transform as an "X" (draw it out) it'll make sense. The solution I came up with was to "project" my points with the absolute value of w instead of w directly. Then clamp it. This gave me the result I was looking for.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-19165511098002844802008-01-23T18:14:00.000+03:002008-01-23T18:14:00.000+03:00One big problem that I encountered when doing thes...One big problem that I encountered when doing these kind of scene dependent calculations is that it causes a lot of shadow swimming as the shadow-map texels change based on the camera location/orientation.<BR/><BR/>This is similar to the problem of the changing projection with perspective shadow maps.<BR/><BR/>Have you found any solution to that?Phil Teschnerhttps://www.blogger.com/profile/07688687352136934369noreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-34055788990187956642007-10-03T20:44:00.000+04:002007-10-03T20:44:00.000+04:00I already thought it wouldn't work by just doing t...I already thought it wouldn't work by just doing the projection...<BR/><BR/>Thank you very much for making this clear!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-80919358307531241702007-10-03T01:16:00.000+04:002007-10-03T01:16:00.000+04:00I see. For spot lights, you have to clip both cast...I see. For spot lights, you have to clip both caster and receiver volumes by light frustum - i.e. in your case, clip view frustum by light frustum (this results in a convex polyhedra), and use all vertices of the result instead of view frustum vertices.Arseny Kapoulkinehttps://www.blogger.com/profile/18310595345818946666noreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-55712413040746074452007-10-03T00:52:00.000+04:002007-10-03T00:52:00.000+04:00Thanks for trying to help.The problem occurs with ...Thanks for trying to help.<BR/><BR/>The problem occurs with a local spotlight, when the viewer is standing behind the light and facing the same direction. In this case some sort of back projection is happening (hence w < 0) since the camera frustum corners (which are multiplied with the light ModelViewProjection matrix) are behind the light frustum. The projection reparametrization is uniform with simple scale/bias as described in your first section. <BR/>Usually I use the projected corner points to build an AABB of the camera frustum in post projective light space by checking them against the current AABB min/max values. From the AABB I calculate the scale and bias factors. But this back projection makes the corner coordinates somehow unusable, at least it results in way too large scale factors.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-34617848676453787382007-10-03T00:15:00.000+04:002007-10-03T00:15:00.000+04:00Please describe your problem in more detail - i.e....Please describe your problem in more detail - i.e., what type of light do you have, what type of projection reparametrization are you using (if any)?Arseny Kapoulkinehttps://www.blogger.com/profile/18310595345818946666noreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-91270788295096271922007-10-02T19:18:00.000+04:002007-10-02T19:18:00.000+04:00This is a very informative article, thank you very...This is a very informative article, thank you very much! I will definitely bookmark your blog.<BR/><BR/>I have a similar problem as the one described in the XPSM section when building the crop matrix for cascaded shadow maps. I project the eight world-space frustum corners into post-projective light-space to get the the min/max AABB values which is working fine as long as all w-coordinates are larger than zero. If w is smaller than zero shadows are sometimes clipped away. I don't know what to do with corners that have their w < 0. Any ideas?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5683237053150646122.post-49252904987848104162007-09-29T09:58:00.000+04:002007-09-29T09:58:00.000+04:00Hi Arseny. It's great to see another technical blo...Hi Arseny. It's great to see another technical blog with detailed, informative posts! Keep up the good work!Anonymousnoreply@blogger.com