"Perfect" Nodes with ZDBSP?

[Xaser]

I've once more found myself eye-to-eye with an old nemesis of mine: Node errors. Simply put, the nodes being built by ZDBSP are never as precise as the ones built internally by ZDoom with "gennodes 1" on, no matter what settings I try. Since they're exactly the same node builder, this -should- be possible, but I've never found the right settings. It was suggested in the past to build compressed nodes (-z option, I think), but that isn't cutting the mustard, either. I'm still getting slime trails and weirdo HOMs in some parts of the map, which "gennodes 1" eliminates without fail.

Thus, I'll re-ask the age-old question: How do you get ZDBSP to build nodes exactly how the ZDoom-embedded one does it?

[randi]

ZDBSP's default options are identical to the ones "baked in" to the internal nodebuilder. As long as you aren't using a node format with 16-bit coordinates and you don't change any of the tuning parameters, they should be byte-for-byte identical. I've compared detailed debugging dumps from both to confirm this. The reason for this is if there's something wrong with the internal nodebuilder, it's a lot easier to debug it with ZDBSP instead of trying to do it from inside the game, but this only works because they build the same nodes.

[Xaser]

That's not matching my experience at all. ZDCMP2 in particular is consistently exhibiting slime trails (related to sub-unit vertex precision in this case, I think) that are eliminated when the internal nodebuilder is used. I'm using the default settings. Something's got to be different, as this has always been the case as long as I've been using ZDBSP.

[NeuralStunner]

What's the command line? I've found that the parameters provided by DB2 leave a lot to be desired. (But then again, so does its "copy the EXE to the temp directory" method.) I don't even build in DB2 any more, I let it run on ZDoom's internal during testing, and build manually before releasing.

The options I use: -Xgrc (Extended, GL, Empy Reject, UDMF Comments)

I get great results from this.

[Graf Zahl]

That's not matching my experience at all. ZDCMP2 in particular is consistently exhibiting slime trails (related to sub-unit vertex precision in this case, I think) that are eliminated when the internal nodebuilder is used. I'm using the default settings. Something's got to be different, as this has always been the case as long as I've been using ZDBSP.

In what format do you save the nodes, extended or regular? Regular nodes do not have the sufficient vertex precision. You should always force extended nodes if you get problems like this.

[Xaser]

I wish I could say extended nodes were fixing it for me, but still no dice.

I know it's not a great example because it's so huge, but the beta builds of ZDCMP2 exhibits this in a few areas, like so:


Warp to the coordinates shown after generating the nodes internally, and it's not there. I haven't been able to oust this particular HOM (among others) at all using external ZDBSP.

[Enjay]

Warp to the coordinates shown...

[Project Dark Fox]

Click the image, Nutjob Enjay...

[Enjay]

Doh!

Thanks

[Project Dark Fox]

Did the streaking through the cool air in Normandy get to your hea--

[Enjay]

Could be.

Anyway, I get the same results: internal node build = fine, external node build = not fine.

I tried a few different options but I couldn't get an external node build that removed the effect in the screenshot,

And, just in case it is important, ZDBSP reported the following on one of my tests:

Spoiler:

Code: Select all • Expand view

----ZDCMP2----
Sectors 2142 at (-8000,3820) and 2141 at (-8028,3820) don't match.
Sectors 2141 at (-8036,3820) and 2142 at (-8064,3820) don't match.
Sectors 2142 at (-8028,3776) and 2141 at (-8028,3812) don't match.
Sectors 2142 at (-8036,3776) and 2141 at (-8036,3812) don't match.
Sectors 2139 at (-8356,3828) and 2140 at (-8384,3828) don't match.
   BSP: 100.0%
