UDMF map keeling over. General limits question.

[Andy Johnsen]

So I've been working on a map for quite some time, using / abusing the UDMF format and extended nodes (using the integrated version of ZDBSP - the only way that seems to do the trick at this point).

It's a large, open map with lots of siddefs and sectors in view.

I've started getting problems with the far end sectors not being built properly, causing lightlevels to boost to 255, sprites floating around and other icky stuff - only at the areas where vast stuff can be viewed at once, no surprise.

I suppose my question is if there is a set limit to what the format can handle?

Stats included:

[scifista42]

First idea that may possibly help: Try to move the entire map closer to the coordinate origin point (0,0).

UDMF itself has no limits of size of numbers, because it represents numbers as texts (specifications here). Real engines that run UDMF maps (and editors too?) may have their limits, though. I think (but not 100% surely) that the usual 32-bit fixed-point number limit applies in ZDoom, which means that coordinates should remain between -32768 to +32767 map units (where 1 map unit actually has 65536 sub-units, that's what makes it 32-bit), but the further the map is from origin, the bigger calculation imprecisions may appear during runtime, so it's safer to keep the map's center as close to origin as possible.

[Dave The Daring]

I really want to see this map now.

[Gez]

Andy Johnsen said:

I suppose my question is if there is a set limit to what the format can handle?

There shouldn't be.

[Andy Johnsen]

scifista42 said:

First idea that may possibly help: Try to move the entire map closer to the coordinate origin point (0,0).

UDMF itself has no limits of size of numbers, because it represents numbers as texts (specifications here). Real engines that run UDMF maps (and editors too?) may have their limits, though. I think (but not 100% surely) that the usual 32-bit fixed-point number limit applies in ZDoom, which means that coordinates should remain between -32768 to +32767 map units (where 1 map unit actually has 65536 sub-units, that's what makes it 32-bit), but the further the map is from origin, the bigger calculation imprecisions may appear during runtime, so it's safer to keep the map's center as close to origin as possible.

Thanks for the insight Sifista42 / Gez, the coordinaters are well within range, and I tried centering the map even more as you mention, to no effect. I've had it happen at very different spots of the map, with the same behavior each time (sprites either being swallowed by the ground or popping to the ceiling height, light levels going ballistic and various other weirdness in a row of clustered sectors). The only thing that has fixed it so far have been cutting back on stuff across the map... :\

DB2 gives no errors in the map.

[scifista42]

Do the problems appear in both software renderer (ZDoom, Zandronum in software mode) and OpenGL renderer (GZDoom, Zandronum in hardware mode), or only a specific one of them? Which port(s) do you actually test with?

[Gez]

Andy Johnsen said:

DB2 gives no errors in the map.

I'm going to be that guy: have you tried switching to GZDB?

I remember we ran into various problems back then when making ZDCMP2 (the largest UDMF map I'm aware of), and DB2 had already ceased development then so we had to switch to GZDB and get MaxED to fix the issues.

[Kappes Buur]

Andy Johnsen said:

It's a large, open map with lots of siddefs and sectors in view.

Indeed. Use GZDoom Builder. See statistics of my map

Spoiler

[Andy Johnsen]

Well, I went ahead and installed GZDoom Builder and it immediately detected two almost overlapping vertices. Deleting them was all it took, I no longer suffer from floating trees. Thanks a lot Scifista42 and Gez, now the madness can resume. :)

(Thats one massive and interesting looking map Kappes Buur. Avilable for dl anywhere, or work in progress?)

[Kappes Buur]

Andy Johnsen said:

(Thats one massive and interesting looking map Kappes Buur.
Avilable for dl anywhere, or work in progress?)

It is still WIP. I'm working on it sort of on and off, but lately
I have run into mapper's block. The map is very much open terrain
with lots of vertex height things, which bogs down a weak computer
system. I really should split it up into hubs.

[TimeOfDeath]

Well my comp can't handle either maps in this thread, but it's cool to see you mapping again Anders. :)

[Andy Johnsen]

TimeOfDeath said:

Well my comp can't handle either maps in this thread, but it's cool to see you mapping again Anders. :)

Thank you sir! I hope you'll enjoy the end product, but it is indeed hard on the specs.

[DeathevokatioN]

I have absolutely nothing of substance to add other than I can't wait to play this map and that it's awesome to see you're mapping again! :D

[Andy Johnsen]

DeathevokatioN said:

I have absolutely nothing of substance to add other than I can't wait to play this map and that it's awesome to see you're mapping again! :D

Hey thanks, that's cool to hear. I hope you'll enjoy it. :)