Different node builders, BSP trees.

[Soundblock]

As someone who's returned to Doom editing for a while and remembering some of the habits that the editing community used to have in the early years I'm curious about one thing. Now that DoomBuilder pretty much has conquered the previous battle for mappers' editor choice, are anything but its built in node builder (ZenNode, is it?) being used to generate the levels' BSP trees? I seem to recollect that different nodebuilders would yield different gameplay results on different maps, such as framerate differences, varying amounts of monster awareness and alternate audio-sensoring across two-sided linedefs. Is it one-size-fits all after DoomBuilder, or do people still generate different nodes with different BSP generators to gain different results?

[Da Werecat]

Doom Builder 2 has various node builders bundled with it. I'm switching between BSP and ZenNode whenever I'm getting glitches with seemingly correct geometry or leet tricks. Sometimes is helps.

[Graf Zahl]

Soundblock said:

I seem to recollect that different nodebuilders would yield different gameplay results on different maps, such as framerate differences, varying amounts of monster awareness and alternate audio-sensoring across two-sided linedefs. Is it one-size-fits all after DoomBuilder, or do people still generate different nodes with different BSP generators to gain different results?

Framerate differences are possible - but only if you compare a very bad node build with a very good one. Normally it shouldn't matter.

As for the rest, no. Most of these things never use the BSP for anything except sight checks and if those fail, the nodes are plain and simply buggy. Properly built nodes should never cause gameplay related differences.

[Foxpup]

Graf Zahl said:

As for the rest, no. Most of these things never use the BSP for anything except sight checks and if those fail, the nodes are plain and simply buggy. Properly built nodes should never cause gameplay related differences.

I think he's talking about imprecise reject maps (most nodebuilders also build reject and blockmaps, who knew?) and IDBSP's broken sector merging (which no other nodebuilder does). Of course, even a perfect nodebuilder can produce gameplay difference if the map contains unclosed sectors, depending on how the subsectors end up being constructed, though unclosed sectors are obviously a failure to begin with except where special effects are concerned.

The only really catastrophic failure I've seen in a nodebuilder is WARM's giant blockmap bug. I've no idea what causes it, but this otherwise reliable nodebuilder occasionally spits out a blockmap that far exceeds the map boundary. The blockmap is still accurate, though it doesn't do the framerate any good and it completely breaks the automap (which uses the blockmap for scaling).

[plums]

BSP-W32 gives me the best results for vanilla special effects: invisible sectors, 3D bridges, that kind of thing. AFAIK it's the only node builder that will let monsters target you if you're standing in a self-referencing sector. It's also usually the first to crap out once the level gets too complicated.

Beyond that I'm not sure it makes too much difference, until you get into really large and complex levels. Apparently DeepBSP is good at very large maps.

REJECT tables (normally built by node builders, but there exist separate tools for them as well) can be used to cause special effects, like monsters that can't see you in certain sectors. REJECT is also something that can speed up processing of maps - but I don't know that the performance gain is noticeable with modern computers. I know it doesn't scale well with large maps at all.

Lastly you can occasionally get funny results with certain node builders. Alfonzo was posting some speedmaps fairly recently, one of them had a trooper that could somehow see you behind a door - likely from the way the nodes were built (though I'd be interested to see a technical dissection of the map to figure out the exact cause). In any case this is quite rare.

[Soundblock]

Graf Zahl said:

Properly built nodes should never cause gameplay related differences.

What plums said seems to point to a different conclusion, depending on the definition of "properly".

As a case in point, a friend of mine's map (hellbolt.wad) had a cyberdemon sat down the end of a very long hallway, seperated by many double-sided linedefs (vanilla Doom ala 95'ish). Depending on what node builder was used on the map, the cybo would or would not wake up due to weaponsfire in remote rooms that weren't directly tied to the great hallway. This made a big difference in gameplay, as if the cybo didn't roar on LOS the player would likely be unsuspecting to his presence and subsequent barrage of rockets, once said hallway had been entered. At the point of entry, the corridor was long enough to mask the cybos footsteps from player detection...

The wad in question was one of only two that my friend made. The other was named atrocity.wad. I'm not sure if he ever uploaded these anywhere to give you a case in point example of nodebuilders' effects on gameplay, but he's since lost track of the files, and I didn't keep any backups of them, so I sadly can't hand over solid proof of the effect.

EDIT: And the map in question magically turns up. I've sent a message to ask if Bjornar remembers what node builder he used on it. I think we were using something just called 'BSP' at the time. Whichever BSP builder was used first or second to produce the differing results, this downloadable version seem to have what I consider to be the inferior gameplay nodes, since the cybo's presence is more obvious here. Might have been the default node builder that came with DEU that produced stealthier cybo results?

[Graf Zahl]

The stuff plums mentioned come from people not knowing how these features work and thus fail to construct them properly.

Self referencing sectors are probably the only thing that is affected by how the nodes are built so it is extremely important to understand the technical details of what these do internally to make them work WITHOUT depending on the node builder. Yes, it is possible to construct self-referencing sector stuff in a way that does not rely on specific node builders to work ingame.

The problem, of course, is that despite their widespread use, they are not *proper* map constructs to begin with. :P


As for that map, no idea. The sound traversal code never even uses the BSP, all it does is traverse sector boundaries, and they don't depend on anything the BSP contains - at all!

My personal favorite is ZDBSP. It seems to be the most robust one overall, and it's the one that most easily shows if some self referencing sector effect may be volatile - I found it's the one that most easily makes them break, so if you can make them work with ZDBSP, they most likely work with all other node builders, too.

I think it's dangerous to make effects that are node builder dependent, because there's some ports out there that throw the internal nodes away without ever looking at them.

[Kappes Buur]

Just as a heads-up:
In the case of pwads for ZDoom / GZDoom, you can set the editor to not build nodes.
Then, when the pwad is opened with ZDoom/GZDoom, the nodes are build with the build-in nodebuilder ZDBSP.

That makes life so much easier.

[plums]

Soundblock said:

What plums said seems to point to a different conclusion, depending on the definition of "properly".

Well, the thing is, the node builder shouldn't matter. It's just in rare cases that something will glitch up, or as Graf said, when people construct things improperly. In that case it's good to have options so that if one doesn't work, you can try another.

I'll take a look at that map, I'm interested to see what's going on there.

[Soundblock]

Well, I'm primarily concerned with how the map ends up playing, regardless of the technicalities invisible to me that take it there. As long as I don't break anything along the way and as long as some interesting gameplay is brought to the table, any node builder is fine by me.

[DaniJ]

Graf Zahl said:

I think it's dangerous to make effects that are node builder dependent, because there's some ports out there that throw the internal nodes away without ever looking at them.

It is precisely because of the fact that node builders produce wildly different and in some cases, broken nodes, that Doomsday ignores them completely. Once we've separated things so that the renderer and playsim can use a different node set, we'll then hookup the regular nodes for the playsim.

When rendering however, we can't use the nodes produced by other node builders because rationalizing them into a verify-ably correct half-edge mesh would be a complete nightmare. As such, its better to generate them ourselves as we can be sure they are valid and that self-referencing tricks are handled in the way we expect.