Need advice for 3D BSP based graphics engine

Sasquatch

Newcomer
Hi. 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.
 
1.a. Depends, if you don't know anything about lighting, the Blinn-Phong BRDF is mandatory. But you will most likely never use Vertex Lighthing.
1.b. Forget about OpenGL prior to 3.0.

2.a. We don't use anything like that anymore. We use spatial acceleration structures and depth-sorted or shader sorted entities lists.
2.b. back to front sorting of alpha blended objects is mandatory, alpha tested ones are treated as opaque. (unless also alpha blended)

3.a. As I said, ignore OpenGL versions prior to 3.0, consider 3.3 or 4.1 today. VBO is the only way in those versions.
3.b. 200-300 draw calls is nothing for modern systems, keep it like that.


Not sure which games use BSP today, I certainly never worked on any.
I used Quadtrees mostly.


I suggest you get your hands on Real-Time Rendering and Game Engine Architecture (from Jason Gregory, not another with similar name) to learn more about modern hardware/technics.
 
Thank you Rodéric. I will definitely purchase that book. I am glad to know I can ditch the old model of lighting as it is most likely obsolete.

And thank you Davros. I will look into the source. Always hesitant to start looking at such huge projects but I have to learn soon anyway.

Thank you both. If anyone has anything else to add, let me know.
 
I will read these Rodéric. Thank you.

You mentioned "We use spatial acceleration structures and depth-sorted or shader sorted entities lists" for use in frustum culling and such. Do you have any links to that which I can implement?
 
I will read these Rodéric. Thank you.

You mentioned "We use spatial acceleration structures and depth-sorted or shader sorted entities lists" for use in frustum culling and such. Do you have any links to that which I can implement?

spatial acceleration structures : quadtree, octree, kD tree...
after that you have an array of entities, that you will sort depending on some master key (opaque/translucent for example). So opaques are shader sorted, while translucents are depth sorted (back to front).
If you have an early depth pass, you might want to depth sort your opaques front to back, or just a subset...

So google up sorting for that ;)
 
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.

Just to give you a frame of reference, in Quake 4 if your map hovered around 1000 batches as a worst case you'd be just fine.
 
Back
Top