Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Super Jamie

Floating lines crossing multiple sectors

Recommended Posts

I thought it was better to explain this with pictures.

Say I have a hallway, and I wish to trigger something when the player gets halfway along. I make a floating linedef and give it a special:



Now say I want to add some detailing to the hallway, like a stepped ceiling, creating multiple sectors:



I still want the trigger I had in the original image. What I usually do is make a line in the center sector, then drag the vertices of that trigger line into the surrounding sectors:



It has occurred to me that this possibly isn't such a good idea. A linedef is only supposed to have a front and back side in one sector, and here I'm dragging it across three. Whilst I haven't found any problems nodebuilding or triggering, I suspect I'm breaking engine rules and possibly causing myself a problem later down the track.

Does this not matter? Or am I better to create three separate lines with the same specials and tags, which are all in their own sector?



This of course creates the problem that a W1 linedef can be triggered multiple times, once in each sector. However, that can be solved easily enough with voodoo doll scripting.

Share this post


Link to post

I actually used overlapping lines quite a bit in some of my maps and they never seemed to cause me any problems. Though they were mostly for K2 bridges, but I would assume that it would also be acceptable to do the same for triggers as well.

Share this post


Link to post

It does matter, linedefs that cross each other are erroneous, and node builders will not be able to generate correct nodes, segs and subsectors.

DOOM's software renderer is very forgiving, but this sort of thing often causes bad glitches in OpenGL source ports

I strongly recommend avoiding this particular situation. Many uses of W1 lines are not repeatable anyway (e.g. a door that opens and stays open, or a floor that lowers to the lowest surrounding neighbor).

Share this post


Link to post

Just goes to show that it's usually not a good idea to listen to me :P. I try not to use overlapping lines very often though (mostly because I'm really picky), but in certain situations your sort of forced to. I can't recall ever doing it for a trigger line, actually. I guess it just depends on what your trying to do.

Thanks for clearing that up andrewj :)

Share this post


Link to post

Now you mention it, I had noticed Doom Builder's GL renderer doesn't seem to like when I do this. Floors sometimes disappear, visual stuff like that. I wonder what havoc it plays with actual game logic in a GL port!

W1s are usually only triggered once, though depending on sourceport I've found an opened door which gets triggered to open again can make a second opening sound, which seems kinda silly.

Depending on timing and/or how obvious it is to the player, I guess this is a situation best voodoo-scripted.

Thankyou for the advice.

Share this post


Link to post

It all depends on how the GL port works. If done properly subsector assignments for rendering (not gameplay though!) should completely ignore any line that has both sides in the same sector and always rely on other information. Without such handling self-referencing sectors will produce errors.

In GZDoom such lines won't produce any glitches. I can't say much about other ports though.

But the fact remains that they essentially produce a broken BSP that actually might have an effect during gameplay because occasionally some sector references may be incorrect.

Share this post


Link to post

If you use the error checker (F4) you will notice that Doom Builder 2 considers overlapping lines erroneous unless both lines reference the same sector on all their sides. Not sure if DB1 also does this.

Share this post


Link to post

Doom Builder 1 error checker pops up with a "Sector Not Closed" on the middle sector of my example image above.

Cool, now I don't even have to remember if I did this anywhere, just F4!

Share this post


Link to post
Graf Zahl said:

But the fact remains that they essentially produce a broken BSP that actually might have an effect during gameplay because occasionally some sector references may be incorrect.

That depends on the nodebuilder of course. The nodebuilder I've been working on for Doomsday 2.0 does not fall foul of such constructs and will always produce a valid BSP.

Share this post


Link to post
DaniJ said:

That depends on the nodebuilder of course. The nodebuilder I've been working on for Doomsday 2.0 does not fall foul of such constructs and will always produce a valid BSP.


The BSP may be valid but it is completely unpredictable in which sector any subsector touching such a line will end up. The BSP actually does not care about sectors so for building a BSP these are just normal lines like any other.

It's only the engine that assigns a real sector to a subsector so it will have to be taken care of in some way by the map loading code.

Share this post


Link to post
Graf Zahl said:

