Post Your Doom Picture (Part 2)

[scifista42]

I almost forgot about the automap - good, then. Maybe all the multiple sectors and 2-sided linedefs inside those islands are unnecessary, though (specifically due to node building - many of practically useless nodes will be created and bloat up + complicate the map's node structure), and making each island consist of a single sector would suffice.

[Mechadon]

Amoeba Doom?

[dobu gabu maru]

scifista42 said:

Maybe all the multiple sectors and 2-sided linedefs inside those islands are unnecessary, though (specifically due to node building - many of practically useless nodes will be created and bloat up + complicate the map's node structure), and making each island consist of a single sector would suffice.

I considered that, but what it boils down to is an aesthetic choice—I deliberately added the interior detail because it makes the non-traversable parts of the automap look nicer. True, it does unintentionally add to the sector count, but I've always been more concerned with visual design over efficiency.

[Empyre]

How about joining all the unreachable sectors of the same height into one sector, and doing the same for each height?

[Avoozl]

dobu gabu maru said:

http://i.imgur.com/2Cofnuz.jpg

Trying out some curvy curves #thanksRibbiks

I have no words to describe this awesome sight.

[Dragonfly]

Delicious shots recently guys!

Empyre said:

How about joining all the unreachable sectors of the same height into one sector, and doing the same for each height?

I was about to suggest the same. This is good practice to do throughout every map where possible. I try to do this, but admittedly sometimes say 'fuck it, can't be bothered' as it can become immensely tedious.

[Urthar]

Shamblers and Archviles anyone?



I got permission from Skiffy to use his updated Shambler mdl to generate the sprites, still needs a lot of tweaking.

[snapshot]

Shambler don't hurt me .

[scifista42]

Empyre said:

How about joining all the unreachable sectors of the same height into one sector, and doing the same for each height?

Dragonfly said:

I was about to suggest the same. This is good practice to do throughout every map where possible.

It helps reducing the size of SECTORS lump and of REJECT table (if the map even has REJECT), which saves file size. But it doesn't help simplifying node structure at all, so that rendering performance and probability of node building errors remain the same as without joining identical sectors.

[Dragonfly]

I remember quite a few years back I built a deathmatch map which had a 'grated ceiling' effect drawn with sectors. Each hole in the grate (approx 1000+?) was an individual sector. Some friends with weaker computers were getting a very, very low frame rate when testing the map with me.

I later merged the sectors and as if my magic, they had a lag free experience thereafter.

[baja blast rd.]

I wonder sometimes if some mappers forgo the simplest of merges not because they don't think of it but rather to get an ultra-high sector count, because, like, Mechadon has a map with like five million sectors and it won a Cacoward and your mom really likes it. Goodhart's law meet Doom mapping. I know this happens, but I'm not sure anyone would admit to it. I personally merge sectors for ease of editing nearly all the time -- whenever it is not a pain elemental to do so.

[scifista42]

Rendering (as in traversing the BSP tree and drawing segs + planes) couldn't have been sped up by mere joining sectors (assuming all linedefs on the boundary of 2 different sectors stayed intact and still on the boundary of 2 different sectors after the joining). Something else than rendering must have been sped up - possibly the decreased memory usage (for sectors and REJECT in the engine's/computer's memory) alone improved performance of read/write-memory operations (a computer-architecture-specific issue, not Doom-engine-specific one), or possibly the decreased amount of sectors improved performance of network communication (though I don't know how) or of certain physics checks (for example when teleportation occurs, the engine checks all individual sectors for the presence of a teleport destination, and less sectors means that it's faster).

[Rayziik]

The last three or four maps I've made had large sector counts (2000+) and being in a spot where you can view a large portion of them at the same time was causing considerable game slowdown. After joining as many sectors as possible (one map went from ~2000 to ~700) performance increased to a reliable and playable state.

That being said, I wonder if there is a utility if some sort that will auto optimize a map by joining as many sectors as possible that share identical properties... Although I guess that it would only work for limit removing or greater maps?

@Urthar: Ooo a shambler in doom? Sounds frighteningly wonderful

[baja blast rd.]

Pop quiz time. This is from a speedmap of mine, which was designed to be compatible with doom2.wad's DEMO1 lump. Can you identify what specific element makes this scene a perfect example of great aesthetic design, without which the whole thing would fall apart?

[scifista42]

Rayzik said:

The last three or four maps I've made had large sector counts (2000+) and being in a spot where you can view a large portion of them at the same time was causing considerable game slowdown. After joining as many sectors as possible (one map went from ~2000 to ~700) performance increased to a reliable and playable state.

Are you sure that the slowdown only happened when you viewed the sectors, and not just all the time, even while being out of the area or while looking away or while having full automap open?

Rayzik said:

That being said, I wonder if there is a utility if some sort that will auto optimize a map by joining as many sectors as possible that share identical properties...

The problems are with 1) moving sectors, 2) untagged raising stairs, 3) sound propagation, 4) sectors with action linedefs on their sides (possibly affecting the sector via tag 0), 5) the possibility of changing such linedef's actions via ZDoom's SetLineSpecial function (therefore affecting sectors that they couldn't affect originally), 6) unintuitiveness of further editing the map after this auto-joining procedure was already run on it, etc.

Rayzik said:

Although I guess that it would only work for limit removing or greater maps?

Why do you think so?

[Crunchynut44]

@rdwpa: I can't help but feel as though the map looks, upside down?

[baja blast rd.]

Spoiler

It's the crates, lurking menacingly in the shadows. :)

[scifista42]

Spoiler

I had noticed the crates but I didn't give them that much of a significance. :) My guess would have been the lighting.

[Angry Saint]

rdwpa said:

Pop quiz time. This is from a speedmap of mine, which was designed to be compatible with doom2.wad's DEMO1 lump. Can you identify what specific element makes this scene a perfect example of great aesthetic design, without which the whole thing would fall apart?

http://i.imgur.com/evkt9cQ.jpg

I wouldnt' define it as "great aesthetic design", but this is obviously subjective. I think it displays good aesthetic coherence because it is all curved lines and green colour, but I feel it is still missing something, for example some variation like stright lines (metal, brick) and other colours (like red), which would make in my eyes the picture more "complete".

But as I said, this is obviously subjective.

[baja blast rd.]

Spoiler

That was (pretty obviously) not a serious claim.

edit: Although I honestly expected someone like Maes to miss that. :)

