Is there any benefit to joining identical sectors?

A sector definition in Doom map format takes up 26 bytes. If you take for example Sunder map 20, which is massive with 13467 sectors, of which 6625 are unique. That'd save about 174 KiB of space. The whole map is about 6564 KiB. So that map could save about 2.65% of total space. No really much. Of course it can vary wildly (in both directions) depending on the map.

Disadvantages for merging sectors:

• It can completely screw up sound propagation, unintentionally alerting monsters in remote areas of the map
• Many more classic ports play the noise of moving sectors in the center of the sector's bounding box, which could result in silent movement because the player is too far away from the center of the bounding box
• Can screw with sector movement in more classic ports (or low complevels) because of quirks in the engine
• Modifying the map after the sectors were joined is a pain in the ass

If you want to check your potential savings you can use this UDBScript:

/// <reference path="../udbscript.d.ts" />

`#version 5`;

const SECTOR_BYTES = 26;

if(!UDB.Map.isDoom)
    UDB.die('Map needs to be in Doom format');

let sectors = UDB.Map.getSectors();
let cache = new Set();

sectors.forEach(s => cache.add(`${s.floorHeight};${s.ceilingHeight};${s.floorTexture};${s.ceilingTexture};${s.brightness};${s.special};${s.tag}`));

UDB.log(`There are ${cache.size} unique sectors in ${sectors.length} total sectors. Merging them would save ${(sectors.length - cache.size) * SECTOR_BYTES} bytes of space.`);

Yeah joining identical sectors which are separated in the map has little value and can cause the issues mentioned by @boris.

But joining identical sectors which border each other is usually a good idea, it means less linedefs and sidedefs and helps the node builder (whether an external one or the one built into the engine) build a better BSP tree.

I think the special cases mentioned already are good. In terms of saving file space, boris already put that to rest. However, I want to take a step back and address the bigger issue.

If you are creating a level with many identical sectors, I think you need to take a hard look at why so many are identical in the context of level of detail. Is it because you have a pattern that looks really good and necessitates having identical sectors nearby? Or is the level of detail low, and several sectors in an area are repetitive? Or by chance are these sectors in different parts of the level? Or is it some other reason?

There is no right or wrong answer here - simply consider what led you to this question and see if maybe the level could be improved by changing things up a bit or adding more detail. Maybe it matters, maybe not, but I find it helps to take a step back and look at the bigger picture sometimes.

On 1/13/2024 at 6:02 PM, boris said:

Disadvantages for merging sectors:

It kinda irks me that these are listed as "disadvantages", as I see a majority of these points as "advantages" given the mapper knows what they are doing. It'd make more sense to call them "consequences" or "results" imo.

Without many of these "disadvantages", doom maps would be alot less interesting with less functionality to boot.

Especially with lower complevels, these can easily be seen as a boon. I constantly use merged sectors to have further control of certain sectors, while also keeping the visplane limit under control. After all, the more control sectors I can keep out of the view of the player for Vanilla, the better.

Another great example is if you wanted to construct a silent fast crusher. The easiest way is to duplicate the crusher sector far away from the crusher in the map, and it'll drag the sector's sound origin away, therefore creating a silent fast crusher. That's not even bringing the idea of adding an extra out-of-bounds sector to move where the sound origin is for a sector. I see merged sectors as giving the mapper more control and options.

On 1/13/2024 at 6:02 PM, boris said:

• Modifying the map after the sectors were joined is a pain in the ass

This is only an issue if you are using Doom Builder settings that don't try and "break up" merged sectors. I always have "merge dragged vertices only" set, and therefore moving parts of a map is never a problem for me.

13 hours ago, Arsinikk said:

It kinda irks me that these are listed as "disadvantages", as I see a majority of these points as "advantages" given the mapper knows what they are doing. It'd make more sense to call them "consequences" or "results" imo.

You are correct, and OP also acknowledges that there are uses for merging sectors. But OPs question was solely about size, and in that context blindly merging sectors can be disadvantageous. Of course accidental sound propagation due to merged sectors is a consequence, but IMO it's also a disadvantage in that case. But it's just semantics, I assume in the end we can agree that there are obvious uses for merging sectors, but you have to be careful to not screw anything up.

13 hours ago, Arsinikk said:

This is only an issue if you are using Doom Builder settings that don't try and "break up" merged sectors. I always have "merge dragged vertices only" set, and therefore moving parts of a map is never a problem for me.

Depends on how you use the editor. Dragging sectors, as opposed to dragging linedefs or vertices is pretty much a no-go with a huge amount of merged sectors.

[edit] There are actually two more advantages additional to the saved space:

• If you're building a REJECT table the size of that can be reduced significantly with fewer sectors, but comes at the cost of more LOS computations at runtime
• Merging sectors opens the possibility for better sidedef compression