P5.js: resetShader() doesn't reset to default stroke / fill shaders

[aferriss]

Most appropriate sub-area of p5.js?

• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] Dom
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [X] WebGL
• [ ] Other (specify if possible)

Details about the bug:

• p5.js version: 1.1.9
• Web browser and version: Chrome 83
• Operating System: OSX Mojave
• Steps to reproduce this: https://editor.p5js.org/aferriss/sketches/X-kF7aVT8

As far as I can tell resetShader() isn't doing any resetting. I haven't dug too deeply into this so I'm not sure what might be going on but it looks like setting userFillShader and userStrokeShader to null is not enough to reset the custom shaders. Oddly, if I place my initial calls to shader() inside of setup, resetShader() does seem to work if I do my non-custom shader drawing inside of draw.

Here's a small example showing the issue
https://editor.p5js.org/aferriss/sketches/X-kF7aVT8

[matvs]

Hi @aferriss
Thanks for reporting this bug.

It looks like rendering order is an issue here.
https://editor.p5js.org/matvs/sketches/_rtBhhm-h
I am working on it :)

[matvs]

It seems to me, that there is actually nothing wrong with resetShader() function.

In my previous example one can see, that the green square is actually rendered, but either drawing order is false or z coordinate of red square is higher.

It looks like it is the latter, because adjusting position.z in vertex shader solves the issue: https://editor.p5js.org/matvs/sketches/FG-Lz2Oon

It can also be solved directly in JS with for example applyMatrix or transform.

I don't think that it is a bug in p5.js, because it simply respects how shaders are defined.

[aferriss]

Ah, this is good to know! Thanks for looking into it. I wonder if there is anything we can add to the docs to make people aware of the fact that depth will be taken into account over draw order.