glBSP: Does anyone still use this?

The reason for the question poll is simple - for map authors who wish their maps to be GL compliant (even with level editors), would you choose zdBSP or glBSP to generate GL-compliant nodes? And, for OpenGL engine authors only, would you prefer glnodes to be generated with glBSP, or zdBSP? 

The reason I ask specifically is I am thinking about swapping glBSP (as EDGE's internal nodebuilder) for ZDBSP, since it can generate both GLnodes and UDMF/PolyObject support out-of-box. EDGE already has a very simplified zdBSP nodebuilder integrated for UDMF maps to build at run-time, but if those maps are not UDMF, EDGE will default to glBSP. So it's not a catch-all library (yet).

I have thought about extending glBSP personally, but it would be a lot of work. zdbsp already generates nodes that EDGE seems to take to better than glBSP. For instance, running Frozen Time through EDGE's default glBSP (^{not glBSPX}) results in a low framerate and a bunch of rendering errors (black holes). Generating the same glNodes through zdBSP (which glBSP ignores since they exist already) results in a Frozen Time which is rendered correctly (no voids, bridge is rendered correctly), and it sees a slight framerate boost (note that the low framerate in that map/et al is due to EDGE's internal BSP walker and not a nodebuilder, though generating good glNodes certainly helps).

I know it seems like a no-brainer (just replace already!!), but I would like to hear what everyone else recommends. I think glBSP was a fantastic tool for its time, and I'm totally not trying to downplay its impact or the authors of that program. Also of note, the rendering problems definitely get fixed up if the WAD is ran through glBSPX, which can fine tune node granularity generation, but it takes twice (or more) as long to generate in the amount of time zdbsp takes as its default. And as we all know, glBSP does not support UDMF. I can write in that support though, since it _does_ support Zdoom/Hexen/PolyObjects, but I'm just wondering if it will be worth the effort. 

Seems I should first find out if people prefer glBSP to begin with. ^_^

GLBSP as a stand-alone application should remain available, of course.

As the internal nodebuilder in 3DGE, given what you've said, it would make a lot of sense to move to ZDBSP. But that is IMO kind of orthogonal to the question of whether people use the standalone glBSP or not.

1 hour ago, Coraline said:

Sidenote: Do most OpenGL engines nowadays even generate their own GLNodes in-engine or on-the-fly like EDGE does? Or does it rely on the map editors to contain the correct information?

AFAIK, and apologies if I'm mistaken:

• Doomsday: uses internal nodebuilder all the time, regardless of whether nodes of any type are present
• GZDoom: uses internal nodebuilder if GL nodes are not found (and/or user settings force rebuilds)
• GLBoom+: does not have an internal nodebuilder
• Risen3D: no idea, sorry
• Zandronum: see GZDoom

I think those and 3DGE are the only GL ports of notice -- perhaps there are a few people who still use Vavoom from time to time, but historical stuff like DoomGL or glDoom has no relevance today.

I use GLBSP, but only because I have it installed already, and packaged it for Debian once. I have no objections to ZDBSP at all and if GLBSP went away (and I realise you aren't proposing that) I'd take a look at it.

19 hours ago, Gez said:

Risen3D: no idea, sorry

Always rebuilds, with its own internal modified glBSP.

Quote from readme if you're really interested...

The nodes are now built internally on a per map basis using a slightly
 modified earlier version of glbsp v205 by Andrew Apted. Support for special
 fx and gNd4 nodes was initially added by both myself and Jack Vermeulen.
 The version of glbsp shipped does not support gnd5 nodes which are needed
 by very large maps.

 gNd5 is supported by Risen3D but is only built by a modified version
 of zdbsp which is substituted automatically as required. The version of
 zdbsp used was 1.17 and was written by Randy Heit.

 The modified versions of glbsp and zdbsp are embedded and do not need to
 (and should not) be built externally. The nodes shipped with pwads are
 normally rebuilt with any gl nodes being ignored as these are always
 built by Risen3D. Pwads remain unchanged in all cases unless using
 edit mode.

On 8/1/2017 at 4:28 PM, Coraline said:

Also of note, the rendering problems definitely get fixed up if the WAD is ran through glBSPX, which can fine tune node granularity generation, but it takes twice (or more) as long to generate in the amount of time zdbsp takes as its default

@Coreline: Do you mean that glBSPX can be set to do a better, more accurate job, but that setting makes it take longer to run? If so, maybe it's worth keeping, or, maybe it could be used to enhance zdbsp, as an option. Either way, if it has the ability to produce superior output in some cases, I don't think it should be tossed out. And, if you actually incorporated both modes, it may be useful for diagnostic purposes, if either method encounters a problem. (The downside being complexity, and more code to maintain). I thought that, at one time, Risen3D was unique in that it went to great lengths to allow some old renderer tricks to work. Is that true?

Im' using glBSP as DelphiDoom's internal node builder.

@kb1 I'm not sure of Risen3D's specifications, but your suggestion sounds great overall. I'll just keep both of them. Since I know IWADS render just as fast under glBSP than they do zdBSP (and if they don't, then something is seriously wrong anyways), glBSP can be the default for those. I can have zdBSP take over node generation under most circumstances since it does output GL nodes. The trade-off is that custom WADS won't generate a GWA file, but with today's computing speeds, I don't see it as too much of a problem.

