What the fuck's a nodebuilder?

Everything you need to know is here:

https://doomwiki.org/wiki/Node_builder

And the 3 main node builders used today:

https://doomwiki.org/wiki/ZokumBSP (powerful vanilla/boom support)

https://doomwiki.org/wiki/Zennode (Joe average node builder)

https://doomwiki.org/wiki/ZDBSP (not ideal for vanilla/boom maps, meant for gzdoom/zdoom)

Might as well ask this here: If I'm making a large limit-removing/Boom map, what is the recommended Nodebuilder choice in GZDB? I currently have ZenNode - Normal for saving the map and ZenNode - Fast(no reject) for testing. Should I be using something else?

For vanilla: BSP (the nodebuilder called "BSP") has this thing where if you tag a line with a tag between 901 and 998, you... uh... make it do some stuff that very much helps in avoiding vanilla limits. I think it excludes it from the blockmap or something??????? Really not sure, but the point is: it helps.

Also I discovered that it can do this: 

And in general, it's way way more friendly if you do crazy-ass vanilla hack stuff. 

9 hours ago, segfault said:

So I come to you guys to ask: What the fuck is a nodebuilder

To answer this question you need to look at the historical context in which Doom came out. It was 1993, 486s were just starting to become widely deployed. Most PCs back then were not able to run Doom at its full 35FPS. I remember playing on a 33mhz machine and it was just barely playable. That's why vanilla Doom had both a configurable screen size and low detail so that you could shrink it down to the size of a post-it note if you were really determined to play it on the 386 you had.

So Doom had to use some tricks to be able to run on the hardware of the day. One of the major problems in building a 3D engine is this: how do you draw things in the right order, so that the things which are close to the camera appear in front of the things which are far away? It sounds a simple enough problem to describe but solving it is difficult to do efficiently. Carmack stumbled across some research about how to use BSP trees as a solution to this problem. The research wasn't about building FPS games but the same approach could be reused. Node builders construct the BSP tree that is used by the engine.

But more generally speaking, the approach used is one of precomputation. When you have a computationally intensive problem you want to solve, you can sometimes "time shift" the work by doing a lot of work in advance to build a structure that lets you produce a quick result later on. To give you an analogous modern example: when you do a Google search you get a page of results seemingly instantly (under a second), but that's only possible because millions of pages have been pre-processed in thousands of hours of precomputation. Same with BSP trees: you were only able to play Doom on a 486 because a node builder crunched the numbers in advance and built the BSP tree.

15 hours ago, segfault said:

I'm having some problems setting up ZokumBSP with SLADE. Is there something I'm missing apart from pointing SLADE to the ZokumBSP binary and telling it to treat it like ZenNode?

ZokumBSP is a drop in replacement for ZenNode, so simply copying your current settings for ZenNode should suffice.

I wouldn't use Zennode for anything these days. ZokumBSP is a fork of Zennode with a lot of enhancements and bug fixes. It will build maps that Zennode would crash on. It will also in many cases do a better job due to better and enhanced algorithms. The level of Boom support is roughly the same as Zennode's, it's not something I have tested at all, instead focusing on Doom support. Hexen, Heretic and Strife are also untested.

@riderr3 I am bit puzzled by "Also in my WIP mapset I've encountered HOM when used ZokumBSP, so I've afraid to use that nodebuilder before it being stable."

Homs are very rarely an artifact caused by improper nodebuilding. They're usually caused by improperly designed maps or too complex maps. If the maps are too complex and you're hitting the drawsegs-limit, try using the segs-reduction emphasis. This might lead to slightly more subsectors, and possibly more visplanes.

I would love to get my hands on a map that has HOMs in ZokumBSP but not BSP or Zennode, so if yours got that, please send it to me.

ZokumBSP should be considered stable, and it also builds maps more correctly than DoomBSP, Zennode or BSP does.

Just use the latest beta, the only known problem is with output to the screen on some windows terminal types. It was put out as beta quickly due to problem with bad angles on segs. This bug is present even in Id's maps. Rebuilding with ZokumBSP fixes the maps with this bug.

2 hours ago, Spectre01 said:

Might as well ask this here: If I'm making a large limit-removing/Boom map, what is the recommended Nodebuilder choice in GZDB? I currently have ZenNode - Normal for saving the map and ZenNode - Fast(no reject) for testing. Should I be using something else?

