"Virtual" NormalNx texture upscaling

Moderator: Raze Developers

"Virtual" NormalNx texture upscaling

Postby phantombeta » Tue Oct 20, 2020 5:38 pm

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
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

Re: "Virtual" NormalNx texture upscaling

Postby Nash » Tue Oct 20, 2020 6:17 pm

Coincidently, Rachael was talking about making GZDoom's NormalNx into a shader too. Sounds like a great idea. :)
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: "Virtual" NormalNx texture upscaling

Postby dpJudas » Tue Oct 20, 2020 6:30 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: "Virtual" NormalNx texture upscaling

Postby phantombeta » Tue Oct 20, 2020 9:35 pm

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.
User avatar
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests