DRD Team

Those green lines.

No, not really. These are wrapping artifacts caused by texture filtering.

Just checked and it looks like JDoom gets this right. Completely different engines, I know, but are we really talking about something "impossible" (genuinely complicated) to fix in GZDoom or simply not a good understanding of the problem?

The problem is easy to understand. Texture filtering compares pixels to their neighbors, and the image is tiled so on the borders it looks at the other side for neighbors. When a texture doesn't tile right (and that one doesn't tile vertically) it produces such effects. But the overwhelming majority of textures tile, so the normal behavior is better in most cases.

It's possible to change that by instead having border pixel use themselves as their missing neighbors, but it might look worse in the majority of cases as it risks making the boundaries between textures more visible where they tile.

Simplest fix: autoload a modified texture for the few cases where it matters. Make it 48-pixel high instead of 24, and put a vertically mirrored copy at the bottom.

That won't work because Doom can align textures both to their top or bottom edge.

I'm not sure that many of the few relevant linedefs are lower-unpegged.

Would it be possible to define texture wrapping modes in the TEXTURES lump? Eg. hwrap, vwrap, hclamp, vclamp, hmirror, vmirror, hmirroronce, vmirroronce. Then textures not meant to wrap vertically or horizontally can be defined so.

That's certainly possible. But it's still no real option here because it would cause some problems with WADs that don't care about proper tiling.

One possible solution would be to check for instances where the vertical texture dimension is close to that of the wall segment and if so, draw with the vertical wrap mode set to GL_CLAMP.

Another would be to duplicate a texel column/row on each side of the texture and upload to GL as a bordered texture. Then you can selectively enable the GL_CLAMP_TO_BORDER wrap mode in these circumstances.

A much better approach though, is to handle texturing using a shader as here you can selectively enforce clamping, wrapping, mirroring (etc...) when your input coordinates align to one or more edges of a primitive.

DaniJ wrote:One possible solution would be to check for instances where the vertical texture dimension is close to that of the wall segment and if so, draw with the vertical wrap mode set to GL_CLAMP.

That was actually doable.

DaniJ wrote: A much better approach though, is to handle texturing using a shader as here you can selectively enforce clamping, wrapping, mirroring (etc...) when your input coordinates align to one or more edges of a primitive.

How can I do that in a shader? You don't mean I should do the texture filtering myself, do you?

Whatever you did for r555, appears to be working great, the wrapping artifact is gone.

Graf Zahl wrote:

DaniJ wrote: A much better approach though, is to handle texturing using a shader as here you can selectively enforce clamping, wrapping, mirroring (etc...) when your input coordinates align to one or more edges of a primitive.

How can I do that in a shader? You don't mean I should do the texture filtering myself, do you?

Whilst it is certainly possible, there isn't much to gain from doing the filtering yourself and obviously by doing so you would most likely be circumventing any high-level optimizations that the hardware could leverage.

What I'm referring to is the approach of handling the texture wrapping in a shader which can be done through fairly simple translations of the texture coordinates. The best example I can point to at this time is that used by id software's megatexture tech though I'm sure it has appeared in a white paper or two also (maybe even a GPU Gems).

We are planning to use a similar approach in the new Doomsday renderer in combination with a new texture paging/texture atlas subsystem I've been prototyping that functions as a lower level of our Materials system. It necessitates manual creation, packing and upload of the mip textures however (though you don't necessarily have to do the scaling yourself, it depends on whether the prospect of getting GL to do it would fit well in your architecture).

The most recent versions do indeed seem to be much better. However, I am wondering if anything similar can be done for floors? In my experience, these artefacts appear far more frequently on floors than on walls. This is probably due to the fact that, in a number of situations, you might have a 64x64 sector that has a pattern that is discrete from the surrounding areas or one which is actually a bigger graphic made up from (effectively) 64x64 patches (like the demon teleport at the end of E1M8).

Example screenshot:

I'm sure something can be done. But it's far less trivial to check if it's appropriate. If done badly this can cause even worse artifacts than the seams you can see now.