Feature suggestion for MBF21: Colourmap Transfer Line

[Chookum]

I was chattering with someone and showing some things off when they mentioned that I had some colour maps in my WAD (which is -complevel 9) that hadn't been used. I explained that I'd tried to get them working but found the juggling of fake sectors wrapped over the colourmap to be a chore, due to a different tag and line and fake sector being necessary for every permutation of floor and ceiling height in a room without leading to visual oddity, and perish the thought if geometry begins moving around too since the fake sectors have to move with the real thing.

 

I begun to realise that I haven't seen colourmaps used in wads (especially in contemporary mapping), and figured the only thing standing in their way was the ease of implementation. Call it the amateurish rush to see a finished product instead of hacking away at every which line, sector, and voodoo trickery is necessary to get the effect working in conjunction with elaborate and moving geometry, but I believe it doesn't have to be this way now that demo-able Vanilla+ Dooming is getting modernised.

 

My suggestion is thus if MBF21 is going to receive future updates: A colourmap transfer line, similar to linedef type 271/272 (sky transfer/inverted sky transfer) which transfers a colourmap selected by the front-facing upper texture to all tagged sectors without the hassle of juggling 242's fake sector. Perhaps use number 273 for it since it's a stone's throw away from the sky transfers.

 

Thank you for reading.

[esselfortium]

Great idea.

[HavoX]

Seconded.

[T.Will]

I support this idea.

[NinjaDelphox]

This an amazing idea

[Wavy]

I actually suggested something similar in this thread:

 

I still vouch for it :p

Edited February 10, 2022 by Wavy

[Redneckerz]

Anything that simplifies usage of a underutilized feature like colormaps is a win.

[xX_Lol6_Xx]

Sounds good

[JXC]

What about colored lighting?

[Graf Zahl]

7 hours ago, Chookum said:

 Perhaps use number 273 for it since it's a stone's throw away from the sky transfers.

 

If you want cross port compatibility, all linedefs below 1024 should be considered taken. Several existing ports already use the range for different purposes.

MBF already defines a few with 1024 on. Would be bad if neither the ZDoom family nor Eternity could use the feature...

 

That said, I'm not really convinced that colormap transfer is really such a good idea. Because...

 

1 hour ago, JXC said:

What about colored lighting?

 

It might be a lot more useful to do it like ZDoom did for its software renderer: Let the sector have an RGB color and create a colormap from that on the fly - hardware renderers can that use the RGB value directly without creating any lookup tables or having to guess a proper color from the colormap. The code is all there and despite being C++ shouldn't be too much of an issue to be backported. Being able to define an actual color is a lot more editing friendly than requiring to ship a fully pre-constructed colormap file for each needed color.

 

Let's also not forget that Boom's colormap feature is a bit weird. Instead of colorizing the tagged sector, it colorizes the entire view when the viewer is in that sector, which limits the usefulness quite a bit.

[GoneAway]

I wouldn't say it limits its usefulness, but rather that it is a completely different use case / feature. Isn't it for effects like being "under water" or maybe in a contaminated room?

 

