I’m having an issue with an ever-increasing number of cached render states.
The more objects visible, the faster it increases.
This leads to the game getting slower and slower due to an increased time spent in garbage collect.
Garbage collect and cache settings are all at default.
Looking for advice on how to proceed with debugging this to find out why the old render states are not being removed.
Is there an easy way to get a list of all the render states in the cache? It might help to be able to see what data they contain.
The root cause seems to be setShaderInput. If I remove my setShaderInput calls then the render state cache stays stable.
Still no idea why the states would not get cleaned up, though. Is it possible to be selective in which states get cached?
Even more bizarrely, I narrowed down the piece of code that I removed that started the whole problem in the first place:
camera_initial = NodePath(PandaNode('initial state'))
This is an UNUSED shader input, hence why I removed it.
This is not supposed to happen, but there do seem to be cases in which it does. What is happening is presumably an undetected circular reference count in the state caches, so that states accumulate instead of being cleaned up properly. If you can boil it down to a fairly simple example, I may be able to use it to help track down a bug. Which version of Panda are you running?
Workarounds include making strategic calls to RenderState.garbageCollect() or even RenderState.clearCache(). If worse comes to worst, you can disable the cache altogether with “state-cache 0”. Many applications run just fine without a render state cache.
We actually run with “state-cache 0” in our release build since it runs faster that way and does not have this problem.
It really only affects our dev build. We’ve had problems with EGG files not loading properly if the state cache is disabled, which is why we don’t do it for the dev build.
Our Panda is built from cvs, from early January.
I’ll see if I can make simple demos for both issues.
That’s strange. It should certainly not fail to load egg files properly, regardless of this setting; that’s certainly a bug. I’d love to have a reproducible case of this problem.
Here is a minimal example of the state-cache setting causing EGG files to not load properly.
Specifically the problem occurs during the conversion to BAM.
You can see with pstats that when “state-cache 0” is set, the EGG file incorrectly loads as 279 geoms.
With the default setting, it loads as only 1 geom.
I know this is probably too late to be useful for you, but I just checked in a fix. As it turns out, RenderState::compare_to compared the render attributes by pointer, which only works if the state cache is enabled. I just changed it to actually invoke compare_to on the RenderAttrib. Picked up for the 1.8 branch.