For those of you that don't know, GWA files act as a "cache" wad that has the glnodes generated, so glBSP doesn't have to run everytime EDGE loads a WAD that needs GL information. That system runs wonderfully under, say, the Sega Dreamcast which has a very limited amount of RAM, but as most people who run the source port nowadays have a pretty decent system, I can just set zdBSP to rebuild everytime. Plus, zdbsp seems better overall for things that EDGE supports now, such as PolyObjects, UDMF, rendering 'tricks', etc. ;-)

I see zdBSP generates a temp file to write that information to as well...I wonder if I can just hijack that and also store it as a GWA file (maybe GW2 format) in case people on older systems like the fast loading times (since node info doesn't need to be rebuilt with GWA). . . hmmmm :-3

I don't use ZDBSP because it cannot generate REJECT.

1 hour ago, 38_ViTa_38 said:

I don't use ZDBSP because it cannot generate REJECT.

Yep. REJECT seems to have fallen out of favor these days, but I use it too. REJECT can be built on it's own with a dedicated toolset. Unfortunately, to build a proper REJECT can take a long time on huge maps, so doing it at game load time is sketchy. This could be mitigated a the cache system, similar to GWA though.

The reject lump is not a node lump and therefore not the normal purview of a nodebuilder. You can use ZDBSP along with RMB if you want rejects.

The problem with rejects is that they basically offer only a very situational speed up on modern systems (requires a scenario in which there are a lot of monster sight checks going on but the player is in a sector invisible from the monsters's point of views) but they take time to compute and space to store. Since the number of rejects to compute is basically equal to the number of sectors squared, the cost-benefit ratio is very bad generally -- on "simple" maps they're unobtrusive but largely useless, on "complex" maps they might provide a small boost but they become really unwieldy. To illustrate: a hypothetical REJECT lump for ZDCMP2 would weigh over 34 megabytes. (16 562 sectors, squared to 274 299 844 bits, so 34 287 481 bytes precisely.)

EDGE itself doesn't utilize REJECT in any way, though, so for my situation it's fine that zdBSP doesn't build it. Is REJECT particularly useful for OpenGL-based ports, given that most of us generate our own data/visibility on-the-fly?

While we are on this subject, I always wondered if adding support for glVIS sets would speed up unnecessary BSP collection (in EDGE, that is), even though pre-calculating would take awhile. Did that ever catch on or is it a relic from Vavoom? I'm not quite ready to tackle the problems EDGE has with polygon visibility with larger maps, and if glVIS would even grant a slight framerate boost then IMO it'd be worth it. Though, the downside is that I'd have to write it in, meaning that glBSP would be extended for the port.

I didn't know people still used glBSP these days -- that's good to know. ^_^ Not saying it's bad at what it does -- it's more of a situational bias for me than a reflection of the program.

@Gez: didn't know the REJECT lump was so volatile, or that it could get so large. I only thought that might have been a GL-only thing. Can the Vanilla engine capably load so much REJECT data or is that a hypothetical thing for other software-based ports?

The REJECT lump has nothing to do with rendering. It is only used to speed up monster line of sight computations. Can monster in sector A see player in sector B? Look it up in the REJECT lump. If it says "no" then don't bother going forward; if it says "yes" then do actually bother making the proper LOS check.

It is entirely unrelated with the GLVIS stuff, even if the concept behind both is the same. REJECT is purely for worldsim, so it deals with sectors (not subsectors). It has been around since the first shareware release at least, long before Doom even had OpenGL renderers available. (It wasn't present in the press release beta, though. It was an optimization added late in the development cycle to make the game more playable on low-end hardware of the era.)

The GLVIS stuff, as far as I know, is used only by Vavoom and by Strife Veteran Edition. Again, it cannot use the same elements as the REJECT lump even if the principle is the same; GLVIS deals with renderer elements (subsectors), not with worldsim elements (sectors).

Oh yeah you're right @Gez, i knew that..!! ...  I think my post got a little jumbled up while I was writing it. I understand the concepts between the two, but my post came out garbled and instead meshed all together. It was totally unintentional. Sorry about that.. even with my medication, ADHD still scrambles my thoughts up, even if it's right in front of me. I hate having this affliction, because I can be working/researching/etc on chunks of code or whatever and the very next second I can completely lose my train of thought or get excited about something random and never recover from it. :/

Anyways, I didn't know Strife: VE used glVIS. I gotta check it out now. I've had it in my Steam library since it was released and never got around to checking it out. Looked pretty from what I remember, though.

This probably isn't too helpful, but just for statistics reasons...

I've been using zdbsp exclusively for the past few years, but that's because I've also only made UDMF wads for the past few years.  If UDMF support isn't needed, or if it was added to it, I'd go back to using glbsp like I used to.  Essentially my choice of node builder rests more on UDMF than anything else.

One thing should be noted:

While GZDoom can use GL nodes made by glbsp, the renderer has been optimized for ZDBSP's output. This is most important with render hacks, because both node builders use a different approach to deal with open sectors. The format in which the nodes are stored is not relevant here, so it doesn't matter if it uses ZDoom extended nodes or GL_xxxx.