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

UDMF - replace dummy sectors with metadata

Recommended Posts

Dummy sectors suck. They are wasted geometry that are not proper parts of the level. Their only purpose was to serve as metadata that some fancy new features relied on.

 

We don't need to do this anymore, we have an infinitely extendable and flexible text-based format now. It's an unclean hack that was only done to avoid making a new binary format that would inevitably run into limitations far sooner than later.

 

If I want to use any such thing that typically requires the use of dummy sectors, why can't I just do it as a sector property? Or, if that doesn't work for some technical reason, put it in a sort of "extradata" field instead.

 

It's 2017, not 1999. Yesteryear's trappings should be stripped away where we can. That isn't to say remove support for the established methods (obviously, compatibility with existing WADs is a must), just that it should be discouraged to use the old deprecated methods and that it should be encouraged to use the newer, cleaner standards instead.

Share this post


Link to post

What dummy sectors precisely would you want to address? Which new fields would be required?

 

A thing I could see however would be "ghost" sectors (sectors that exist and the the editor has to keep around, but that are not referenced by any sidedef, so that they are not physically present on the map).

Share this post


Link to post
17 minutes ago, Gez said:

What dummy sectors precisely would you want to address?

Any and all of them. To hell with dummy sectors in general, or at least physically present ones.

 

17 minutes ago, Gez said:

Which new fields would be required?

I can only think of one; a "ghost sector" field. On the other hand, it's probably more sensible to just stick it into the sector field, so never mind.

 

17 minutes ago, Gez said:

A thing I could see however would be "ghost" sectors (sectors that exist and the the editor has to keep around, but that are not referenced by any sidedef, so that they are not physically present on the map).

Yes, this is a good idea. Basically what I already had pictured, but you clarified it in a practical way.

Share this post


Link to post

Think of something like ZDoom's 3D floors: you can have several 3D floor in a single sector (there's no hard limit on their number) so you'd have to have several sector per sector for projecting the floor. Inversely, you several sectors can share the same 3D floor, so if the dummy sector is turned into a sector property you start having to maintain sync between every sector that has the 3D floor. Also keep in mind that properties to the 3D floor are numerous and can include things such as terrain type, sector type, etc., in addition to the basic of heights, textures, and light levels.

 

Basically for 3D floors, more sector properties instead of using a dummy sector would be all around less convenient, instead of more.

 

Then there are uses of dummy sectors for other purposes. For example you can have a bunch of contiguous dummy sectors, each joined to a real gameplay sector, and then you run a stairbuilder effect and you get disconnected stairs raising up. This trick can also be used for every effect that references neighbors (light flicker/pulse/strobe, floor/ceiling raise/lower to nearest/lowest/highest, and so on). The "more properties" alternative would also be complex. Each use can be addressed individually by an ad-hoc property (e.g. light_low, light_high for all your light flicker effects) but some will be unwieldy (stairbuilder_nextsteptag???). Anything where the mapper has to juggle with sector numbers can be assumed to be bad from a design point of view.

 

These are the reasons why I don't think it's going to be possible, or even desirable, to get rid of the "dummy sector" design paradigm. And while we can hide some, others will have to remain (any use of adjacency effects will require adjacency, which means it has to be present on the map somewhere).

Share this post


Link to post

Dummy sectors are fine, they allow for abstraction and are very versatile.

Share this post


Link to post
1 hour ago, Urthar said:

Dummy sectors are fine, they allow for abstraction and are very versatile.

They're an ugly hack created from the necessity of the time. They are indeed very versatile, and all-around useful. Having these things occupy physical space... disgusting and gross. UDMF makes it possible to create and use a better solution.

 

It's not a real concern these days, anyhow, but it'd be nice to reserve using the blockmap for actual playable areas.

 

