Jump to content

  • Log In with Google      Sign In   
  • Create Account


CSM Speed Improvements


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Quat   Members   -  Reputation: 403

Like
0Likes
Like

Posted 26 September 2012 - 01:53 PM

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?
-----Quat

Sponsor:

#2 MJP   Moderators   -  Reputation: 10949

Like
0Likes
Like

Posted 26 September 2012 - 02:34 PM

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.

#3 Frenetic Pony   Members   -  Reputation: 1282

Like
0Likes
Like

Posted 26 September 2012 - 03:19 PM

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.

Edited by Frenetic Pony, 26 September 2012 - 03:21 PM.


#4 Tournicoti   Prime Members   -  Reputation: 683

Like
0Likes
Like

Posted 27 September 2012 - 07:17 AM

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

#5 B_old   Members   -  Reputation: 658

Like
0Likes
Like

Posted 27 September 2012 - 08:38 AM

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.

#6 Tournicoti   Prime Members   -  Reputation: 683

Like
0Likes
Like

Posted 27 September 2012 - 10:02 AM

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
Posted Image

#7 kauna   Crossbones+   -  Reputation: 2345

Like
0Likes
Like

Posted 28 September 2012 - 08:29 AM

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!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS