billyV Posted December 13, 2022 Share Posted December 13, 2022 Currently optimising a project and I've been looking at ways of minimising the amount of CPU time spent on Spine animations. I basically want two copies of the same Spine object on screen, but I don't want to create two objects and calculate the texture transforms twice. I have tried unsuccessfully to create new spine objects that refer to another objects skeleton, but Pixi only allows an object to be added to the scene graph once. Despite having these objects animating in Unison, CPU time seems to grow linearly as I add more copies of these animations to the stage and I'm thinking that I'm just doing the same calculations over and over. Because of the nature of the project, I can't handle this within Spine itself. I need to be able to dynamically add copies of this animation as needed. They never need to be offset in time, and because of this I did consider rendering the Spine to a texture and then copying this around the scene graph, but I wondered if anyone had covered this before and come up with the best approach, or maybe I'm just missing something? Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted December 13, 2022 Share Posted December 13, 2022 you can try a hack: "spine2.skeleton = spine1.skeleton" but that way I'm afraid "currentSprite" will work wrongly, need to patch the way pixi-spine does things. I think, at the moment, NONE of runtimes (Unity, Unreal, e.t.c.) have the feature you are requesting. Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted December 14, 2022 Share Posted December 14, 2022 Maybe just just render-texture it ? Quote Link to comment Share on other sites More sharing options...
billyV Posted December 14, 2022 Author Share Posted December 14, 2022 Yes I tried “spine2.skeleton = spine1.skeleton”, and although it is possible to have both objects to share the skeleton, I just couldn’t get them both to display. A rendertexture seems like it would be the simplest way of making it work. I will have a play with it. I’m thinking though that maybe I just have an awkward requirement though, as I’m never going to need more than about 40 of these spine objects on screen at once, and a lot of the time it will only be 2-10 copies. If we were talking 100s or 1000s of these, then the rendertexture approach would be the definitive approach but I’m not sure about the up-front cost of rendering to a rendertexture and then copying over the screen (it’s probably very small, I’m just lacking the confidence to get going with it). I’m guessing whether it’s worthwhile, would depend upon the context, and the fact that no-one else has required it from the library means that maybe the performance increase may be small. First project in a long time and I need to not get hung up on over optimisation 😊 Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted December 14, 2022 Share Posted December 14, 2022 Yes, renderTexture should be the way, try it ) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.