Good docs on BSP rendering?

[JasonX]

I'm working on a small map viewer to improve my modern OpenGL skills. I've been postponing the learning of shaders for too long! I've seen tons of BSP loaders out there, including the Assimp one, but i'm curious about the rendering of BSP maps in modern OpenGL. How would you guys do it? Would you even consider PVS? Or just send everything to the GPU? How would you do the lightmaps?

[Spike]

pvs is still good for reducing overdraw and texture switches, but recalculating everything that's visible every frame is a lost cause.

http://triptohell.info/moodles/junk/onedraw.zip is my toy engine (or rather, renderer). source is included.
you can compile it to use either bindless textures or array textures to avoid texture switches.
you can use the number keys to switch between different bsp strategies. see for yourself which is best. for whichever map you're throwing at it.
I could claim massive framerate increases, but you wouldn't believe me anyway. see for yourself, just remember that it skips much of what quake engines do so its pretty much guarenteed to be faster...

it worked for me at the time, but I probably depended on nvidia's non-standard vulkan behaviour, so ignore that if its b0rked. and the bindless stuff requires nvidia to work properly, so that stuff might not fully work for you either. the other one requires gl3.3 or something.
anyway, bsp loading+rendering for bsp29+bsp2 can be found in gl_bsp29.cpp. see if you can figure the rest out.

[JasonX]

Outstanding. Thank you so much. I'll be digging in the source, specially in the vulkan part.

[toneddu2000]

my gtx 970 makes vulkan exe crash. The other two exes go well. It's really a majestic project, I must say! It's a pity for the license.. I'd prefer MIT but whatever
You think that would be impossible to add csqc to it?

[Spike]

personally I just get a black screen with the vulkan build, oh well. frankly there's no advantage to vulkan here - vulkan excels at high drawcall counts but this thing explicitly keeps drawcall counts low, while current drivers waste their time being poo, so expect half the framerate from vulkan at eg 1920*1080, were it to work properly (this is what I see with vulkan vs d3d9 in fte).
yes, gpl sucks. I don't personally care that much about my code, but I'm not going to claim that I wasn't at least influenced by the gpled quake source in terms of file format/protocol support.
while someone could write csqc support for it, I don't really see all that much point considering all the other things currently lacking. If you're going for high framerates then a qcvm won't help much. I added demo playback for benchmarking purposes more than anything else. Being able to join servers was then just a small extra tweak allowing slightly more direct comparisons. If you actually wanted to mod that thing, I'd suggest just learning C++ instead of QC (in addition to the C++ fixes/extras it would need for it to be usable as anything but a toy engine).

[toneddu2000]

[JasonX]

Holy crap this qclib thing is amazing.

[frag.machine]

Great job indeed. Some time ago I tried to do the same with the regular Quake VM (just for fun), but the final result resembled more something a drunken Dr. Frankenstein would create... Also, having the compiler embedded is definitely a plus.

[frag.machine]

[toneddu2000]

[frag.machine]

There are tons of free resources in the subject available in the web, but since most of what I learned about basic programming was before the internet age I'm afraid I can't give any tested pointers (pun intended).

That said, at least in my case the relatively deep knowledge of hardware inner working (again, back in the 8 bit era) helped me to understand most of the more abstract concepts as pointers, arrays, structures and even objects. This is quite rare nowadays, but maybe the success of the rPi project can change it.

[mh]

[frag.machine]

[toneddu2000]

I think I'm starting understand things now, thanks a lot to both of you!