Make shaders define what they get used for. #7256

Garima3110 · 2024-09-09T03:45:38Z

This is a work in progress addressing the issue ##6759

PR Checklist

npm run lint passes
Inline documentation is included / updated
Unit tests are included / updated

perminder-17 · 2024-09-09T19:32:20Z

Great job so far, Garima! The idea is that when you call shader(yourShader), it should only apply to fills, regardless of other settings, like the uStrokeShader uniform or whether lights() is used in the sketch.

Currently, methods like isLightShader()

p5.js/src/webgl/p5.Shader.js

Line 983 in 349b7d4

isLightShader() {

check which uniforms are defined, and if any are defined, the function returns true. This allows us to apply fill shaders when lights() is used in sketches.

One possible solution would be to remove these methods that check whether uniforms and attributes are defined. Instead, we can directly set the appropriate user shader based on the method the user calls, such as strokeShader(shader) for stroke shaders.

Also, we should modify the function _getRetainedFillShader() written here:

p5.js/src/webgl/p5.RendererGL.js

Line 1768 in 349b7d4

_getRetainedFillShader() {

We could probably return the user-defined fill shader if present, or light shader if no fill is set. I guess this should work for fill shaders since _getLightShader() is returned when lighting is enabled or a texture is present. That's it for fill shaders, I can leave more reviews for strokeShaders and imageShaders as we proceed further but it's pretty similar for those methods also. Thankyou so much for working on it.

perminder-17 · 2024-09-09T19:36:05Z

src/webgl/p5.Shader.js

@@ -1012,6 +1012,10 @@ p5.Shader = class Shader {
    return this.uniforms.uStrokeWeight !== undefined;
  }

+  isImageShader() {


I think we don't need this method because we don't want our imageShader(yourShader) method to work depending on some uniforms (uImageSampler for your case). We could probably take this one out.

perminder-17 · 2024-09-09T19:36:41Z

src/webgl/material.js

-    this._renderer._useNormalMaterial = false;
-  }
+  // Always set the shader as a fill shader
+  this._renderer.userFillShader = s;


Garima3110 · 2024-09-11T19:17:44Z

Thanks for the suggestions @perminder-17 !
I have made the suggested changes, and the fill shaders seem to be fixed. Please have a look , if everything seems fine I'll work further with the docs and other shaders too.
Thankyou!

perminder-17 · 2024-09-12T09:11:38Z

src/webgl/p5.RendererGL.js

    }
-    return fill;
+    if (this._tex) {


Can we use the OR operator here and combine it into a single if statement? Something like:

if(this._enableLighting || this._tex) return this._getLightShader();

Can this make the code cleaner instead of using two separate if blocks?

perminder-17 · 2024-09-12T09:38:53Z

Great work @Garima3110 so far. I tested it, and it seems to be working well. But to be double sure, I'll test it again to make sure nothing is breaking. In the meantime, you should focus on completing the documentation for the fill shader to meet the first week's target.

The documentation should include: (these are just my thoughts, feel free to add your own explanations if you have any).

A description stating that the fill shader applies only to fills. (explain it in your way)
Reference links to other shaders (strokeShader, imageShader) with a brief explanation, just one line for each of them.
2-3 example sketches for the tutorial, showing how when lights() are enabled, it returns this._getLightShader() (which is a light shader). When lights() are not enabled, it uses the fill shader and returns the fill. Don't go too deep into p5.js's internal system, but give users a basic idea of what’s happening at the backend as well.

Also, talking about the strokeShaders here's the method created

p5.js/src/webgl/p5.Shader.js

Line 1020 in 12e6276

isStrokeShader() {

You can remove the method and update the function here as well: (just you did for fill shaders)

p5.js/src/webgl/p5.RendererGL.js

Line 1710 in 4a2f704

_getImmediateStrokeShader() {

and then we can move to the docs of strokeShader() as well.

Let me know if strokeShader() works for you.

I think we also need to alter some tests created for shaders, will update you for the tests as we completes the docs and code of this project.

Thanks again for your work. :)

Garima3110 · 2024-09-12T11:30:47Z

Thanks for the follow up @perminder-17
I'll work on these and get back to you soon!

Garima3110 · 2024-09-13T07:49:01Z

I have done all changes in docs and examples for fill shaders, please have a look @perminder-17
And just to mention I'm starting the work for strokeShader() too.

perminder-17 · 2024-09-13T15:49:11Z

Great work @Garima3110 so far. I tested it, and it seems to be working well. But to be double sure, I'll test it again to make sure nothing is breaking. In the meantime, you should focus on completing the documentation for the fill shader to meet the first week's target.

Just an update, previously i mentioned the wrong block of code by mistake. I just saw when you pushed it you need to remove the isStrokeShader() code. I have edited the above comment now.

p5.js/src/webgl/p5.Shader.js

Line 1020 in 12e6276

isStrokeShader() {

perminder-17 · 2024-09-14T20:10:27Z

src/webgl/p5.Shader.js

@@ -579,9 +579,6 @@ p5.Shader = class Shader {
    const modelViewProjectionMatrix = modelViewMatrix.copy();
    modelViewProjectionMatrix.mult(projectionMatrix);

-    if (this.isStrokeShader()) {
-      this.setUniform('uPerspective', this._renderer._curCamera.useLinePerspective ? 1 : 0);


I think we use uPerspective uniform in our line.vert file here:

p5.js/src/webgl/shaders/line.vert

Line 31 in 4fbbaf5

uniform int uPerspective;

So, we could keep them without the if block as well. Otherwise we would not be able to use uPerspective unfiorm and could throw errors.

perminder-17 · 2024-09-14T20:13:46Z

src/webgl/material.js

+ * process each pixel on the canvas. This only affects the fill (the inside part of shapes),
+ * not the strokes (outlines).
+ * If you want to apply shaders to strokes or images, use the following methods:
+ * - **[strokeShader()](#/p5/strokeShader)**: Applies a shader to the stroke (outline) of shapes, allowing independent control over the stroke rendering using shaders.


Okay, I was thinking to add these references at the last.
Like at first we could have our fill shader explanation.
At the middle we could have our example sketches how it works.
After the sketches we could have the references of strokeShader() and imageShader(). Let me know if that sound's okay to you?

Yeah that too makes sense, I'll do that no worries!

perminder-17 · 2024-09-14T20:28:45Z

As we're making breaking changes in this PR, we’ll end up with two distinct methods for applying shaders: strokeShader() and imageShader(). I'm considering whether we should also rename shader() to fillShader() for consistency. I'd like to get the WebGL stewards' thoughts on this. Tagging: @davepagurek @lukeplowden @stalgiag @aferriss @aceslowman, @ShenpaiSharma, @teragramgius, @JazerUCSB, @richardegil, @itsjoopark, @Gaurav-1306, @jeanetteandrews

The advantage of renaming it would be creating a clearer, more defined structure: fillShader() for fills, strokeShader() for strokes, and imageShader() for images. However, a potential downside is that users have grown accustomed to using shader() over the years, especially since fill shaders are used most often. This change might cause some confusion for long-time users. What are your thoughts on this?

Here's how it looks as of now:

Screencast.from.15-09-24.01.13.59.AM.IST.webm

Garima3110 · 2024-09-14T21:19:04Z

Thank you for raising this discussion @perminder-17 !

Well, I would also like to add something to your suggestion, I see the potential value in renaming shader() to fillShader() for consistency alongside strokeShader() and imageShader(). However, I believe it would be better to keep the name shader() as it is. My reasoning is that in p5.js, we often retain a feature's basic name based on its default behavior, without explicitly naming it according to that behavior.
The shader() function naturally applies to fills by default, and users are familiar with this behavior. Renaming it could introduce unnecessary complexity or confusion, especially for those who have been using p5.js for a long time. By keeping shader() intact, we maintain simplicity while introducing strokeShader() and imageShader() for more specific cases.

This approach aligns with how we’ve handled similar features, where the core functionality remains intuitively named, while specialized methods are introduced for distinct use cases.
I’d love to hear your thoughts on this approach and whether this strikes a good balance between clarity and consistency.
Thankyou!

lukeplowden · 2024-09-15T09:19:17Z

Looks good @perminder-17 !

I agree with @Garima3110, I don't think shader() should be changed to fillShader(). It's breaking, but I also think it's better to leave the name general because shader() may be used for things which aren't really 'fills'. For example you don't have to draw the results of a shader() call directly to the screen inside of p5.Framebuffer.draw(), it could be a post processing pass, or it could be related to instancing using endShape(). Eventually they might affect fill colour but I think the general function name is more intuitive.

With imageShader() is the idea to affect image() calls? I'm curious to see how that one will work!

davepagurek · 2024-09-15T10:57:20Z

I think I also agree with @lukeplowden and @Garima3110. Maybe the way to think about it is not in terms of fills and strokes, but in terms of materials and strokes. I suppose fill is actually just one component of an object's material, in addition to other properties like texture or shininess. Strokes are a separate system which adds something on top of the base material. In that view of everything, the material system is the main one you interact with and includes the most stuff, so treating it like the default in its naming feels right to me.

One thing that's not super clean about the model I just described is that images are kind of just a separate system, and regular objects that have a material and stroke can't go through the image system, and likewise, images don't get materials and strokes. I think that's fine, since we want images to always draw an image, so making overriding of image() very separate and explicit probably will help avoid accidental overrides and confusion. So I see image shaders as maybe more of a convenient way for developers to change small bits about image drawing and still take advantage of the fit and fill options of image() rather than a core part of the material/stroke system I guess.

…aders

perminder-17 · 2024-09-19T00:40:24Z

Thankyou @lukeplowden @davepagurek and @Garima3110 for your thoughts.

With imageShader() is the idea to affect image() calls? I'm curious to see how that one will work!

We are now planning to create a method that will only affect image calls. In simple terms, we are separating our methods because in many scenarios, we have seen that sometimes fill gets applied to images and sometimes it doesn't, which causes problems and confusion see here: #6327 , #6564 . To avoid accidental shaders being applied and also to avoid confusion, we will create a new method called imageShader() that will specifically handle shaders for images called through the image() function.

I’d also like your thoughts on something related to the question, which may seem obvious but I want to confirm. Do you think the image() function should be influenced by shader()? Or, put simply, should shader() ignore image() calls?

perminder-17 · 2024-09-19T21:00:05Z

Okay, @Garima3110 currently, the imageShader is not working. As we discussed on the call, we need to troubleshoot some functions.

For example, if you see the code

p5.js/src/webgl/p5.Shader.js

Line 1374 in 5fbde13

isTextureShader() {

we check if this.samplers.length > 0 so, when it returns true that means we have our image in our shader and we are currently using it (by calling uniform sampler2D uSampler and also using it).

For now, it’s worth disabling the fill shader effect for images, as @davepagurek's inclination was also towards not using fill shader for effecting image. For doing that, We can update the function

p5.js/src/webgl/p5.RendererGL.js

Line 1768 in 5fbde13

_getRetainedFillShader() {

by adding an extra condition which could handle isTextureShader().

Then, for imageShader() we can create a new function to return _getLightShader() when isTextureShader() is true.

Also, we could add example of by shaderHooks for only strokeShader() by studying this interesting tutorial. #7149 (comment) .

perminder-17 · 2024-09-19T21:02:41Z

src/webgl/material.js

+ * The shader will be used for:
+ * - Strokes only, regardless of whether the uniform `uStrokeWeight` is present.
+ *
+ * @method strokeShader


A question @davepagurek, since we need to add docs for strokeShader utilising shaderHooks. I see we have a method with same name strokeShader in shaderHooks as well. Do you think the method created in shaderHook PR will override this method (because they are with the same name)?

We've renamed the shader hooks method now to be baseStrokeShader, but I'm just commenting here to mention that we'll probably need to update the examples for that after this is merged. Currently, the shaders made with it are applied via shader(). I think after this change, they will need to be applied with strokeShader().

Sure thing! @davepagurek , thanks for the reminder

Garima3110 · 2024-09-19T22:19:38Z

Thank you for bringing this up! @perminder-17

I’d also like your thoughts on something related to the question, which may seem obvious but I want to confirm. Do you think the image() function should be influenced by shader()? Or, put simply, should shader() ignore image() calls?

From my perspective, the motivation behind introducing a separate imageShader() method is to bring greater clarity and control to the way shaders are applied in p5.js. Specifically, this new method would target images drawn using the image() function, thereby avoiding the confusion and unintended behavior that can arise when shader() affects image rendering.

Considering the issues mentioned (#6327, #6564), I would say that the shader() function should not influence image() calls. Instead, shader() should be reserved for fills, and strokeShader() should handle strokes. Meanwhile, the newly proposed imageShader() method, which me and @perminder-17 are currently working on, would exclusively manage shaders, for images drawn with the image() function.
I would also like to know what others have to say on this one!
Thankyou.

davepagurek · 2024-09-20T15:37:40Z

Ahh @perminder-17 you're right, those methods are going to clash, so we'll have to rename something. Maybe the hooks ones should be renamed to defaultStrokeShader() instead of just strokeShader()? It's a little verbose, maybe someone else has a better name idea?

perminder-17 · 2024-09-20T15:40:10Z

src/webgl/p5.RendererGL.js

-      }
-    } else if (!fill /* || !fill.isColorShader()*/) {
-      return this._getColorShader();
+    if(fill && !fill.isTextureShader()){


aah....._getRetainedFillShader() is for shapes, not images. You need to modify getImmediateFillShader(), specifically where we are checking

if (this._tex) { ..... }

to properly handle images.

We could change the condition to :

Suggested change

if(fill && !fill.isTextureShader()){

if(fill ){

since, isTextureShader() is not checking for image. it's done in _getImmediateFillShader()

perminder-17 · 2024-09-20T15:46:45Z

src/webgl/p5.RendererGL.js

+  _getRetainedImageShader() {
+    const imageShader = this.userImageShader;
+    if (imageShader && imageShader.isTextureShader()) {
+      return this._getLightShader(); // Return light shader if the shader is a texture shader
+    }
+    return imageShader || this._getColorShader(); // Default to color shader if no image shader is defined
+  }
+


no need for these many conditions.
Just you have to do is:
If a texture is present, it then checks if the imageShader is either missing or not set up for handling textures. If that’s the case, use light shader. Otherwise, it simply returns the existing imageShader.

Also, you should rename it to getImmidiateImageShader

p5.js/src/webgl/p5.RendererGL.Immediate.js

Line 510 in e624307

p5.RendererGL.prototype._drawImmediateFill = function(count = 1) {

Also, we need to create something like _drawImmediateFill for images where we could use _getImmidiateImageShader in the function to make it working.

perminder-17 · 2024-09-20T15:54:56Z

defaultStrokeShader

How about lineShader() @davepagurek ? For hooks?

davepagurek · 2024-09-20T15:57:10Z

That also works for me. I guess the stroke one is the only naming conflict because the shader used internally for images is the material shader, and we're just using shader() to set that?

perminder-17

Thanks to everyone, @Garima3110 and @davepagurek . Things have started coming at a good form. Will request @Garima3110 to add visual tests for all the shaders and could remove/update the previous test where it used the function isTextureShader() or isLightShader() which we currently don't have, that's the main reason of our tests to fail.

perminder-17 · 2024-10-11T21:51:32Z

src/webgl/p5.RendererGL.js

+  _getImmediateImageShader() {
+    const imageShader = this.userImageShader;
+    if(imageShader) {
+      return imageShader;
+    }
+    return this._getImmediateModeShader() ; 
+  }
+
+


we could probably make just one method for all three, _getImmediateImageShader(), _getImmediateFillShader() and _getRetainedFillShader() and could name as _getFillShader() something like that.

The only problem could be with the overriding of imageShader() with the beginShape/endShape part, so we could probably add a logic here:

p5.js/src/webgl/3d_primitives.js

Line 3437 in 5810754

this.beginShape();

something like:

this._drawingImage = true; this.beginShape(); // ... this.endShape(); this._drawingImage = false;

and for the _getFillShader() I am talking about, it could look something like:

getFillShader() { if (this._drawingImage) { return this.userImageShader; } else if (this.userFillShader) { return this.userFillShader; } else if ...

Really thanks to @davepagurek for his suggestions on this.:)

perminder-17 · 2024-10-11T21:52:42Z

src/webgl/p5.RendererGL.js

+        point: this.GL.createBuffer(),
+        image: [
+          new p5.RenderBuffer(3, 'imageVertices', 'imageVertexBuffer', 'aPosition', this, this._vToNArray),
+          new p5.RenderBuffer(2, 'imageUVs', 'imageUVBuffer', 'aTexCoord', this, this._flatten)
+        ]


could be reverted, I don't think we need this.

perminder-17 · 2024-10-11T21:53:36Z

src/webgl/p5.RendererGL.Immediate.js

+ * and drawing the image geometry.
+ * @private
+ */
+p5.RendererGL.prototype._drawImmediateImage = function(count = 1) {


Could probably remove the whole function. Since the logic with merging it, this._drawingImage will take care of that.

perminder-17 · 2024-10-11T21:54:19Z

src/webgl/p5.RendererGL.Immediate.js

+      let fillShader = this._getImmediateFillShader();
+      let imgShader = this._getImmediateImageShader();
+
+      if (this.textureMode === constants.IMAGE && imgShader) {
+        usimageShader(imgShader);
+        this._drawImmediateImage(count);
+      }
+      else {
+        shader(fillShader);
+        this._drawImmediateFill(count);
+      }
+


Could be reverted.

perminder-17 · 2024-10-11T21:55:04Z

src/webgl/p5.RendererGL.Immediate.js

+    if(imageShader){
+      // We have an image shader, normalize UV coordinates based on texture dimensions
    if (this._tex !== null) {


I don't think we need any extra checks, Could be reverted.

Garima3110 · 2024-10-12T04:41:14Z

Thanks for all the suggestions to you @perminder-17
Special thanks to @davepagurek too for his valuable insights !
I'll work on these and aim to finish it super soon!

perminder-17

Looks great so far, we are just on the last bits.

src/webgl/p5.RendererGL.js

perminder-17 · 2024-10-12T13:34:57Z

src/webgl/p5.RendererGL.js

+    else if (this._enableLighting || this._tex) {
+      return this._getLightShader();
+    }
+    else {


could probably remove this else block, it's obvious that it could return this._getColorShader(); .

we could just write return this._getColorShader(); without the else block.

ok @perminder-17 I'll soon push these suggested changes.
Thankyou!

perminder-17 · 2024-10-13T17:56:01Z

test/unit/visual/cases/webgl.js

+          `
+        );
+        p5.strokeShader(strokeshader);
+        p5.noFill();
+        p5.strokeWeight(2);
+        p5.rect(-20, -20, 40, 40);
+        screenshot();
+        resolve();
+      });


As I could see, this code produces a white canvas, so it's not good to test strokeShader this way. Probably could do with the baseShaderHooks, or maybe the examples for reference you added for strokeShaders.

perminder-17 · 2024-10-13T17:59:05Z

test/unit/visual/cases/webgl.js

+          `
+          precision mediump float;
+          void main() {
+            gl_FragColor = vec4(gl_FragCoord.x / 100.0, 0.5, gl_FragCoord.y / 100.0, 1.0);


Probably could just be a vec4(1.0,0.0,0.0,1.0) red color. Actually not sure what this will produce, so could just add a simple visual test for it. And could turn on lights(), texture(img) and all won't effect any thing in the result.

perminder-17 · 2024-10-13T18:01:03Z

test/unit/visual/cases/webgl.js

+      );
+      p5.imageShader(imgShader);
+      p5.texture(img);
+      p5.noStroke();
+      p5.rect(-25, -25, 50, 50);
+      screenshot();
+    });


imageShader() applies to image() function and not with texture(img) followed with rect. So, it could be a better check to just see weather imageShader() is not applying to these. But we could also add a test for image(img,0,0) to test weather imageShader probably applies to image or not.

perminder-17 · 2024-10-13T18:04:25Z

src/webgl/material.js

 * }
 * `;
 *
 * function setup() {
 *   createCanvas(100, 100, WEBGL);
+ *   fillShader = createShader(vertSrc, fragSrc);


I think, we could include a shaderHooks example for fillShader, by removing one example.

perminder-17 · 2024-10-13T18:58:24Z

Just a question: Suppose we render something, like a rectangle with a red color, and then apply the filter(BLUR) function. Naturally, the result is a slightly blurred red rectangle. Now, if we also use a shader where gl_fragColor = vec4(green color), it would produce a blurred green rectangle.

But here's where it gets interesting: If we use imageShader(), it would render a completely red canvas. This happens because we're creating a framebuffer that matches the canvas size here :

p5.js/src/webgl/p5.RendererGL.js

Line 1057 in c377b53

let fbo = this.getFilterLayer();

and then using the image() function to render the contents of the framebuffer (FBO) back onto the main canvas or target .

p5.js/src/webgl/p5.RendererGL.js

Line 1170 in c377b53

this._pInst.image(fbo, -target.width / 2, -target.height / 2,

This behavior also impacts panorama(img), likely because it uses filter shaders. So, I am thinking if we could disable imageShader() when applying filters?

Or maybe we could add some extra conditions to _getFillShader() by adding a boolean variable maybe (this._drawingFilter) at filter block, where when image() is called with filters, how imageShader() should effect without any effect via shader() anything else. If a model is rendered with filters() how it should react with imageShader() (should be ignored) and shader() should work.

@davepagurek, can you give a thumbs up if you agree?

Garima3110 · 2024-10-13T19:21:51Z

I completely agree with the suggestion made above by @perminder-17 . The key issue lies in how imageShader() interacts with the framebuffer, especially when filters like filter(BLUR) are applied.

So according to me also, introducing a condition to disable imageShader() when filters are being applied, or adding a boolean like this._drawingFilter within the filter block in _getFillShader(), would help address this issue. It would allow filters to function as expected without interference from shaders, and maintain the correct interaction when both are used together.

davepagurek · 2024-10-14T16:04:02Z

Agreed, filters shouldn't be affected here.

If you're curious, I was talking a bit here #7270 (comment) about refactoring how some of these things work so that there are "safe" functions we can call internally without user code leaking in. For now I think we just have to know to disable user shaders here.

perminder-17 · 2024-10-14T20:52:09Z

src/webgl/p5.RendererGL.js

-        return this._getNormalShader();
+  _getFillShader() {
+    // If a filter like BLUR is applied, disable imageShader
+    if (this._drawingFilter) {


Have you tested it? I think you need to include this._drawingFilter = false initally and then in filter(...args){ you need to make it true so it could catch the filter() calls.

perminder-17 · 2024-10-15T16:37:08Z

src/webgl/p5.RendererGL.Retained.js

@@ -133,8 +133,10 @@ p5.RendererGL.prototype.drawBuffers = function(gId) {
    this.retainedMode.geometry[gId].vertexCount > 0
  ) {
    this._useVertexColor = (geometry.model.vertexColors.length > 0);
-    const fillShader = this._getRetainedFillShader();
+


add an extra condition here,

let fillShader; if (this._drawingFilter && this. userFillShader){ fillShader = this.userFillShader; } else { fillShader = this._getFillShader(); }

perminder-17 · 2024-10-15T16:38:51Z

src/webgl/p5.RendererGL.js

+    }
+    // If drawing an image, use the image shader or light shader
+    else if (this._drawingImage) {
+      if(this.userImageShader){


like, instead of adding an extra condition can we just do something like

if(this.userImageShader && !this._drawingFIlter){ // your code } else{ return this._getLightShader(); }

perminder-17 · 2024-10-15T16:41:09Z

src/webgl/p5.RendererGL.js

@@ -575,6 +575,7 @@ p5.RendererGL = class RendererGL extends Renderer {
    this.userFillShader = undefined;
    this.userStrokeShader = undefined;
    this.userPointShader = undefined;
+    this.userImageShader = undefined;


above this, where every boolean variables are defined and set to false, you need to set there this._drawingFilter = false;

and at the function

filter(...args) { // where the image call is present, above that set the this._drawingFilter = true; this._pInst.image(fbo, ....)

Alright @perminder-17 working on these changes.!

Garima3110 · 2024-10-15T20:22:46Z

@perminder-17 I have made all the changes, please have a look and let me know if any other thing needs to be updated.
Thankyou!

perminder-17

Thankyou so much @Garima3110 for working through everything. I request @davepagurek to give a round of review.
here's the build : https://editor.p5js.org/aman12345/sketches/fzhPwc8Hr (from the main branch)

Basic methods written and other related changes done

6421777

perminder-17 reviewed Sep 9, 2024

View reviewed changes

Updated code for fill shaders

621dbcb

perminder-17 reviewed Sep 12, 2024

View reviewed changes

Fill shader documentation+code examples complete

c696a4a

Qianqianye added the p5.js 2.0 label Sep 13, 2024

Changes in Stroke shaders

1f64472

perminder-17 reviewed Sep 14, 2024

View reviewed changes

Garima3110 and others added 3 commits September 15, 2024 19:35

Stroke shaders documentation and code changes done

955fcc5

Merge branch 'dev-2.0' of https://github.com/processing/p5.js into sh…

6fbd3e0

…aders

Merge branch 'dev-2.0' into shaders

937d073

perminder-17 reviewed Sep 19, 2024

View reviewed changes

Changes in Image shaders

bb39efe

perminder-17 reviewed Sep 20, 2024

View reviewed changes

Garima3110 added 3 commits October 9, 2024 20:43

Fix on the affected base shaders

db82c11

Cleanups

f13ddb0

Image shader

734f354

perminder-17 reviewed Oct 11, 2024

View reviewed changes

Garima3110 added 2 commits October 12, 2024 15:53

Image shaders working

02042f6

Image shader inline docs

11eee41

perminder-17 reviewed Oct 12, 2024

View reviewed changes

Garima3110 added 3 commits October 12, 2024 19:34

Minor changes

ba793c3

Visual tests added

9c7ef5a

Unit tests updated/deleted

6cbca22

perminder-17 reviewed Oct 13, 2024

View reviewed changes

Garima3110 added 2 commits October 14, 2024 23:14

Visual tests updated

1d4a3ee

minor changes

a4867c3

perminder-17 reviewed Oct 14, 2024

View reviewed changes

perminder-17 reviewed Oct 15, 2024

View reviewed changes

Garima3110 added 2 commits October 16, 2024 00:17

Minor fixes

394eedd

cleanups

03faf7b

perminder-17 approved these changes Oct 15, 2024

View reviewed changes

davepagurek added 3 commits October 17, 2024 15:05

Merge branch 'dev-2.0' into shaders

a414e6b

Fix a few lingering merge issues, remove unused files

aeb5a39

Remove more lingering unused methods

26c88bb

davepagurek merged commit 39aab83 into processing:dev-2.0 Oct 17, 2024
2 checks passed

Garima3110 deleted the shaders branch November 2, 2024 08:03

Garima3110 restored the shaders branch November 2, 2024 08:04

Garima3110 deleted the shaders branch November 2, 2024 08:04

Make shaders define what they get used for. #7256

Make shaders define what they get used for. #7256

Conversation

Garima3110 commented Sep 9, 2024

PR Checklist

perminder-17 commented Sep 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Garima3110 commented Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

perminder-17 commented Sep 12, 2024 • edited Loading

Garima3110 commented Sep 12, 2024

Garima3110 commented Sep 13, 2024

perminder-17 commented Sep 13, 2024 • edited Loading

perminder-17 Sep 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

perminder-17 commented Sep 14, 2024

Garima3110 commented Sep 14, 2024

lukeplowden commented Sep 15, 2024 • edited Loading

davepagurek commented Sep 15, 2024

perminder-17 commented Sep 19, 2024

perminder-17 commented Sep 19, 2024

perminder-17 Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Garima3110 commented Sep 19, 2024

davepagurek commented Sep 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

perminder-17 commented Sep 20, 2024 • edited Loading

davepagurek commented Sep 20, 2024

perminder-17 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Garima3110 commented Oct 12, 2024

perminder-17 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

perminder-17 commented Oct 13, 2024 • edited Loading

Garima3110 commented Oct 13, 2024

davepagurek commented Oct 14, 2024

Choose a reason for hiding this comment

perminder-17 Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Garima3110 commented Oct 15, 2024

perminder-17 left a comment

Choose a reason for hiding this comment

perminder-17 commented Sep 9, 2024 •

edited

Loading

Garima3110 commented Sep 11, 2024 •

edited

Loading

perminder-17 commented Sep 12, 2024 •

edited

Loading

perminder-17 commented Sep 13, 2024 •

edited

Loading

perminder-17 Sep 14, 2024 •

edited

Loading

lukeplowden commented Sep 15, 2024 •

edited

Loading

perminder-17 Sep 19, 2024 •

edited

Loading

perminder-17 commented Sep 20, 2024 •

edited

Loading

perminder-17 left a comment •

edited

Loading

perminder-17 commented Oct 13, 2024 •

edited

Loading

perminder-17 Oct 15, 2024 •

edited

Loading