Segments

ok I ran into a segs problem here. I have a fake floor (with a lot of two-sided-linedefs to emulate a grid). the sector is perfectly closed.

when I try to build the nodes with zennode, though, it gives me a "too many SEGS!!!" error. I played around a bit and it obviously has something to do with the number of two-sided-lindefs. I also tried to split up the grid into three seperate sectors and it worked for a while but now as I'm adding detail to the (sourrounding) sectors, I get the error again. someone know exactly what is causing the segs count to incease?

I also wondered what node builders are capable of ignoring the segs cound as zdoom obviously has upped the max?? any help is greatly appreciated !! ;)

whee, by naming the thread Segments. you revived a thread from over a year ago heh. I split it, should be good now.

I believe at the moment the only nodes builder that supports large amounts of segs is deepbsp, and the only port that supports said segs is zdoom. That said you could also use zdoom's internal builder in the latest releases of 2.0 (http://zdoom.notgod.com/lars, grab the top cab file) which only takes a few seconds to build nodes even on insanely large maps (I forget the exact time, but vrack2 copied over three times was done in an acceptable amount of time, though I haven't tried that myself).

Builders like zennode, warm, bsp etc don't support large amounts of sidedefs and segs at least not to my knowledge.

The limit is determined by the internal format. NODES uses the high order bit to determine if it's a node or subsector. That leaves NODES at 32k (which is actually enough). But then that means the largest subsector is only 32k -and that's not enough. So although DeePBSP does make nodes successfully, they can't be used because the format still has to be the same.

I had a discussion with Randy a few months ago (?) about changing this and the limits in general. So the limit for a level with DeePsea and ZDOOM is 64k linedefs, 64k sidedefs and 64 vertices. This is the limit of the DOOM format - this is frikken huge compared to anything out there now.

DeePsea was modified to let you make HUGE levels. If Fred approves, I can post a level that we used to test this - it's VRACK2 triplicated. The number of SEGS here is OVER 64k, since that's one of the first things Randy ran into. IOW, ZDOOM goes over 64k internally. This level takes some time to load (15 seconds or longer + the node build)- so hold on if you have an older machine. Or I can take some other level and make it HUGE - or maybe combine a few with some "connectors" to make it more interesting:) Depends on interest.

The other DeePsea modification to support huge levels was to save a level with -0- NODES - this automatically forces ZDOOM to make nodes. Then also a -0- REJECT and -0- BLOCKMAP. None of those are required with ZDOOM and make for a huge file size difference.

I released a map some months ago in which I hit the segment limit, I couldn't build any further as a result and ended up modifying the map to be able to finish it. I did post asking if there was any way around this or if there was a way to reduce segs by any simple means with no real result....magikal.supanet.com/cata.zip]Catastrophe. Could I have got around this Deep?

thnx alot for all the info cyb and deep!! I got it to work with deepbsp.

one thing about zdoom internal notesbuilding, though. it looks like zdoom is not rebuilding the reject map? at least it looks like it as I'm able to walk through (impassible) walls and some player-use-lines are not triggerable. when I build reject/nodes with deep its all working perfecty, though.

magikal... uhm shit. sorry to hear that. I remember running into vanilla doom limites a few years ago and it was a mayor pain in the ass ;) maybe you didn't get any proper reply on your request as deep/randy had not decided on increasing the segs limits at that time. well - now go make another map thats even bigger and forget about the old one (which one was it btw?)

magikal said:

I released a map some months ago in which I hit the segment limit, I couldn't build any further as a result and ended up modifying the map to be able to finish it. I did post asking if there was any way around this or if there was a way to reduce segs by any simple means with no real result....magikal.supanet.com/cata.zip]Catastrophe. Could I have got around this Deep?

Yes you can play that level with the new ZDOOM (2.0.xx). Might be best if you -0- save the NODES lump. IOW, this lumps has to be -0- length in size. However, there may be a problem with ZDOOM's internal code (assuming no mistakes in the level - I didn't verify if the errors were deliberate design choices or real mistakes).

I did a quick play test in ZDOOM using DeePBSP and internal. ZDOOM made a mistake on the Y bridge vs DeePBSP, so assuming there's not some mistake in the level, this is something of interest to Randy. You can test using +gennodes 1 to force ZDOOM to build noes.