Another idea is the way vanilla set sector sounds, it came from the middle of the bounding rectangle around the sector, IIRC. Thing is, if you were to merge it with some unseen dummy, that will make the sound go way off. If there was some kind of a way to merge "ghost sectors" with normal sectors, by the complete lack of physical presence of the dummy counterpart geometry, the sound could come from the part the player is meant to observe and use (as that is the only physically extant point of reference anymore, in this scenario), rather than the position becoming increasingly distorted depending on how far away the dummy geometry is.

 

1 hour ago, Gez said:

These are the reasons why I don't think it's going to be possible, or even desirable, to get rid of the "dummy sector" design paradigm.

Well, your "ghost sector" idea was really good, same as my concept but better execution.

 

All the things normal dummy sectors can do would be doable in a proper implementation of ghost sectors. You could define ghost lines, that have their own ghost sidedefs (sidedefs are optional for anything that doesn't use it) and that you could assign a ghost line to a ghost sector. You can't assign a ghost line to more than one ghost sector, but more than one ghost line can reference the same ghost sector.

 

*unless... you could, but only if the ghost line was considered "two sided", and even then it would only ever support two sectors, with one explicitly defined as being on the front side and the other on the back side

 

Even after that, perhaps still expose the really simple things as ad-hoc options, but only where that makes life easier and not harder.

Edited by Blastfrog

Share this post


Link to post
54 minutes ago, Blastfrog said:

It's not a real concern these days, anyhow, but it'd be nice to reserve using the blockmap for actual playable areas.

ZokumBSP, a new fork of ZenNode, allows you to flag lines to not appear in the blockmap, for this purpose. It's far less of a necessity in mapping for any port that supports UDMF, because the blockmap limit is so higher than vanilla's, but I imagine it could be implemented in ZDBSP. I also imagine Graf wouldn't want to include something with such potential for creating hacky broken maps, though.

Share this post


Link to post

Dummy sectors are a necessity. The features using them require those added sectors or they would not work. How would you do a 3D floor instead. How would you MOVE a 3D floor, or a Boom deep water sector? Without some sector in the map this simply cannot be done.

 

Share this post


Link to post
5 hours ago, Blastfrog said:

Dummy sectors suck. They are wasted geometry that are not proper parts of the level. Their only purpose was to serve as metadata that some fancy new features relied on.

 

We don't need to do this anymore, we have an infinitely extendable and flexible text-based format now. It's an unclean hack that was only done to avoid making a new binary format that would inevitably run into limitations far sooner than later.

 

If I want to use any such thing that typically requires the use of dummy sectors, why can't I just do it as a sector property? Or, if that doesn't work for some technical reason, put it in a sort of "extradata" field instead.

 

It's 2017, not 1999. Yesteryear's trappings should be stripped away where we can. That isn't to say remove support for the established methods (obviously, compatibility with existing WADs is a must), just that it should be discouraged to use the old deprecated methods and that it should be encouraged to use the newer, cleaner standards instead.

Why would I want to use more flags when I can just make a dummy sector and be done with it? Everyone knows how to use it, Everyone knows how it works, It works in every port ever, It takes like 5 seconds to make, And I can see which sectors are affected by the dummy by selecting them instead of having to hunt through sectors and hope I find the one I put flags on.

Share this post


Link to post

Here's the thing, Dummy Sectors are such a generalised tool, that I have to suspect that their full range of functionality still hasn't been discovered. As soon as you try to quantify their uses, you're limiting mappers from trying things no one's even considered yet.

Share this post


Link to post

You use dummy sectors or linedefs when you need all their properties as reference on how their target area should act like. Keep in mind that dummy sectors can be changed during the game, and their target areas must adapt as well. All this gives too much information to be comfortably expressed in a few UDMF fields.

Share this post


Link to post

Eh, dummy sectors don't cause any issues when playing. There's no reason to really remove them.

I guess you could argue that the engine still has to render the dummy sectors, etc, ect... But it's 2017 lol dummy sectors aren't going to cause any issues for players regardless of their settings, max or low.

Share this post


Link to post

the dummy sector should probably never get rendered except when noclipping, so there's frankly no effect there. Blastfrog did mention blockmap limitations, but this seems to be unlikely to be a big deal if I'm honest (how many maps fully occupy the blockmap space? is there seriously no crevice between playable area you can fit the control sector in?)

Share this post


Link to post

My two cents on this: I always place dummy sectors in physical space so they're arranged logically and easy for me to find. If this "ghost sectors" concept existed, how would I go about keeping track of them?

Share this post


Link to post
1 hour ago, InsanityBringer said:

the dummy sector should probably never get rendered except when noclipping, so there's frankly no effect there.

Everything in game is rendered, even sectors you can't see.

Share this post


Link to post

eh, source on that? everything I've read in the past indicates that things are drawn front-to-back, with 1s lines serving as clipping regions where segs won't actually get drawn beyond that. I mean I'm nowhere near an expert on this, and I guess to some degree its going to have to process everything, but if it was drawing its segs, wouldn't that just be super inefficient overdraw?

Share this post


Link to post
24 minutes ago, jdagenet said:

Everything in game is rendered, even sectors you can't see.

Definitely not!

 

Share this post


Link to post
49 minutes ago, Graf Zahl said:

Definitely not!

 

Uuuh did that change recently then?

We've been working on maps in the past that would contain lots of sectors that were raised to the ceiling/floor rather than just deleted. These same sectors would cause some players with low-end PC's to lag. Deleting the sectors would fix this lag issue for those players.

I guess just seeing one of the linedefs on the sector will then render the entire sector? Dummy sectors that the player will never psychically see aren't actually rendered? Like ones out in the void space?

Share this post


Link to post
4 minutes ago, jdagenet said:

Uuuh did that change recently then?

We've been working on maps in the past that would contain lots of sectors that were raised to the ceiling/floor rather than just deleted. These same sectors would cause some players with low-end PC's to lag. Deleting the sectors would fix this lag issue for those players.

I guess just seeing one of the linedefs on the sector will then render the entire sector? Dummy sectors that the player will never psychically see aren't actually rendered? Like ones out in the void space?

You're describing two very different things. If a 2-sided line is placed between sectors, there are circumstances where the backside will still be drawn, creating extra work for the renderer. If there are solid 1-sided walls blocking your view of a sector, it won't be drawn. It's always been that way.

Share this post


Link to post
8 minutes ago, jdagenet said:

Uuuh did that change recently then?

Isn't "not rendering the whole map at once" literally the whole point of the BSP?

Share this post


Link to post
8 minutes ago, esselfortium said:

You're describing two very different things. If a 2-sided line is placed between sectors, there are circumstances where the backside will still be drawn, creating extra work for the renderer. If there are solid 1-sided walls blocking your view of a sector, it won't be drawn. It's always been that way.

Oh how interesting, I had no idea.

See it doesn't make sense for the raised sectors to be rendering so when I found out they were lagging players I assumed every sector, regardless of vision, was taken into account.

Learn something new everyday I guess lol.

Share this post


Link to post
4 hours ago, Xaser said:

If this "ghost sectors" concept existed, how would I go about keeping track of them?

Simple. You'd have a list of them in some kind of a "manage ghost dummies" window of the editor - even better than arranging them sensibly in space, it's a literal list that you can manually organize however you want.

 

It's important to note that ghost sectors should share numbering with regular sectors, i.e. what was a dummy sector was sector 9, then it got converted to being a ghost sector, but it's still considered to be sector 9 by the map.

 

It's also important to note that there should be more than ghost sectors as well, there should be ghost linedefs and sidedefs.

Share this post


Link to post
56 minutes ago, Blastfrog said:

Simple. You'd have a list of them in some kind of a "manage ghost dummies" window of the editor - even better than arranging them sensibly in space, it's a literal list that you can manually organize however you want.

 

It's important to note that ghost sectors should share numbering with regular sectors, i.e. what was a dummy sector was sector 9, then it got converted to being a ghost sector, but it's still considered to be sector 9 by the map.

 

It's also important to note that there should be more than ghost sectors as well, there should be ghost linedefs and sidedefs.

This is an awful lot of complication being added to solve a problem that doesn't exist.

Share this post


Link to post
12 minutes ago, esselfortium said:

This is an awful lot of complication being added to solve a problem that doesn't exist.

Eh, you're probably right. Dummy sectors work just fine, I just think they're really inelegant in design and are not how id would have done things for how most source ports make use of them.

Share this post


Link to post

IMO, they're an acceptable compromise for an engine where 3D geometry isn't a native thing. Sometimes there's just no alternative to putting things "elsewhere," and the map editor itself lets me keep track of these "elsewhere"'s quite easily.

 

[Biased I guess since I'm used to this sort of thing, but eh]

Share this post


Link to post

The new effects added (by Boom and Legacy originally) needed *some* place to store extra data needed by the effects. They cleverly chose to store that extra data in structures that already existed in the Doom map format, so existing editors could expose these new effects without being modified.

 

Forward-fast to today: Yes, we now have new map formats and new editors. But, even those new formats still have all the original structures - sectors, linedefs, sidedefs, thing angles, etc. Why not keep the data where it's been for 20 years? If you convert an old map to UDMF, you want all the old effects to keep working, and they will. If you went to the trouble to add new data structures to store the extra info, you'd still have to support the old method too, which means that, you've actually make the format *more complicated*, in an effort to simplify it.

 

I do understand the motivation. Perhaps the map editor programs could have special modes that, when enabled, abstract some of those difficulties away, by automatically creating control sectors for you, configuring them with "wizard" screens, like a "Make 3D water" plugin that does the dirty work for you. Even better, if these screens could be more tightly integrated. I would like to see a map editor configuration file that defined effect wizard screens. Text boxes, dropdowns, labels, buttons...everything you'd need, with a small scripting language that manages the conversion from wizard screen to control sector creation. Bonus points if it lets you edit an already-existing effect. In this case, the map editor might want to add a special lump to your wad, just to store info about what control sectors were added via Wizard, so the wizards could edit the effects they created later on.

 

My point is that, even if we had your "ghost" sectors, or my wizards, you can't avoid having to learn the details of how the effects are created. A map author is actually at a disadvantage, if he only knows the "ghost" or "wizard" way to build an effect, cause he won't understand how effects in older maps are built.

 

Having said all that, if the game engine can determine that a control sector is never seen, it could possibly mark the sector as invisible, automatically, saving a small amount of render time. But, that's not easy to do - some control sectors double as visible sectors, so it's probably not worth pursuing.

Share this post


Link to post

And even then, some effects that can be done with control sectors depend on those sectors being able to have a neighboring sector with different properties, like 'move 3D floor to next lowest floor' or implementing some lighting effects that require an adjacent sector to work.

 

On 23.5.2017 at 5:01 AM, Blastfrog said:

I just think they're really inelegant in design and are not how id would have done things for how most source ports make use of them.

 

I guess they would have used even cruder hacks to do it. There's little about Doom's map format that justifies the term 'elegant' for its design, especially if you know how the original editor worked. Making sectors editable entities was only invented by third-party editors but it's the single biggest improvement over id's editor which was just an open invitation for gross mapping errors, like in MAP21.

 

Share this post


Link to post
12 hours ago, Graf Zahl said:

And even then, some effects that can be done with control sectors depend on those sectors being able to have a neighboring sector with different properties, like 'move 3D floor to next lowest floor' or implementing some lighting effects that require an adjacent sector to work.

 

 

I guess they would have used even cruder hacks to do it. There's little about Doom's map format that justifies the term 'elegant' for its design, especially if you know how the original editor worked. Making sectors editable entities was only invented by third-party editors but it's the single biggest improvement over id's editor which was just an open invitation for gross mapping errors, like in MAP21.

 

id did the bare minimum to get their 27, then 68 maps on the shelf. The rest is up to us.

Share this post


Link to post

I always thought that Dummy sectors were an upgraded version of Sprites of Duke Nukem 3D.

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
×