tag:blogger.com,1999:blog-595994106258820418.post3956075484349427355..comments2023-04-26T17:17:36.413+02:00Comments on Sebh's blog: Crytek's Best Fit Normalssebhhttp://www.blogger.com/profile/14650504326449432531noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-595994106258820418.post-23795158971111639282012-01-16T18:58:52.523+01:002012-01-16T18:58:52.523+01:00That's a shame, about the interpolation issue....That's a shame, about the interpolation issue. It seems like a lot of effort to get precision out of your g-buffer normals, when you could simply use something like R10G10B10 to get even more precision without any encoding effort. All BFN gets you is an extra 8-bit channel in your g-buffer which may not really be all that useful for some.Chris_Fhttps://www.blogger.com/profile/03273431186737285272noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-12639351432546884402010-08-23T19:18:11.890+02:002010-08-23T19:18:11.890+02:00Indeed, you are right! I was a bit too much enthou...Indeed, you are right! I was a bit too much enthousiastic with this first post on bfn! I wanted to correct this in my more recent posts but forgot about it... Interpolating non-normalized normals could result in errors (wrong directions). The same for mipmap...<br /><br />example of wrong interpolation:<br />A=(0,6) and A'=(0,2) (A' is same direction as A)<br />B=(6,0)<br /><br />A+0.5*(B-A)= (3,3)<br />A'+0.5*(B-A')= (3,1)<br />Not the same direction...<br /><br />So bfn can only be applied to compress normals in a g-buffer...Or any idea?sebhhttps://www.blogger.com/profile/14650504326449432531noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-67929916773828019182010-08-22T21:14:25.905+02:002010-08-22T21:14:25.905+02:00I may be mistaken as I've quickly browsed thro...I may be mistaken as I've quickly browsed through the Crytek paper, but they seem to provide the "better representation" through symetries. I understand that they actually encode their "Normals Fitting Texture" in a 512x512 2D texture (some code in given at the end of the siggraph course paper).<br /><br />Using this storage for regular normal maps may prove difficult as it certainly doesn't play nice with bilinear filtering and mipmapping, no ?<br /><br />Cheers,<br />Nicolas.rotogluphttps://www.blogger.com/profile/15688884816193838150noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-81853772763885749942010-08-05T20:48:33.283+02:002010-08-05T20:48:33.283+02:00I totally agree with this method being oriented to...I totally agree with this method being oriented toward a console use.<br /><br />And yes, there is a symmetry for each cube face and around each major axis. That was something I was thinking about when I said "better representation instead of the cube map". However, I wonder how many ALU ops it will cost to handle this in the shader considering a single 2D texture storing the replicable symmetry pattern (face detection to swizzle the components, mirror repetition, etc).sebhhttps://www.blogger.com/profile/14650504326449432531noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-16303635982685473742010-08-05T19:33:51.709+02:002010-08-05T19:33:51.709+02:00On the consoles, the recommended ALU/texFetch is p...On the consoles, the recommended ALU/texFetch is probably lower, which I'm guessing is Crytek's main motivation. The cost is the memory to store the cube-map.<br /><br />A colleague of mine pointed out that there is probably some symmetry in the cube-map that could be exploited, no? Like different faces would be the same values just swizzled. I wonder if there is an efficient way to reduce the storage requirements and take advantage of that symmetry.Stevehttps://www.blogger.com/profile/15315525780089168677noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-869023578019038642010-08-05T11:37:10.540+02:002010-08-05T11:37:10.540+02:00Dear matumbo,
I love this funny fractal-like look...Dear matumbo,<br /><br />I love this funny fractal-like look of the texture :)<br /><br />And it is a cubemap not a 3D texture so no problem for real time use. :) The current recommended ALUop/texFetch is 20:1 if I remember well so normalization should be acceptable as you said.<br /><br />In fact, A 256*256 cubemap is not the best solution because it is still using only 2.31% of the full RGB8 volume voxels (1.31% for the scale&bias approach based on my computation). I would like to compute the total number of directions that can be represented using the RGB8 volume (because some directions can be represented by several voxels) to know the real capacity of the RGB8 volume.<br /><br />Yes, implementing this in DCC tools would be great!sebhhttps://www.blogger.com/profile/14650504326449432531noreply@blogger.comtag:blogger.com,1999:blog-595994106258820418.post-7998764609608181162010-08-05T11:22:54.918+02:002010-08-05T11:22:54.918+02:00Clever, why haven't we thought about that soon...Clever, why haven't we thought about that sooner ? I guess the unpack requiring a normalization used to cost too much. That may not be the case with today's GPU performance.<br /><br />But if you have to generate a normal map in real time, fetching the precomputed 3d texture may take a little longer than just scale&bias :) Maybe they only use that technique in DCC Tools plugins.<br /><br />Anyway, we were not using the whole RGB range, that's a fact :) That changes the "look" of normal maps, they get dirty.Matumbohttps://www.blogger.com/profile/05077126100494278327noreply@blogger.com