ZDBSP extended uncompressed nodes, is there any point these days?

[plums]

My understanding is that uncompressed ZDBSP extended (UDMF) nodes were developed so as to have better cross-port support. But it seems like these days anything that supports them also supports compressed extended nodes. Is that correct? Is there any other reason to use uncompressed nodes?

 

Bonus question that's probably more interesting: Are there any ports that support UMAPINFO but not extended nodes? Are there any downsides to using extended nodes, other than possible port support, and bsp tricks like you can do with zokumbsp?

[Professor Hastig]

4 hours ago, plums said:

My understanding is that uncompressed ZDBSP extended (UDMF) nodes were developed so as to have better cross-port support. But it seems like these days anything that supports them also supports compressed extended nodes. Is that correct? Is there any other reason to use uncompressed nodes?

 

From what I remember, the only reason to even introduce the uncompressed format was the unwillingness of some ports to implement the decompression logic.

Whether all ports that have implement extended nodes also support the compressed variant I cannot say, but I don't think so. There's just too many forks floating around and not all are up to date.

 

 

4 hours ago, plums said:

Bonus question that's probably more interesting: Are there any ports that support UMAPINFO but not extended nodes? Are there any downsides to using extended nodes, other than possible port support, and bsp tricks like you can do with zokumbsp?

 

If you disregard port support, the extended node format is actually better because it has full fixed point precision for vertices and nodes so it should be a lot less susceptible to slime trails or other node-based render glitches.

 

BSP tricks are generally not format dependent, but you need a node builder that can generate them and output the node in the extended format - but to my knowledge such a node builder does not exist. You'd have to be very careful anyway because most of the time these tricks are not portable which makes it rather unappealing to support them in a format the vanilla engine cannot read.

 

[dasho]

8 minutes ago, plums said:

My understanding is that uncompressed ZDBSP extended (UDMF) nodes were developed so as to have better cross-port support. But it seems like these days anything that supports them also supports compressed extended nodes. Is that correct? Is there any other reason to use uncompressed nodes?

 

Bonus question that's probably more interesting: Are there any ports that support UMAPINFO but not extended nodes? Are there any downsides to using extended nodes, other than possible port support, and bsp tricks like you can do with zokumbsp?

 

My only guess for the desire to use uncompressed nodes for a port is if they don't have a zlib/equivalent library integrated and don't want to.

[plums]

11 hours ago, dasho said:

My only guess for the desire to use uncompressed nodes for a port is if they don't have a zlib/equivalent library integrated and don't want to.

 

7 hours ago, Professor Hastig said:

Whether all ports that have implement extended nodes also support the compressed variant I cannot say, but I don't think so. There's just too many forks floating around and not all are up to date.

 

Thanks both. So it seems like there's probably not many ports that support extended nodes but not compressed ones, but if the only difference is filesize of the wad, there's also not much harm in just sticking to uncompressed nodes either.

 

 

7 hours ago, Professor Hastig said:

If you disregard port support, the extended node format is actually better because it has full fixed point precision for vertices and nodes so it should be a lot less susceptible to slime trails or other node-based render glitches.

Exactly, which is why I got curious if there were any hidden disadvantages.

 

7 hours ago, Professor Hastig said:

BSP tricks are generally not format dependent, but you need a node builder that can generate them and output the node in the extended format - but to my knowledge such a node builder does not exist.

I could have phrased it better, but yes that's what I meant.