GZDoombuilder slow down on big maps

[Bridgeburner56]

Does anyone have any tips/tricks for improving the performance of GZDoombuilder? Specifically the slow down when you reach high linedef amounts. I have a ... tendency to make massive, detailed maps (my attempt to make a 'small' map was still 40k linedefs) and I find that 'builder starts to struggle past the 50k-60k linedef point. In particular, switching to sectors mode now takes several seconds. The other modes don't have too much trouble and if them's the breaks then I'll just deal with it.

 

Thanks in advance

[mgr_inz_rafal]

Can you attach an example WAD file so I can verify if it slows down for me?

 

I don't work with such monstrosities, but I used to edit some pretty big maps and actually never experienced any performance problems.

[Dragonfly]

Am I misunderstanding? When you say sectors mode, do you mean the S hotkey, or the 3D mode?

 

In case you mean 3D mode - reducing the Draw Distance is my usual go-to solution for reducing framerate issues. You can also disable dynamic lights / 3D models in 3D mode unless needed. If it's lag when switching to sectors mode, then I'm honestly not sure. Sorry!

[Bridgeburner56]

@Dragonfly Switching to sectors mode using 'S' takes a few seconds. Switching to any other mode doesn't seem to have this issue. Also if I'm in sectors mode and draw something, it lags for a few seconds when I stop drawing. Again, other modes do not do this.

 

3D mode is not so bad. I do have the draw distance at a minimum for this map but that seems to be more effected by areas with a large concentration of lines rather than the total count on the map and then it's more a frame rate drop rather than a stall.

 

If it's just a product of 'builder struggling or my slightly old rig then I'll just keep slogging through it. Unfortunately I'm at 85k linedefs and I'm about 70% done so it's going to get worse before it gets better! But that's the price we pay for our, ahem, "art" ;p Maybe I'll learn my lesson and make the next map a bit smaller.

 

Maybe

 

 

[Dragonfly]

I have had issues similar to this before, not with switching to sectors mode specifically but with lag management as a whole. The quick'n'dirty solution is to make the next segment of the map in an independent map then stitch them together when nearly done with the new segment. This may help as a temporary solution for you!

[Bridgeburner56]

Thanks, I may end up doing that with some of bigger remaining areas. We'll see how she goes

 

@mgr_inz_rafal thanks for the offer but it's not bad enough to go to the trouble of uploading something.  I suspect it's just my comp groaning under the weight of these fat maps

[Mordeth]

Turn off 'fancy' features, such as lights or textured floorplans in editing mode. If you have 3rd party add-ons, maybe try and turn them off as well. My maps are typically 'a bit' larger than the ones you're working with, and I don't experience the slowdowns you describe with gzdoombuilder (although I use an older version), even on this older machine.

[ukiro]

Yes, there's something going on with large amounts of lines, it's like it's having to shift an array or something and it does so in a very slow way.

 

Another, related performance problem: Using the ellipse tool also slows down tremendously when there's a lot of other linedefs. But it seems worse when drawing in the void than when drawing inside an existing sector, so for this particular problem I can draw inside a big square sector and then delete the outside bits once I'm done.

[anotak]

