"Virtual" NormalNx texture upscaling

Moderator: Raze Developers

User avatar
phantombeta
Posts: 2009
Joined: Thu May 02, 2013 1:27 am
Graphics Processor: nVidia with Vulkan support

"Virtual" NormalNx texture upscaling

Post by phantombeta »

Essentially, this is a fragment shader-based emulation of the NormalNx texture upscaling mode that I came up with. It requires no extra VRAM, and only uses ALU operations. Here's the GLSL code for it.
Why am I suggesting it for Raze specifically? Because GZDoom has user shaders, and they get the texture UVs by accessing the vertex outputs directly, so this wouldn't work there*.

* (It'd need a preprocessing pass to replace any usage of the vertex output UVs with these modified UVs for it to work)
User avatar
Nash
 
 
Posts: 17319
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: "Virtual" NormalNx texture upscaling

Post by Nash »

Coincidently, Rachael was talking about making GZDoom's NormalNx into a shader too. Sounds like a great idea. :)
dpJudas
 
 
Posts: 2890
Joined: Sat May 28, 2016 1:01 pm

Re: "Virtual" NormalNx texture upscaling

Post by dpJudas »

Not bad phantombeta. My ideas for a shader version involved doing the linear filtering manually using texel fetches, but your version is better as it should work with anisotropic filtering I think. I do wonder if the pow() could be replaced with something cheaper.

Supporting it for GZDoom is possible. It requires renaming the fragment input for the texcoord and putting a global variable with the old name in its place. At the start of the main() function (in main.fp) it could then apply the texcoord adjustment and store the result in the global variable.
User avatar
phantombeta
Posts: 2009
Joined: Thu May 02, 2013 1:27 am
Graphics Processor: nVidia with Vulkan support

Re: "Virtual" NormalNx texture upscaling

Post by phantombeta »

dpJudas wrote:Not bad phantombeta. My ideas for a shader version involved doing the linear filtering manually using texel fetches, but your version is better as it should work with anisotropic filtering I think.
I believe I tried to do that at first too, but it just didn't work well.
I do wonder if the pow() could be replaced with something cheaper.
Maybe, but I wouldn't know how to do so. That said, if you only make it possible to choose hardcoded values like with the "real" NormalNx, you could hardcode it as multiplications. That should be cheaper than a generalized exponentiation algorithm.
Supporting it for GZDoom is possible. It requires renaming the fragment input for the texcoord and putting a global variable with the old name in its place. At the start of the main() function (in main.fp) it could then apply the texcoord adjustment and store the result in the global variable.
Huh, that's nice to know. Didn't know you can have globals in GLSL like that.

Return to “Feature Suggestions [Raze]”