DeePBSP worked ok in that area, but that's probably because I didn't go to the area that might not look ok using DeePBSP nodes (assuming it's visible).

Pretty interesting level - I think that's the most bridging I've ever seen:)

guru said:

thnx alot for all the info cyb and deep!! I got it to work with deepbsp.... one thing about zdoom internal notesbuilding, though. it looks like zdoom is not rebuilding the reject map?

DeePBSP will build it, but any amount over 32k may not display correctly if it happens to be "inside" the level where you can see it.

ZDOOM should work - there could be a level mistake causing this - not ZDOOM? If you are sure there are no level mistakes, try saving with -0- nodes, -0- reject (this is just for enemies though) and -0- blockmap, since that's something else that can go over the limit and again requires an internal format change. ZDOOM has all of these covered.

If the level still fails, then you might want to send it to Randy. It's hard to test all the possible combo's people come up with when doing nodes.

ok I'll play aroudn with that a little and then go bugging randy ;)

I reread what I wrote and realized that maybe a little more explanation might help, plus some more "why" detail since I've seen some statements in the past that did not accurately state how the SSECTOR and SEGS limits are reached.

First, what I mean is that if the SSECTORS lump go over 32,767 entries, then the DeePBSP nodes won't work (you may have to get to the area to notice, since it may load ok). The cata.wad is actually ok in this regard.

It's OK for the SEGS to go up to 65536, although only ZDOOM supports this for now. If ZDOOM builds the nodes, you can go over this - although as I noted above, I think there might be some changes required by Randy in either case.

These new limits actually supports a larger level than any level made (just ZDOOM though, since most other ports barf at SEGS over 32,767 - BOOMSDAY works since I was working with GRAHAM on this subject to modify GLBSP).

How big is the largest level for DeePBSP? That's where an explanation is in order since it depends on how the level is constructed. On the one hand, this could be a level with 30,000 linedefs -IF- you don't use too many angled lines.

IOW, although the number of linedefs is a good approximation, it's the number of angled lines that has a BIG influence on the final number.

The level posted above (cata.wad) is 11,700 linedefs (small in the context of 30,000) but it has gobs of angled lines (that's just how it's designed). So it ends up creating 20,035 SSECTORS and 33,927 SEGS. By comparison, VRACK2 is 12,441 linedefs, yet has only 8028 SSECTORS and 24,516 SEGS. I think you can see my point.

So the goal to make efficient levels and large levels that play within the limits is to make sure that lines are straight where possible. Eliminate those lines that are off by a few units from perfectly vertical or horizontal. I find these fairly often in levels. These are almost always by accident (not realizing that it makes a difference).

Make these slightly off lines straight and you get a level that plays better plus you get more SSECTOR and SEGS breathing room for all the ports.

yikes. thats what I call a comprehensive post. oh and a usefull, too.

I played through catastrophe last night (tough one hehe) and I did realize quite a slowdown in the big lava hall. the way I understood your post this is not mayorly a result from the many two-sided lines but rather from the angled ones. as the level I'm working on has a lot of prometeus doom1 style areas I should be able to keep the angled lines count rather low. I suppose the problem zennode had was not about the level segs count but rather about the count inside one sector. well doesn't matter anyway as I'm going for deepbsp from now on. great tool there deep. it's amazingly fast! DEU - well ZETH - is still the level editor of my choice, though. silly nostalgic me I suppose ;)

The reason a lot of angled lines are used is because the light shines differently on straight lines (horizontal and vertical) and makes them stand out from the others. (hence angled lines are used in rocky/natural type environments)

Thankfully, the evenlighting feature in ZDoom gets rid of this problem.

Thanks Deep for such a comprehesive explanation, that explains all. I wanted the wad to be playable with Boom and Legacy so I did cut the size a little to bring it under the seg limit, it just meant one or two areas weren't as detailed as they would've been, I was happy with the result.
Thanks for playing through the map Guru, I hope you enjoyed it and yes it is tough one. There's a lmp at my page on a slightly earlier version (small cosmetic difference) under misc if you're interested. Yes there can be slowdown in that final area on even reasonable comps but it plays with no slow down on my latest machine which is pretty quick.:)
Btw I'm up to 15000 linedefs on my latest map.