RenderTarget vs Custom canvas

0 favourites
  • 4 posts
From the Asset Store
Pixel Destruction like in "Worms" (Drawing Canvas based)
  • Hi Ashley, in the past few C3 releases you included 2 examples for custom drawing with canvases inbetween layers. This is pretty cool, and in fact it's something I've been experimenting with in the past, but I'm curious about something:

    Why do it this way rather than using C3's provided dynamic texture system? Dynamic textures can also take canvases as input, and with them I'd be able to integrate rendering with a lot more precision than with an extra canvas inbetween 2 layers.

    Also, using dynamic textures, I can place my custom drawing in the C3 world directly and have it automatically be affected by layout/layer positionning, the Z ordering, and the effects compositor.

    Is it that this method is more performant? If so, how much better is it?

    I'm curious to learn more about the rationale behind these. As I said, I've been experimenting with something like this recently to implement custom 3D in my games, and for my specific use case, both would actually work fine (with some minor caveats on both sides) so if you can explain, it would help me a lot.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Why do it this way rather than using C3's provided dynamic texture system?

    You could do that too. As with everything in engineering, there are usually different ways to do things, each of which have different trade-offs, and choosing between them involves judgement and the particulars of what you're trying to do.

    The main problem with dynamic textures is likely to be that texture uploads can be slow. They might be a GPU copy, but some combinations of data/browser/OS/driver may end up doing a slow copy from CPU, which will kill performance. It's hard to know in advance how well it will work without lots of testing. Some texture upload paths are also async which can cause some tricky synchronization issues. On the other hand, it gives you true in-engine rendering.

    If the goal is to render a viewport-sized image, then rendering in-engine with dynamic textures seems slightly odd in that it doesn't actually draw anything correlated with an object position. It's more like an entire layer of custom content. In that case, HTML layers seem a suitable solution. I'd say it's particularly good for 3D content, as generally you'd have a 3D world with 2D content layered on top (e.g. for a HUD) and perhaps some 2D content layered underneath too, which HTML layers solve nicely. Additionally it simplifies the integration, as a library like three.js keeps control of the canvas and renders it like anything else, just using the browser compositor to blit the canvas to the display, avoiding any extra texture upload overhead.

    Perhaps it would still work fine with dynamic textures. Try making a prototype and seeing how it works out. With 3D content I'm not sure there will be much benefit to doing that, but it might be a good approach for 2D content.

  • I've done work like this with dynamic textures before (I made an addon that used the SDK to update a drawing object addon from a canvas). I tried it with a few different ideas, including 3D, Spine, Babylon and I did find it to be a performance bottleneck.

    The first Spine addon was something like that also, updating a C3 dynamic texture from a separate canvas / webgl context that was rendered by Spine. This was also a bottleneck which is why I jumped through so many hoops to implement spine webgl rendering direct to a C3 dynamic texture in the C3 webgl context. With SDK V2, the goal is to render spine with only SDK V2.

    I don't know if it still works, but here's the addon (it has an example of rendering to a separate canvas for spine webgl and then using that canvas to update a C3 dynamic texture in the addon.)

    construct.net/en/make-games/addons/312/elementquad

  • Sure wish I could do animated vectors on Drawing Canvas.

    Because they are actually captured on video export in Animate.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)