Pondering about deposterisation filter

Pondering about deposterisation filter

Postby Phredreeke » Tue Jun 23, 2020 6:57 am

I know the issue of palette emulation is controversial around here, I'm not gonna go into the merits for or against it.

However, disabling palette emulation doesn't resolve the root issue of the original assets themselves only having 256 colors. Which leads to my question - has anyone attempted a texture filter like XBRZ, expect instead of raising resolution you smooth out the posterisation caused by the original palette?

Is it even a good idea? I know people have attempted to train neural networks for the purpose but that is obviously too slow to do real time in a source port.
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Pondering about deposterisation filter

Postby mjr4077au » Tue Jun 23, 2020 7:03 am

Ehh it's only controversial for some. Others like Nash won't even use a head version of Raze since it's not currently working on the unified backend code.

I'd be interested in seeing some samples. The upscaling code from GZDoom, including XBRZ is already in Raze and can be controlled via the console. I'm sure it wouldn't be impossible to use the XBRZ code for other purposes.

Upscaled textures for Duke3D are a bit of a mixed bag. I thoroughly love your sprite upscales but wasn't a fan of your texture upscale pack for Duke 3D, and I don't think that's a representation of you but more of the source artwork perhaps being difficult to upscale.
Last edited by mjr4077au on Tue Jun 23, 2020 7:26 am, edited 1 time in total.
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Pondering about deposterisation filter

Postby Nash » Tue Jun 23, 2020 7:23 am

Appreciate it if accusations aren't thrown around like that. :) To clarify, my stance is - for the big Build engine games (at least Duke, SW and Blood) - lack of palette emulation completely changes the art style of the game (the colours are WAY wrong compared to what they originally were) - I agree that true colour is "better" if the end goal is limitless colours - but as far as aesthetics, the vanilla games just don't look right at all without their original palette and I just cannot enjoy them.

If there is somehow some black magic that allows the original games to retain their look (so that Duke's hands don't turn yellow; so that the desaturated horror colours in Blood still look like horror, etc etc etc) BUT somehow operate in true colour as far as light fading and colour blending goes - hey, I'm all for that. Not really a fan of banded shading myself.

I'm an artist, when I see things I visually like, it is because a specific something of that thing stimulated me; be it colours, composition, whatever. There is no "objectively true colour is better" - is true colour better? Sure, I can vouch for certain projects that look amazing while utilizing true colours - but guess what? Almost all of said projects utilize a PALETTE. ;) Palette in this context meaning, not "limited to 256 colours" palette, but the artist stuck with a consistent set of colours while creating it, even though the end result is in true colour.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Pondering about deposterisation filter

Postby Phredreeke » Tue Jun 23, 2020 7:25 am

Well, upscales the way I do has to be done in advance, it's just not feasible to do it in realtime.

What I'm suggesting here isn't even related to upscaling, or it could be potentially used as a post-processing filter on my existing upscales (since I for multiple reasons convert the result back to the original game palette)

I'm sure it could be done, I just don't have the programming skills to pull it of, hence making me the dreaded "idea guy"
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Pondering about deposterisation filter

Postby mjr4077au » Tue Jun 23, 2020 7:31 am

Nash wrote:Appreciate it if accusations aren't thrown around like that. :)

If that's directed at me, I'm sorry for the name drop and speaking on your behalf :)
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Pondering about deposterisation filter

Postby Graf Zahl » Tue Jun 23, 2020 7:31 am

Nash wrote:Appreciate it if accusations aren't thrown around like that. :) To clarify, my stance is - for the big Build engine games (at least Duke, SW and Blood) - lack of palette emulation completely changes the art style of the game (the colours are WAY wrong compared to what they originally were) - I agree that true colour is "better" if the end goal is limitless colours - but as far as aesthetics, the vanilla games just don't look right at all without their original palette and I just cannot enjoy them.


If that is as important to you as the noisy sound there's fortunately a very simple solution: Go back to the parent ports. But what would be the point if I just copied those traits? Raze would be an utterly redundant thing that might just be discontinued on the spot.

Nash wrote:If there is somehow some black magic that allows the original games to retain their look (so that Duke's hands don't turn yellow; so that the desaturated horror colours in Blood still look like horror, etc etc etc) BUT somehow operate in true colour as far as light fading and colour blending goes - hey, I'm all for that. Not really a fan of banded shading myself.


It's hard to reproduce shitty assets with non-shitty means. The big problem is that Build is a very hacky engine and all those hacks depend on ancient limitations. You cannot retain the effects based on these hacks without keeping the limitations in place. But my expressly stated goal was to get rid of these limitations. If that doesn't suit you, please look elsewhere for a solution that fits your needs.

Nash wrote:I'm an artist, when I see things I visually like, it is because a specific something of that thing stimulated me; be it colours, composition, whatever. There is no "objectively true colour is better" - is true colour better? Sure, I can vouch for certain projects that look amazing while utilizing true colours - but guess what? Almost all of said projects utilize a PALETTE. ;) Palette in this context meaning, not "limited to 256 colours" palette, but the artist stuck with a consistent set of colours while creating it, even though the end result is in true colour.

[/quote]

Whatever. All the Build games with their visual hacks look like eye-rape to me and that's what I base my work on.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Pondering about deposterisation filter

