Quote:- I have to rewrite my code
- I have to recompute ALL normals every frame

Rewriting code to make it better should never be avoided. No excuse. [SMILE]

However, you're working on an editor and (I assume) you'll want to save the normals to file. You can ensure what you save is what you see by using the same code to calculate the normals as what is rendered, i.e., in the CPU. If you use a shader calc and you want to change the code for calculating the normals, you have to revise both the "save" code and the shader.

A consideration for using the shader calc, however, may be any slowdown in the interface to the user when you're calc'ing new normals. That seems a bit unlikely if you're only recalcing normals for 3 vertices at a time, though, even with locking a buffer (if that's where the normals are stored), revising the normals and unlocking.

Testing will help you decide.

Like Buckeye, rewritting your code isn't an excuse.

As for recalculating all the normals every frame depends on the terrain's complexity.

If your terrain has 1.000.000 normals, it's better to do it offline. While if it has less than i.e. 50.000, you woouldn't notice a difference.

If you're in DX10, you can consider the possibility of using stream out to compute the normals in the GPU only once, then get the results.
Otherwise, I'd go for the do-it-on-the-cpu unless it becomes very tedious or you come with a LOD algorithm that allows you to only compute the normals (every frame) of the parts of the terrain you're actually seeing.

Cheers
Dark Sylinc

Quote:Original post by SymLinked

Quote:Original post by adt7

Quote:- I have to recompute ALL normals every frame

Why?

I believe he's saying that if he puts it into his shaders he'll have to do it each frame, as opposed to his CPU method.

And adt7 is saying that you can use a shader to generate a normal map from the heightmap, and then cache that normal map until the next update...

Agreed. When the heights change run a pixel shader that computers the normal map.

Quote:Original post by Buckeye
A consideration for using the shader calc, however, may be any slowdown in the interface to the user when you're calc'ing new normals. That seems a bit unlikely if you're only recalcing normals for 3 vertices at a time, though, even with locking a buffer (if that's where the normals are stored), revising the normals and unlocking.

Now I feel terrible stumbling across you again [grin] but doing the normals calculation in a thread does not stall the GUI in any way. But you should not microlock the vertex buffer for a bunch of three vertices to be updated. Kick off a thread that recalculates the whole concerned patches of terrain. Once this thread is finished lock and load ... and unlock. There should be no stall whatsoever.

@original poster
There is no general answer to that. You cannot point your finger at this and that and tell that it will be the bottleneck of your application. Doing the normal calculation on the shader should only be done if you do not have other hefty shaders which are really required to be runtime calculations. Using the CPU for precalculating data is okay, especially for an editor that saves this information then in its custom export format.

The only real advantage I see in using shaders for normal calculations are indeed an ever-changing geometry. If you are just looking at local modifications of terrain patches it will be okay to use a CPU thread to recalculate the normals and upload a changed vertex buffer when such a change in terrain occurs.

You could also use the GPU with a shader to calculate the normals and output them to a texture you access when rendering your terrain (read: normal map). But keep in mind the memory consumption of such an approach. In todays 3D applications you are already bound to have several render targets for things like HDR, deferred shading, SSAO, and things like that. Adding more load to the GPU for terrain normals does not sound necessary for me.

I would try and go with the local vertex buffer modification for a changed terrain patch. If this is too slow for your purposes start analyzing your app for real bottlenecks to see if using shaders would be of any help. But (which I guess is more likely) if you find no bottleneck with the CPU approach stick with that.