Shadow performance

[eagletree]

I've read the topics on shadows and issues people have had. I have one that I'm curious if anyone has faced and fixed. The performance hit from Irrlicht shadows seems to be significant. I can double our frame rate with them disabled. It may cause us to cut back on the number of AIs we can spawn, but they look so good, we are keeping them. I've toyed with the parameters and the best solution thus far was just setVisible(false) based on proximity to the player character. With a lot of optimization, this may let us squeak by.

It appears that whether remote shadows are visible or not, something hangs for a few seconds after getting control in a new level. It occurs if I pan the camera around and several AIs or vehicles clip in. It only happens the first time I pan around the scene, and it only happens when shadows are enabled. It's as if the initial calculations for scene node shadows doesn't occur until they enter the camera fustrum. It never occurs again as long as I wander around the scene and regardless of camera view.

A great solution to this would be to have those calculations occur before the scene starts rendering, but since I can't say for sure what is causing it, I'd have no idea how to force that to happen. Does this sound familiar to anyone.

BTW, I'm talking about addShadowVolumeSceneNode shadows.

[hybrid]

The lag is due to the shadow node allocating the memory only the first time the shadow comes into the view frustum. We are currently reworking the stencil shadow implementation, so there could be some improvement in the next Irrlicht release. I will also try to make this allocation more deterministically happening at certain points.

[eagletree]

Thank you.

Based on what you said, I put calls to updateShadowVolumes() immediately after the creation (addShadowVolumeSceneNode) of any scene nodes shadow, called on the pointer returned. The freeze disappeared completely and game play action is now smooth. I'm guessing this is equivalent to what the render in IAnimatedMeshSceneNode does on PassCount=1. It works. I don't see the allocation issue as a problem unless it occurs during gameplay, it doesn't with this workaround, it's part of the loading screen now.

Here was the solution, is there anything I'm missing about it?

Code: Select all

 
//do this for every node that may spawn outside of fustrum, i.e., clipped on first render
shadowpointer = node->addShadowVolumeSceneNode(0,-1,true,1.0f);
shadowpointer->updateShadowVolumes(); //force memory allocation now
shadowpointer->setVisible(false); //don't show until in player proximity

Just a thought, if it's this simple, why not add the updateShadowVolumes() call into addShadowVolumeSceneNode() since it's a foregone conclusion that this will end up being done eventually. Then it wouldn't be a surprise to the programmer, and would most often occur at more convenient times.

Edit: corrected important spelling error
Edit 2: added question after code

[hybrid]

The reason it was implemented like this was probably, that adding shadow nodes to many objects in a large world would require an considerable amount of memory. Even if the objects will never come into sight. Whether this is a good optimization for all cases is definitely argueable. So I guess we will make it configurable, and add a defer flag for altering this behavior.

[eagletree]

I'm not criticizing at all. This method puts the control in the hands of the programmer anyway. I am surprised it's not been a major issue for others, or at least if so, they haven't posted about it. It makes me wonder if something else in my code needs some severe optimization. It may be that due to all our AIs using the bullet character controller and vehicles using the vehicle controller, I may have an elongated lag due to an already taxed scene. I will let it do it's normal default allocation after I change the characters over to standard rigid bodies as a test. If it's less noticeable, I'll post a note back to this thread to also check optimizations first before worrying about the stall.

Thank very much for this solution though.