hey, this may not solve your problem with GZDB, but you could try a different editor like DBX? (full disclosure: i'm the maintainer of DBX). DBX has less features, so it may not be able to do what you want, but it tends to run faster than GZDB at many things. But it has a similar interface to GZDB, since they are both based on DB2.

 

link here:

 

[Bridgeburner56]

Hey thanks for the help guys,much appreciated.

 

@Mordethhow big are your maps? Not that it's a competition... ;)

 

I'll check out your editor at some point @anotak but I am addicted to the gzdb features. 

[Bridgeburner56]

OK, so changing to wireframe mode (I'm assuming that's what @Mordeth was referring to) has no impact on the switching to sectors mode hitch.

[Mordeth]

5 hours ago, Bridgeburner56 said:

 

@Mordethhow big are your maps?

 

Current in-progress level is 28981 vertices, 38176 linedefs, 60892 sidedefs, 6042 sectors and 727 things. That last number should be taken with a large dose of salt; mapspots (usually numbering a few hundred) are spawned-in at map load in-game.  Biggest level so far tallies 32684 vertices, 43200 linedefs, 71037 sidedefs (yay for sidedef compression..!) and 6863 sectors.  While initial texture loading takes a fair amount of time (sometimes up to 1,5 minutes), switching modes is instant.

 

This using gzdoombuilder 2.3.0.2620.  Occasionally I use gzdb-bugfix 2.3.0.2993 or doombuilderX 2.1.3.6 for UDMF experimentation. No third party addons (I think); draw distance in visual mode maxed out; on an Intel Core duo cpu 3.00 GHz with 4 GB of RAM...

[Vorpal]

 

1 hour ago, Mordeth said:

 

Current in-progress level...

 

Dude it's not healthy what you do to me. When I first saw screenies of mordeth2 I was barely a teenager, and now I'm starting my gray-hair phase. I'm going to require some proof of life, or else I swear to god I will write a bad /idgames/ review on its release in 2035.

[Bridgeburner56]

9 hours ago, Mordeth said:

 

Current in-progress level is 28981 vertices, 38176 linedefs, 60892 sidedefs, 6042 sectors and 727 things. That last number should be taken with a large dose of salt; mapspots (usually numbering a few hundred) are spawned-in at map load in-game.  Biggest level so far tallies 32684 vertices, 43200 linedefs, 71037 sidedefs (yay for sidedef compression..!) and 6863 sectors.  While initial texture loading takes a fair amount of time (sometimes up to 1,5 minutes), switching modes is instant.

 

This using gzdoombuilder 2.3.0.2620.  Occasionally I use gzdb-bugfix 2.3.0.2993 or doombuilderX 2.1.3.6 for UDMF experimentation. No third party addons (I think); draw distance in visual mode maxed out; on an Intel Core duo cpu 3.00 GHz with 4 GB of RAM...

The hitching that I get switching modes doesn't get bad till I cross the 60,000 linedef mark. I"m at 85,000 at the moment and probably got another 20k-30k till I've finished this map so more pain awaits! It is weird that it's only when I switch to sectors mode. All other modes are fine, including visual mode, so I'm adjusting my behaviour to do as much editing in lindef mode. I would have thought that visual mode would struggle the most. That being said I do have the draw distance at 1000mp at the moment.

 

I'd be curious to see if this is a product of the later versions of GZdoombuilder. I don't remember getting this issue with Doombuilder 2 which I managed to hit the sidedef cap on on one map (just over 120,000). This was about 6 years ago though so that might have been improved/removed.

 

I should post on the zdoom bugfix thread and see if there is any new knowledge in that particular recess of internet land

[Bauul]

Out of interest, what map format do you use?

 

I've noticed GZDB does slow down definitely over time if you use UDMF.  UDMF is a pretty chunky file format when uncompressed (even medium sized maps can be thousands of lines long) so I have a suspicion that GZDB is re-reading the entire file on a pretty regular basis as you edit the map. 

 

I don't think there's any real way around it, other than creating the map in chunks and editing it together at the end like Dragonfly suggested.

[Bridgeburner56]

35 minutes ago, Bauul said:

Out of interest, what map format do you use?

 

I've noticed GZDB does slow down definitely over time if you use UDMF.  UDMF is a pretty chunky file format when uncompressed (even medium sized maps can be thousands of lines long) so I have a suspicion that GZDB is re-reading the entire file on a pretty regular basis as you edit the map. 

 

I don't think there's any real way around it, other than creating the map in chunks and editing it together at the end like Dragonfly suggested.

Yeah, I use UDMF and I'm too addicted to the features that it brings to the table. UDMF wad files are certainly much bigger than other formats so that makes sense. To be honest, the slow down is not a deal breaker, just a minor inconvenience so I'll just keep muscling through it.

[Mordeth]

10 hours ago, Bridgeburner56 said:

doesn't get bad till I cross the 60,000 linedef mark. I"m at 85,000 at the moment and probably got another 20k-30k till I've finished this map so more pain awaits

 

Please tell me you meant to write *sidedefs* instead of linedefs...

[Bridgeburner56]

21 minutes ago, Mordeth said:

 

Please tell me you meant to write *sidedefs* instead of linedefs...

ha, unfortunately not.

 

yep, i'm a little bit mad

this room has 10,000 linedefs. things ... escalated.

end result is quite nice though. whether it was worth it is another question. the things i do for lighting

[mgr_inz_rafal]

Oh my god... :D

[RockstarRaccoon]

GZDoomBuilder re-evaluates the sectors and lines to see if you're trying to attach some new piece of geometry to what you have every time you draw a sector.  If this is unusually slow, it means you have something wrong with the way it's organized your geometry and probably need to rebuild a chunk of it.  I suggest going around the edges of your major features and manually rebuilding some of that geometry, line by line, so you can find the places where it either has a line of length 0, or two lines don't actually connect, or whatever is causing this.  It is annoying, but 90% of the time that is what is causing the problem.

 

And instead of using sectors for those lighting effects, I'd suggest you look at dynamic lights, as they're gonna work much better for you here, both in ease of use, quality of look, AND (since you have way too many sectors) the speed at which the map edits, saves, loads, and runs.  Merging those sectors and replacing the lights with attenuated spotlights and maybe a bit of specular mapping should make this better all around...

[Bridgeburner56]

8 hours ago, RockstarRaccoon said:

GZDoomBuilder re-evaluates the sectors and lines to see if you're trying to attach some new piece of geometry to what you have every time you draw a sector.  If this is unusually slow, it means you have something wrong with the way it's organized your geometry and probably need to rebuild a chunk of it.  I suggest going around the edges of your major features and manually rebuilding some of that geometry, line by line, so you can find the places where it either has a line of length 0, or two lines don't actually connect, or whatever is causing this.  It is annoying, but 90% of the time that is what is causing the problem.

 

And instead of using sectors for those lighting effects, I'd suggest you look at dynamic lights, as they're gonna work much better for you here, both in ease of use, quality of look, AND (since you have way too many sectors) the speed at which the map edits, saves, loads, and runs.  Merging those sectors and replacing the lights with attenuated spotlights and maybe a bit of specular mapping should make this better all around...

I don't think it's a geometry error as it is consistently happening at a certain linedef count and gets progressively worse as I draw more. That being said I really have no idea so it may be the case, however there is no way I'm redrawing the map in the hopes it'll fix it.

 

I do use dynamic lights (attenuated, spotlight or otherwise) a lot although I'm still learning how to use them. In hindsight I may have been able to recreate the lighting with dynamic lights using an pitched attenuated spotlight and I may go back and do that once the rest of the map is finished. At this point saving myself a few thousand lines wont help much (if my theories are correct) but tidying that area up will help with fps (which is better than I was anticipating but there is still a bit of a slow down).

 

Thanks for the tips anyway. I'll try to remember to record at what linedef count things get noticeable in future maps to see if it's consistent. Might help shed some light. Or not and it's just my punishment for making big maps with obsessive levels of detail.

[RockstarRaccoon]

On 6/25/2018 at 2:01 AM, Bridgeburner56 said:

I don't think it's a geometry error as it is consistently happening at a certain linedef count and gets progressively worse as I draw more. That being said I really have no idea so it may be the case, however there is no way I'm redrawing the map in the hopes it'll fix it.

You don't need to redraw the whole map for this, just the outsides of it, to make sure they're closed.

 

I'd also recommend that, in the future, you start by building out your entire map and then work out the issues in the way it plays, THEN go for the intense details.  That way, you know your gameplay is the best it can be before your map is filled with things which will be hard to rework later.

[durian]

Just a thought, but looking at those shots I think you could afford to lose a lot of lines without much in the way of noticeable cosmetic sacrifice. Most obviously, you needn't use so many lines/vertices to get all those nice curves. I'm not suggesting you go back re-do anything here (though optimising can be oddly enjoyable), but it might be worth bearing in mind next time around :)  

