From DoomWiki.org

m (✓)
m (Slade3 new release)
Line 10: Line 10:
 
File:MAP01-omgifol0.2.png|2: via omgifol 0.2
 
File:MAP01-omgifol0.2.png|2: via omgifol 0.2
 
File:MAP01-omgifol.png|3: via omgifol [[Omgifol#cite_note-3|improved]]
 
File:MAP01-omgifol.png|3: via omgifol [[Omgifol#cite_note-3|improved]]
File:MAP01-slade3.png|4: via slade3
+
File:MAP01-slade3.png|4: via slade3 v3.1.1.1
 
</gallery>
 
</gallery>
  
Line 49: Line 49:
 
TO DO:
 
TO DO:
 
# <s>Recreate and upload all IWAD maps. I will do this soon unless someone objects.</s>
 
# <s>Recreate and upload all IWAD maps. I will do this soon unless someone objects.</s>
# <s>Contact [[Simon Judd]] to request improvement of map image generation.</s> Improvement confirmed for the next release.
+
# <s>Contact [[Simon Judd]] to request improvement of map image generation. Implemented in v3.1.1.2.</s>
 
# <s>Revive the maptabs RFC</s> and see if progress can be made towards adding spotted images (with walkthrough text to match) to all IWAD map pages.
 
# <s>Revive the maptabs RFC</s> and see if progress can be made towards adding spotted images (with walkthrough text to match) to all IWAD map pages.
  
 
Bottom line: until SLADE 3's map images are improved, the preferred wiki maps are those by omgifol (v0.2 or later)‎, IMHO. Given that it does not have a GUI, and not all regular map contributors will even read this here discussion, chances are that ragged map images will continue to be uploaded. Such is life in wiki-land. ;)
 
Bottom line: until SLADE 3's map images are improved, the preferred wiki maps are those by omgifol (v0.2 or later)‎, IMHO. Given that it does not have a GUI, and not all regular map contributors will even read this here discussion, chances are that ragged map images will continue to be uploaded. Such is life in wiki-land. ;)
 +
 +
''Edit'': As of the v3.1.1.2 release of SLADE 3, its map images look similarly crisp as omgifol's thanks to linedef sorting, and all map contributors using SLADE 3 are advised to upgrade.
  
 
==Scaling==
 
==Scaling==

Revision as of 04:17, 7 June 2016

This page discusses aspects of, and improvements for, map views. Having dabbled in PostScript map printing in the (distant) past, I have a soft spot for this topic. :) This page aims to tie together all available info that's fragmented in various talk pages (or even only hidden in some contributor's heads), and document the bits I figured out for myself. And sometimes it's little more than a brain dump.

Crispness

Two tools are commonly used to create map images for this wiki: the Omgifol drawmaps.py script and SLADE 3. Other tools appear to have been sporadically used to generate map views, e.g. MAP22-castle-of-grief.svg, No_Rest_for_the_Living_Map01.png and Lost_episodes_of_doom_e1m3.png, but it's unknown what and where they are, and they don't seem to be in active use anymore, so they are not covered here.

Omgifol‎ drawmaps.py exists in three versions. These test images illustrate the differences:

omgifol images are generated via the command-line:

# image 1 & 2:
python omg/demo/drawmaps.py doom2.wad MAP01 999 PNG
# image 3:
python omg/demo/drawmaps.py doom2.wad MAP01 1079

slade3 images are generated via the following GUI steps:

  1. Open dialog tab Edit -> Preferences -> Interface -> Colours & Theme
  2. In section "Map Image Export", set Background 'White' (default) & Opacity 255 (non-transparent)
  3. Switch to dialog tab Advanced
  4. Find the map_image_* entries, and set _thickness to 3
  5. For the test image, set _height to 1079 and _width to 999
  6. Load doom2.wad
  7. From the WAD directory, preview MAP01
  8. Use the Save Map Image button, to the left just above the preview, and Save

See also the built-in Documentation -> Tutorials -> How to Create Map Images page.

Differences

Looking closely at the full-size images, there are three visible differences. In image 1, the end points of many (gray) 2-sided linedefs appear on top of the (black) 1-sided linedefs they connect to. See for example where the diagonal steps in the starting room meet the walls. This gives a ragged look to the overall map.

In images 2 and 3, this problem is solved by drawing the black lines after all the gray ones, thanks to this sorting statement:

    # draw 1s lines after 2s lines so 1s lines are never obscured
    edit.linedefs.sort(lambda a, b: cmp(not a.two_sided, not b.two_sided))

The result is a clean and crisp map image.

Image 1 is part of the very first batches of map uploads by Fredrik (author of Omgifol‎) for the UDoom, Doom2, Evilution & Plutonia IWADs in January 2005 (some superseded by Ryan W, see below). Source code of that pre-0.2 version of omgifol is not available, but most likely the sorting statement was not yet present then. It's unknown how many maps have been uploaded using this version, but assuming that v0.2 was the first public version (released in May 2005), any maps uploaded by anyone since then will likely be crisp.

Image 4, however, has the same ragged look as image 1, and therefore SLADE 3 probably does not sort the linedefs before drawing.

IMO the map pages of the official IWADs serve as "reference" for how all map pages could (eventually) look. Therefore they should have crisp map images, with the added benefit of distinguishing Doom Wiki more from its Wikia origin. Caveat is that the E1M*, E2M1-E2M5, E2M9 & E4M1 images use walkthrough spots added by Ryan W, so let's defer those for now. This is related to the marked spots discussion and maptabs RFC; see its demonstration.

TO DO:

  1. Recreate and upload all IWAD maps. I will do this soon unless someone objects.
  2. Contact Simon Judd to request improvement of map image generation. Implemented in v3.1.1.2.
  3. Revive the maptabs RFC and see if progress can be made towards adding spotted images (with walkthrough text to match) to all IWAD map pages.

Bottom line: until SLADE 3's map images are improved, the preferred wiki maps are those by omgifol (v0.2 or later)‎, IMHO. Given that it does not have a GUI, and not all regular map contributors will even read this here discussion, chances are that ragged map images will continue to be uploaded. Such is life in wiki-land. ;)

Edit: As of the v3.1.1.2 release of SLADE 3, its map images look similarly crisp as omgifol's thanks to linedef sorting, and all map contributors using SLADE 3 are advised to upgrade.

Scaling

The second visible difference, between the omgifol versions, is that some lines change very subtly. The scaling computations changed from v0.2 to the improved version, probably resulting in small rounding differences in placing the vertexes. And the original images were likely done on a 32-bit platform while my test images are done on 64-bit, also resulting in rounding differences.

The third difference, between omgifol and slade3 images, is that the former reserves a 4-pixel border while in the latter this is about 25-26 pixels. That's a matter of style. Neither difference is very interesting, so enough about these.

More relevant is the question of what a useful scale for a wiki-suitable map image is, in relation to the map's overall size.

File sizes

First, however, the file size itself depends on the tool: the above omgifol test images (since v0.2) are 17 KB, the slade3 one is 68 KB. Even accounting for omgifol using 24-bit PNG without alpha channel (transparency) and slade3 32-bit with alpha, this factor 4.0 increase seems steep. For bigger maps and images, the difference is likely proportional.

Image file size matters in general, both for websites serving them (traffic costs, server load) and for users downloading them (time), so omgifol images are clearly preferable, IMHO. But to Doom Wiki, it is of no consequence.

Controlling scale

Omgifol drawmaps through v0.2 takes its pixel-size parameter to be the required width, and the height is calculated proportionally. That's why portrait-oriented maps (e.g. MAP32, 1.8M px2) can end up being significantly larger than landscape ones (e.g. MAP03, 0.67M px2) at identical width. The improved omgifol version applies its pixel-size parameter to the largest of either width or height, making for smaller, narrower landscape images (e.g. MM2_MAP20). This is why in the above command-line for image 3, 1079 was used to arrive at the same dimensions as images 1 & 2.

SLADE 3 allows separate definitions of width and height in pixels (positive numbers), shown in step #5 above to match omgifol's test image dimensions, while negative values are taken to be the scale between map units and image dimensions. E.g. setting both to -4 for MAP01 produces a 844x912 px image. That's flexible and useful, although carelessly setting fixed dimensions without regard for the map's orientation can result in excess whitespace (e.g. D2TWID_MAP33), as does setting width and height to different scale values. Also, SLADE 3 does allow changing line thickness, while Omgifol does not.

Factors influencing the appearance of map images are:

  • map dimensions versus image dimensions, i.e. the scale
  • overall image dimensions (which affects file size, preferably kept below 250 KB)
  • line thickness versus map dimensions
  • level of detail in the map (e.g. large numbers of 2-sided linedefs)
  • whether monster caches & control sectors are edited out before generating an image

A large image of a small map like Fava_Beans_E1M1 seems excessive but is otherwise nice and clean. Conversely however, small images of big maps (e.g. 50shades_MAP06 & Breach) are, frankly, useless as many lines simply blur together. It's impossible to find one's way around them in tandem with a textual walkthrough. A large image helps a lot to understand the lay of the land (e.g. E1M8B), or compare Sunlust_MAP10 versus Sunlust_MAP10 (talk).

Line thickness should be more than 1 pixel or some lines will disappear when the map is scaled down to a thumb image next to a walkthrough. Omgifol always uses 3-pixel lines while the SLADE 3 default is 1, hence the adjustment in step #4 above, and while some experimentation with other values can be interesting, 3 is usually fine.

Lastly, editing out parts of the map that cannot be accessed by the player, such as monster caches and control sectors, affects the scale and dimensions with which the image is subsequently generated. For example, the 1000x917 px image of the edited Cchest3_MAP23 becomes a 1258x917 px image (trust me) of the original map when adjusting for the same height. The visual appearance is indeed different, but this isn't problematic unless the trimmed sectors are way outside the regular map area. And map editing is, of course, time consuming if all one wants is a quick map. :)

Useful scale

With all that covered, back to the original question: what is a useful scale, especially for a multi-map series? If all maps in series (e.g. an IWAD) are rendered at the same scale, the viewer immediately gets a good idea of the size differences between those maps. While SLADE 3 allows setting scales, it is not convenient to generate an entire batch of map images via the GUI. So I updated the Omgifol drawmaps script to accept an optional scale parameter as well, and apply that to all generated maps.

After some experimentation the value 4.0 gives acceptable results for the four official IWADs. A factor of 4.5 would also work, but SLADE 3 accepts only integer scale values, so let's stick to that. However, a fixed scale like that can result in impractically large images for really expansive maps, such as the outdoor levels in the IWADs, and modern maps for limit-removing ports (e.g. Plasmaplant).

To get a feel for this problem, I generated the four IWADs' maps with scale 4.0:

Level Ult.Doom Level Doom II Evilution Plutonia
E1M1
1152 x 712
MAP01
852 x 920
440 x 532
1244 x 944
E1M2
1336 x 984
MAP02
480 x 484
869 x 669
1084 x 997
E1M3
1064 x 772
MAP03
754 x 504
943 x 1088
996 x 1008
E1M4
938 x 704
MAP04
522 x 424
1250 x 928
752 x 916
E1M5
1000 x 816
MAP05
792 x 536
900 x 916
1120 x 1112
E1M6
1452 x 1200
MAP06
960 x 648
924 x 768
1128 x 1064
E1M7
1016 x 866
MAP07
600 x 504
1816 x 1096
627 x 1011
E1M8
1662 x 1792
MAP08
984 x 952
1768 x 1306
1064 x 764
E1M9
856 x 808
MAP09
1086 x 1020
1004 x 760
1092 x 1208
E2M1
652 x 504
MAP10
1056 x 1064
486 x 664
744 x 808
E2M2
808 x 1304
MAP11
904 x 724
1048 x 960
784 x 1200
E2M3
896 x 638
MAP12
984 x 1112
1888 x 1720
832 x 848
E2M4
984 x 952
MAP13
800 x 1176
1348 x 1904
970 x 694
E2M5
1080 x 936
MAP14
984 x 888
1224 x 1026
752 x 792
E2M6
832 x 1258
MAP15
1104 x 1838
1204 x 1258
1032 x 1088
E2M7
1000 x 728
MAP16
1208 x 1224
1568 x 1008
888 x 936
E2M8
792 x 1272
MAP17
848 x 842
1040 x 816
848 x 616
E2M9
904 x 488
MAP18
1256 x 1134
1776 x 1784
968 x 944
E3M1
584 x 1096
MAP19
1400 x 1512
1420 x 1680
984 x 640
E3M2
726 x 1096
MAP20
1304 x 1580
3663 x 2469
848 x 832
E3M3
888 x 760
MAP21
880 x 746
3976 x 1960
704 x 768
E3M4
1048 x 958
MAP22
588 x 480
2250 x 1563
1270 x 958
E3M5
1208 x 1164
MAP23
1102 x 1278
868 x 1332
952 x 1256
E3M6
1704 x 1706
MAP24
1512 x 1340
936 x 766
880 x 800
E3M7
936 x 968
MAP25
1038 x 1808
1824 x 1256
1083 x 1084
E3M8
936 x 1006
MAP26
1154 x 800
1448 x 1264
1546 x 884
E3M9
1418 x 1464
MAP27
976 x 1128
3618 x 2604
1024 x 1168
E4M1
552 x 280
MAP28
1122 x 1262
1528 x 1024
1976 x 2000
E4M2
558 x 670
MAP29
1212 x 1160
1800 x 1776
1640 x 2024
E4M3
1208 x 1112
MAP30
682 x 700
2656 x 1064
1240 x 1120
E4M4
716 x 632
MAP31
2194 x 1800
2616 x 2392
812 x 924
E4M5
1008 x 868
MAP32
1000 x 1800
1092 x 2448
1360 x 1048
E4M6
1106 x 730
E4M7
776 x 976
E4M8
928 x 1146
E4M9
582 x 1152
>= 1600
2
4
15
2

In today's era of large monitors, an image with a maximum dimension (height and/or, especially, width) of 1600 pixels seems (IMHO) of acceptable size for displaying in a browser without excessive scrolling around at 100% scaling. As indicated by italics in the table, only a few maps in most IWADs exceed that dimension. TNT: Evilution is notable however for almost half its maps being (very) expansive. And a modern level like the aforementioned Plasmaplant would be 2801 x 3399 pixels at scale 4.0, too. As rendered, its 2060 x 2500 dimensions correspond to scale 5.44 instead, but an even larger scale factor to bring its height (closer) to 1600 would blur together too many of the 2-sided linedefs.

So a mechanism is needed to keep large maps down to acceptable image dimensions. That's actually simple: fall back on the already specified maximum dimension for the largest of width and height. Limiting the above expansive maps to 1600 pixels results in the following new dimensions, with the effective scale added in italics:

Level Ult.Doom Level Doom II Evilution Plutonia
E1M7 MAP07
1600 x 966
4.54
E1M8
1483 x 1600
4.48
MAP08
1600 x 1182
4.42
E2M3 MAP12
1600 x 1457
4.72
E2M4 MAP13
1133 x 1600
4.76
E2M6 MAP15
961 x 1600
4.60
E2M9 MAP18
1593 x 1600
4.46
E3M1 MAP19
1352 x 1600
4.20
E3M2 MAP20
1600 x 1079
9.18
E3M3 MAP21
1600 x 791
9.97
E3M4 MAP22
1600 x 1112
5.63
E3M6
1598 x 1600
4.27
MAP24
E3M7 MAP25
918 x 1600
4.52
1600 x 1102
4.56
E3M9 MAP27
1600 x 1152
9.07
E4M1 MAP28
1580 x 1600
5.01
E4M2 MAP29
1600 x 1578
4.50
1296 x 1600
5.07
E4M3 MAP30
1600 x 642
6.65
E4M4 MAP31
1600 x 1313
5.49
1600 x 1463
6.55
E4M5 MAP32
889 x 1600
4.50
715 x 1600
6.13

Most of the new scale factors are not significantly larger than the default, with the exception of Evilution's MAP20, MAP21 and MAP27.

Conclusions

Scale 4.0 (for Omgifol drawmaps) or -4 (for SLADE 3) is the best scale to render the vast majority of regularly-sized maps, and especially useful when generating a series of maps so the viewer gets a good feel of the size differences between them.

Limiting the largest dimension (width and/or height) to 1600 pixels for larger maps is an acceptable compromise. With Omgifol that's handled automatically, but setting a fixed pixel limit for one dimension in SLADE 3 requires adjusting the other dimension such that little excess whitespace results, which can take some experimentation.

For modern, expansive maps with a great level of architectural detail, a larger dimension limit such as 2000-2500 pixels may need to be chosen to prevent lines blurring together. Line thickness should be 3 (in SLADE 3, already default in Omgifol).

The drawmaps commands to generate the IWADs' maps thus become:

python omg/demo/drawmaps.py DOOM.WAD E?M? 1600 4.0
python omg/demo/drawmaps.py DOOM2.WAD MAP* 1600 4.0
# same for TNT.WAD & PLUTONIA.WAD

The current drawmaps script with scale support can be downloaded from my homepage. This version also offers verbose logging of the actual scale and dimensions used for each map if the -v option is specified. This feature provided the data for the above tables.

Lastly, if no scale is specified and multiple maps are generated, then verbose logging will include the average scale used to draw those maps within the specified (or default) size.