Saturday, March 3, 2007

GPU Geometry Clipmaps WIP

i have optimized vertex cache hit of triangle strips and i got a boost of 10 Fps ( + 25 % ). I discovered pixel artefacts in the middle of grids ( not T-Junctions ) and post about it on gamedev for help, Normals update don't work yet, just a matter of time.

Edit : No more T-Junctions and pixel artefacts, those were Mipfilter artefacts. Normals are now correct but i will have to use the last row and column to get correct normals for clipmap n=255. Thinking about a way to manage this.


vaseo said...

Hi, nice work, i am working on gpu clipmaps implementation too.
You mentioned that you compute normals on the fly - you mean computing them in the pixel shader while rendering? if so, could you be more specific on that? i didnt managed to do that :(

I update normals using normal textures and updating them when clipmaps shift as described in the gpugems paper but the shading is very strange, sometimes like a checkerboard. With higher normal map resolution the squares are sharper but still like checkerboard. See it on the screenshot (my name link). Just curious if you have come across something similar.

FilouGK said...

By "on the fly" i mean when clipmap shift. i Follow the paper like you.

i also had problems like that when i used a wrong "ScaleFac" in "ComputeNormals.fx". How do you compute "ScaleFact" ?

keep in mind that if your terrain data as an high frequency ( lots of "pikes" ) you will get the same result.

ps : When you have a clipmaps size of 255 with a texture of 256, how do you manage to get the last row and column of normal map correct ?

vaseo said...

yes, the shading problem could be in a heightmap, that is not verz suitable, i should test more heightmaps. btw do you know some good source of 16bit raw heightmaps?

the last row/column in normal maps was a real headache for me. for me the problem was not in the last row/col, i simply use them so the whole texture is used but there is one pixel (or two when using double res) between the start and end. But when you use linear filtering for the normal maps, the end row/col will be affected by the row/col next to it, ie.the row/col between end and start so i had to update the normal map twice, once for the most of the texture and second for the last col and row but with different (shifted) height offset. this has to be done only when initializing and then always just in one direction vertically and horizontally.

hard to explain, i coded that a year ago and dont remember the details, but now i want to extend that project as a school project. so i tell you more during this semester because i want to update exactly that part of code. its not so easy as described in the paper but also not so hard, maybe you find out a more elegant and effective way.

FilouGK said..., left bottom category, you may found what you want.

if you use the shader "ComputeNormals.fx" given in the GPU Gems II, "ScaleFac" =
-0.5 * MaxHeight / (Grid Spacing for clipmap level l). Save the normal texture to bmp and check the red and green values. if there is only a few values like 0,64,128,255 it means ScaleFac is not correct.

i think i found how to use their shader without artifacts on last row and col but i must rewrite the update routine. If you remember the paper, it's the coarser normal that is used in the level boundaries (morphing), so even if normal of row, col 255 is incorrect we don't care but you must write on it during clipmaps shift. The quads to update are not the same as for clipmaps.