Which solution is better to draw 2d parts that plays well with THREE.js?

Well, our use case is using THREE.js drawing 3d parts, using DOM / SVG to draw 2d parts (like UI elements and something else). We are facing performance problem, so, we must switch to another solution to keep everything runs smoothly.

Some candidates are PIXI, Konva, EASEL.js and Two.js.

I would like to know, which of these libraries can play well with THREE.js? What’s everyone’s insight?

It doesn’t really matter if you use any of them as overlay, but you can’t mix them on the same canvas as each engine (if they even use a WebGL context) maintains their own state.

By using masks you can also give dom elements, svg or other shading from THREE or some mask to actually hide behind other objects. But if things should get mixed, with which type or can be done more reasonable within THREE depends on the very specific case.

For what are the 2D elements used?

@Fyrestar do you know an example of using masks to give DOM elements shading/effects from Three.js?

@DolphinIQ I think this is what @trusktr is doing with Lume
Relevant demo : https://lume.io/docs/#/examples/autolayout-declarative

2 Likes

Here’s one https://codepen.io/Fyrestar/pen/QOXJaJ

2 Likes

Thanks for your reply! Most of our use case is drawing user interface, but sometimes we need do make some “mini games” that would work independently.

The 2d element will always rendered on the top of the 3d layer. All the 2d things won’t have z-axis, will not intersect with any 3d objects in the 3d scene.

Yeah then you can use any of them, while for UI dom is best suited, even some game engines use a webview overlay for UI. So we already have a built-in rich and very extensive layout engine by default ^^

2 Likes

Hi Losses,
I am very curious to know what was causing the performance problems specifically? I have been experimenting with two layers of canvas, one for 2d and the other for 3d. Ideally I wanted to merge the two image feeds into one canvas onscreen. I managed to get both canvasses on seperate workers and in doing so I can’t merge the two canvasses anymore (they get neutered). The compositing of the two layers by the DOM seems to be pretty good though but I didn’t test it all through. The possible advantage may be that the UI layer doesn’t have to have the same fps, especially when nothing moves. And the logic-update fps can also be independend. Offcourse this all uses techniques not readily available everywhere (offscreen canvas, workers -> chrome only I believe). I hope you’ll post the candidate framwork and/or solution you went with!
https://sander-wouter.com/sander/ur/

Hmmmmm, I don’t know anything about workers, googled some information:


it seems your use case would be pretty hard to achieve…

Like user oea, I too am curious about your performance issues you had with SVG.
I’m using svgs into data uri’s on object image textures, though been experimenting with using CSS3D a bunch.
I had reviewed all the libraries you mentioned months ago, though settled on SVG.js but was seriously considering (and may still) go with one you hadn’t mention, which I should recommend: Fabric.js for its easy to implement UI elements.

I also use Easel.js with anything created in Adobe Animate for overlays, menus.

Yes workers are a real pain. I do not recommend them yet, as they are not widely supported or understood. It is good to read for example on the link you provided that using workers for graphics number crunching might not be optimal and that workers are (mostly) used for path planning or AI, ie other heavy number crunching domains. It was merely to show another option as I hope workers and such will be more used by the community.
The pain stems from the DOM not being available in workers. For the webgl layer I got into problems with OrbitControls for example which relies on de DOM for events. Most solutions I found online create a sort of proxy document or window class. Besides not being a fan of those kind of solutions I think I can state that it makes it more difficult in general and that it feels like you are working “against the grain” anyway since there is a reason workers can’t access the DOM.
So yeah, perhaps this solution is not the way to go. Keep an eye out for Offscreen Canvas in the future though!