Building WebGL libraries that work with each other in the same webgl context.

[trusktr]

Description of the problem

It's difficult and complex these days to mix WebGL libraries together, to draw things using different libraries in the same webgl context. (examples of difficulties: mrdoob/three.js#8147, #3230, #3345, #1366, #298, jonobr1/two.js#233)

For example, suppose we would like to render Three, Babylon, and Pixi objects into the same WebGL context, in the same 3D space.

It is currently very difficult to do this because each WebGL library manages state of the context in their own ways, and these private internals often change and break solutions that people come up with because there's no standard way to do it.

Pixi.js v4 goes through efforts to make Pixi compatible with Three.js, so that it can render in a Three scene, but this is obviously fragile.

Solution

Enter Regl to the party.

Maybe if the foundations for each library (Three, Babylon, Pixi, Two, etc) were built on Regl, we'd have a common way of rendering to a single context.

Regl makes an abstraction just on top of raw WebGL for managing WebGL state. It doesn't render for you all the things that Three.js can, it only provides the minimal foundation for working with raw WebGL in a stateful way that is easy to manage.

It seems that libraries like Three, Babylon, PlayCanvas, Pixi, Two, etc, could benefit from using a standardized way for managing WebGL state, which would make it easy to combine renderings from any of these libraries into the same WebGL context.

---

What are your thoughts on refactoring the foundation of Pixi.js to use Regl for managing WebGL state? Does Regl offer enough flexibility for Pixi.js to do what it needs to do on top of Regl?

[ivanpopelyshev]

I support the idea to try build several interfaces of popular libraries on top of something, because im doing the same thing, but oriented for production, with bonus difficulties, which is Not Safe For Newbies.

Now to bad things: whatever you make would have to exist as an alternative at least for two years, before significant portion of auditory goes for it. Are you ready to dedicate at least half-time rate to support several projects that uses it and grow userbase?

I think Regl is not enough even for pixi-v4, and new v5 of pixi that is developed in several branches has much more functional on low-level than that. The only way to understand whether its versatile enough is to try port pixi on it, that's several weeks at least and I dont want to do it after I saw regl code.

[ivanpopelyshev]

Btw, I did read many articles from 0fps.net , and I admire the author, even wrote him fan mail three years ago. But right now Regl is not enough to reproduce pixi features. Of course you can try :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.