 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
 GameDev.Net Discussion Forums  Image of the Day Screen Space Normals (SSN) + SSAOSend Topic To a Friend | View Forum FAQ | Track this topic | View Forum |
 Last Image Next Image  |
| Screen Space Normals (SSN) + SSAO |
|
 |
  spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
|
||||
Here an experiment of Screen-Space-Normals (SSN). They are entirely computed from the depth buffer, without using any other information. The advantage is, its not necessary anymore to store normals or a normal-map anymore. However, as a certain radius is necessary for the SSN computation, there will always be an inaccuracy for about this radius. Perhaps its possible to extend this idea further and make it more robust. For the ones of you willing to experiment, I uploaded the shader code(GLSL) - it computes SSN and SSAO in one-pass (un-smoothed). Feel free to use it for your own experiments! Fragment shader source Vertex shader source [Edited by - spacerat on December 12, 2008 1:30:16 AM] |
||||
|
||||
|
popsoftheyear Member since: 5/19/2007 From: McKees Rocks, PA, United States |
|||
Posted - 12/18/2008 4:26:50 PM |
||||
| So I wonder... would it be more efficient to push out many more polygons without normal maps and let it compute shading like that, or less polygons with normal maps, but have to include the normal map in the whole picture. Because if one ditches normal maps, the whole advantage of having > 1 normal per polygon kinda goes right down the tube. This is really interesting though and I'd love to hear what others have to say about it. Cheers -Scott |
||||
|
||||
|
james_g Member since: 4/8/2006 From: Halifax, Canada |
|||
|
Posted - 12/18/2008 10:35:04 PM |
||||
| First of all, neat idea! Sometimes you can get a lot of geometric information from renderings of a scene at much lower cost than from the scene itself, and I like seeing new tricks. That said, I would think you could calculate the normals more efficiently using a straightforward finite-difference scheme rather than the 'radius' stuff that you're currently using. This would require only five samples for second order accuracy and would be less sensitive to the choice of radius, and not need all the trig. For example: dw/du = ( w[u+eps,v] - w[u-eps,v] )/(2*eps) dw/dv = ( w[u,v+eps] - w[u,v-eps] )/(2*eps) normal[u,v] = ( [u+eps,v,w+eps*(dw/du)] - [u,v,w] ).Cross( [u,v+eps,w+eps*(dw/dv)] - [u,v,w] ) here w the true depth (i.e. not the biased and scaled values directly from the depth buffer), u is the x-coordinate of the current pixel in screen space, v is the y-coordinate in screen space and 'eps' is a small value (a pixel width or larger in screen space). This will give artifacts at the silhouettes of objects but you should be able to avoid those by using one-sided differences if the sample depth values vary wildly from the value at that point. A search for "finite difference" might be helpful if you're not sure what this means. Of course, if you're doing SSAO and sampling all those points anyway, you may as well just do it your way :) |
||||
|
||||
|
Martin Member since: 9/11/1999 |
|||
|
Posted - 12/19/2008 5:04:41 AM |
||||
Quote: Sorry but I disagree. Consider a flat wall viewed head on, this will give an identical screen space normal at every pixel. A normal map will not. While potentially useful for effects such as SSAO this is not a replacement for normal mapping / writing normals to a buffer in defered rendering. [Edited by - Martin on December 19, 2008 6:04:03 AM] |
||||
|
||||
|
skynet_ Member since: 9/26/2005 From: Ilmenau, Germany |
|||
|
Posted - 12/19/2008 9:00:16 AM |
||||
| AFAIK, you all seem to overlook that the OP is not rendering polygons but voxels. Hence all the speculation on normalmaps and flat-wall-polygons is pointless. Besides the neat lighting, I'd really like to see the renderer in action... Spacerat, would you please make a demo-exe available for us all to play around with? |
||||
|
||||
|
PeterV Member since: 1/24/2008 From: Delft |
|||
|
Posted - 12/19/2008 2:44:39 PM |
||||
| What are you exectly using to create the depth information? Are you rendering polygons or is this some kind of voxel engine? |
||||
|
||||
|
BlindSide Member since: 10/12/2005 From: Auckland, New Zealand |
|||
|
Posted - 12/19/2008 8:46:47 PM |
||||
| He's using RLE voxels iirc. The SSAO looks spectacular, but what are those faint scanline looking rectangles on the right side of the screen? |
||||
|
||||
|
spacerat Member since: 10/26/2006 From: Yokohama, Japan |
|||
|
Posted - 12/20/2008 2:48:30 AM |
||||
| Thank you for all the comments. @Scott: yes, in case of polyonal data it might not be so efficient as you not not have such a high amount of normal data - also you can easily get the surface normal there on the fly from the three vertices. As Skynet mentioned, the main purpose of this algorithm is voxel data. Usually its necessary to store one normal for each voxel - and thats a lot for the dataset above. The pure surface data already has 200 MB (2048^3 voxels) which means about 70MB of normal data would be necessary in addition to that. @James: The idea to include the derivative in the sampling process sounds interesting - would be worth a trial. I only dont know if it works well on voxel data, as the surface is not very smooth in this case.. Silhouettes are indeed a problem - I think for an optimal result, it might be necessary to do some sort of edge detection with segmentation.. Once I came over a paper doing this in an offline process, but I didnt see this yet for interactive applications. @Martin: Yes - it wont replace normal maps that was a mistake. @Skynet: I am currently in Germany over holidays and dont have all my development stuff with me. I hope I can put a movie or demo online when I'm back in Japan. @PeterV: Yes,its an RLE voxel engine, as Blindside mentioned. Original Paper (1992) Voxlap technology (2000) CUDA demo of me without SSN (2008) @Blindside: The scalines on the side are just a debug output of the algorithm - its not related to SSN. [Edited by - spacerat on March 9, 2009 6:48:10 AM] |
||||
|
||||
All times are ET (US) |
Last Image Next Image |
|
