GLES3: Allow repeat flag in viewport textures

[ricmzn]

This patch changes the texture_set_flags function in the GLES3 renderer to allow the use of the "Repeat" flag for render targets, which can fix visible seams when using viewports to generate procedural textures.

My setup for this is to generate a tiled noise texture around a sphere via the tutorial outlined here, reducing the viewport resolution to make the effect more visible, and enabling the filter and repeat flags in the texture. Notably, the repeat flag doesn't have any effect for viewport textures as of Godot 3.2.beta2.

Before applying the patch, enabling texture filtering creates a visible seam at the edges of the texture, where it wraps around the object:

But with the patch, the repeat flag works as it should and gets rid of the seam:

I believe there could be a reason for the flags to be set up as they were originally, however, I'm not very knowledgeable on OpenGL or Godot's rendering internals (it took me changing texture flags in many places and several compiles to nail the issue down!).

[clayjohn]

The change looks good. However, we are in feature freeze for the 3.2 release and so we won't be merging any new features (even small ones like this) because it risks introducing bugs.

Unfortunately, that means that this PR will become irrelevant because 3.2 is the last release to have the GLES3 backend. 4.0 will have Vulkan and GLES2.

For now, I am setting the milestone to 4.0. However, for it to be merged it will need to be updated to work on both Vulkan and GLES2.

[Calinou]

@clayjohn I guess it could still be merged in 3.2.1. We tend to allow small features like this one in point releases.

[aaronfranke]

@ricmzn Is this still desired? If so, it needs to be rebased on the latest master branch and redone to work with Vulkan.

[ricmzn]

@aaronfranke I'm not sure if this fix would be applicable to Vulkan, as this whitelists a specific texture flag that's only ignored in the GLES3 renderer. As such, this would only be applicable for future 3.X releases.

I would have to check if the same thing happens on the Vulkan renderer on master, and if it does, both the cause and the fix would be completely different, especially as my use case (ie. procedurally generated sky textures in shaders) has also been given some attention.

Would it be better to change the target branch of this PR to accommodate the fact it works on a deprecated renderer in maintenance mode?

[ricmzn]

Hello, I know this is an old PR, but I believe it can still be merged into 3.2, as it's not pertinent to the renderer rewrite in 4.0.

Or, if the team believes it would be a better approach, this could be closed as the 3.2 branch is in maintenance mode.

[Calinou]

Or, if the team believes it would be a better approach, this could be closed as the 3.2 branch is in maintenance mode.

The 3.2 branch is still maintained until 4.0 is released, if not more 🙂

[Calinou]

I think this is harmless for 3.3 as it only allows a new flag (rather than changing existing behavior).

[akien-mga]

Thanks!