Me the same. Not encountered slime trails yet. But on large map with many lines and sectors saving map takes longer.

Also in my WIP mapset I've encountered HOM when used ZokumBSP, so I've afraid to use that nodebuilder before it being stable.

7 hours ago, Edward850 said:

Everything you need to know is here:

https://doomwiki.org/wiki/Node_builder

 

And the 3 main node builders used today:

https://doomwiki.org/wiki/ZokumBSP (powerful vanilla/boom support)

https://doomwiki.org/wiki/Zennode (Joe average node builder)

https://doomwiki.org/wiki/ZDBSP (not ideal for vanilla/boom maps, meant for gzdoom/zdoom)

I'm having some problems setting up ZokumBSP with SLADE. Is there something I'm missing apart from pointing SLADE to the ZokumBSP binary and telling it to treat it like ZenNode?

34 minutes ago, fraggle said:

-

Thanks! I already kind of understood this but I really appreciate the explanation. I suppose my big problem now is trying to get ZokumBSP to play nice with SLADE.

In my experience, picking the right node builder can have big effects on the generation of your map, but only if you make a map that's big enough/weird enough for that to matter.  Most node builders do the basics absolutely fine: you could generate the whole of the Doom 2 IWAD on pretty much any of the main modern node builders and (as far as I'm aware) not notice any differences between them.  

Long story short: If I were you, I wouldn't worry about the node builder until you start to see some things that don't look quite right.

(Please anyone correct me if I'm way off the mark!)

3 hours ago, zokum said:

I wouldn't use Zennode for anything these days. ZokumBSP is a fork of Zennode with a lot of enhancements and bug fixes. It will build maps that Zennode would crash on. It will also in many cases do a better job due to better and enhanced algorithms. The level of Boom support is roughly the same as Zennode's, it's not something I have tested at all, instead focusing on Doom support. Hexen, Heretic and Strife are also untested.

@riderr3 I am bit puzzled by "Also in my WIP mapset I've encountered HOM when used ZokumBSP, so I've afraid to use that nodebuilder before it being stable."

Homs are very rarely an artifact caused by improper nodebuilding. They're usually caused by improperly designed maps or too complex maps. If the maps are too complex and you're hitting the drawsegs-limit, try using the segs-reduction emphasis. This might lead to slightly more subsectors, and possibly more visplanes.

I would love to get my hands on a map that has HOMs in ZokumBSP but not BSP or Zennode, so if yours got that, please send it to me.

ZokumBSP should be considered stable, and it also builds maps more correctly than DoomBSP, Zennode or BSP does.

Just use the latest beta, the only known problem is with output to the screen on some windows terminal types. It was put out as beta quickly due to problem with bad angles on segs. This bug is present even in Id's maps. Rebuilding with ZokumBSP fixes the maps with this bug.

I've seen nothing major really with zennode (mostly because I'm not doing crazy stuff with my maps just yet), just a seldom slime trail, but I have major OCD about that kind of thing. For a while I thought slime trails were actually a map error and I had tried futilely to make them go away, before discovering it had to do with the nodebuilder, then just now finding out that it was actually my fault and probably had to do with me not really doing something correct with my first map (whoda thunk?).

Anyway ZokumBSP is working perfect for me now, the problem I had was that I had left "vanilla optimized" checked in SLADE's options. I had erroneously thought that because ZokumBSP's a fork of Zennode, that it would keep all of the command line arguments, which in hindsight is kinda silly of me.

Thanks for the tool and your hard work!

I have painstakingly kept all of the old ZenNode argument stuff working. The algorithm and handling of command line isn't very pretty and people / tools might have invoked Zennode in an unintended way, and that MAY have broken something when using ZokumBSP.

Do you have an example of a commandline that works in Zennode, but breaks in ZokumBSP?

I've tried to let the default settings be sane settings that will build a usable map within a reasonable timeframe. There are a lot of knobs to tweak if you're interested in tweaking the process. The help screen is a bit unwieldy, I'd use the documentation instead.

I'm pretty certain it's an issue with SLADE then. I'll have to see what SLADE does with that "vanilla compatible" checkmark exactly.