(This is to Graf's point, not the proposal in general)

Edited February 10, 2022 by kraflab

[ChopBlock223]

6 hours ago, Graf Zahl said:

Let's also not forget that Boom's colormap feature is a bit weird. Instead of colorizing the tagged sector, it colorizes the entire view when the viewer is in that sector, which limits the usefulness quite a bit.

Sure, that is weird, but it has its uses too. It's rare, but I last saw it in HFFM's Heart Attack level (a kind of map I didn't realize could even be done in Boom), so it still sees use, even if most people avoid the hassle of trying to use the effect for less complicated ventures than that.

 

An easier to use colornap feature, along with actual colored sector lighting, Midway style, would both be good and useful.

I'm for either, if doable.

 

[Arsinikk]

I would like to weigh in to this since I've recently made a map that's used an altered colourmap section.

 

@Graf Zahl The problem with using a different colourmap for a section is that it is not just an RGB coloured section. In a map I recently made, I used a colourmap in a library to change all the colours except green and red to be black and white, with the addition of changing the green colours to purple instead. In addition my red colour is bright visible in dark areas, and this is all because I used an altered colourmap and not just an RGB coloured sector. What you are talking about sounds like the coloured lighting from Doom 64 or like the linedef action 282 used in Eternal's Hellground (that's in fact a Doom Legacy linedef action). Don't get me wrong, I love Doom 64 lighting, but it's very different from the creativity that a colourmap can provide.

 

I have attached a video of the section of the map that uses an altered colourmap. (in addition, the second half of the vid shows how GZDoom's hardware renderer can't render the colourmap section correctly)

 

 

A special action like this for MBF21 would be very interesting to me, because doing fake floors for a section of a map quickly becomes very complicated and confusing for areas with multiple floor/ceiling heights. Also using different flats for the floor / ceiling gets even more complicated as sometimes they get ignored.

 

The only thing that concerns me / intrigues me is how this linedef would be implemented. Currently, when the player is in the fake floor/celing sector, everything in the players view is covered by that colourmap... even the sectors outside the colourmap affected section. In addition, currently a midtexture is required to transition the colourmap or else a HOM results. I'm wondering if the linedef action could somehow avoid using a midtexture transition, or if there'd be a way to only show a colourmap in the section that it's affecting.

Edited February 10, 2022 by Arsinikk

[Graf Zahl]

40 minutes ago, Arsinikk said:

 (in addition, the second half of the vid shows how GZDoom's hardware renderer can't render the colourmap section correctly)

 

 

Yes, that's the main problem with this approach. It does not translate well to hardware rendering at all, so you effectively lock your mod to the software renderer.

I'd still say that the colored lighting approach is what most mappers really prefer and what offers more usefulness.

 

 

Edited February 10, 2022 by Graf Zahl

[Arsinikk]

1 minute ago, Graf Zahl said:

 

Yes, that's the main problem with this approach. It does not translate well to hardware rendering at all, so you effectively lock your mod to the software renderer.

  

However, I'm a bit confused because the Hardware renderer of DSDA Doom and PrBoom Plus are able to render the colourmaps fine. It's essentially only GZDoom that has this issue.

[Chookum]

A thought occurred as to why there's no desire to see colourmaps implemented or utilised in hardware mode. The difficulty of implementation against the modern mapping principles and thus nobody bothering with them design-wise outside of hard-core software players means that thinking about them doesn't come up when iterative development on modernised source ports occurs.

 

In addition, the modern cohort of Doom players use hardware modes and thus colourmaps are invisible to them - I was one of those users too, but I'm branching out and expanding my horizons after having GZDoom as the accessible hardware-driven inroads into modern Dooming.

 

Colourmaps are a victim of being out of sight, and out of mind, and exist vestigially to the map format and engine. Can anyone name a recent Cacoaward winning map/mapset that's used Colourmaps in any capacity large or small? No? YES, actually: Dimension of the Boomed, for its deep water/acid/lava dotted throughout the set.

 

5 hours ago, Arsinikk said:

I'm a bit confused because the Hardware renderer of DSDA Doom and PrBoom Plus are able to render the colourmaps fine.

Are you sure about that?

 

Spoiler

Loading DOTB_RC3.wad...

 

Everything's set up right according to this.

 

But no doughnut.

 

Meanwhile, in Software Mode...

 

PRBoom+'s not safe either:

Hardware Rendering (with some additional FOV)

 

Software Rendering (32bit)

What versions of DSDA Doom and PRBoom had it working in hardware? Did something get broken and nobody noticed because as outlined its so far out of sight and out of mind that nobody noticed the breakage (or perhaps omission)? Perhaps DOTB should be used to test colourmap functionality in future, along with old BOOMEDIT.wad.

 

For comparison's sake, let's look at how GZDoom gets it done:

Spoiler

Hardware GZDoom handles things reasonably well...

...but not without jank on the "greyscale" area. There's a little more chroma than usual.

 

But the software modes don't quite stack up either. Doom Software Renderer forgets to apply the effect to things, but doesn't forget to colour Doomguy's hand, somehow.

 

TrueColor SW misunderstands the greyscale and loses the crunchiness of the palette conversion as a result of being able to paint with all the colours of the wind and not clamping itself down.

But it does remember to colour things inside the sector.

 

5 hours ago, Graf Zahl said:

I'd still say that the colored lighting approach is what most mappers really prefer and what offers more usefulness. 

Let's meet in the middle if you want to steer into something you want to see instead of taking my suggestion. Utilise Colourmaps to make the visible-from-outside-sector coloured lighting between hard/software.

Edited February 11, 2022 by Chookum

[Arsinikk]

31 minutes ago, Chookum said:

 Are you sure about that?

 

That's really strange, because my custom colourmaps work correctly in OpenGL mode of DSDA Doom (0.24.0) and PrBoom Plus (UMAPINFO Stable).

Here are some screenshots of my settings / colourmaps working in OpenGL:
 

Spoiler

 

 

 

 

 

 

 

 

I will admit that switching from software to opengl, or vice versa often breaks the colourmap in DSDA Doom and it may require a restart for OpenGL to work properly again.

 

31 minutes ago, Chookum said:

But the software modes don't quite stack up either. Doom Software Renderer forgets to apply the effect to things, but doesn't forget to colour Doomguy's hand, somehow.

 

I have also noticed there is something strange with how GZDoom renders sprites in colourmaps, in that sometimes it ignores them in Software mode.

[Chookum]

17 minutes ago, Arsinikk said:

I will admit that switching from software to opengl, or vice versa often breaks the colourmap in DSDA Doom and it may require a restart for OpenGL to work properly again.

That could have something to do with it. Its perhaps contingent on other settings with my computer or DSDA Doom I'm not aware. I followed your example from a fresh open via the Launcher.

 

Spoiler

 

 

But with some experimenting by following your settings, I disabled external Hi-Res textures and the overriding PWAD graphics with hi-res and it now works as you've outlined.

 

That's a very odd contingency I wouldn't have expected interplay with, but thanks for your example and settings.

[Graf Zahl]

9 hours ago, Arsinikk said:

However, I'm a bit confused because the Hardware renderer of DSDA Doom and PrBoom Plus are able to render the colourmaps fine. It's essentially only GZDoom that has this issue. 

 

They apparently create different textures for these colormaps. GZDoom treats Boom colormaps as fullscreen overlays, which for virtually everything that had been released over the last 20 years yields better results and is more performant.

 

[Gez]

A vanilla-like implementation of colormaps in hardware could probably be done with a postprocess shader.

[Graf Zahl]

No, it can't. You'd have to palette match every single pixel to get that right and that's a problem even for modern hardware. As long as the colormap is just a single colored tinting table, all no problem, but if you get something that applies very different transformations to separate color ranges this won't work.

 

The only realistic way to handle it would be to treat these colormaps as a global palette and create a separate set of hardware textures for it - but then you'll have to add precaching logic for that - and this is where things get tricky because with Boom's way of using colormaps it is virtually impossible to catch all map objects in need of such a processed texture.

For the original low-res textures that's normally acceptable, but not for high res stuff or map sections wil a large variety of different textures.

 

[ChopBlock223]

14 hours ago, Graf Zahl said:

 

Yes, that's the main problem with this approach. It does not translate well to hardware rendering at all, so you effectively lock your mod to the software renderer.

I'd still say that the colored lighting approach is what most mappers really prefer and what offers more usefulness.

I'd certainly love to use colored sector lighting, but the use in Arsinikk's map I think is creative and novel. I would love to see more people play around with stuff like that, and even try it out myself given less cumbersome implementation on the mapping end.

 

For hardware rendering, could any kind of workaround be employed to properly replicate that kind of visual at all?

[Graf Zahl]

It is possible but we'd have to make sure that this doesn't negatively affect the simple colormaps, because we do not want to create all new textures for those.

 

[ChopBlock223]

Uh, in that case, what about a separate group of colormaps, and maps like that one can use the second colormap function to ensure better compat with more ports?

Wouldn't really solve older cases of not rendering right (though I'm not aware of any), but perhaps there would be ways to patch older maps if really necessary.

