Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

textureSampling does not work on Linux #4934

Open
methodrunnerII opened this issue Feb 23, 2017 · 5 comments

Comments

@methodrunnerII
Copy link

commented Feb 23, 2017

I'm making a processing sketch using P2D, and I'm trying to change the texture sampling mode to nearest neighbour. I'm using the statements

hint(DISABLE_TEXTURE_MIPMAPS);
((PGraphicsOpenGL) g).textureSampling(2);

On Linux, this doesn't change the sampling, regardless of the argument provided to textureSampling(). When I scale the sketch up, there is still interpolation, which I'm trying to avoid. I've tried placing the statements in setup(), and after reading a seemingly related issue, in draw(), to no avail.

This issue does not appear on Windows 7.

Details:
OS: Linux Mint
Processing 3.3

@benfry

This comment has been minimized.

Copy link
Member

commented May 4, 2017

(Assigning this to @codeanticode since it's not official API…)

@scudly

This comment has been minimized.

Copy link

commented Feb 14, 2019

Two years later and I've now run into this issue on Processing 3.5.3 on Linux.

Please make textureSampling an official part of the API so we can rely on it when writing interesting shaders.

@dzaima

This comment has been minimized.

Copy link

commented Feb 14, 2019

noSmooth(); seems to make scaled up images draw using nearest neighbor, but only on the JAVA2D renderer, with no indication of the difference in P2D, which may not be related, but probably should be fixed.

((PGraphicsOpenGL) g).textureSampling(2); does however make things get drawn with nearest neighbor on Linux Mint for me though.

@tolkanabroski

This comment has been minimized.

Copy link

commented Feb 15, 2019

@scudly Just randomly flew by here. I read your forum post
Just a guess : Your shader Problem looks from this far away more like an Anti-Aliasing issue, make your own reserach. Hardware multisampling technigues such as MSAA can be handy, so check your Linux settings, you also can multisample direct in your shader

   // antialiasing - https://www.shadertoy.com/view/tslGz7
   const int AA = 2;
    for (int jj = 0; jj < AA; jj++)
        for (int ii = 0; ii < AA; ii++) {

            vec2 q = fragCoord.xy + vec2(float(ii), float(jj)) / float(AA);
            vec2 st = (2. * q - iResolution.xy) / min(iResolution.x, iResolution.y);
        };
            
    col = col / float(AA * AA);

The other case is: Some default (behind the scenes) processing render settings can cause some weird results when using shaders, see here #1272 (comment)

Good Luck

@scudly

This comment has been minimized.

Copy link

commented Feb 15, 2019

FIXED! Or at least hacked around.

In the Linux NVIDIA X Server Settings application, under Antialiasing Settings, I set Anisotropic Filtering to Override Application Setting, leaving the slider at 1x. Along with textureSampling(2), the incorrect interpolation I was getting goes away and my images now look the same on Linux as they do on Windows and Android.

Now we just have to get Processing to do whatever it is that that setting is doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.