But in all seriousness, I am surprised it turned out so well with only ~15 minutes of scribbling.

[Dragonfly]

scifista42 said:

6) unintuitiveness of further editing the map after this auto-joining procedure was already run on it, etc.

Some good reasons. This above one though can easily be mitigated by simply using the Make Sector tool in GZDoom Builder.

I also imagine it being possible to analyze the map for any of those given circumstances before applying the merges, but from the perspective of whoever would build this editor feature, it's an incredibly low priority for the amount of work needed that it'll probably never happen!




As for rdwpa's popquiz, I'd go with the contrast. Flatten out the lighting and that would look very, very boring. The colour coordination is also a factor here, as well as the scene's noticeable use of height variation in both the floor and ceiling. Also, that demo is so damn cool! I think I'll have to try that kinda challenge out sometime.

[baja blast rd.]

Dragonfly said:

Rayzik's

First he got all the praise for (elaborating on) the fake 3D door idea I came up with, now people are attributing him my posts. :O

[Rayziik]

rdwpa said:

First he got all the praise for (elaborating on) the fake 3D door idea I came up with, now people are attributing him my posts. :O

C'mon, everyone knows all of us with an 'r' at the start of our names are really just the same person :P

scifista42 said:

Are you sure that the slowdown only happened when you viewed the sectors, and not just all the time, even while being out of the area or while looking away or while having full automap open?

Yea of course that's the only time it happens, but viewing the sectors while playing the map is highly likely so it's still an issue.

The problems are...

All good points. The moving sectors bit maybe only in specific scenarios, given the connected highs/lows, but I usually use control sectors to dictate heights. (another issue would be control sectors disappearing now that I think about it)

I suppose doing it manually is the best idea, although I would hold the position that 0-tagged switch linedefs are typically a mapping error.

Why do you think so?

Aren't there issues with bounding box sizes for moving sectors in vanilla? As far as I have experienced, -complevel 09 doesn't have these issues.


Alright less babble more pictures!

[Dragonfly]

rdwpa said:

First he got all the praise for (elaborating on) the fake 3D door idea I came up with, now people are attributing him my posts. :O

Shit, sorry! I am the dumbs. Also all these anime avatars blur into one for me it seems. ;D

[Crunchynut44]

Bless DB2's curve tool!

[dobu gabu maru]

^ Is that a pipe border on those wood supports? If so, brilliant addition!

Dragonfly said:

I was about to suggest the same. This is good practice to do throughout every map where possible.

Yup, I've been adhering to this technique for years. Turns designing into less of a chore when you can select all sectors with a single click.

[Memfis]

Getting somewhere with this. Mostly need to do some major work on the left.

[yakfak]

don't get hung up on where the light actually comes from
if I was more focused on stuff like that then my mapping style would be limited to recreating bad versions of toxic touch (irony)

[Fonze]

Sandy would be super jelly of those slime ceilings ;D

Can't wait for the next zzzv map

[an_mutt]

returning to some Return to Necropolis mapping tonight:



No in-game shots, because no texturing has been done yet. Absolutely not looking forward to doing the shadows for this map!