[GoneAway]

2 hours ago, Graf Zahl said:

It is possible but we'd have to make sure that this doesn't negatively affect the simple colormaps, because we do not want to create all new textures for those.

 

One option is if it's enabled via a new line action then the presence of that line could switch the mode used to render the colormaps for that map only (for vanilla format maps).

Edited February 11, 2022 by kraflab

[Worst]

Would color translation strings for sectors, similar to the actor translation strings in ZDoom, work any nicer with hardware rendering than colormaps do?

"112:127=208:223", "192:207=16:31"
"112:127=[32,32,0]:[224,196,0]"

Those could offer more flexibility than a simple RGB color tint, but I don't really know if such definitions would be any less cumbersome for hardware renders to handle... (Or if they would be even more cumbersome.)

[Graf Zahl]

That'd be easier to define, of course, but the end result would still be a separate texture

[esselfortium]

Text translation strings seem kinda like the worst of both worlds for this -- it would still lack the immediacy and hardware compatibility of being able to just specify an RGB tint, and would also mean not being able to just export COLORMAP and use an image editor to tint or gradient-map it however you like.

[MTrop]

Map feature implementation aside (which is already going to be difficult without an entirely new metadata structure and a way to not break "control line" conventions in Boom mapping), I'd have to side with Graf on its current lack of feasibility of implementation on truecolor renderers.

 

I'm not sure what the current architecture is in GZDoom around converting palettized textures to a form that can be preloaded and rendered in OpenGL/Vulkan, but without something like a shader or somesuch mechanism that does a palettized lookup for starting texel/material color in its pipeline, it will never be as fluid as the software renderer being able to render columns with a colormap index unless some major changes were made to texture format storage strategy. In essence, on the hardware side, it would need to be "pre-process," not post-process.

[Graf Zahl]

What it does with the textures is quite simple: It creates an RGBA8888 image from the paletted texture data and the palette. For palette translations used with sprites or fonts it creates separate textures for each translation. Sadly that old GL_EXT_paletted_texture extension had been dropped by hardware 15+ years ago - if that was still available these things would be a lot easier.

 

But even with that, you'll run into problems if you used alternative palettes with textures that do not use the palette. Then you'll have to downconvert the image to the palette in order to translate it.