gl-react icon indicating copy to clipboard operation
gl-react copied to clipboard

Node: escape hatch for more advanced WebGL stuff

Open gre opened this issue 8 years ago • 5 comments

Node should expose a more generic escape hatch to use gl and do any WebGL stuff.

Node should expose a basic way to implement your own draw(). that way, people can do whatever they want with gl, but the contract should be clear (should you still receive the uniforms? is the shader in the scope? should there be a more generic contract that Node implements?). The simplest example is to call gl.clear() to fill a color. Try regl in this paradigm. Try Three.js in this paradigm.

The main problem is most WebGL libs are intrusive and alter the gl state (e.g. they don't expect to just draw in the current bounded framebuffer).

e.g. https://github.com/mrdoob/three.js/issues/7483#issuecomment-264195243

gre avatar Dec 07 '16 11:12 gre

actually, might instead have an escape hatch at the Surface level for now.

I imagine there could be a mix with some <Node> e.g. if you want to compute something in a FBO and use it yourself,.. but it's an edge usecase.. The important part is the escape hatch only used, needs to be equivalent to do WebGL vanilla, there should probably be no call to gl API at all in such case.

gre avatar Mar 14 '17 07:03 gre

for gl-react-native, needs to create a polyfill Image class and expose it, an instance of this would be accepted as pixels data.

gre avatar Mar 14 '17 07:03 gre

maybe gl-react-native should simply expose the lower level GLView. Surface is already in gl-react Surface/Node paradigm. maybe eventually we can think of Surface/Node escape hatch.

gre avatar Mar 14 '17 07:03 gre

status update: gl-react-native now expose the EXGLView directly, but there is still a usecase to have such an escape hatch that you want to render something with a lib into a FBO and pipe the result to the gl-react stack of effects.

probably this would not be part of <Node> like initially stated, but instead be a new component.. the main concern with libs like Three.js is we need them to draw on a specific framebuffer and not directly on the canvas. so it might be something to fix in Three.js if we want the interop possible.

we also need to figure out how it would be possible to "save & restore" the GL states across libs and this sounds the main headache to having this whole feature possible maybe https://github.com/stackgl/gl-state solves that but also need to see if it's not an overhead to have

gre avatar Jul 20 '17 08:07 gre

Awesome, following this thread.

robertjuh avatar Apr 23 '18 12:04 robertjuh