Hey there.
I’ve got some stuff going on that ends up applying some pretty complex matrix operations. I want to avoid drawing anything that won’t appear onscreen (i.e. won’t appear within the viewport), but I don’t want to bother with the math to convert those points backwards to find if they’re on screen or not. Is there a nifty OpenGL call I can use to see if something is within the viewport?
You might want to google ‘frustum culling’ and ‘occlusion queries’ for more advanced ways of checking whether geometry is visible.
With frustum culling you can make a lot of ‘early escape’ calculations on the CPU, using a quadtree or an octtree, or some other (binary) structure.
With occlusion queries, you can determine (on the GPU) whether a render call would yield any result. Something may be in the viewport, but behind another object, ‘rendering’ it invisible.
Cool beans, that’ll do the trick.
@Riven: Yeah I have a quad tree in there already for collision, the issue is that the coordinate space for all the entities is significantly different than the actual drawn space (it’s scale, translated, rotated, and wrapped around a circle like in Super Mario Galaxy), so I’d need to make quite a bit of calculations that I don’t have the time to make right now (I need a prototype done by the 15th for Make 'em Up).
Create a bounding sphere around your entities. Scale/translate/rotate that, and put it in your quadtree. Nothing hard to calculate about that.
You can also do occulsion queries. As a quick overview: Basically you turn off depth/framebuffer draws. Start a query, draw a flat poly (or bounding cube…whatever) that covers the area of interest, stop the query and it tells you if ‘any’ pixel would have been drawn.
(edit: opps…missed Riven already talking about this)
Also, a couple of in-CPU matrix operations should be faster than hitting the GPU. In my engine, I switched away from using glPush etc. to do the math for me to computing the final transforms in Java and had a reasonably significant performance boost. I’m pretty sure this was mostly do to the JNI overhead but I can’t be sure. My recommendation is to try the culling and math in the CPU and see if that runs well enough.