Skin on GPU or CPU
Author
I've read that using effects that require multiple rendering passes, and using shadow volumes with GPU skinning would mean that the GPU has to re-skin the meshes multiple times per frame. This is why CPU skinning is sometimes used instead.
However, this came from old sources and I have also read that vertices can be rendered to a VBO. If that is the case then why not skin to a VBO, and then use that result to compute the mult-pass and shadow volume effects?
I'm still figuring this stuff out. Any help is a appreciated.
I'd like to leave the CPU as free as possible for more AI stuff.
I skin on the GPU and have never run into any problems. Then again I don't do shadow volumes (too fill rate limited). As for running the skinning code multiple times for multi pass shaders, yes this does happen. What I have done is I try when possible to do as much as I can in a single pass.
For example if I have 2 lights contributing to an object I will have a specific shader to deal with 2 lights in one pass rather than calling the same shader multiple times for each light source.
Also another trick you could try is not skin as often on the GPU for objects that are far away as no one will notice. For example, you could have a shader that does the skinning, but when the object is far away, run a less expensive shader every other frame that does not do the skinning. However, you should also take into account that switching shaders does not come cheap and the switches should be minimized as much as possible so you should try and reach a balance.
I for one use shaders to do my skinning and have not run into any significant problems.
For example if I have 2 lights contributing to an object I will have a specific shader to deal with 2 lights in one pass rather than calling the same shader multiple times for each light source.
Also another trick you could try is not skin as often on the GPU for objects that are far away as no one will notice. For example, you could have a shader that does the skinning, but when the object is far away, run a less expensive shader every other frame that does not do the skinning. However, you should also take into account that switching shaders does not come cheap and the switches should be minimized as much as possible so you should try and reach a balance.
I for one use shaders to do my skinning and have not run into any significant problems.
There is a technique called Render to Vertex Buffer (R2VB)
presented at Siggraph06 by ATI's Thorsten Scheuermann.
http://ati.amd.com/developer/siggraph06/SIGGRAPH06_ShadingCourse_Scheuermann.pdf
Seems like a bit of a hack but it's supposed to really help when you are doing multipass. I haven't tried it myself yet.
presented at Siggraph06 by ATI's Thorsten Scheuermann.
http://ati.amd.com/developer/siggraph06/SIGGRAPH06_ShadingCourse_Scheuermann.pdf
Seems like a bit of a hack but it's supposed to really help when you are doing multipass. I haven't tried it myself yet.
but what if you have say 1000 characters running around in your scene, all the same mesh, but all at different animations => need individual skinning? say you need to do 10 passes over each of them, what'll be more efficient?
- to switch 10'000 times all the pass-configuration, + 1000 times render current skinning to a vertexbuffer, and do the 10 passes per object
- to render to 1000 vertex buffers all the skinning states needed into memory, resulting in 1000x more memory needed
- simply push the mesh 10 times trough the skinning shader each time, set up 10 different passes, and invoke the 1000 meshes once per pass (there are even new ways to invoke that more efficiently afaik, but i forgot the name).
My guess is that the last one is the most scalable of all.
- It doesn't require much render state changes (and the amount is constant, independent of mesh count).
- It doesn't require much memory (constant amount per mesh TYPE, not per instance)
And don't forget, vertex shaders are normally never really the bottleneck. If they are, increase the resolution of your application. Problem "solved" :D
- to switch 10'000 times all the pass-configuration, + 1000 times render current skinning to a vertexbuffer, and do the 10 passes per object
- to render to 1000 vertex buffers all the skinning states needed into memory, resulting in 1000x more memory needed
- simply push the mesh 10 times trough the skinning shader each time, set up 10 different passes, and invoke the 1000 meshes once per pass (there are even new ways to invoke that more efficiently afaik, but i forgot the name).
My guess is that the last one is the most scalable of all.
- It doesn't require much render state changes (and the amount is constant, independent of mesh count).
- It doesn't require much memory (constant amount per mesh TYPE, not per instance)
And don't forget, vertex shaders are normally never really the bottleneck. If they are, increase the resolution of your application. Problem "solved" :D
Oh, and if you're thinking about it because of stencil shadows you want to do, then Pixel Fillrate will most definitely be your bottleneck, not the vertexshader.
Author
I've thought about limiting stencil shadow volumes only to static geometry. I'm not sure if putting them on animated meshes will have that much of an effect for my engine's planned use.
However, shadows on buildings and other structures are very important. Therefore, if limiting these shadows to static geometry then I may take that rout. However, my engine will still use multi-pass lighting.
Right now I am considering combining the following in my lighting model:
1) Stencil Shadow Volumes
2) Normal Mapping (tangent space for everything except the terrain)
3) A gloss map for per pixel specularity (encoded as the Alpha component to the normal map)
4) Real-time ambient occlusion optimized using spatial subdivision structures (still researching this)
I plan on using quaternions in my skinning and allowing support for blending animations together.
However, shadows on buildings and other structures are very important. Therefore, if limiting these shadows to static geometry then I may take that rout. However, my engine will still use multi-pass lighting.
Right now I am considering combining the following in my lighting model:
1) Stencil Shadow Volumes
2) Normal Mapping (tangent space for everything except the terrain)
3) A gloss map for per pixel specularity (encoded as the Alpha component to the normal map)
4) Real-time ambient occlusion optimized using spatial subdivision structures (still researching this)
I plan on using quaternions in my skinning and allowing support for blending animations together.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