The BSP may be valid but it is completely unpredictable in which sector any subsector touching such a line will end up.

What usually happens is you get a subsector with segs from two or more different sectors. So if you must choose one of them as "the" sector, then yes the result will be unpredictable.

It doesn't bother the software renderer since it doesn't use subsectors for drawing sector floors and ceilings. Theoretically you could make a GL renderer where it also doesn't matter (and maybe that is what DaniJ has done).

Share this post


Link to post
Graf Zahl said:

The BSP may be valid but it is completely unpredictable in which sector any subsector touching such a line will end up. The BSP actually does not care about sectors so for building a BSP these are just normal lines like any other.

It's only the engine that assigns a real sector to a subsector so it will have to be taken care of in some way by the map loading code.

That is assuming of course that the nodebuilder is producing subsectors with segs from linedefs of differing sectors. Our new nodebuilder does not.

andrewj said:

Theoretically you could make a GL renderer where it also doesn't matter (and maybe that is what DaniJ has done).

Its no longer a theory :)

The first version to see the new nodebuilder (originally based on glBSP 2.24 btw) will be 1.9.0-beta7

Share this post


Link to post

How do you handle such cases?

ZDBSP creates multiple minisegs along the improper linedef to avoid having subsectors with lines from different sectors but the end result still means that there's subsectors belonging to different sectors that stand next to each other so the question which one to use for rendering must be used is still there

GZDoom never uses a sector for this that's only connected to a subsector through a 2-sided line with both sides in the same sector - and if that's all that's connected to a subsector it traverses across the partner segs until it finds something that can be used reliably.
Essentially this means that each subsector gets assigned to 2 sectors: One for gameplay and one for rendering and in cases like this they are not identical.

And in case I have to rebuild nodes I keep the original BSP around for the gameplay checks so that old WADs with rendering tricks depending on the nodebuilder's behavior don't get destroyed. A good example for this is the crane in P:AR E1M3. No matter what nodebuilder I used on that map - something always didn't work. The original nodes do though.

Unless there's real mapping errors (or rendering tricks that depend on having corrupt geometry) this has worked so far for everything I checked it with.

Share this post


Link to post
Graf Zahl said:

A good example for this is the crane in P:AR E1M3. No matter what nodebuilder I used on that map - something always didn't work. The original nodes do though.

Heh, the crane near the start of P:AR E1M1 (perhaps you meant that one?) is a test case of mine. It messes up in EDGE because the self-ref lines are above a BOOM deep water area.

My plan to get it working was this: build the BSP ignoring self-ref lines, and let the engine draw any mid-masked textures on such lines in a similar way to sprites.

Share this post


Link to post
andrewj said:

Heh, the crane near the start of P:AR E1M1 (perhaps you meant that one?)

I think he's talking about the big crane... that is in E1M3. :p

Share this post


Link to post
andrewj said:

Heh, the crane near the start of P:AR E1M1 (perhaps you meant that one?) is a test case of mine. It messes up in EDGE because the self-ref lines are above a BOOM deep water area.


Kristus is correct: I mean the big one in M3. That one contains a few overlapping sectors which wreak havoc with how the subsectors are assigned. The one in M1 is mostly clean. I don't see how this could create problems with Boom deep water. I never had problems with it in GZDoom.


My plan to get it working was this: build the BSP ignoring self-ref lines, and let the engine draw any mid-masked textures on such lines in a similar way to sprites.


But then you have to rebuild the BSP with a custom node builder. My method works with any prebuilt GL nodes.

All I'm doing is not assigning the first seg's sector but the one from the first seg not coming from a self referencing linedef. If that fails I check all neighboring subsectors and pick a sector assignment from there. I repeat that second step for all sectors until no more subsectors can be assigned to sectors. What's left then gets the sector from the first seg. After that I have sufficient information that all tricks based solely on self-referencing linedefs are properly handled - without custom nodes.

Share this post


Link to post

In Doomsday, we always opt to build are own nodes and any present in a map will always be ignored.

A GL port requires a far more stringent and correct structure. The only nodebuilder I found to produce mostly predictable results was glBSP and that is why I used it as a base.

