gradients could be a could idea, I remember that I used the sobel operator to compute gradients for a stuff an it was pretty fast but I never heard of it for the normals.
I''ll have a look for it.
I spend too much time in computing normals
Author
Is is possible, with vertex shaders, to compute the normals by the GPU, and get back the result on the main memory ? If I send vertices to the GPU they will go through the pipeline of the graphic card and at the ouput I got fragments but is it possible to "intercept" the vertices at the output of the vertex shader unit and send them back to the main memory ?
Sorry if this question seems weird but i''m newbie with vertex/pixel shaders.
Sorry if this question seems weird but i''m newbie with vertex/pixel shaders.
Would it be possible for you to precalculate the normals once, and then, whenever you modify a vertice do the same to the normal?
That is, when you rotate the vertice (sin, cos, looks like it?) just apply the same rotations to the face''s normal?
That is, when you rotate the vertice (sin, cos, looks like it?) just apply the same rotations to the face''s normal?
only calculate normals for faces where a vertice actually change.. that should save you some time if you don''t got waves everywhere.
The first loop takes 15 floating point operations, times 32768 to make a whopping 491520. The second loop takes 3 FP ops 128x128 times for a total of 49152, and a grand total of 540672 FP ops. I could be off a bit (I don't have the full source), but the magnitude order should be correct. Now, you'd expect this to run 30 times per second, giving a measure of 16.2 MFLOPS. No wonder this takes up a large chunk of CPU power.
Note that in the first loop, computing the line segments is done *twice*, 95% of the time (2 triangles share the same line segment, except on borders). Reducing this portion of the computation would require a different topology data structure for a reduction from 15 FP ops to 12 FP ops (15 minus the 6 subs divided by 2).
> I need to compute normals for all vertices {...}
Maybe and maybe not. Some suggested adding each vertex a flag so that vertices that don't change can be used to avoid some of the calculations. I'd go farther and say that if the wave doesn't affect more than 10% or 0.01 (or some other user-defined threshold) of the vertex, than it stays unaffected. OK, it's cheating, but users won't see ditch at 30 FPS.
All in all, I think you'd need to add more information to vertices and faces so to avoid calculating the same thing more than once and modifying vertices when you don't have to.
If all else fails, you could convert to fixed point arithmetic using CORDIC algorithms. They are *WAY* faster than FP operations, albeit at the cost of precision.
http://www.dspguru.com/info/faqs/cordic.htm
http://www.andraka.com/cordic.htm
http://www.gamedev.net/reference/articles/article406.asp
Hope this helps.
-cb
[edited by - cbenoi1 on August 14, 2003 10:43:41 AM]
Note that in the first loop, computing the line segments is done *twice*, 95% of the time (2 triangles share the same line segment, except on borders). Reducing this portion of the computation would require a different topology data structure for a reduction from 15 FP ops to 12 FP ops (15 minus the 6 subs divided by 2).
> I need to compute normals for all vertices {...}
Maybe and maybe not. Some suggested adding each vertex a flag so that vertices that don't change can be used to avoid some of the calculations. I'd go farther and say that if the wave doesn't affect more than 10% or 0.01 (or some other user-defined threshold) of the vertex, than it stays unaffected. OK, it's cheating, but users won't see ditch at 30 FPS.
All in all, I think you'd need to add more information to vertices and faces so to avoid calculating the same thing more than once and modifying vertices when you don't have to.
If all else fails, you could convert to fixed point arithmetic using CORDIC algorithms. They are *WAY* faster than FP operations, albeit at the cost of precision.
http://www.dspguru.com/info/faqs/cordic.htm
http://www.andraka.com/cordic.htm
http://www.gamedev.net/reference/articles/article406.asp
Hope this helps.
-cb
[edited by - cbenoi1 on August 14, 2003 10:43:41 AM]
You can speed up your face-normal computation tremendously by fixing the X and Y (assuming Z is up) values to a uniform grid and only varying the height of each vertex. Then all sorts of computations are constant and/or cancel each other.
possibly computer normals for water surface that is only within your view.
possibly computer normals for water surface that is only within a certain distance from the camera - for ex: if the distance is too far, perhaps using the same normal values would look just as good, maybe even better, since the farther its away the less visible it should be, depending on the "atmosphere" of your game i guess.
not so sure myself on how to let the GPU process it instead of the CPU. how would one go about programming that?
and one more thing, if you have a profiler, like Intel''s VTuner, then try giving that a try. It will give you a lot fo suggestions.
possibly computer normals for water surface that is only within a certain distance from the camera - for ex: if the distance is too far, perhaps using the same normal values would look just as good, maybe even better, since the farther its away the less visible it should be, depending on the "atmosphere" of your game i guess.
not so sure myself on how to let the GPU process it instead of the CPU. how would one go about programming that?
and one more thing, if you have a profiler, like Intel''s VTuner, then try giving that a try. It will give you a lot fo suggestions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
