After unfurrowing my brow, I end up with the same count for lists. Could you explain a bit more in depth how lists are faster than strips, specifically how you arrived at the other 2 figures you gave for the naive and optimized list method?

Certainly, the naive - brute-force, if I may - indexation in lists will not yield anything over the strips. Like, at all.

However, if you take into account the fact that the cards have (at least had, at the time I implemented it), usually, 24 vertices in post-transform vertex cache, you can come up with a "shape", how to traverse the 2D Grid of the heightmap that reuses all of those 24 vertices for multiple triangles.

Remember, at any time, the inner vertices in the heightmap, are common to 4 quads - that is 8 triangles.

I really don't want to give any more spoilers. Actually, I think I gave away too much already, but perhaps you can still enjoy the joy of discovery - just take a piece of paper and start drawing and counting - which ones can be grabbed from cache and which one not - just use colors, or make dots to mark them.

Note, that when I implemented it first time, I got a result of 0.67. Later,also on paper, I came up with yet-another shape that gives the ratio of 0.57 - I just couldn't be bothered to implement that one (the difference was not worth it for me), but on paper it works just like the 0.67 one did - it's just a more crazy shape.

Now, of course, you may ask - how do I know those exact vertices are fetched from the post-transform cache. Since I was immensely curious, I also implemented a method with a SW queue that emulated the cache to make sure the shape really results in a working (e.g. non-broken) heightmap.

I tested that and the max amount of triangles in scene rose because of this technique. That was pretty exciting to see the HW boundary be pushed.

Back in the day, this was one of the few ways you could actually pull outrageous amounts of triangles on screen, that you simply could not otherwise, if they were all separate vertices and you would have to pay the transform cost for each of them.

It's still a fun excercise today, even if it does not make sense these days (since now you waste all performance not on vertices, but post-processing garbage effects like Bokeh et al...

I've yet to even begin with post processing effects, as i'm still struggling with my pipeline management(which was still based on 9.0c. In fact, i've yet to even implement HDR(though i'm confident i'll manage).

After posting previously, it had occured to me that perhaps moving to a more equilateral shape, as opposed to a high aspect one, would allow for better reuse of cache, so off to pen and paper i go. Coincedently I had to use the same technique to find out how to procedurally generate a proper list based grid my first time. Now to do it better!