I decided that rather than being forced to spend time attempting to analyse and validity check the nodes output from countless different nodebuilders, that with the right design, they could be rebuilt completely in the same time. Furthermore, the new nodebuilder produces a data set that includes a great deal more spacial relationship information than that found in the BSP and the subsectors.

The map representation used in Doomsday 2.0 differs considerably from DOOM. For starters, polyobjects are handled completely differently. Most other nodebuilders will attempt to "tip-toe" around them and in Doomsday this is completely unnecessary. In fact, our new nodebuilder does not produce any segs for the linedefs of a polyobject or alter the BSP in any way because of the them (linedefs of polyobjects are ignored by the nodebuilder completely).

Share this post


Link to post
Graf Zahl said:

All I'm doing is not assigning the first seg's sector but the one from the first seg not coming from a self referencing linedef. If that fails I check all neighboring subsectors and pick a sector assignment from there. I repeat that second step for all sectors until no more subsectors can be assigned to sectors.

Yeah I understand such a "floodfill" approach, and agree it is the best thing you can do without building the nodes yourself.

DaniJ said:

linedefs of polyobjects are ignored by the nodebuilder completely

I always thought that polyobjs in a GL port could just render the linedefs "directly" and let the Z buffer handle it.

Share this post


Link to post

In the end it really doesn't matter much if the actual polyobjects are handled by the node builder or not. There's nothing gained - nothing lost if you do it. They are never treated as part of the BSP anyway. All that matters is how the game engine uses them - and it just so happens that the one I build upon still uses Hexen's code to maintain them which uses them per seg.

GZDoom never renders per seg anyway because it is much slower than processing complete linedefs.

Share this post


Link to post

That is assuming you aren't caching geometry and aren't doing per-vertex lighting.

Share this post


Link to post

Even with caching you will have to do some processing multiple times. But the main deciding factor for me was that adding splitting vertices directly in the rendering pass cost almost nothing whereas having to shove several sets of data through the draw buffer for a linedef really brought performance down.

Share this post


Link to post

Clearly GZdoom and Doomsday are using very different approaches to rendering the world. As I said, whether it is more or less costly to render per linedef or per seg is completely dependant upon the architecture of the engine. In this context, the 'better' solution is the one that yields the best results for you.

With a good geometry caching scheme, it really doesn't matter if you have to do a few things multiple times for each seg along the same linedef. As the cost is up front rather than per frame, you can afford to take a bit more time.

If you are using a per-vertex lighting scheme, the "extra" geometry will produce nicer results.

Share this post


Link to post
DaniJ said:

If you are using a per-vertex lighting scheme, the "extra" geometry will produce nicer results.

Well you could automatically split long lines/segs if you want consistently nice results.

Share this post


Link to post

Yeah. I plan to subdivide the map up into much smaller regular pieces, subsectors included. I'd like to leverage hardware tessellation too, if available, however that will come later.

Share this post


Link to post

I'm pretty sure if you make the line in the center sector the W1 and the lines in the outside sectors do nothing, you shouldn't have much of a problem. It's not often people are walking around hugging the walls unless they are desperately trying to find a secret. Generally players will stick to the center of an entire hallway.

In several maps of mine a W1 line covers a short distance in a relatively large hallway but 99% of the time I activate it during playtesting unless I intentionally try to meander around it. If it's not obvious that your W1 line will activate something then I'm pretty sure your players will walk over it and activate whatever action you want achieved.

Share this post


Link to post
40oz said:

I'm pretty sure if you make the line in the center sector the W1 and the lines in the outside sectors do nothing, you shouldn't have much of a problem. It's not often people are walking around hugging the walls unless they are desperately trying to find a secret. Generally players will stick to the center of an entire hallway.

This is probably true for almost all players, there will always be one person who doesn't do what you expect and breaks the map. I'd rather try make my maps unbreakable.

Share this post


Link to post

Why not just cut the hall up into half and use the lines that seperate the sectors the lines you are using. Since you are looking at a W1 switch, if you did a lower floor quick or raise ceiling you would not have the problem of multiple door opening sounds.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×