- 編集済み
[Spine-TS] Running multiple canvases with multiple animation
Hi there,
We're trying to test spine for some facebook game implementations and we were trying to use the spine-ts webgl lib. But trying to get multiple spine instances on multiple canvases on screen at the same time. However for some reason it keeps overloading the multiple instances with the same animation across all the canvases. Is there any example anywhere on running i.e. 3 animations on 3 canvas contexts doing differen things? This overloading animtations stuff is driving me nuts hahah.
I also tried converting all the states /shaders to different objects but it just keeps filling up the most recent animation state created so all the animations get triggered when i run
for(var i=0;i<stateCount;i++){
animationStates[i] = new spine.AnimationState(animationStateData);
animationStates[i].setAnimation(0, initialAnimation, false);
}I was trying to use https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-ts/webgl/example/barebones.html as a base
i could really use just a really barebone example of a webgl implementation runing multiple canvases on the same page doing different things thank you 
Unless you are doing something fancy, I would suggest to use the Spine Web Player. It is much easier to use and handles all the boilerplate and camera stuff for you. You still have access to the Skeleton and AnimationState objects. For example, the Spine player is used for all the animations on this blog post:
Blog: Spine 4.0 is here
The code for that:
http://n4te.com/x/2243-2ChD.txt
You can see the surf skeleton has a sequence using AnimationState and the favor skeleton reacts to the mouse. Many of these players customize the viewport, but that is optional.
Anyway, to do it without the player you basically need to do most the stuff in barebones.html for each canvas. The Spine demos page does that:
Spine: Demos
The source for the demos is in Git. Description here:
https://github.com/EsotericSoftware/spine-runtimes/tree/4.0/spine-ts#webgl-demos
Code here:
https://github.com/EsotericSoftware/spine-runtimes/tree/4.0/spine-ts/webgl/demos
The demos.html page has them all on one page, or you can view them individually.
You'll find the demos are not a particularly simple example. The Spine player was not as capable when we made the demos as it is now. If we were to redo it, we'd use the Spine player.
One thing to note is that browsers limit the number of WebGL canvases. Mobile browsers have a lower limit than desktop, allowing something like 4 canvases. You'll notice the demos page has more than that. It achieves that with a fancy trick: there are only a few (4 I think?) canvases and as you scroll, there's code that removes the farthest away canvas, places it where you scroll to, and renders the appropriate demo for that location. This works only because you only need to see a few canvases at once (unless you had some sort of freakishly tall monitor).
I see, thank you. Yeah we're trying to integrate spine within our current system so we'd need to be able to listen to it animating, delay each instance starting if we wanted, be able to chain it to work with GSAP animations, to know the length of each instance, have a load checker so theres no loading spine post page launching. I will look more into the demo sources, its a very good point you brought up thank you about the multiple instances, in our games i've put down many instances of canvases but they were using non webgl canvas draws so i imagine the cpu drain wouldnt even match.
Do you think its possible to load multiple spine skeletons/binaries on to the same webgl view with them being unlinked? With either the player or manually? And to at least be able to disable the spine loading spinner completely , for context trying to use it to summon characters, objects and other things in and around our game by generating and removing canvas objects on the fly
Sure, you can disable the player loading spinner with showLoading: false. Some of the players on the blog post do that.
You can ensure that assets are downloaded only once and shared with multiple players by passing a spine.Downloader, as the blog post code I linked above does. However, it's not possible to share textures between canvases. So while the images, JSON, etc are downloaded only once, if you are using the same images in multiple canvases, they need to be loaded to the GPU for each canvas.
The player should do what you want. If not, we'd be interested to hear why it doesn't meet your needs. Maybe we can make it more flexible so it does.
Thanks Nate, this is super useful and trying it now with the next build for the game on some basic overtake screens thank you!
The worry I had is the one you mentioned where if we have more than a few webgl canvases its going to take a toll on mobile and trying to avoid that as much as possible. So for easy use case e.g. character shows up in the game, talks and leaves 1 webgl player works great.
But i want to do worst case scenario , e.g. screen has a loot box showing 10 seconds into it, character 5 seconds into it, maybe some small explosions for tiles staggered on top of items come in at 2,4,6,8 seconds in. So that would be 3 seperate spine files (player, loot box, explosions (with different timelines triggered on explosions and duplicated 4 times)
In this case it would be 6 different canvas webgls. Currently we do this with normal 2d canvases and we just spawn and do canvas draws on them then they leave. Performance has been great but its a 2d canvas library i made that i'm using for it(I made it public here https://github.com/luckyde/elCanvas)
But if this was 6 different webgls all seperately processing that would be very taxing, i was kind of picturing maybe it's a single webgl fullscreen transparent view which could spawn all 6 skeletons, animations and binaries. Then the shader could mix them(not animation wise obviously, graphics renderwing wise) So they are all rendering on the same render loop. So I could say shader.startAnim(Character).setDelay(5000), .startAnim(Particles_1).setTimeline(explode_1).setDelay(2000), .startAnim(Particles_2).setTimeline(explode_1).setDelay(4000) etc
Sudo makebelief code but does that kind of make sense? So everything still processes fast and the only high intensity thing that might happen is it would need to draw the graphics on top of themselves on every loop if they're overlapping
lucky wrotemore than a few webgl canvases its going to take a toll on mobile
Note what I mentioned is not about performance, browsers will completely refuse to render more than a certain number of WebGL canvases.
I've not tried mixing a huge WebGL canvas on top of lots of HTML, but I imagine it could work. You could also just render everything in WebGL. It has its challenges but allows you to do anything. Check out: Gloomhaven Helper
2年 後
Hi Nate. Sorry to post on a dead thread. I'm using the Spine Web Player and absolutely love it. I have come against the multiple WebGL canvas limitation you mention in this post. I'm curious if your solution to remove canvases on scroll is open source/on GitHub? I looked through the links and couldn't immediately find this solution. No worries if this precise solution is closed source. I'd appreciate any pointing in the right direction to implement a similar fix.
Many thanks
-Josh
Yeah, it is, but it's not for the faint of heart.
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-ts/spine-webgl/demos/utils.js#L32-L110
This is the code used on our demo page to display more than 5 Spine demos, each requiring a WebGL enabled canvas. The demos are layed out vertically in our case, and it's actually not possible to see more than 3 on most display configurations at a time in the browser tab viewport:
http://en.esotericsoftware.com/spine-demos
The basic principle is this: it's save in all browsers to show 5 WebGL enabled canvases at a time. The code pre-allocates 5 WebGL enabled canvases in createCanvases(). Each demo is assigned one of the 5 WebGL canvases.
In the loop() function, we loop through all the demos and check if their container elements (called placeholders) are visible in the browser tab viewport. If a demo's placeholder is visible, it is marked as such in checkElementVisible().
Finally renderDemo() is called, which bails if the demo container element isn't visible. If it is visible, it will insert the WebGL canvas assigned to it into its container element, and then tell the demo to finish loading assets if necessary, followed by having the demo render itself.
It's very specific to our demos page, but the basic principle can be adapted to your use case as well.
This is brilliant! Thanks for taking the time to explain this in detail, Mario. I'll definitely use a version of this trick in my projects!
Thank you again!
All that said, if I understood your use case correctly, you want to draw Spine skeletons on top of standard HTML UI. It might be simpler to create a single big WebGL enabled canvas with a transparent background that overlays the HTML UI (or is layered in between HTML elements if you need to draw stuff on top of the skeletons). That will likely result in better overall performance.