Jump to content
  • Advertisement
Sign in to follow this  
vinnyvicious

OpenGL Rendering Quake 3 BSP in modern OpenGL

This topic is 995 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been reading some modern tutorials on OpenGL, trying to get rid of all the pre-OpenGL 2 bad habits. So, i decided to write a small Quake 3 BSP renderer to make sure i'm understanding everything. After hitting a few bumps, i wonder: Does it really make sense to read and calculate VIS data? Shouldn't i just render everything and use a basic frustum culling?

Share this post


Link to post
Share on other sites
Advertisement

If you rely on frustum culling, then you still submit everything to the GPU that is hidden behind walls and closed doors. Even though you might not pay a pixel shader cost, you still pay for the cost of the driver calls on the CPU, any state switching and vertex shader costs.

 

Modern games can still use precalculated vis data, though some are moving to dynamically calculated vis data such as software occlusion buffers due to the need for dynamic scenes.

Share this post


Link to post
Share on other sites

VIS data in the Quake map format is basically occlusion culling data. Frustum culling is something else entirely. Both methods are useful on their own as well as combined. If you have the data, I don't see a reason not to use it.

Share this post


Link to post
Share on other sites

nowadays it might make sense to chop the level into coarser chunks and pre-upload these to the GPU and then just based on where you are, render the appropriate chunk.

 

GPUs are fast enough to easily handle the vertex count of a whole Q3A map, hence you would rather not worry about drawing out of frustum object. Fillrate, on the other side, can still become a bottleneck if you go for crazy resolution with insane antialiasing modes (and honestly, why wouldn't you on such an old game/tech?). that's why it makes sense to chop the map into smaller visible areas to reduce overdraw.

 

running the detailed PVS might not be of any benefit nowadays, but you can use it to create the chopped areas.

Share this post


Link to post
Share on other sites

Simple alternative would be just sort room size chunks front to back after frustum culling and rely on Hi-Z culling.

Edited by kalle_h

Share this post


Link to post
Share on other sites

Simple alternative would be just sort front room size chunks front to back after frustum culling and rely on Hi-Z culling.

Upvoted because this is quite true for a Q3A level, but wanted to note that depending on what you are drawing that you can't always rely on Hi-Z. Certain shader bytecodes and state combinations will disable writing and/or reading from Hi-Z, and relying on Hi-Z will not remove state change overhead or vertex shader costs.

Share this post


Link to post
Share on other sites


Certain shader bytecodes and state combinations will disable writing and/or reading from Hi-Z, and relying on Hi-Z will not remove state change overhead or vertex shader costs.

Besides modifying depth disabling early-z, I can't figure out what you're talking about - could you elaborate?

 


Upvoted because this is quite true for a Q3A level,

Yeah I upvoted for this reason as well since you can get a front to back or back to front draw order from the BSP tree.

Share this post


Link to post
Share on other sites


Certain shader bytecodes and state combinations will disable writing and/or reading from Hi-Z, and relying on Hi-Z will not remove state change overhead or vertex shader costs.

Besides modifying depth disabling early-z, I can't figure out what you're talking about - could you elaborate?

 

IIRC, the discard keyword in a pixel shader, stencil operations and alpha-test also disable the early-z path.
 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!