Skybox Interpolation(Texture filtering)

I’m trying to set up a skybox in Panda, however I have a problem with pixel interpolation, it looks like panda doesn’t rely on UV maps to sample pixels. I have such a skybox map:

The problem is that the selection of pixels comes from the gray area (There is no image), this leads to this result.

What’s really going on.

Disabling filtering helps, but it’s not an option. I can also copy the desired pixels from another face to solve this problem. But maybe there is an easy way to do this?

Ah, I’m guessing that this is a mip-mapping issue (especially as disabling filtering helps): in short, the mip-maps include some grey in those areas due to downscaling.

One potential solution might, I think at least, be to extend the colour of the skybox a little further into the dark region than it already goes; this should result in the mip-map not reaching the dark area, if taken far enough.

But there is one problem, I would like to generate a skybox with a shader. Manipulation with UV coordinates will again lead to a thin seam. However, I need to read more literature on this occasion.

Does panda generate mip-mapping on its own? I used to think this is only available for DDS textures.

It should still be possible to have the shader generate the skybox past the UV boundaries, if you have it render more than would be rendered when used.

I think so. I also think that it may be possible to provide mip-maps of your own, which may also be an option for you. Alas, however, I don’t know how this is done, myself.

I found some information, but it may be outdated.

And yes, dds can contain their own mip texture levels. But I wonder if panda overwrites them… Well, I need to try it with a shader.

1 Like

Ah, I also found this:

1 Like

I found a detailed answer outside of our forum.

1 Like

Well, time goes by quickly and cubic maps are outdated, or rather they are required at some stage of design, but in the end you should use this to create a skybox.

This does not create problems with infinitesimal mip-mapping in the visible range.

1 Like

Three ways to fix this:

  1. Extend the image so that there is no black or transparent area.
  2. Use 6 separate textures, one for each face.
  3. Use a cube map - a real cube map, not a single texture with a big :heavy_plus_sign: in it. This means splitting up into 6 separate images and loading it via loadCubeMap. The faces need to be in a particular order and orientation for this.
2 Likes

Oh, I came upon this thread on another forum recently, which may be of interest:
https://www.gamedev.net/forums/topic/713104-texture-bleed-when-using-tiling-mipmaps/

This is not suitable, since there is a side effect in the form of the difference of neighboring pixels. Alternatively, I can copy the pixel line to the other side if I need a static skybox, however I want to generate it with a shader.

This is too many passes for the shader.

Here again the same problem. For some reason it seemed to me on the contrary that a real cubic map should be whole. The engine should provide links to the faces after processing under the hood.

As for generating with the help of the GPU, I don’t need to render the entire size, it’s enough for me to drop the bottom part and draw the sides in half. And for these purposes, one texture is very well suited, in fact, calls to shader programs are reduced.

I am not sure what you mean by this, but the only way to get “perfect” filtering at edges (except using a different projection, which will have more distortion) is to use a cube map texture, because the GPU then has access to all 6 faces and knows how to sample pixels across face boundaries.

I mean, there is usually a solid cubic map. Its separation into facets is performed by the engine for transmission to the graphics pipeline.