Postby Nash » Tue Jun 23, 2020 8:02 am

See the thing is I feel like you are antagonizing me for the wrong reason - I'm not an enemy to true colour, far from it. GZDoom looks amazing in true colour and I wouldn't GZDoom any other way. Also in GZDoom, the colours don't get butchered - the original assets still look the same color-wise. Doom guy still has light-brown caucasian hands, not asian hands.

The problem I'm seeing with ANY Build engine (not just Raze) is that when in true colour, the assets get recoloured in a way that's not pleasing to my eyes at all.

I am NOT talking about light fading, BTW. I am talking about the assets in fully lit area. As I said, Duke's hands turn yellow in true colour.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Pondering about deposterisation filter

Postby Rachael » Tue Jun 23, 2020 8:29 am

I think the best thing we can do at this point is beg for drfrag - or someone like drfrag - to make a fork of Raze to support these kind of things.

Graf - you seem unusually hostile today, enough that it is actually a bit out of character for you. Nash may be an artist but remember that he has skills you have little interest in developing, and has used those very skills to help you on numerous occasions. He is expressing his preferences but it is by no means a requirement or imposition for you - he's just trying to explain why the games feel less genuine to him in Raze's current state. This hostile attitude you seem to have sometimes, particularly lately, is quite alienating - and it is a very effective way to drive off skilled contributors.

Yes - a lot of that fault can be attributed to the Build engine being built literally for the limitations within which it was created at the time and not having the foresight to escape those limitations. But that doesn't mean there aren't ways to work around this. What about the brightest color mapping of the shading table? If it helps to stop Duke's hands from turning yellow, it might be all that's needed to resolve this issue in truecolor, without actually fully implementing the palette emulation. It's possible that it wasn't a full simple [0-255] fill if this is the case.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Pondering about deposterisation filter

Postby Phredreeke » Tue Jun 23, 2020 9:11 am

This is what I meant with it being controversial.

Maybe a lighting shaded could be made that shifts yellows towards red when darkening (which has a precedent in CGA monitors, where dark yellows had its green component further attenuated to turn brown)

Now can we get back to my idea?
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Pondering about deposterisation filter

Postby markanini » Tue Jun 23, 2020 9:24 am

Your idea in proposed in OP might end up looking like plain true color rendering which is kind of redundant.
markanini
 
Joined: 18 Jan 2020

Re: Pondering about deposterisation filter

Postby Phredreeke » Tue Jun 23, 2020 9:37 am

The posterisation I'm talking about is what's inherent in the textures themselves, not what's caused by the lighting model.

Rendering a 256 color texture in true color you still only have 256 colors, just they may be darker depending on distance.
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Pondering about deposterisation filter

Postby sinisterseed » Tue Jun 23, 2020 10:20 am

Rachael wrote:Graf - you seem unusually hostile today, enough that it is actually a bit out of character for you. Nash may be an artist but remember that he has skills you have little interest in developing, and has used those very skills to help you on numerous occasions. He is expressing his preferences but it is by no means a requirement or imposition for you - he's just trying to explain why the games feel less genuine to him in Raze's current state. This hostile attitude you seem to have sometimes, particularly lately, is quite alienating - and it is a very effective way to drive off skilled contributors.

Indeed. It's been a while since I've seen this side, so I suppose it's mostly stress at work/a bad day to blame here. But frustration like this is best expressed elsewhere, yes, because it's the kind of attitude that can push people away.

Like it or not, when it comes to palette emulation it is a necessity in these games, especially in SW, from my POV at least. Without it, I think it looks the worst out of the bunch since everything is really brown without it, there's no way that that is the way the game was originally meant to look like, especially when looking at the prototypes and alphas which are even more colorful at times, and have some very deep blues that just go to waste completely without it. Unnatural looking? Maybe, but it is how it was meant to be, for better or worse. Though thankfully it's possible to get rid off the banding.
User avatar
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Pondering about deposterisation filter

Postby mjr4077au » Tue Jun 23, 2020 3:45 pm

I think his message is fine, but the delivery could have been softer. Graf has said that previously that he wants to make the port his own and do his own thing and I think you either need to be onboard with that or not. You really might as well use EDuke32 if you want it look and feel exactly like EDuke32.

Credit where its given though, he's putting considerable effort into making the GZDoom backend handle palette emulation even though I'm sure he doesn't play with it himself. So while he does want to make it his own, he's still considering the broader audience.
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Pondering about deposterisation filter

Postby Phredreeke » Tue Jun 23, 2020 5:03 pm

Honestly, I'm more interested in seeing how Raze does things differently.

I wonder if the port would need to have different lighting models for each game (except for the Duke3D based ones which would share one I guess)
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Pondering about deposterisation filter

Postby mjr4077au » Tue Jun 23, 2020 5:34 pm

Phredreeke wrote:Honestly, I'm more interested in seeing how Raze does things differently.

I wonder if the port would need to have different lighting models for each game (except for the Duke3D based ones which would share one I guess)

I agree, that's what I want to see as well.

I believe it'll have all the lighting modes that GZDoom has available for usage (which may or may not look good). It'd be great to see some other lighting modes come into the project specifically for Build though :)
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Next

Return to General

Who is online

Users browsing this forum: No registered users and 0 guests