BSP Formats and performance using DarkPlaces.

[Qrv]

Hello,

I'm wondering if anyone has done some benchmarking/performance tests on q1bsp vs q3bsp map formats in DarkPlaces?
See, I'm debating which to use for my current project, ideally, I need whichever one is going to give me the best FPS ofcourse.

Understandably, such a statement is probably hard to do a performance test for, seeing how I see no easy way to compare the speeds of the two.
Sure, I can make a .map, build a q1bsp, import to radiant or whatever, make a q3bsp ( Maybe even use natural patch/mesh corners in the q3bsp version, I dunno )
and do some tests, but it doesnt seem a good range for testing purposes.

My head tells me that q3bsp should be the faster format, it's newer than q1bsp afterall. But I just cant get my head around the DP engine source to see if this is indeed the case, compared to q1bsp.

I can live with sacraficing lightmap lightstyles if I use q3bsp ( because partly I can re-add them using RTLights, and partly q3bsp does AO on the lightmap far as I know, and I've never seen a radiosity light tool for q1bsp. ), but if it doesnt render any faster than a similar detailed q1bsp, why bother using it? I can map for both formats happily enough.

So yeah, if anyone has any thoughts/proof on which is indeed faster when running in DarkPlaces ( Not interested in other engines. ) please share.

[Nahuel]

It´s some strange, but i believe that q3bsp is faster. Otherwise in q3bsp you have some nice shaders to compile (with lights for example) and the Beziers.

[Qrv]

The only advantage I gain from q3bsp ( assuming the rendering speed is identical to q1bsp ) is curve patches.

Using q3 shaders with "texlight" is nearly useless to some extent, as RTLights will be in use on the map. Sure, for those that cant use RTLights, then yeah, texlight and the AO in q3bsp lightmaps will be a welcome addition, but no one should really see this at all due to RTLights. Prehaps some nice effects could be made by mixing RTLights and the original map lightmaps, but in my testing, this always comes out too bright. Might as well use RTLights and r_fullbright 1.
And thats with r_lightmaps at 0.1 or whatever the DP setting is. >_>

[mh]

That's an interesting can of worms.

At the most basic level, q3bsp is set up for the way graphics hardware (or at least graphics hardware of the previous century) actually works, whereas q1bsp (and, by extension, q2bsp) is set up for use by a software renderer. Based on that alone q3bsp should be faster, but there are other variables.

First one is that q3bsp (and note my "previous century" comment above) is set up with software transform and lighting in mind. Witness the padding of glVertexPointer to 4 floats for SIMD operations - completely irrelevant and unnecessary when you've got hardware T&L (and it consumes extra bandwidth which won't help with performance). Welcome to the 21st century!

Second one is no animating lightstyles and no proper dynamic lights. This translates to no calls to glTexSubImage2D at runtime, which in turn translates to faster performance. This is absolutely nothing to do with q3bsp in itself, you could easily switch off dynamic lighting in q1 and get the same result.

Third one is the shader system (I really wish that id had chosen a name other than "shader" for this - "surface scripts" would have been more appropriate and less confusing). You can set up a complex shader and totally wipe out any performance gains. What's more, all shader (i.e. Q3 "shader") operations are performed in software and on the CPU. That's slow - these days you would do them in a real shader (i.e. on the GPU) and you wouldn't restrict yourself to two texture units either. Welcome to the 21st century!

Fourth one is that performance of a given format is also down to how well the engine implements a renderer for that format. It's possible to set up a renderer for q1bsp that completely annihilates Q3A, even with incredibly complex maps, for example. That would depend on how DP does it's thing.

Fifth one is that q3bsp (and q2bsp, but not q1bsp) has some nice additional features that may very well weigh in it's advantage, even if q1bsp does turn out faster. Things like detail brushes can greatly accelerate vis times, area portals can cause closed doors to block visibility (meaning that performance doesn't go down - owing to extra overdraw - when you walk up to a closed door), and surface flags (so you can mark surfaces with various properties without having to rely on texture name hackery). These are important but often underestimated, and may swing the balance irrespective of performance.

Sixth one is limits. q1bsp has some limits which - depending on how complex a map you wish to make - you may end up hitting. That's really gonna suck if you do, and it won't matter a damn if q1bsp does turn out faster as you won't be able to finish your map.

[Qrv]

Some good points there Mh.

Detail brushes and area portals are one thing that will be an instant advantage to using q3bsp for me, it's something I moaned constantly about after mapping for q3 and going back to q1.

Surface flags are another feature I would make great use of in my project, another thing I did enjoy from q3 mapping.

As for how DP does it voodoo when it comes to rendering, I wish I knew to be honest. Last time I looked into the DP engine source, I was working on my own modified GLQuake... and that was some years ago. LordHavoc was still using a very similar code-base to GLQuake back then in DP. Last I looked into LordHavoc's new code base for DP engine, I quickly bailed out as I had no clue as to what was going on, heh.

[Spike]

to counter mh's points...

1: simd: DP uses the same code to submit verticies for both q1 and q3 bsps. there is no speed difference.

2: while there are no animating lightstyles, which will yield a small improvement, DP typically does dynamic lights using additional passes instead of using lightmap animations.
DP still supports lightstyle 0 for q3 bsps, I believe.

3: Again, DP uses the same code for q1 and q3, so no difference here.

4: complexity: any modern gpu can cull a few verticies faster than the cpu can. extra verts from large trimeshes are not a problem, but generating excessive batches still are. q3bsp has trimeshes while q1bsp does not.
side note: q3map2 is a lot more permissive about overdraw. This means less surfaces/batches, which can reduce cpu overhead. This is generally what you need if you want faster rendering. qbsp does not permit unneeded overdraw.

5: hidden features: the shader system can provide shader flags the same way. DP doesn't support area portals. All you really gain is detail brushes, which is a tool feature more than an engine feature.
side note: q2/q3 bsp have brush information stored inside them. This means that you can trace through the world at more than just 3 specific sizes. But also means its slower to do so.

6: limits: q1bsp sucks!

so I'm going to say q3bsp is faster for rendering, while q1bsp is faster for physics/servers.

[Qrv]

Hmm, interesting.

I cant say I'm fussy about server speed, although my project will support co-op and dm, it's more of a bonus extra as it's already in Q1. Primarily, the focus of my project is single player ( Although all the SP stuff will have excellent support for co-op, realistically, I cant see people playing co-op much over the net. Lan prehaps, but not inet. )

As for physics, its Q1. Lets face it, Q1 and physics in the same sentance shouldn't exist.

[stoleYourBike]

Q1 compilers plain suck, splits are everywhere and you`d easily get 4-5x higher poly count for anything remotely detailed and largish. So if you build large scale detailed maps then Q3 is the only way. If you build small low detail levels then it doesn't matter.
Not to mention q3map2 lighting is ages ahead of any q1 light compliler. Did I mention Q3 VIS is more efficient if you know what you're doing?