Jump to content

Problem with texture sampling mode

Recommended Posts



First of all thank you for Babylon.JS, it is a wonderful library and a pleasure to code with it :)


I am working on a game project and I need to display textures with a 'nearest neighbour' sampling mode (pixelated effect). Babylon.JS theoretically offers this possibility, but I could not manage to get it working. Here is a playground illustrating my modest struggle:




Left cube's texture is created with the NEAREST_SAMPLINGMODE parameter, while the right one uses TRILINEAR_SAMPLINGMODE. In my browser (Chrome v38), there is absolutely no visible difference.


I have seen a couple of threads about this on the forum but nothing that provides a real solution. Hopefully this thread will be able to do that.


Of course there is always the possibility to multiply the size of the texture using a nearest neighbour interpolation with an image manipulation software, but I'd prefer not as it adds steps in the workflow and prevents doing big texture atlases.


Thank you very much in advance :)

Link to post
Share on other sites

That confirms what I saw in BJS source code. Which is all the more surprising...


I also thought this may be due to the fact that since the same texture is used in both cases, BJS reuses the first instead of creating a new one, copying the sampling mode along the way. I did a new playground to check it and nothing changed :



Also tried with other browsers and still nothing.


I guess I'll try to dig deeper in the webGL code, and I'll post here if I find the solution. Thanks :)

Link to post
Share on other sites

It's me again. I could not find a fix, although I've looked everywhere and into every WebGL call with WebGL Inspector. I also compared BJS's source with a working example of a 'NEAREST' sampling mode, namely this one.

My observations:

- although the textures I use have a magnification filter set to gl.NEAREST (checked in the WebGL inspector), they will still appear blurred

- BJS's custom shaders are not responsible either; using a ShaderMaterial with a basic shader still displays the texture blurred

- I compared all the gl state flags with the ones in the working example, and I couldn't find any notable difference

- using mip-maps or not doesn't change a thing

In the end I can't even tell if the problem lies in BabylonJS or WebGL.


This is starting to drive me nuts. I desperately need this feature working :( Surely someone around here must have a small idea on what can be the problem?


Also I could not find any project made with BabylonJS that uses the 'NEAREST' sampling mode. But there must be one somewhere, I mean there are new minecraft clones at least every week! (OK maybe not that much anymore)


Sorry for the useless post, I just though I'd try my luck one last time here.



Link to post
Share on other sites

I think I've figured out this issue after quite a bit of digging through the BABYLON source code.


Babylon draws image textures to a canvas to resize them before they are passed to the WebGL, but the canvas they are being drawn to has imageSmoothing enabled. Therefore it's this smoothed image which is getting passed to WebGL so it is actually performing its NEAREST_SAMPLINGMODE correctly (just on a pre-smoothed texture).


So to fix this (as can be viewed here with a slightly hacked version of babylon):


The canvas context needs to following settings applied (every browser seems to use a different property):

this._workingContext.imageSmoothingEnabled = false;
this._workingContext.mozImageSmoothingEnabled = false;
this._workingContext.oImageSmoothingEnabled = false;
this._workingContext.webkitImageSmoothingEnabled = false;


This seems to need to be done just before drawImage functions (or I just implemented it badly)


I'll leave it to Deltakosh in his wisdom to implement the fix without causing any unintended consequences :)

Link to post
Share on other sites

Wow Xeonzinc, excellent find! But sadly, the problem persists with power of two (PoT) textures.


The playground I made earlier still shows the issue, since the grass texture on the right is 1024x1024 pixels. Also the textures I use on my project all have PoT sizes.


I'll keep looking, there must be an explanation. Soon I'll know BJS source by heart :D


Thanks guys!

Link to post
Share on other sites

Hey DK,


Thanks for taking the time to look into this issue. I hate to be a bringer of bad news but the rendering on the playground (which I believe uses the most up-to-date codebase) still behaves the same way:




Reminder: left texture (link) is not PoT, right texture (link) is PoT.


I feel like I'm boring everyone around here with this stuff... and I'd love to be able to help, but really, I couldn't find anything so far (still looking though).



Link to post
Share on other sites

I found something. Not really an answer to why?, but a culprit: anisotropic filtering.


The 'nearest neighbor' appearance works well when it's disabled ( texture1.anisotropicFilteringLevel = 1 )



As to why it gives this weird blurred render when activated... no idea. Also the render is the same for any filtering value, from 2 to 16.


I guess I'll disable the filtering for now. Also I'll try to document the ability to disable it, if I have the time & find how to do it!


For the record, I've attached the rendering I'm having now. Still have some work on seams & aliasing... ugh :( pixelated textures reduce texturing work but what a hassle to make it look nice!


Link to post
Share on other sites
  • 1 month later...

I've just noticed that this bug is platform specific. On mac, sampling mode works correctly regardless of anisotropic filtering (I tested chrome/safari/FF). It seems to be only on windows that sampling mode is ignored (I tried chrome/IE).


So if BJS internals do anything differently for win/mac, that might be the source of the bug.


It would be great if this could be fixed... minecraft-style scenery looks pretty terrible when there's no anisotropic filtering! :(

Link to post
Share on other sites

Sure, it's unavoidable that some bug reports are wrong. But forum threads often meander over several topics, so it's impossible to know if something is a bug without reading several whole threads.


I imagine you keep your own bug/feature backlogs, but if we can't see them we can't help fix them! ;)



But I'm open to improvements :) You can use the issue tracker of github 


That would be ideal, but it's disabled (on the GH project settings page).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...