Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Normal Map Magnitude property to Decals #3326

Open
Tracked by #57284
unfa opened this issue Sep 21, 2021 · 1 comment
Open
Tracked by #57284

Add a Normal Map Magnitude property to Decals #3326

unfa opened this issue Sep 21, 2021 · 1 comment

Comments

@unfa
Copy link

unfa commented Sep 21, 2021

Describe the project you are working on

I am working on a 3D game.

I've created a simple puddle decal, a pretty common thing to do.

Describe the problem or limitation you are having in your project

image

The puddle uses an extremely weak normal map, only to slightly bend the light reflections. Because the texture is 8-bit however, this causes ugly quantization artifacts to be clearly visible.

Puddle_Normal

Highly exagerrated contrast:
image

Because Godot's Decals have no way of scaling the Normal Map's values - the only way to get this working without quantization artifacts would be to use a floating-point EXR texture for the Normal Map, which would be:

  1. Very, very difficult to author - Godot expects a specific Color Space to be used and EXR files don't want to cooperate...
  2. Most likely more storage and memory intensive

Here's an attempt at using an EXR Normal Map to solve the quantization artifacts:
image
Yes, it's smooth, but I was unable to get the color space to be properly decoded by Godot, and as a result, the normals are all skewed.

It doesn't seem sensible that the only way to adjust a Decal's Normal Map magnitude is to alter the texture anyway...

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I see two solutions to this problem:

  1. Allow users to use 16-bit PNG files without reducing the color depth to 8 bits per channel. It'd make it easier to author precise Normal Maps, and it would also help a lot with Normal Maps in general - 8 bits for Normal Maps is often just not enough precision. I know that 16-bit PNG support has been deliberately disabled to avoid users from accidentally using more disk space and memory without a real benefit. I think a swithc re-enabling this in User Preferences would do. Not all users are oblivious ;)

  2. Implement a Normal Map Magnitude factor fro the Decal Node, and let the users exaggerate their Normal Maps(to fully utilize the 8-bit color depth available) and then scale that back down using the magnitude factor specified in the Decal Node's properties. Such a parameter would need to be added, and the Standard 3D Material's shader would need to include this factor into Decal evaluation.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Here's a UI mockup of the Decal Node's Properties:
image

I am not familiar with the inner workings of Godot enough to be sure of the following, but I assume that the Standard 3D Material's shader would need to be altered to multiply a Decal's Normal Map input by the magnitude float value provided in it's settings.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Not really, it either requires changes in how the engine handles importing 16-bit PNG files and/or how the Standard 3D Material Shader.

Is there a reason why this should be core and not an add-on in the asset library?

It seems like a pretty basic functionality, and I don't expect there should be any visible performance hit from implementing teh Decal Normal Map Magnitude factor this into the core.

Since user error is a cnsideration when alowing 16-bit PNG files to eb used, a swithc could be added in user or project preferences disabling automating quantization to 8-bit color if users are sure they can handle the extra freedom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants