Batching and Sorting

[raynorpat]

[mh]

[raynorpat]

[Spike]

[mh]

[mh]

[mh]

Just been doing quite a lot more hands-on research into this whole area; some conclusions here: http://mhquake.blogspot.com/2011/09/sur ... notes.html

The summary is - use glDraw(Range)Elements with GL_TRIANGLES and 16-bit indexes and you won't go too far wrong. (I already knew that but it was nice to formally confirm it and have the working code to prove it.) Some older hardware might be happier with glDraw(Range)Elements and GL_TRIANGLE_STRIP, and it's not too bad (a bit fiddly to get things straight though) to provide both options and let the user select which one they want. With newer hardware you can just blast a load of glDrawArrays calls and it will run almost as fast and save you a lot of work in setup - you most definitely need a big static VBO for this (and that means that you also need shaders if you want to do water and sky animations).

Key point number two is that there are a number of cases where - if you violate your hardware's limits - OpenGL will drop you back to software emulation without any warning. This would be just on the T&L stage of the pipeline, but it's still bye bye high performance, hello a drop to potentially one third or less of the framerate you had before (depending on scene complexity) and you scratching your head and wondering why you put in all that extra work only for things to run slower (if you're interested, D3D's reaction to this is normally a crash - I prefer the crash because I can catch it happening and take corrective action sooner, but I can see why OpenGL's behaviour exists). Hardware T&L devices are fussy and you need to be aware of this in order to properly get the fast path.