Also I’m not sure how/if the webGPU-related code would be tree-shaked in a webGL setup and vice-versa.

But all that is interesting, I will think about it !

3/3

Currently the API is designed as a light layer on top of webgl, which makes it difficult to reuse with webGPU.

The idea of sharing functions for both apis is interesting but I’m not sure how to handle their differences.
I would like to keep it low-level, the focus is on writing shaders

2/3

Indeed, but their arguments are more low-level and close to the webgl api (at least currently), and:

- in webGPU we can write fragment and vertex shaders in one string
- many things become a kind of « buffer »
- compute shaders, pipelines, bind groups etc don’t exist in webgl

1/3

Good point, writing similar functions in webGPU has crossed my mind.

But since they are low level and the webGPU API is quite different, I don’t think the same functions will work for both. So either it will be another lib, or I use 2 prefixes (glCanvas / gpuCanvas), which seems consistent

Most functions create and/or initialize something so it would rather be createXXX, but I don’t really like that 🤔

Ok I understand, in my case I think it would be something like « createRenderPass(…) », but it seems a bit verbose to me.

I also thought about a « gl » prefix, like glRenderPass(). It’s shorter and allow to separate WebGL related stuff from JS utils. I think I like this one.

What do you think ?

Also, I don't know what other names to use:

I can't remove the "use" because the functions would have the name of the object they return. e.g, "const compositor = compositor(...)" is not possible.

And I don't want to prefix "createXXX" on all functions.

So yeah, I would appreciate some feedback!

I like the hook-style naming with "use" because the functions actually behave like hooks (output destructuring, re-render when updated etc), but I wonder if they could be confused with "real" hooks or composables in a react or vue codebase.

I'm not sure if it would be a big issue though.

It's as easy as declaring the effects in an array

Haha seems like a lot of fun…
Anyway thank you for your valuable feedback 🙏🏻

Ok this is what I thought. I guess as long as it’s properly documented, any default is acceptable.

I am just struggling to make my bloom effect work on a transparent background so I was wondering how (if) threejs handles that if it uses straight alpha

I see that #threejs has premultipliedAlpha false by default on their Material, so I'm not sure how they handle that throughout the render pipeline, especially with postprocessing.

For my lib I think I'm going to assume premultiplied alpha everywhere, but I would be glad to get some feedback on this

Thanks 🙏🏻
Yes I’m just starting to understand the use of premultiplied alpha. I realized I might have some bugs related to it in the lib I am building.
So I just need to figure out where and when to do the conversion between straight and premultiplied alpha, and properly use gl.blendFunc()

Thanks ! This is combined with bloom and tone mapping so yes it can be pretty bright

Indeed there is potential to make cool loaders !

Thanks !

btw it works with 2 ping-pong buffers that accumulate the previous frames with a light erosion effect to make the tail thinner