Texture lookup rules for walls in Build

Texture lookup rules for walls in Build

Postby Graf Zahl » Mon Jun 01, 2020 12:57 am

The Polymost renderer features some awful hackery to make non-power-of-two textures work and I've been trying to find out how to do the job without this hack, but so far to no avail.
Polymer just glitches - it has no handling whatsoever for this case and fails miserably, and the math routines in Polymost are just like the rest of it: Hideously dirty code doing black magic that is virtually impossible to derive any formula from.

Therefore my question: What precisely are the rules? Does anybody know? The math present in both renderers does not deal with this case in a way that makes sense to me, but I cannot say if this is because of a flaw in the math or a screw-up by Redneck Rampage's makers - because it seems to be the only game running afoul of the problem.
I cannot make much sense of the motivation for the shader-based solution, to me it looks like it is intended to reproduce a behavior that can only be the cause of poor mapping that abuses an engine glitch.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby mjr4077au » Mon Jun 01, 2020 2:26 am

I know it's probably backwards, but I've read that the software renderer is always considered 'right'. Perhaps referencing that instead of Polymost would be the better approach?
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: Texture lookup rules for walls in Build

Postby Graf Zahl » Mon Jun 01, 2020 2:29 am

Of course the software renderer is "right", but if its code oversimplifies the task it is worthless as a reference. Just think about Tutti Frutti in vanilla Doom as a good example for this. I am convinced the problem here is the same in some way.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby mjr4077au » Mon Jun 01, 2020 3:04 am

I probably worded my comment around it being "right" wrong as I was walking and texting. I more meant that perhaps it could provide a clearer implementation but perhaps not. If RR is the only game that glitches and Polymer has no handling of it (since it predates NRedneck), I can only imagine that your hypothesis is correct about poor mapping.

Apologies that I can't offer any useful contribution towards this.
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: Texture lookup rules for walls in Build

Postby Rachael » Mon Jun 01, 2020 3:11 am

I know in the original, vanilla Duke/SW/etc (don't know about RR) it was not possible to use NP2 textures as a floor or ceiling for a sector, unless you wanted it to look really really bad. So that right there is already a feature enhancement if it works.

I am not sure about walls though. I think the original renderer expected it to be handled much the same way GZDoom already does.
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: Texture lookup rules for walls in Build

Postby Graf Zahl » Mon Jun 01, 2020 3:53 am

This is solely about walls, there is no handling for flats anywhere - it's just that without the compensation the texture does not wrap correctly, which is what makes me think that they tiled a NPOT texture and somehow abused the side effects of it. But the entire math is so obtuse that I cannot make much sense of it. The code was optimized for "performance" in all the wrong ways, i.e. using math shortcuts where their gain is minimal and ignoring obvious routes of optimization at nearly every corner.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby mjr4077au » Mon Jun 01, 2020 4:03 am

The code probably hasn't changed at all since JFBuild3D which features Ken's original Polymost implementation. He has a penchant for numbers and a lot of his future works like Build 2, etc are all done on the CPU, so I imagine Polymost was his first exposure to hardware rendering.
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: Texture lookup rules for walls in Build

Postby Graf Zahl » Mon Jun 01, 2020 12:22 pm

It was also written for a different generation of graphics hardware. That clearly shows these days. Polymost is the child of hardware that wasn't good at performing coordinate transformation in hardware, so doing it all on the CPU didn't really matter.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby Phredreeke » Mon Jun 01, 2020 1:31 pm

I got three examples
- dancing girl texture inside the projector in Hollywood Holocaust
- "You must be this tall" in House of Horrors in Blood
- the grandfather clock at the start of The Siege in Blood

Here's an example of the last one with and without npotwallmode correction enabled
User avatar
Phredreeke
 
Joined: 10 Apr 2018
Discord: phredreeke#6500

Re: Texture lookup rules for walls in Build

Postby Graf Zahl » Mon Jun 01, 2020 1:45 pm

I can see what this option does, but the one thing I wasn't able to derive from the observed scenes was how this works.
That grandfather clock is a good example. Where's offset 0, to what edge is the texture aligned and most importantly, why is the realignment done in the fragment shader and not up front in C++ code?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby Graf Zahl » Sun Jun 07, 2020 4:58 pm

I think I know now how this thing works. I just needed to see this in a context I know better, so I hacked the feature into GZDoom and checked a level where I know that it has major alignment issues in strict vanilla compatible ports on an NPOT texture and also know how it lookes there. Turns out that this code is just doing mostly the same thing, i.e. it renders the texture normally until the first power of two beyond the texture's height is reached while offsetting the overflow part by one texel and then at that POT boundary wraps around to 0. It's essentially what Doom also did with non-POT textures, minus the tutti frutti effect that occured in the leftmost column.

This obviously means that there's no way to fix this on the engine side, the shader hack is really the only workable way to handlie this case.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby mjr4077au » Sun Jun 07, 2020 5:16 pm

You've said it's essentially 'what Doom did', just curious if it's what GZDoom still does or is there a better way?
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: Texture lookup rules for walls in Build

Postby Graf Zahl » Sun Jun 07, 2020 11:32 pm

All Boom compatible engines implement proper texture wrapping in the software renderer - ZDoom was the last to get it but even that was a long time ago. For hardware renderers this isn't an issue, they can wrap NPOT textures natively. But from the looks Build not only never got fixed but apparently the games actively exploited the issue. Is anyone really surprised?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture lookup rules for walls in Build

Postby Gez » Mon Jun 08, 2020 12:45 am

I suppose the level designers, instead of flagging the issue when textures behaved weirdly, just assumed everything was working as intended and fiddled with the offsets until it looked right.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Texture lookup rules for walls in Build

Postby mjr4077au » Mon Jun 08, 2020 1:14 am

Not really surprised at all, and Gez's hypothesis sounds reasonable enough. What's the go here then? Fix it properly and hack the game code to do the right thing, or just preserve how it's been done as something unchangable?
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 1 guest