OpenGL, how much to draw at once?
I truly hate asking what feels like a completely stupid question, but my lack of formal training as lead me to throw this question right out there.
I'm getting to the point in current game project where rendering the main game area/level is approaching and there is something I'm not certain about, basically with concerns to how much is actually seen vs. how much to throw into the draw commands.
This may not be what will be done, but for the sake of explaining it in an easier way I'll pose these examples. I am currently using OpenGL ES 1.1.
Say I have a character and the view is 3rd person, close to the character. I have a large level area with rooms, etc. Do I:
Throw the entire level into the draw commands and assume the clipping and depth buffers do the job of trimming out what isn't seen/rendered to the screen?
Break the area up, only drawing sections 开发者_如何学JAVAthat could possibly be seen?
Something else more efficient?
If you are making a restricted environment, like what is common in FPS games, then research Portal Occlusion.
It is a popular topic, and books such as 3D Math Primer for Graphics and Game Development and Real-Time Rendering have good overviews of the technique. Other texts can provide more detailed/thorough readings on the subject.
BSP-trees could also be useful in this type of setup.
If you are making an open, large world similar to what is in RPGs then look into using Quad/Oct-trees.
Ideally, you'll want to send to the GPU only visible vertices. Otherwises, you'll lose performance. On the other hand, trying to do a perfect culling may need too much CPU cycles. You'll have to break the area in some patches and try to draw only what can be seen. If possible, try to be as accurate as possible but don't spend too much time on the CPU either.
Always profile and check :)
That depends on how well your driver can optimize the rendering. You will have to give it a try and measure the performance.
If the performance isn't good enough, here are some tips:
Cut the whole game into areas which can't possibly see each other (if you have an area below the ground, there is no way to see the surface, so you can cut that away). You just need a way to keep the transition areas (ramp down to the underground area) in sync in both areas.
Most drivers are pretty good at ignoring parts behind the player using octrees. If that doesn't work for you, create your own octree to optimize the the model which you pass to the renderer.
Geometry is often no problem, texturing costs time (lots of memory reads). Many drivers allow to use textures with different resolutions (mipmapping) to speed up the process.
精彩评论