Emulator

Stage download link: http://forums.kc-mm.com/Gallery/BrawlView.php?Number=31626

I looked into this a little further. I'm certain the problem has something to do with structures2.mdl0

Exporting then re-importing the model via BrawlBox did not change the problem so it's likely unrelated to materials or shaders.

This model has a very large number of facepoints for a model imported into Brawl (80969). Perhaps that is relevant here?

Removing some of the objects from the model made this problem go away. Now the question is does Dolphin rightfully complain about about the abnormally large model?

This is entirely a dolphin error, and in fact the message is incorrect (we already do reset them on flush). All that's happening is that you're sending more than 0xffff vertices with the same configuration; dolphin likes to merge together groups of vertices with the same configuration because that's faster, but at some point a new batch needs to be started. That message indicates that a new batch should be started; I'm pretty sure it just predates the code that actually started a new batch (it was added for #6135 in this 2013 commit, and I think we start a new batch in this 2014 commit but I'm not 100% sure).

For reference, the grass in #6135 is rendered in 4 primitive commands, each containing 63000 vertices. The broken rendering of the grass was fixed in 3.5-1063 (and is present in 3.5-1062).

There was a regression in 4.0-699 which caused the "Too little remaining index values. Use 32-bit or reset them on flush." message to be spammed for the grass case; this did not happen in 4.0-692. More precisely, the regression happened in StreamBuffers-4.0-695 and did not exist in StreamBuffers-4.0-694. All that changed in that version was that Flush() no longer directly resets the index generator, but instead PrepareForAdditionalData() does it afterwards if a flush occurred, so the message is incorrectly shown. (I'm also a bit confused about the message saying "reset them on flush" as even in 3.5-1063 Flush() called ResetBuffer() which reset them.) Strangely this is not the version where this issue was introduced; I'm guessing something changed at some point that allowed the separate draws there to be merged together. But it's where the underlying issue came from.

For whatever reason I can't comment on #6135 (I think it uses a field that no longer exists), so I'm putting this here.