sipahiro

Hello, I created a huge terrain by Spine and only a small portion of it would get in the viewport at certain time. I find it consumes quite a lot CPU time while I'm panning this terrain spine object. My question is that is there some way to optimize this kind of situation? Like only display and do calculations within viewport (camera) region?
FYI, I use Starling Framework if that matters.
sipahiro
  • Сообщения: 8

Nate

Certainly there are optimizations you can do, but you should only do them where benchmarking tells you the changes will have the most impact. Where do you see the CPU time being taken?
Аватара пользователя
Nate

Nate
  • Сообщения: 9264

sipahiro

Hello Nate, thanks for your response!
I use Adobe Scout to check the performance of our game at run time. When I'm panning this huge terrain Spine object, I could see SkeletonSprite.render() and Mesh.setVertexPosition() takes so much time. I could understand that a huge spine object with so many vertex would consume a lot, so in this kind of situation, will there be a way to eliminate unnecessary vertex rendering and calculations which are out of the viewport?
sipahiro
  • Сообщения: 8

badlogic

The rendering of Spine skeletons in Starling would not benefit much from per-vertex culling. Is your terrain Spine object actually animated, or are you using Spine for the terrain to unify your art creation workflow? If you do not animate the Spine object, you might be able to bake the mesh generated by the rendering code once, so it does not get regenerated every frame.
Аватара пользователя
badlogic

Mario
  • Сообщения: 2076

sipahiro

The terrain spine object is not animated and the reason for using spine is that we want to use less textures. With spine we could setup basic shapes by modifying vertex positions.

You mentioned about baking the mesh. Did you mean something like:
terrianEntity.filter = new FragmentFilter();
terrianEntity.filter.cache();
I've already tried this solution, but it would consume a lot of GPU texture memory and lead to "out of memory" crash.
sipahiro
  • Сообщения: 8

badlogic

I'm talking about creating a specialized version of SkeletonSprite for your use case. The method responsible for creating and submitting meshes to the GPU is SkeletonSprite#render():

spine-runtimes/SkeletonSprite.as at 3.7

In it, we iterate through all slots and create meshes for each attachment in the slot. In the highlighted line above, we then submit that to the Starling painter which ensures the individual meshes are batched and submitted to the GPU.

As a first measure, you could adapt this class so that the meshes are only generated once in the first render() call, stored in a list, and then re-used for subsequent render calls. This should get rid of any overhead stemming from calculating the mesh vertices on every render() call.
Аватара пользователя
badlogic

Mario
  • Сообщения: 2076

sipahiro

Thanks so much! It solved my problem which bothered me for so long!
sipahiro
  • Сообщения: 8


Вернуться в Runtimes