[scifista42]

From my experience, GZDB slows down when some sectors have too many adjancent linedefs. You might be able to speed it up by adding linedefs splitting those sectors into multiple smaller sectors, each with relatively small number of adjancent linedefs.

[Bridgeburner56]

1 hour ago, RockstarRaccoon said:

You don't need to redraw the whole map for this, just the outsides of it, to make sure they're closed.

 

I'd also recommend that, in the future, you start by building out your entire map and then work out the issues in the way it plays, THEN go for the intense details.  That way, you know your gameplay is the best it can be before your map is filled with things which will be hard to rework later.

Maybe i should switch back to DeePsea where the editor would just crash if you tried to build the nodes with an unclosed sector or a 0 length line. Ahhh, the good old days.

 

I do tend to build my maps slightly backwards so I'll definitely bear that in mind on the next one. I do a lot of sketching before I start a map/area which helps prevent tripping over myself as areas develop. That being said I do end up in awkward positions trying to shoe horn something into an existing area but I tend to enjoy the challenge. 

31 minutes ago, durian said:

Just a thought, but looking at those shots I think you could afford to lose a lot of lines without much in the way of noticeable cosmetic sacrifice. Most obviously, you needn't use so many lines/vertices to get all those nice curves. I'm not suggesting you go back re-do anything here (though optimising can be oddly enjoyable), but it might be worth bearing in mind next time around :)  

You are probably right. I do like my nice smooth curves though ;p