Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Vertex cache optimisation and GeoSphere render call reduction #1507
The purpose of this patch is two-fold, first to reduce the number of calls to OpenGL to render parts of an index buffer from 5 to 1 and secondly to make that call closer to being optimal.
In future it should be possible to optimise LMR objects with the vcacheopt library
There are 16 possible configurations that a terrain patch can be rendered in from having all neighbours at lower resolution through to all neighbours at the same resolution.
Because of this we can precalculate all 16 configurations and create index buffers for them, we then choose which index buffer to use based on a patches edgeFriend pointers and render all of the applicable vertices with a single draw call.
Once each of the index buffers has been created it is then optimised, at lower resolutions this makes very little difference but at the higher resolutions the index ordering is substantially different.
None, it works fine.
No really, what's wrong with it?
Oh, ok, so the way I decide how to assign which combination of edges to which index buffer was a bit... "evolved", i.e: there was no intelligent design about it.
What else? C'mon...
Cripes ok, so the "vcacheopt" part isn't strictly necessary, you could just build the 16 index buffers and not bother to optimise them. The reason I don't just do that is that I started out trying to optimise the buffers using the vcacheopt system and only then did I realise the draw call reduction optimisation.
...that really is everything though ;)
I've made some house-keeping changes on top of this, at johnbartholomew/geosphere-vcache.
Plus a few even more minor things.
Nice changes! Glad you were able to see what needed changing about that bizarre edgeBools things I came up with - it was "sort of" logical and it worked as I hoped, I could see that it was just... bonkers but when you've come up with something like that it's hard to come back from the madness ;)
I'm unsure of how much a performance difference this will make in most situations we currently encounter, maybe we'll see a change up at the very high detail settings. Originally I worked on this stuff for the Orbital code I wrote because it generated such a flipping enormous amount of geometry.
Hopefully it'll pay off in the longer run, plus, it's just plain cleaner! :D
Hey, nice work:)
I tested this briefly just now and terrain rendering seems to work fine:)
Some notes about the vcacheopt, after looking through this paper johnbartholomew found:
It's a nice point to consider, and would end up being useful in other cases such as huge cities:).
Optimal Grid Rendering. There might be others, but that one was easy to find. It does want to know the cache size though.
Yes I've read that one, but we're not rendering a grid here.
There's an underlying set of gridded vertices but only one case where we're rendering all of it and 15 where we're rendering a variety of different edge triangulations that ignore some of the vertices.
Also, I picked this case because of A) the stated non-grid indexing above, B) as a test case before applying it to the object/model loader.
Doesn't really matter. I would've merged already but I was waiting for someone to do a little more testing/review, mostly to check I hadn't broken something when I got rid of the edgebools thing. I probably should have been more explicit.
Anyway, I guess we've had enough eyes on this now. I'll merge today.
The index orders could probably be added to the model cache to speed-up start time..
It's close to to a grid, in spite of the edge stuff Tomm put in (even if all of the vertices in edge triangles miss the cache there might be so many inner triangles to make the ACME improvement worthwhile, assuming it's not as good now), so an analytical approach with a modification is something to keep in mind when we have heavier loads for the vertex shaders.