Mikal's Forum Posts

  • Ashley Thanks for the reply (and thanks for the comments in the bug report, I understand, that makes sense.)

    I do agree that rendering directly to the C3 canvas would be better and that will be something to explore, however, the render is done through the Spine-TS runtime script and it looks like a lot to dive into to figure out (10K lines). It's already set up to render to a canvas, however, also integrating in the render with other sprite objects could be a challenge? Though I think it would be possible if created a Drawing plugin and did the work to integrate the Spine render into the Drawing Plugin Draw function? Something to explore in the future.

    I was looking for a short cut to use the existing Spine-TS. I have found a way that works and _seems_ to perform pretty well. I definitely tried to use only C3 SDK, but I think I used a little more. In this method, I created a drawing plugin which replaces a sub texture of the drawing plugin Sprite Sheet with the canvas texture on each Draw() call. There are limitations: it only replaces the top MIP level, so if the Sprite is scaled down, the old image starts to blend in. So, for the game, I will force screen resolution and keep Sprite size relatively the same so the other MIP levels do not kick in (this will likely be a desktop nw.js / Electron game, so I will have some control over which chromium engine the game is shipped with and control over full screen vs windowed.) I know this is not bullet proof, but I think I can work around the issues. If you have suggestions on how to make the below use more C3 SDK functions, that would be very appreciated!

    In general for Spine animations, I will just use 1-3 characters animated this way, so 'only' 1-3 texture updates per frame. The rest will be simpler and use traditional sprite frame animation. 

     Draw(renderer)
 {
 var gl = renderer._gl
 const imageInfo = this._objectClass.GetImageInfo();
 const texture = imageInfo.GetTexture();
 if (!texture) return; // dynamic texture load which hasn't completed yet; can't draw anything

 const wi = this.GetWorldInfo();
 const quad = wi.GetBoundingQuad();
 const rcTex = imageInfo.GetTexRect();
 var myCanvas = document.getElementById(this._elementId)

 gl.bindTexture(gl.TEXTURE_2D, texture._texture);
 // webgl2: gl.texSubImage2D(gl.TEXTURE_2D, 0, (rcTex._left * texture.GetWidth() - 0.5).toFixed(0), (rcTex._top * texture.GetHeight() - 0.5).toFixed(0), myCanvas.width, myCanvas.height, gl.RGBA, gl.UNSIGNED_BYTE, myCanvas);
 gl.texSubImage2D(gl.TEXTURE_2D, 0, (rcTex._left * texture.GetWidth()).toFixed(0), (rcTex._top * texture.GetHeight()).toFixed(0), gl.RGBA, gl.UNSIGNED_BYTE, myCanvas);

 renderer.SetTexture(texture)

 if (this._runtime.IsPixelRoundingEnabled())
 {
 const ox = Math.round(wi.GetX()) - wi.GetX();
 const oy = Math.round(wi.GetY()) - wi.GetY();
 tempQuad.copy(quad);
 tempQuad.offset(ox, oy);
 renderer.Quad3(tempQuad, rcTex);
 }
 else
 {
 renderer.Quad3(quad, rcTex);
 }
 }

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've posted a project template with the plugin bundled.

    The new drawing plugin ElementQuad, takes an element as ID as an argument and each frame (Draw is called), it sets the image texture to the element (I am using the SpineCanvas which is the canvas I am using to render a Spine animation to.) It is just replacing the top MIP level, so you cannot scale the ElementQuad too much (or other MIP levels which do not contain the Sprite render will start blending in.) The ElementQuad image size works best if it's the same size as the Element (canvas.)

    So, the original issue in the thread is no longer blocking, this alternative approach also seems much more performant (with the caveat for the sizing limitations.)

    Here's a link to the template and plugin, please feel free to suggest improvements. It is still only a template and only one Spine object is currently supported.

    construct.net/en/forum/construct-3/general-discussion-7/spine-animation-js-template-145940

  • Update 08/11/2019:

    Created a plugin helper ElementQuad, which can use a canvas directly as a texture, which lowers memory usage and improves performance. There is now no stutter, one caveat is that it works best if the ElementQuad image size is the same as the Spine render canvas.

    An updated project with the new ElementQuad plugin bundled is in the original post.

  • I am taking a new approach.

    I've created an ElementQuad helper plugin which is a Drawing plugin that replaces its initial texture with an Element from the document which can be set via an action. Right now I'm using the Spine render canvas as the Element to be used as a replacement texture. With this method, it looks there is not a large amount of new data/objects created to be GC'd later and the animations now run smoothly without a stutter. I will post the new template and plugin.

  • Try tuning the water effect a little and you may end up with something ok (but it will have a hard edge at the borders.)

    This looks good, but it's a GPU killer due to the effect applied to the many fire sprites to create a nice ragged dynamic edge on top of the lava, perhaps something to inspire you to try something which has less perf impact than this example.

    Fire.c3p

  • Looking forward to this, also it’s great to have you working on C3 projects!

  • Thank you both. I added a pointer to the 'official' outline effect, thanks for pointing that out Eren.

    I don't plan on making a plugin. When I use this in a game, I'm going to use the C3 JS scripting features and C3 JS files and C3 functions to access the Spine-TS API directly.

    Eren if you want to make a C3 plugin for it, please use whatever you want/can from the project. I have seen comments in other threads that make me think if you make a Spine plugin, there will definitely be a few more folks joining your Patreon, just let them know before you start so they can gather people to join and support you!

  • Since I did not see the possibility of a Spine Animation plugin on the near horizon, I am experimenting with using the Spine-TS webgl runtime and integrating it with C3 through JS integration. I updated the Spine TS demo to load the Spine atlas and skeleton files from the local C3 project files. The runtime renders to a separate non-visible canvas each frame and the result is loaded into a C3 sprite animation frame to be displayed. The api provides control over the animation, mixing, animations, changing skeletons, skins, etc.

    I currently have some simple controls to change the skeleton, change render resolution (the render canvas resolution), play/pause the animation.

    It works fairly well, except for an occasional stutter (which seems to be the C3 execution stuttering due to movement of data into the spirte animation frame, in other threads and bug reports, I'm exploring that.)

    Please feel free to test/extend/use/improve the project, please repost if you find some good improvements or extend it (or fix the stutter issue!)

    Update 08/14/2019:

    Updated the ElementQuad helper with the help of Ashley to use newly documented SDKs and released.

    The Spine example is doing one Spine animation rendered to one separate canvas and the canvas is used for multiple ElementQuad instances (a light port of the Spine meshes demo.) For more Spine animations, this example may need another canvas per Spine animation and either a clone of ElementQuad or a new instance. Control of the animation will need to be done through JS calls to the Spine-TS API, movement, angle, size, effects, etc. on the resulting ElementQuad can be through C3 events.

    ElementQuad Addon and Spine Example

    Update 08/11/2019:

    Created a plugin helper ElementQuad, which can use a canvas directly as a texture, which lowers memory usage and improves performance. There is now no stutter, one caveat is that it works best if the ElementQuad image size is the same as the Spine render canvas.

    Older project with new ElementQuad plugin bundled in.

    SpineJSEQTemplate.c3p

    SpineAnimationTool

    Older files

    OutlineEffect

    SpineJSTemplate.c3p

  • Nice work, very cool style with all the angles and it really flows into the game UI also. Good luck with it!

  • Filed a bug. In case anyone wants to follow the discussion there, see:

    github.com/Scirra/Construct-3-bugs/issues/3201

  • Thanks for the help investigating this, that's too bad about the binary object. I have been working on the full project and trying some different ideas. However, then I just fall back to the test case that already has issues with just the one action, so I should probably just focus on that. I'm going to file a bug report and see if I can get some attention from Scirra also.

  • Agreed on the memory allocation, this is where I started on the problem also, Major GC, blob creation seem to be the issue. However, I'm also exploring some more with coordination (or lack thereof between the rendering process and loading the Sprite image.) If the 'consumption' gets out of sync and delayed, perhaps blobs could be created without revoking. I'm adding in some check and variables, but have not yet seen improvement.

    I'll take a look at the BinaryData object too, but it sounds like you already did and it's not going to help.

    I really just want to have a reusable ping-pong buffer that is the size of the image data for the sprite that I can load into the Sprite (as long as that load does not create new blobs which must also be dealt with.) I may need to start exploring readpixels from the webgl context of the canvas that was rendered: WebGLRenderingContext.readPixels()

  • Yes, I think Spine and Spriter animation in C3 will take more performance than frame by frame (though with the benefit of potentially lower memory footprint and more flexibility of controlling the animations during runtime.) It's a tradeoff. Exporting png Spritesheets from Spine and Spriter is also a reasonable solution with different tradeoffs.

  • q3olegka Sorry, I'm not sure I understand your question. This is a Spine skeleton, animations, and atlas imported into C3 from Spine (_not_ done with exporting spritesheets from Spine.) The Spine-TS JS runtime is also imported into C3 (via JS script files) to render the animation to a canvas each frame. The canvas image is then loaded into a C3 sprite animation frame on each tick. The original Spine animation and skeleton are using mesh (you can see the animation mesh deform as it moves.) The Spine animation could be controlled dynamically by C3 JS scripting events which use the Spine-TS JS API.

    At this stage, it's a C3 tech demo to see if it's possible to use the Spine-TS JS runtime as an alternative to waiting for someone to do a full C3 plugin / port to C3 SDK. If it works reliably (there is a stuttering issue every few seconds which I am tracking down), I'll make a template and share it.

    Did I answer your question?

  • Magistross Agreed - though it seems pretty close to working. It works well for 100s of frames before it stutters, so I'm hoping Ashley can give some guidance on how to improve this, perhaps using a function of the C3 Plugin SDK or Scripting SDK instead of the Sprite action, or if there can be some improvement done to my use of the Sprite Load Image action (or if it's possible to change the C3 implementation of the action so the Major GC does not occur.) The Load image w/ blob takes up < 1ms of frame time, so pretty usable.

    Here's a short loop that shows it works well for a second or two (this is from the full project, Spine webgl runtime integrated with C3 via Sprite image loaded from separate Spine runtime webgl rendered canvas and outline effect applied on Sprite.)