How can you calculate it in the vertex shader, when it relies on information about neighboring vertices?

Assuming the tcs don't change, you can pass the deltas as a vert attribute.
(Which isn't what I said, I admit)

Quote:Original post by emeyex
Just out of curiosity, have you actually tried, profiled, and found the normal/tangent computations to be the bottleneck? If so, what is your algorithm for recomputing the normals/tangents?

What a strange question. Why would I waste time implementing a solution I do not know will work well?

Quote:Original post by mrbastard
Assuming the tcs don't change, you can pass the deltas as a vert attribute.
(Which isn't what I said, I admit)

Thanks.

Quote:Original post by Prune

Quote:Original post by emeyex
Just out of curiosity, have you actually tried, profiled, and found the normal/tangent computations to be the bottleneck? If so, what is your algorithm for recomputing the normals/tangents?

What a strange question. Why would I waste time implementing a solution I do not know will work well?

Because you might be surprised by how fast it is. Recalculating the tangents again is what we do for deforming meshes.

And what about normals?

Quote:Original post by Prune
And what about normals?

It's not that much more expensive to just recalculate those at the same time as the tangents. Just clear the normal array to zero, and for each triangle, add the triangle's plane normal to the normal for each of its three vertices. We don't normalize the normals or the tangents on the CPU, but instead let the vertex program handle that.

I don't see how I can calculate the triangle plane normal on the GPU when that needs information from three vertices.

I think my earlier comment led you astray a bit, and I apologise. I should have thought more carefully before commenting. Reading it again, I think RobTheBloke was actually suggesting doing it on the CPU, as Eric Lengyel is. I'd trust their experience, at least until you prove your case is significantly different. Especially Eric, who wrote the code you're using!

There are a couple of ways to get access to multiple verts in a shader, but both are probably more hassle to set up than they're worth at this stage.

This is a fairly easy problem to solve for specifc types of deformation (skinning, displacement maps), but you're after a general solution.

You could supply the vertex positions as a texture, thus giving access to multiple vertices in one shader scope. This would require hardware that supports vertex shader texture fetch.

You could use a geometry shader and emit a stream of normals based on the stream of vertices. I've never written a geometry shader though, so I can't be any more specific I'm afraid.

There are a few other ways I can think of too, but they're even more hassle to set up.

Are you sure your problem can't be reformulated in terms of matrix transforms? Fish bending their bodies sounds like a perfect candidate for skeletal animation. Maybe give more details about what you're trying to achieve.

That was an example. I was aiming for a general solution allowing for deformation of large meshes (where it's unreasonable to upload large sections of a CPU-updated VBO to the card every frame--even though processing the vertex positions by the CPU can be done in a fraction of a frame).

What I ended up doing in the case of the fish is restrict and simplify the deformation to a simple analytic function that allowed fast computation of the Jacobian. But I'm still hoping to implement a more general solution later on.