So after I have gotten both methods of getting normals for my surface working (CubicSurfaceExtractorWithNormals, and calculating them in shader) the question has arisen that isn't it far, far better to calculate the normals once when extracting the surface then to make my shaders do a cross product for every single fragment every frame? I can't see why I wouldn't want to do maybe ~1ms of preprocessing work to save my shaders billions upon billions of cross products. Can someone explain to me the reasoning here? (I've taken my linear algebra and I'd like to think of myself as an ok programmer I think I should be able to understand this concept!)

Thanks.

One thing I thought of is that maybe that way you can decide if you want a shorter "loading" time for your volumes with more work for your GPU or if you want slightly longer loading times with less GPU work. As I'm un/loading volumes very often I think it could make a difference. But I think David knows a better reason for this

It's a good question

The main advantage is that the version without normals uses significantly less memory. There are two reasons for this:

1) We have less data per vertex, in that we have 3 position components rather than 3 position components + 3 normal components. This is the obvious saving of a factor of two.

2) The less obvious (but actually more important) saving is that we have less vertices. Typically we would expect a cube to have 8 vertices, and we would expect these to be shared between adjacent faces. The problem here is that all the adjacent faces actually have completly different normals. As a result, vertices do not get shared and you end up with 24 vertices for a single cube. In this case it's a factor of three differnce, but actual result will depend on the shape of your volume.

As AndiNo says, you can choose which ever one is most appropriate for you. In another post you also mentioned Minecraft and per-vertex lighting, if you want to use this then you will need normals in you vertex shader and in that case you can't use the ddx/ddy approach.

I see. So I guess if memory usage creeps up over ~400mb on video card then it might be significantly better to compute on the fly... One thing I did notice is that on the small dataset (the sphere) it is almost identical fps I'm sure that once I have a scene streatching into the distance I'll be able to see the impact (or lack there of) of computing normals in the shader... I wonder if there is a way for me to store my normal for each face without having to do the xproduct... I dunno I'll give it thought as I develop around it. It seems like it could have a significant impact either way. Empirical data will help someday!

I implemented a face merging thing that uses Run Length Encoding (still some bug left I will post it later) and from rendering a 1500x1500x256 (1500 x,y is approximate) terrain I get around 19-40 FPS for "long views". At the center of the terrain I get 39-70, and mostly in the 60-70s range. Okay it's very casual testing... Also, this is with the normal material and without normals. There are some differences but it's minor. I personally think the without normals it is slightly faster when in the long view, but with normals it's faster on average.

Also, this is without the sharing of vertices. I have not done that yet.

For a 630x630x256 terrain it's totally playable at 60+fps. With SSAO turned off I get hundreds of FPS... oh yeah, I play at 1080p 8x AA.

Plus, I'm not seeing any T-Junction issues at all. Which is kind of surprising since I thought I was going to see a lot of those.

In the future I may implement a better face merging by doing RLE in 2D.

In general there are a lot of factors which can affect the speed of rendering on the GPU, and it's hard to know where the bottleneck is without profiling your particular application. Computing normals on the fly does require some fragment program work, but wherther this is significant depends on the complextity of your fragment programs and wherther fragment processing is even the bottleneck in you particular application. But is does force you to do your lighting calculations per-pixel rather than per-vertex because you don't have normals in your vertex shader.

On the other hand, although precomputing the normals can save some work in the fragment program, the computed normals have to be interpolated accross the face of the triangle. This uses up extra interpolator units and can potentially become a bottleneck.

In my particular case, I was happy with the rendering speed I was getting but I wanted to reduce my load times and allow modification of the environment to be as fast as possible. I noticed big speed improvements with the switch to computing normals on the fly, but I also changed other things at the same time so it's hard to be clear where the improvements came from.

I played around with it more, and clean up my pixel shader some, it feels more responsive when not passing in the normals and computing them in the pixel shaders. I have still yet to do the sharing of vertices though, this will improve it even more I think.

Well I'll look forward to seeing your results, but actually I think the real value of your face-merging work will be if/when you integrate physics or collision detection. From the performance figures that people have posted so far, it seems the GPU is quite happy dealing with a large number of triangles (typcally it's the batch count which becomes the bottleneck). But a physics engine won't be able to handle sch a large number of triangles as easily, and I think merging faces might then become essential.

yes, I thought about that too. I also wanted to have larger terrain. And before I went and implemented the merging of faces I found (I could be wrong, by "finding" I mean just messing around with the game running and looking at frame rates) I was having low frame rates issues with the size of terrain that I wanted. This is with a bunch of shaders on though, without those shaders I get very good frame rates. Now it's even better. I need to do more testing though.

Right now, I have the thing implemented but I still have a few bugs (holes in the terrain) to work out. I'm also using UInt8 volumes; actually I had a version implemented which uses MaterialDensityPair and thus I don't assume anything about the voxel type. I'm no longer doing that. It's mainly because I need to use Minecraft's textures for testing, and I don't feel like using the 16 bit to represent the voxels.

Edit: What I mean by the frame rate is it matters if I can squeeze out couple of more frames, especially with the shaders.

BTW: the physics thing, yeah that's a must-have thing for me. I plan to use Bullet physics. I want to use it's convex hull capabilities if I can, but I'm not sure yet how to do that. I know I can turn my surface from Ogre into a triangle mesh for collision testing. Whether there is a easy to do also do that for convex hull I don't know. It should be possible because the entire world is made up of cubes.