Combining PlayCanvas with a 2D WebGL library in a single project. Yay or nay?

Hi everyone,

This is my first post in the Play Canvas forum and I’m in the process of porting an existing native mobile game I’ve built to HTML5 with some 3D enhancements.

According to this post and many other similar posts, PlayCanvas recommends using SVG/DOM elements on top of the canvas to create UI and Game HUD. It’s the simplest solution and gives you greater control over things like text. The alternative is using primitives, sprites and bitmap fonts (like in the Flappy Bird project) which is great but I don’t like the idea of creating and managing bitmap fonts or trying to calculate the UV Tiling & Offset manually of a sprite sheet and apply that to each material.

For my game, I plan on using Play Canvas for the 3D game mechanic but I was thinking of using Pixi JS as the Game HUD and UI (menus, etc). The reason being is that it has many features (masking, bitmap filters, support for Texture Packer, etc) that I’d like to implement.

I did some more research into other 3D engines (Three JS) with Pixi and that it’s possible to have 2 canvases (one hidden, one visible) and draw the Pixi canvas onto the Three JS. I’ve attached some links below should anyone want to follow along how I got to this point:

I just have a couple of questions:

  • Has anyone had experience using 2 canvases together (eg. a transparent PIxi canvas on top of a PlayCanvas background)? Were there any issues or performance losses?
  • Is it possible to implement the approach suggested of painting the 2D Pixi Canvas onto the 3D PlayCanvas? The example provided cautioned that competing WebGL libraries may not play nicely with each other due to keeping track of the GL. I also read about using a fragment shader to combine one canvas onto another Is this something that’s possible with PlayCanvas?
  • If using other WebGL libraries are really not recommended, is there a better way to manage Offset & Tiling of a generated spritesheet? (ie. recommended tools, etc)

I’m going to try and build a simple example over the coming days to see what possible but if someone else has tried and even come up with alternate solutions, I’d really like to hear about it.

Thanks, /Topher.

You could use as many canvas elements as layers, or even have single canvas visible, and others to render off-screen and then copy to texture which is then rendered in main canvas.

But there are drawbacks with this approach:

  1. Performance consideration - having more than one canvas, is expensive, especially for mobile.
  2. Download consideration - you will have to download both engines, and duplicated resources in case if they are used in both contexes. This true as well for increased VRAM usage.
  3. Code management - you will have 2 APIs to deal with, and you will have more complex codebase, especially will have to figure out a “bridging” mechanics, how from one context you interact with other context. You could make a logic separate from rendering, sort of Model-View pattern, but this seems to be overly big effort for minimal benefit.

There is 2D API in development actually right now, and can be enabled for individual users if the need rises. It has font rendering (not bitmaps, something more like vector fonts), image rendering, and whole screen-element system.

Additionally we will be working towards exposing Editor API in future, to allow developers to extend it to automate their workflows, but there is no ETA on that.

Hi Max,

Thanks for your reply. You’ve given me many things to consider regarding performance, file size and complexity.

Just a couple more questions:

  • Can you elaborate on in the 2D API? Is it a similar mechanism to say the Unity UI API where you create elements that can pin, reposition and scale based on screen size?
  • Is that available to paid members? I’d love to take a look at it before I start just to see if it’s a viable option. I’m just a little apprehensive about using code in development as it might be subject to change.

Thanks, /Topher.

Very similar indeed.

It is done more on request basis. Summoning @dave to consider white-listing you to it.

Thanks Max. Great stuff :slight_smile:

Update to this thread. The Element and Screen components are public and available to everyone.