Xna - draw batching

eprime

Hi,
the video game we are making is visually similar to Ori and the blind forest, we have hundreds of elements on the screen.
Although we only render objects in the camera view, it is too slow.
as regards non-mesh elements, is it possible to improve the drawing performance?

Mario

That largely depends on how you render your assets. Can you share more information? Mixing rendering of skeletons via SkeletonRenderer, and rendering of other things into a single batch may be possible. The SkeletonRenderer exposes the underlying MeshBatcher. You can use the MeshBatcher to draw your non-skeleton assets. Additionally, making sure you don't switch textures for every object rendered can vastly improve performance. That can be done by using a texture atlas composed of images of more than just one skeleton.

eprime

Hi Mario,
I'm making a game editor, then at now for test I draw a basic texture, without nothing, no mesh, no animation. This could be considered a static element on map level
example of single texture of 1024x1024 pixel
json

{
"skeleton": { "hash": "sEE2IpGcZ2AnGO9uEumZ8iCtj91", "spine": "3.8.99"},
"bones": [
   { "name": "root" }
],
"slots": [
   { "name": "roccia-12", "bone": "root", "attachment": "roccia-12" }
],
"skins": [
   {
      "name": "default",
      "attachments": {
         "roccia-12": {
            "roccia-12": { "width": 1024, "height": 1024 }
         }
      }
   }
],
}

atlas

roccia-12.png
size: 1024,1024
format: RGBA8888
filter: Linear,Linear
repeat: none
roccia-12
  rotate: false
  xy: 0, 0
  size: 1024, 1024
  orig: 1024, 1024
  offset: 0, 0
  index: -1

trying to improve the performance I analyzed the MeshBatcher class and proposed these changes:
XNA - MeshBatcher improvement
and gained 20%
but it doesn't seem enough
is there a way to improve the rendering of simple static objects?

Harald

If you don't want to animate the texture and only need it for a completely static background, then using the Spine Skeleton infrastructure for it seems a bit odd. Instead of re-batching the static elements of your scene every frame, you would rather want to create a batch of completely static geometry once and then only render it.

It would however depend on your typical scene setup what you would effectively group to a static batch and where things should be separate. The general rule applies that you should minimize draw-calls and thus create atlases of your background elements to be able to render them in a single draw-call and group them reasonably (you don't want them to span over 10 screen-widths for frustum culling).

In general however even batching all static quads to vertex buffers every frame (via the Spine Skeleton infrastructure) should not take immensely long. So you might have other things lowering your performance. You would most likely need to perform some profiling in order to find out more about the actual cause of your framerate problem.

eprime

I would also like to use spines for static backgrounds for one practical reason. Obviously spine makes sense for animations.
In my test I only did a for loop drawing the same skeleton with a 1024x1024 texture and a perspective camera instead orthographic