Unclosed subsector 25471, from (-3308,3052) to (-3308,3052)
Unclosed subsector 27698, from (-8069,5183) to (-8069,5183)
Unclosed subsector 27960, from (-8328,5172) to (-8328,5172)
Unclosed subsector 36012, from (-929,10720) to (-929,10616)
Unclosed subsector 36013, from (-929,10616) to (-929,10720)
Unclosed subsector 36269, from (-2241,10128) to (-2241,10112)
Unclosed subsector 36270, from (-2241,10112) to (-2241,10128)
Unclosed subsector 36307, from (-1216,10000) to (-1216,9968)
Unclosed subsector 36308, from (-1216,9968) to (-1216,10000)
Unclosed subsector 36626, from (4372,9343) to (4372,9343)
Unclosed subsector 37743, from (-1216,9616) to (-1217,9568)
Unclosed subsector 37744, from (-1217,9568) to (-1216,9616)
Unclosed subsector 37841, from (-640,9248) to (-640,9216)
Unclosed subsector 37842, from (-640,9216) to (-640,9248)
Unclosed subsector 37847, from (-640,9216) to (-640,9184)
Unclosed subsector 37848, from (-640,9184) to (-640,9216)
Unclosed subsector 37886, from (63,9088) to (64,9100)
Unclosed subsector 37929, from (176,8960) to (176,8832)
Unclosed subsector 37931, from (176,8832) to (175,8832)
Unclosed subsector 41636, from (-1259,18692) to (-1284,18595)
Unclosed subsector 41637, from (-1284,18595) to (-1259,18692)
Unclosed subsector 41737, from (-1232,18072) to (-1211,18156)
Unclosed subsector 41738, from (-1211,18156) to (-1232,18072)
Unclosed subsector 42376, from (490,18196) to (471,18268)
Unclosed subsector 42377, from (471,18268) to (490,18196)
Unclosed subsector 42667, from (362,18692) to (216,19256)
Unclosed subsector 42668, from (216,19256) to (284,18976)
Unclosed subsector 42669, from (284,18976) to (341,18774)
Unclosed subsector 42671, from (341,18774) to (362,18692)
Unclosed subsector 43450, from (-2682,23248) to (-2720,23615)
Unclosed subsector 43451, from (-2720,23615) to (-2682,23248)
Unclosed subsector 44597, from (2192,26592) to (761,28672)
Unclosed subsector 44603, from (1142,27008) to (2043,26548)
Unclosed subsector 44614, from (2043,26548) to (2192,26592)
Unclosed subsector 44619, from (761,28672) to (-464,28368)
Unclosed subsector 44620, from (-464,28368) to (352,28096)
Unclosed subsector 44621, from (352,28096) to (704,27768)
Unclosed subsector 44627, from (1040,27456) to (1094,27218)
Unclosed subsector 44628, from (704,27768) to (1040,27456)
Unclosed subsector 44631, from (1094,27218) to (1142,27008)
Unclosed subsector 45536, from (-6598,14984) to (-6701,16192)
Unclosed subsector 45591, from (-6642,15168) to (-6608,15104)
Unclosed subsector 45592, from (-6608,15104) to (-6598,14984)
Unclosed subsector 45609, from (-6701,16192) to (-6888,15928)
Unclosed subsector 45618, from (-6888,15928) to (-6880,15887)
Unclosed subsector 45620, from (-6880,15887) to (-6736,15416)
Unclosed subsector 45628, from (-6736,15416) to (-6683,15245)
Unclosed subsector 45637, from (-6683,15245) to (-6642,15168)
   6.873 seconds.

Total time: 6.886 seconds.

[esselfortium]

I've had this problem all over the place with SpaceDM9 and TSoZD. Before I found out that it could be fixed by forcing ZDoom to build nodes internally, I had to wiggle vertices around in all sorts of awful ways to try to avoid giant gaping sector holes.

[Edward-san]

what about a minimal test wad (remove useless sectors which aren't connected directly to the bad ones) which replicates the bad behavior?

[edit]my supposition is that zdbsp is missing some fixes which are in the zdoom internal nodebuilder...

[Gez]

It's hard to make a minimal test map since deleting a single sector can result in entirely different nodes being built and the problem being moved away. Giant maps like ZDCMP2, on the other hand, are practically guaranteed to have the problem somewhere.

[Graf Zahl]

What happens if you let ZDBSP create GL nodes?

If that works it may narrow down the place where things go wrong.