Maybe state caching is less performance boosting, if the shaders are in a Display List. Maybe the advantage of Display Lists is worth more than the state cache can do. But I don’t know…
Marvin
Maybe state caching is less performance boosting, if the shaders are in a Display List. Maybe the advantage of Display Lists is worth more than the state cache can do. But I don’t know…
Marvin
Hi,
We can easily experiment with disabling the state caching. There is only one method affected, so we can try to build complete appearance in display list.
On the other hand, I believe that higher efficiency of jME is in different area than display lists. For complicated scenegraphs numerous display lists may become an issue - it is even highlighted in some application notes for VBO extension.
BTW, I am still checking what is wrong with multitexture. Currently implemented architecture seem to be correct, but due to some reason it does not set up proper texture states if only one of textures changed.
Yuri
Hi,
After really long and complicated debugging I finally found a REAL reason for object flashing in Q3 Benchmark. It was… attempt to access texture unit states higher than allowed by OpenG: implementation. This means that for cards that support >= 4 texture unit states for multitexturing, the problem did not appear, but other implementations are silently clamping texture unit state number to maximum allowed if it is too big.
This caused highest texture to be turned off after the core was trying to switch off non-existing not-used texture (states 2 and 3 in case of Q3 Benchmark).
To fix this, stricter checks against implementation limitations added. I will commit the fix after removing all debugging stuff.
Yuri
Hi,
Fix committed to CVS.
Yuri