shader program about pex-next HOT 4 CLOSED

Meant to add:

If you guys have thoughts on how it could be structured, or things that look weird, or parts of it that might be easy to break off into separate modules for Pex/Foam, let me know. It's pretty early stages right now.

from pex-next.

@mattdesl Thanks for that. It's a bit early to define where pex will go but to sum up:

Currently new Program(vertSrc, fragSrc) takes context from global singleton pex-glu/Context this has number of issues:

• having two WebGL canvases on one page is tricky (a async loaded asset can end up to fire callback in another window's draw() function and result in wrong context exception)
• requiring pex-glu twice (from two different sources e.g. as a sub module) is not possible because you end up with different Context objects
• Context.currentContext is set in Window class just before calling init() and draw()
• We have program.uniforms.texture(0) but material.uniforms.texture = textureObj
• We have texture/fbo .bind() but program.use()

My current ideas about where Program/Shader should go next

• pass gl object directly at the Program construction time to avoid context issues
• use .bind()
• remove Material abstraction
• bind mesh to shader, not shader to mesh to again avoid coupling in Mesh class, allow for custom attribute locations, VAOs, remove Mesh<-->Material coupling, allow re rendering mesh with different materials

Your API is definitely in the right direction as it provides solution for most of the things above. One thing that needs more discussion with @automat is functional / procedural style of factory function createShader(gl, {vert:, frag:}) vs new Shader(gl, vert, frag) and naming Shader vs Program.

from pex-next.

Cool. 👍 Sounds like we are both more or less working toward a similar goal.

Right now all my constructs accept a gl parameter as the first parameter. This is pretty clean, ends up being easy to modularize (not coupled to a "framework" itself), handles multiple contexts etc. But it has some downsides, and in the end I may revisit it:

• there is no "safe" or optimal way to cache something like max texture size so you often end up with redundant get calls to GL state
• there is also no safe or clean way of caching currently bound GL states like blend/attributes, so you end up with a lot of redundant changes

Regarding functional style. I'm cool with doing more prototypes for these low-level utils, like I've started in texture. But I usually don't export new on the end-user for a couple reasons:

• it adds additional overhead for the user; they can't just treat it as a function like this
• your implementation is now locked to a class, changing it to a factory function for some feature like this would be a breaking change
• it implies a Class that the user can "extend" -- this tends to be pretty fragile
• it looks ugly with inline requires: var shader = new (require('shader-program'))(gl, vert, frag)

I'm sure there will be disagreements at this "high level" as we are working toward different goals/audiences/etc... But even if we only end up sharing some of the "low level" functions/modules, it will still be better than not sharing any code at all. 😄

from pex-next.

Not relevant given new pex-context@2

from pex-next.