ZDBSP binary map format SSECTORS/SEGS limit?

[DoomerMrT]

I keep hitting some limit while mapping in binary map format. The SSECTORS and SEGS of the map does not get built.

Map statistics:

21013 Vertices
25853 Linedefs
48082 Sidedefs
5808 Sectors

With these statistics, it is working. Getting somewhat above these though causes SSECTORS and SEGS to be 0 byte lumps inside the wad, rendering the map unplayable. What are the limits of the nodebuilder (or the map format maybe?). BTW, the map has to be in binary (Doom in Hexen) format.

[Graf Zahl]

Yes, you are hitting the SEGS limit of 65536 with that map - which makes ZDBSP automatically build extended nodes. Those only occupy the NODES lump which contains all the needed data, the other two will remain empty.

[DoomerMrT]

Thank you for the detailed answer

[DoomerMrT]

I could build the nodes with Zen Node and it appears there are "only" ~59200 SEGS. Doesn't that mean that ZDBSP's automatic extended node building triggers too early? Or it might mean that SEGS are split differently, resulting greater number with ZDBSP?

[Graf Zahl]

No, it means that ZDBSP tends to create larger BSPs. Zennode has always been more efficient here, but it's always a trade-off between loss of vertex precision, an unbalanced BSP tree and more data.

[DoomerMrT]

That explains it. I had to fix some problems with 1 unit wide sectors where bounding vertexes overlapped to other adjacent sectors after building the map with Zennode. Other than that the map looks fine, just used less SEGS on the cost of precision.

[Bauul]

I had a lot of fun trying to get my head around this just today actually. From what I can work out, there are essentially a series of map-complexity 'milestones' as it were where compatibility slowly decreases in breadth. I might have the details wrong, but from what I've gathered, you're looking at the following:

(Note: these limits apply to all lumps in the data, but the ones I've listed below are the ones that are typically the first to be hit)

1. Up to 32,768 SEGS: Any map format, any source port (notwithstanding other limits like Visplanes)
2. 32,768 to 65,536 SEGS: Any map format, but limit-removing source port needed, so excluding only the really hardcore vanilla ports like Chocolate
3. 65,537 or more SEGS, but 65,536 or fewer Sidedefs: BSP map formats must support extended nodes, i.e. ZDBSP or DeepBSP. Source port compatible with those node builders needed.
4. 65,536 Sidedefs + a varying amount (depends on map), but 65,536 or fewer Linedefs: GZDoom Builder automatically implements Sidedef compression to try to keep the final number under 65,536. Combined with extended nodes, this is absolutely pushing the limit of BSP.
5. 65,536 or more Linedefs, or far more than 65,536 Sidedefs: Only UDMF works, and the source ports that support it.

[Graf Zahl]

An additional limit for 5. is 65535 linedefs. And this is a hard limit. If it gets exceeded the binary map format won't do it anymore. With sidedef compression this is more likely to occur before the compressed sidedef limit is reached.

[Bauul]

An additional limit for 5. is 65535 linedefs. And this is a hard limit. If it gets exceeded the binary map format won't do it anymore. With sidedef compression this is more likely to occur before the compressed sidedef limit is reached.

Thanks! I didn't know how effective the Sidedef compression actually was, so thanks for the information. I've updated my post above for posterity.