I'm rendering outdoor scene with 6 cascades. I use spheres to avoid the "flicker" problem when the camera moves. The main problem is that the last two cascade spheres are very large (containing a good portion of my entire level). Therefore, I get a lot of "draw call" overhead.
I tried updating one cascade per frame, but when the camera moved very fast, I could notice a quick flickering error. Most likely because the camera no longer matches the camera that was used when a cascade was updated, so it doesn't correct until the cascade is "updated".
I'm going to try static shadow maps for far distances. Of course, they will not support animated meshes. Any other ideas?
CSM Speed Improvements
6 is a lot of cascades!
You could use instancing to render meshes that are in multiple cascades. Just pass all of the cascade matrices to the vertex shader, and use the right one based on SV_InstanceID.
You could use instancing to render meshes that are in multiple cascades. Just pass all of the cascade matrices to the vertex shader, and use the right one based on SV_InstanceID.
Hello next gen game maker! I mean, by Zeus six???
Anyway, depending on your problems I can think of two things.
This should help cull a lot of stuff out, and give you speedup at least: http://www.cg.tuwien...1-scc-paper.pdf
Think of it as "sparse shadow caster culling" or rather, just culling out objects that aren't going to directly affect the players view from the shadow map.
Another, more relevant to the draw call problem is this: http://advances.real...ggraph2012).pdf
It's essentially shadow map cache for CSM. Not sure how you'd adapt this too well to a moving overhead lightsource/the sun. But maybe you're doing an all static sun all the time, in which case the above should work out very well indeed.
Anyway, depending on your problems I can think of two things.
This should help cull a lot of stuff out, and give you speedup at least: http://www.cg.tuwien...1-scc-paper.pdf
Think of it as "sparse shadow caster culling" or rather, just culling out objects that aren't going to directly affect the players view from the shadow map.
Another, more relevant to the draw call problem is this: http://advances.real...ggraph2012).pdf
It's essentially shadow map cache for CSM. Not sure how you'd adapt this too well to a moving overhead lightsource/the sun. But maybe you're doing an all static sun all the time, in which case the above should work out very well indeed.
I use a geometry shader to dispatch the geometry on the render targets. (I can't use instancing in my case, at least not easily, because I already use instancing to automatically render duplicated geometry.)
The geometry is provided to the geometry shader with a 8-bit (max 8 splits) mask so that the geometry shader is dispatching the geometry on the appropriate render targets only.
The drawback is that I have also to compute these flags using each split frustum. (ie frustum culling for each split)
Hope it can help (?)
Nico
The geometry is provided to the geometry shader with a 8-bit (max 8 splits) mask so that the geometry shader is dispatching the geometry on the appropriate render targets only.
The drawback is that I have also to compute these flags using each split frustum. (ie frustum culling for each split)
Hope it can help (?)
Nico
I use a geometry shader to dispatch the geometry on the render targets. (I can't use instancing in my case, at least not easily, because I already use instancing to automatically render duplicated geometry.)
The geometry is provided to the geometry shader with a 8-bit (max 8 splits) mask so that the geometry shader is dispatching the geometry on the appropriate render targets only.
The drawback is that I have also to compute these flags using each split frustum. (ie frustum culling for each split)
Hope it can help (?)
Nico
Have you tried it without the geometry shader? My experience with using geometry shaders to render something from different views have been discouraging in the past. I'm curious whether newer graphics cards make this more feasible.
My experience with using geometry shaders to render something from different views have been discouraging in the past. I'm curious whether newer graphics cards make this more feasible.
Hello, no I haven't tried with instancing .... I've used this , using the geometry shader method
Hi,
The method described in the provided link is something to be avoided (as far as I know), The geometry shader can't handle efficiently outputting lots of primitives.
However, the geometry shader has its use. You can use the GS to define the render target index. You should modify your instancing code in a way that you have the render target index available for shadow rendering. So instead of drawing your scene * number of cascades times, you can draw everything in a single loop. Although drawing the meshes belonging to several cascades multiple times, your total number of draw calls doesn't increase.
Cheers!
The method described in the provided link is something to be avoided (as far as I know), The geometry shader can't handle efficiently outputting lots of primitives.
However, the geometry shader has its use. You can use the GS to define the render target index. You should modify your instancing code in a way that you have the render target index available for shadow rendering. So instead of drawing your scene * number of cascades times, you can draw everything in a single loop. Although drawing the meshes belonging to several cascades multiple times, your total number of draw calls doesn't increase.
Cheers!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
