I have coded myself a OpenGL BSP viewer for an old game format. It is very similar to the Quake 3 file format. Because my interest is developing graphics engines, I want to be developing while looking at using current technology. So I turn to you, the experts on the subject for direction of what to focus on. I would like this to be as fast as possible and considering the old file formats are very simple and have few polygons, I think it should be doable. Here are my questions:

  1. Lighting a. Does it make sense for me to learn vertex lighting or should I just implement per pixel lighting instead? b .I know OpenGL has an 8 light limit. Should I realistically only use one of those for ambient light and the rest computer through shaders? If not, what should I do?

  2. Sorting/Culling a. What is the fastest most common used algorithm for sorting surfaces to render. Complexity is not really an issue. I want to learn what is currently being used and ways to really only render the things I can see. I have seen a number of algorithms described like the painter's algorithm and am wondering what makes the most sense for BSP based geometry. b. If I have textures with alpha masks, I was told that sorting has some sort of involvement with this process. How do I allow them to render correctly in 3d space?

  3. Graphics Pipeline a. Should I be sending my geometry data via VBOs? Is this the standard used today? b. If I have a number of "regions", possibly 200-300, should I find a better way to send them to the GPU without sending 200-300 chunks. Should I combine them into one and keep a reference associated with each.

Any other tips for BSP based rendering and things of that nature?

Also, if I said something that was incorrect, please correct me. I'm that person who would rather be corrected and slightly embarrassed than ignorant and unaware.

Thank you for your time. I really do appreciate it.

  • \$\begingroup\$ Do you plan to put all triangles of your scene into the BSP, also dynamic ones like animated characters or moving objects? A BSP is not very good when it comes to dynamic objects. \$\endgroup\$ Commented Aug 3, 2011 at 5:57
  • \$\begingroup\$ Don't have time for a full comment at the moment, but check out icculus.org/twilight/darkplaces/technotes.html and don't hesitate to hop on #darkplaces on irc.anynet.org and ask LordHavoc/others your questions. \$\endgroup\$ Commented Aug 25, 2011 at 3:22

2 Answers 2


If you're - as you say - interested in current technology :

1) Lighting : Per-pixel lighting, definitely. If you want to look at current-gen rendering, you'll be looking at writing vertex- and pixelshaders. Simple as that. They offer almost unlimited flexibility and are not much harder to use than the fixed-function pipeline, if you start to learn them properly. OpenGL's 8 light limit is only applicable for old-fashioned fixed-function pipeline setups. Don't go that route, learn OpenGL Core and forget about all the dated glBegin/glEnd stuff.

2) Sorting / Culling : To start out : only sort if you need to for transparency. Only cull objects that are outside the view-frustum.

3) If you're using OpenGL, use VBO's and VAO's.


Unasked : if you're making a viewer for an old-fashioned BSP format (I suspect something from an ould Valve / ID engine ?) you should be able to get away with drawing the entire level without any sort of optimization (culling / bsp) at all and still get full framerate on modern hardware ;)

OpenGL Tip: Get the OpenGL Superbible 5th edition. This will teach you how to do modern OpenGL and will not cloud your mind with stuff you'll later find out is outdated.


1.a Per-vertex lighting is easier then per-pixel lighting (per-vertex lighting is built-in into OpenGL, perpixel lighting requires a custom shader).

1.b If you have eight lights, use them! You'll have to calculate which lights are visible, though.

3.a Use VBOS. Never use glBegin/glEnd (unless you use display lists, but in your situation VBOs are the better solution)

3.b You should not worry about performance while the program is still in development. Especially with todays hardware. So, send out your 200-300 chunks.

I don't know BSP maps well enough to help you with your other questions.

  • 3
    \$\begingroup\$ -1 for 3.b. I hate the "don't worry about performance" mantra that is incorrectly applied to everything. It has its place, as in don't spend 50% of the development time on making something run 2% faster. But when designing larger systems, it is good to have an efficient plan. Data being sent to the GPU in 200-300 chunks will possibly cause the CPU and GPU work needlessly harder than if it was all sent as one chunk. \$\endgroup\$ Commented Aug 2, 2011 at 23:01
  • \$\begingroup\$ @AttackingHobo +1 \$\endgroup\$ Commented Aug 3, 2011 at 14:37

Not the answer you're looking for? Browse other questions tagged .