Introduce Depth Access for Filters Functionality

[perminder-17]

Increasing access

The feature request entails an enhancement to the current functionality of the filters() function. It proposes the addition of a third parameter, allowing for depth access when applying filters.

Most appropriate sub-area of p5.js?

• [ ] Accessibility
• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [X] WebGL
• [ ] Build process
• [ ] Unit testing
• [ ] Internationalization
• [ ] Friendly errors
• [ ] Other (specify if possible)

Feature request details

This parameter would be utilized in the following format: filter(BLUR, BLUR-VALUE, DEPTH). Previously, our implementation relied on p5.Graphics, which facilitated filter access through a hidden WEBGL canvas. Now, with the transition to framebuffers, which serve a similar purpose, we have the opportunity to incorporate depth into filter shaders. Initially, this update will focus on integrating depth into filters applied through framebuffers. Subsequently, we plan to extend this capability to encompass 2D filters as well, ensuring a comprehensive enhancement to our filtering system. Maybe giving depth access to 2D filters can be a follow-up update.

Following the implementation of depth buffers for filters, we can expand the range of available filters that utilize depth, such as adding a Fog filter. The addition of depth is crucial for the Fog filter, as it enables objects closer to the viewer to be less obscured by fog, while objects farther away appear more obscured.

An image I found from photoshop:- Maybe a depth blur filter will look something like-

Maybe a depth fog filter will look something like:-(maybe fog can be a followup update after adding depth access to filters)

[perminder-17]

Tagging WebGL stewards for their inputs, let me know what you think! @aferriss, @davepagurek ,@aceslowman, @ShenpaiSharma, @ChihYungChang, @teragramgius, @JazerUCSB, @richardegil, @itsjoopark, @Gaurav-1306, @jeanetteandrews

Also let me know what are your plans on the implementation part. Thankyou ;)

[davepagurek]

I think the main technical hurdle here is that we only have access to depth information on framebuffers, so this would involve looking into https://github.com/processing/p5.js/issues/5571 again.

If we have a default framebuffer for the main canvas, we'd need to:

• accept a lack of antialiasing on WebGL1 contexts (anyone have any idea how widespread support is now?)
• handle cases where one might read canvas data and use the framebuffer instead
  • Setting uniforms in shaders?
  • Load/update pixels functions
• Figure out when to draw the main fbo to the main canvas to make it visible
  • Maybe at the end of draw?
  • Do people often step through line by line in a debugger? We'd lose that if we only flush to the main canvas once
  • How do we handle drawing outside of draw, e.g. in button click handlers?