No Mipmap for Basis Universal texture

Hello !

It’s been a while since my last post :wink:

I come today with a question, and depending on the answer, a possible bug for the support of .basis files (I did not test .ktx2 yet).

Is mipmap supposed to be supported with .basis texture ?
According to the documentation:

The compressor is able to exploit color and pattern correlations across the entire file, so multiple images with mipmaps can be stored very efficiently in a single file.

I would say it is supposed to be supported, but according to my experimentations, it is not…
The aliasing is clearly visible in the example playground, but if you go check the parameters of the texture in the inspector (which breaks the basis image by the way), you can see “has Mipmap Yes”…

I tested using both babylon 4.2 and 5.0-alpha, but both seems to have the same issue.

Thanks for your answers :slight_smile:

Adding @bghgary who knows a lot about basis and ktx

1 Like

@DarraghBurke Can you look into the texture inspector problem? Somehow, just selecting the basis texture causes it to turn colors.

@Mickael_PASTOR Can you send some screenshots or elaborate on what you mean by this? I don’t see any big differences on my machine between the cubes.

Thanks for your answer!

Here is the slightly modified demo playground
(I just changed the camera and the material for the floor)

You can see the aliasing from an angle like this one:

1 Like

There is no mipmaps in the .basis file according to basisu.exe:

Mipmaps must be contained inside the file, they can’t be generated at runtime for compressed formats.


Following your post, I did my research with a colleague, and there is an option when generating a .basis image to include a mipmap GitHub - BinomialLLC/basis_universal: Basis Universal GPU Texture Codec (-mipmap).

And it just works!! So it is not a bug! Maybe I am the bug…

As I read the documentation again, it clearly says:

so multiple images with mipmaps can be stored very efficiently in a single file.

“stored” it is, it was right there, beneath my eyes from the beginning!

Thank you very much @Evgeni_Popov <3

Maybe the sample playground should be updated with a basis file that has mips since that would match the behavior of loading the PNG.

1 Like

I might have been mislead by the playground, as there are two distinct visual aspects…

The inspector bug when inspecting the gpu compressed texture does not occur for .ktx2 images, in my case, and the -mipmap option has to be enabled for this format as well.

Thanks again for your answers, it’s really great to work with the engine!!

When we render a preview image in the inspector, we briefly set the texture sampling mode to nearest neighbor, before setting it back to the original sampling mode. Calling updateSamplingMode() on this texture for any sampling mode with a mips setting (eg. LINEAR_LINEAR_MIPLINEAR, NEAREST_NEAREST_MIPNEAREST) will break the texture. Other sampling modes (NEAREST_NEAREST) are fine.

Simple repro of this here: Babylon.js Playground (

This is particularly strange, because in theory, the texture already should have that sampling mode set. Why is not broken on initial load? I’m not sure. @bghgary any thoughts?

Note that it can be “unbroken” simply by setting the sampling mode to any of the functional models.

I am trying to create a simple repro in the playground to file an issue for this, but having a hard time getting it to repro. It seems to only break when used in a PBR material, but not as diffuse for a standard material. Not sure why yet.

Also, even with a working sampling mode, the inspector preview view still doesn’t work. That may be an inspector bug.

I’ll keep looking into this next week. Thanks for bringing it to our attention!


Any update?

Sorry @Mickael_PASTOR, with Thanksgiving happening last week I let this fall by the wayside for a bit. I’m looking into it right now and I’ll have issues open by the end of the day :slight_smile:


I have opened an issue here with PG repro: Sampling modes with Mipmaps do not work correctly for basis textures · Issue #11549 · BabylonJS/Babylon.js (

I will ask around and see if anyone is available to investigate this. Thank you for your patience!

Maybe @Evgeni_Popov can have a look?

This is now resolved! Thanks @Evgeni_Popov :slight_smile:


Thanks guys! You guys are great!

I solved the topic with @Evgeni_Popov’s first answer because it’s the solution to the original question :slight_smile:

1 Like