automatic normal calculation?

i think this would be a good feature as long as it could be enabled/disabled!

Originally posted by c_olin:
i think this would be a good feature as long as it could be enabled/disabled!

It’s possible, but bear in mind that it would only work for flat shading, i.e. per-face normals. Wouldn’t work for the per-vertex normals needed by Gouraud/Phong lighting, because these are averaged from the faces using each vertex. (The exact calculation varies.)

In the general case, GL has no way of knowing which other faces are sharing a given vertex, so it can’t do the calculation.

I agree we need an automatic non clock cycle expensive method for normal calculation on the fly. For example when I do lighting calculations for medical 3D volumetric data with 3D textures. I need the estimated gradients made with the central difference method in realtime otherwise I waste valuable memory storing normal imformation and not to mention the time it takes to transfer over the AGP bus.

I agree we need an automatic non clock cycle expensive method for normal calculation on the fly. If it can be done for Volume data that would be great like how it is done right now in hardware by the VolumePro500 and 1000 by www.terarecon.com. For example when I do lighting calculations for medical 3D volumetric data with 3D textures. I need the estimated gradients made with the central difference method in realtime otherwise I waste valuable memory storing normal imformation and not to mention the time it takes to transfer over the AGP bus.

OpenGL is useful in medical imaging. I personally think it is the best graphics API but it needs on the fly normal generation using central difference. Driver writers need to also ensure that Paletted textures and shared paletted textures are supported in all drivers. Nvidia recently added those extensions back to their drivers. Good on them. YEAH!

For example when I do lighting calculations for medical 3D volumetric data with 3D textures. I need the estimated gradients made with the central difference method in realtime otherwise I waste valuable memory storing normal imformation and not to mention the time it takes to transfer over the AGP bus.

This is hardly a difficult problem. Use a fragment program. You can compute the normal by doing lots of texture accesses of the same texture, just change the coordinates.

There’s no reason for them to add fixed-function functionality for something that is best implemented in programmable hardware. Especially when that functionality is not widely useful.