Horde3D

Hi guys,

I know there are a lot of different topics addressing performance currently, but I thought this required a new one as it’s a slightly different issue to the ones being discussed.

Currently if you have more than one pass with lighting (i.e. DoForwardLightingLoop) the shadow map is rendered as many times as you have passes. This isn’t an issue in the samples as the transparent pass is unlit. I’m lighting my transparent objects, which means when I render the transparent pass all the geometry is rendered to the shadow map a second time. To combat this extra unnecessary cost I’ve pulled out the shadow map rendering to a separate pass where everything that casts shadows is rendered up front, and this shadow map is used for all subsequent passes.

Is this a reasonable thing to be doing? Am I missing out on something else and have possibly broken something by doing this?

In addition to this, updateQueues is called for every pass (for DrawGeometry and DrawLightGeometry etc). Again I may be misunderstanding this, but I think that this must be called at least once for generating the shadow map, and once for every camera you render to. But presumably it doesn’t need to be called for each pass to the same camera which it currently is.

These two issues are fairly significant costs for me at the moment as I do multiple passes. Has anyone else found anything similar? I can fix these issues locally but I thought if other people were experiencing similar problems the correct fix may warrant some discussion.

Shadows from transparent objects are very hard to render correctly - the issue probably never arose. I don't see a theoretical problem with reusing shadow maps across multiple passes, but I can't speak as to the implementation.

_________________
Tristam MacDonald - [swiftcoding]

Yeah, several passes using the same shadow map are currently not supported efficiently. In your implementation, how do you handle the case of several light sources where you require several shadow maps?


You are right here, that is still quite inefficient. Sorry for that, but the optimization phase is just about to start.

Currently I don't My implementation isn't much more than a hack at the moment!