Normal Map + Distortion Shader Support

[Major Cooke]

...I get the fact that first something probably needs to be done about binding to textures first.

For those who don't know about normal maps... They are essentially the things that can be utilized as refraction waves or making distortions via an image rather than having to manually generate one with code. They are also used in engines to provide depth in flat surfaces and give the illusion of 3 dimensional lighting.

On models, it looks like this:


When used as a shader, however, the colors act as distortions to pixels, commonly seen with Half Life 2's Strider particle cannon or Darwinia's grenade explosions. (skip to around 0:47)



This would be a good shockwave shader for example:

[ZZYZX]

*obligatory notice that normalmaps are actually processed bumpmaps and have the same original use goes here*
What you are asking for requires kind of a shader that allows applying postprocessing to a specific area of the screen limited by a polygon. Like water with refraction. It's not related

[Rachael]

That kind of thing is possible with fragment shaders, though, but they need to be linked to these textures, and therein lies a big problem.

[Graf Zahl]

Support for normal maps would require a similar setup as brightmap textures, but add a third getter function to the actual material shader. The main issue with this is of course that a normal map would only apply to dynamic lights but not to the static sector light level so its use will inevitably be limited. The suggested use case in the first post is of course NOT what a normal map is normally designed for. It cannot alter the world position of a pixel, only how light is refracted off it.

[dpJudas]

Normal maps is only one of the types of additional textures that could be interesting to bind. There's also specular and displacement textures.

I only looked shortly at this part of the code, but my impression was that we are missing a generalization of the brightmap texture solution. I know the current solution kinda generalizes the concept, but it lacks the part that manages which texture units are used for what and also the thing that enables the samplers for it on the main.fp side.

Graf is of course right about the dynlight limitation, but maps made specifically for GZDoom can really benefit from the visual improvements. Even if you are playing Doom 2 a fireball flying down the hall will look far more cool if the wall/flat next to it has the correct specular and bump highlights - assuming someone makes a texture pack for that.

[Graf Zahl]

I know. I already worked on a prototype some time ago but never committed it. My main fear was that it may create incompatibilities with Vulkan because back then I had no idea what parts of GLSL it would allow and which it would not.

I guess before going there it is necessary to refactor the renderer away from global uniforms to using uniform buffers for everything so that the shader code is compatible with what Vulkan needs. After that things may become easier. I would have done this earlier but it was only recently that GL implementations without uniform buffer support would be rejected by the renderer.

[dpJudas]

When I was looking into Vulkan for the PP shaders I discovered that as long as no user code declares the uniforms directly we can more or less move them around as we see fit. This works because the members in a uniform buffer appear as global variables.

One other thing I noticed with Vulkan is that they have a new buffer layout type for the uniform blocks called push-constant. I think that means even if we move all the uniforms to buffers with OpenGL we might want to use a slightly different buffer setup for Vulkan.

In any case, the old material shaders are in big trouble as they declare their own global uniforms. I think we only really have two choices: either parse enough GLSL to find them and remove them, or break backwards compatibility there.

[Graf Zahl]

Fortunately the only uniform in there is 'timer'. And it needs to be a float. Parsing the user shaders and removing the sequence 'uniform float timer;' should be doable.
There's already some code to handle first generation material shaders which were a bit different.
Too bad that this got into the wrong place so many years ago.

[Graf Zahl]

One other thing I noticed with Vulkan is that they have a new buffer layout type for the uniform blocks called push-constant. I think that means even if we move all the uniforms to buffers with OpenGL we might want to use a slightly different buffer setup for Vulkan.

I just read the docs about that. This actually looks very interesting and is probably better suited for GZDoom than having one large and bulky uniform buffer that needs to be maintained - at least for the less frequently used uniforms. In that case it actually makes very little sense to refactor OpenGL, but this probably needs some investigation and benchmarking first.

[Major Cooke]

I take it the way I was hoping to use it isn't doable after all?

Don't get me wrong, this talk about light displacement on textures would be extremely gratifying too. I was just curious about if my original usage suggestion is applicable. Garry's Mod happens to also do this in particular.

[ZZYZX]

This is doable but this should be called "distortion shader support" as in making shaders that are able to operate background of the polygon. Other than that simple distortions can be made both with and without normalmaps.

[Major Cooke]

Topic title changed to reflect as such.

So it would have to be on a model in order to work? Or could it also be done via a sprite too?

So far the only way I know it can be done is via postprocessing/textures via hard assignment without the normal maps. I'm not yet ready to work on it via entirely code yet -- rather I'd prefer to have the shapes/noise on an image and used as part of the postprocessing/textures.

[Xabis]

Seems a simple approach to allow distorting the scene would be by doing something like unity's GrabPass, which simply copies the underlying pixels to a separate texture that can be accessed by the shader.

Since it can be expensive to capture, it should be opt-in. For textures/flats, it could be another config param in GLDEFS.