Segments.

[magikal]

Okay I'm creating a map, almost finished, I keep it inside the blockmap limit,11k linedefs, only 700 sectors...and then I hit the segment limit, damn. Silly question, but what precisely are segments?

[DooMBoy]

AFAIK, segment refers to a piece(s) of a given linedef. If you split a linedef, then you now have two segments, for example.

I think. I could be wrong, so don't quote me on this.

[Ichor]

Are you sure you don't mean sidedefs?

[magikal]

Ichor said:

Are you sure you don't mean sidedefs?

Absolutely.
DooMBoy thanx, but surely if you split a linedef you get 2 linedefs!
Anyone with DeepSea run the error checker/level stats and you will quite clearly see segs listed.It must have something to do with sectors/enclosed spaces as I deleted a couple of sectors and I'm down to 32753 segs.

[Volte]

I think Segs has to do with the way the BSP splits up the rooms (it
splits up into a bunch of different pieces so it knows what to draw
first).

[esayeek]

once the nodes are built, you can check to see how many segs there are.

[Biffy]

Yeah, and some node builders will produce fewer segments than others. I think BSP has a switch or two to affect this. WARM seems to make somewhat fewer segments than some others, try that.

[The Ultimate DooMer]

magikal said:

It must have something to do with sectors/enclosed spaces as I deleted a couple of sectors and I'm down to 32753 segs.

It could still be linedef related, after all, sectors contain linedefs.....

Actually it is linedef related cos I just looked in Wintex and every level has a SEGS lump, and when highlighted, Wintex says 'Wall segments' so it must be something to do with walls.

[Searcher]

The unofficial Doom guide has the following:

[4-6]: SEGS
===========

The SEGS are stored in a sequential order determined by the SSECTORS,
which are part of the NODES recursive tree.
Each seg is 12 bytes in 6 <short> fields:

(1) start of seg is VERTEX with this number
(2) end VERTEX
(3) angle: 0= east, 16384=north, -16384=south, -32768=west.
In hex, it's 0000=east, 4000=north, 8000=west, c000=south.
This is also know as BAMS for Binary Angle Measurement.
(4) LINEDEF that this seg goes along
(5) direction: 0 if the seg goes the same direction as the linedef it
is on, 1 if the seg goes the opposite direction. This is the
same as (0 if the seg is on the RIGHT side of the linedef) or
(1 if the seg is on the LEFT side of the linedef).
(6) offset: distance along the linedef to the start of this seg (the
vertex in field 1). The offset is in the same direction as the
seg. If field 5 is 0, then the distance is from the "start"
vertex of the linedef to the "start" vertex of the seg. If field
5 is 1, then the offset is from the "end" vertex of the linedef
to the "start" vertex of the seg. So if the seg begins at one of
the two endpoints of the linedef, this offset will be 0.

For diagonal segs, the offset distance can be obtained from the
formula DISTANCE = SQR((x2 - x1)^2 + (y2 - y1)^2). The angle can be
calculated from the inverse tangent of the dx and dy in the vertices,
multiplied to convert PI/2 radians (90 degrees) to 16384. And since
most arctan functions return a value between -(pi/2) and (pi/2),
you'll have to do some tweaking based on the sign of (x2-x1), to
account for segs that go "west".

[mmnpsrsoskl]

Biffy said:

Yeah, and some node builders will produce fewer segments than others. I think BSP has a switch or two to affect this. WARM seems to make somewhat fewer segments than some others, try that.

You can do this change with GLBSP. Quote from manual:

A node builder works like this: say you are looking at your level in
the automap or in the level editor. The node builder needs to pick a
line (stretching to infinity) that divides the whole map in two halves
(can be rough). Now cover up one half with your hand, and repeat the
process on the remaining half. The node builder keeps doing this
until the areas that remain are convex (i.e. none of the walls can
block the view of any other walls when you are inside that area).

Those infinite lines are called "partition lines", and when they cross
a linedef, the linedef has to be split. Each split piece is called a
"seg", and every split causes more segs to be created. Having fewer
segs is good: less to draw & smaller files, so partition lines are
chosen so that they minimise splits. The "-factor" value controls how
costly these splits are. Higher values cause the node builder to try
harder to avoid splits.

So, each "partition" line splits an area (or "space") of the level
into *two* smaller spaces. This is where the term "Binary Space
Partition" (BSP) comes from.

Another thing: having a good BSP tree is also important, and helps for
faster rendering & smaller files. Thus the node builder also tries to
make the BSP tree good (by making it balanced, and keeping it small).
If the "-factor" value is too high, it will care too much about the
splits, and probably make a bad BSP tree. How good the BSP tree is
can be gauged by the output line that reads:

Heights of left and right subtrees = (12,24)

Lower values are better (the BSP tree is smaller), and values that are
closer together are also better (the BSP is more balanced).

[fraggle]

DooMBoy said:

AFAIK, segment refers to a piece(s) of a given linedef. If you split a linedef, then you now have two segments, for example.

I think. I could be wrong, so don't quote me on this.

doomboy is right. Segments are used in the BSP tree structure. Its not something you usually edit in the editor.

[magikal]

See below, heh.

[magikal]

Thanks I'm a little wiser...so the best way to reduce segments?

[Fredrik]

Good news, ZDoom has support for levels with up to 65K segs now. So if you use sidedef compression, your map can be 32K lines big.

[esayeek]

Fredrik said:

Good news, ZDoom has support for levels with up to 65K segs now. So if you use sidedef compression, your map can be 32K lines big.

sidedef compression has no relationship at all to number of segs

magikal said:

Thanks I'm a little wiser...so the best way to reduce segments?

segs are indirectly related to the number of linedefs and sidedefs you have, so the only solution is to cut things down

[cph]

esayeek said:
sidedef compression has no relationship at all to number of segs

Yes, but once you solve the segs limit, sidedefs is the next to reach the magic 32k.

magikal: what actually fails when you hit the limit - editor blocking you, tools failing or the engine crashing? It would be useful to have a test level for adding 65k segs support to prboom (and bsp, which fredrik has been nagging about for ages, but should "just work" I think).

[esayeek]

cph said:

Yes, but once you solve the segs limit, sidedefs is the next to reach the magic 32k.

ahh i get it now ok so you use sidedef compression, zdoom for 64k segs, and you'll probably be able to get maybe 25k-30k linedefs.

[Erik]

holy christ, what zdoom versions support 65k segs?

[Fredrik]

Beta 33 and later.

[magikal]

cph said:

magikal: what actually fails when you hit the limit - editor blocking you, tools failing or the engine crashing?

Actually nothing yet it's just the editor telling me I've reached the limit.I haven't finished the map yet, it's not massive but there's several 3D bridges and a fair bit of detail.So I'm worried if I continue without reducing something I'll have problems.There's 700 sectors but many of them have a lot of linedefs.