- Modifié
Unity runtime performance issue
Hi Nate,
Have noticed in the latest version of the Unity runtime that it now costs something like a drawcall per quad you have associated with the animation. I reckon this is due to the introduction of submeshes in SkeletonComponent.cs but really not sure. This should obviously not be the case, it used to be that we would get a draw call per material used, so 1 drawcall for spineboy rather than 11. Obviously this performance decrease would only allow two characters or so on screen on a mobile device. Can you advise whether this is a bug or not? It seems like a ridiculous performance cost for rendering quads?
Kind regards,
Robert
[Have included a picture of a super basic scene, 1 spineboy animation, 1 camera and 11 drawcalls for 17 quads 
]
[EDIT : Also should mention that the example uses the two standard atlases provided in the examples folder to render SpineBoy, not sure if this could be cause, as in a multi atlas issue? Or it could just be a super cool Unity sub-mesh issue?]
Sorry to bombard you, but I also noticed something to do with event firing. I played the example draw order animation, and when not looping, it fires off three events:
- behind
- behind
- headAttach
However, when set to repeat, after playing for the first time it fires off a fourth event (presumably first in the order) as follows
- headPop
- behind
- behind
- headAttach
This behavior then continues. Is this correct behavior, or is the first event being lost somehow?
For all tests I am using the latest csharp and unity runtimes.
Many thanks,
Robert
Also....
Thought I would point you in the direction of this page http://docs.unity3d.com/Documentation/Manual/MobileOptimisation.html (good practice section, point 13) and more importantly this thread http://forum.unity3d.com/threads/118723-Huge-performance-loss-in-Mesh-CreateVBO-for-dynamic-meshes-IOS which seem to have some good information on increasing performance in Unity by double buffering meshes that are updated every frame. Apparently it is still more beneficial to ping pong between two meshes than simply mark a mesh as dynamic. I know it wouldn't be very difficult to modify the code to include this for myself, but just thought I would mention it and see if you wanted to investigate introducing this in future until Unity sort their Mesh.CreateVBO() issue out?
Again apologies for bombarding you,
All the best,
Rob
The spineboy project uses a multi page atlas, solely to exercise multi page atlas support. Using an atlas that has multiple textures can lead to an explosion in draw calls if the images are split across textures without regard to draw order, as in the case of spineboy. You might need to use multiple textures if your images don't fit on a single texture. Eg, you might want all your character parts on one texture and the myriad of weapons on another. If only one weapon is equipped, you'd get 1 draw call for character parts, 1 draw call for the weapon, and maybe 1 more draw call for more character parts. Without multi page atlas support, you'd have no recourse if your images don't fit on one texture.
Here's the goblins example with 1 draw call: Image supprimée en raison de l'absence de support de HTTPS. | Afficher quand même
The Spineboy.cs class that attaches the event listener does so only after the SkeletonAnimation has advanced a frame, so the event listener is not fired for the first event, which happens on frame zero. Not sure how to make Unity run the script first.
Double buffering meshes is interesting, I'll give that a shot, thanks! I'll also read the thread you linked.
Nate,
Thanks very much for the info, will look into the event firing and see if I can figure something out. Also, I was wondering if you could advise me whether there is a way of determining the current frame of the current animation that is playing? I couldn't seem to find an example of grabbing this info. I do hope that the double buffering helps out, at least for some people. I will keep you informed if I turn up any other useful information regarding improving the runtime performance.
Many thanks,
Rob
AnimationState has a number of tracks. You can use state.GetCurrent(trackIndex).Time / 30 to go from seconds to frame number. Spine uses 30 fps by default, which will be configurable someday.
Task:
https://trello.com/c/AfsUxYbM/49-double ... ity-meshes
Thanks Rob! 
4 jours plus tard
Hi Rob, I've implemented double buffered meshes (and a few other things).
Wow, thanks Nate, that was super speedy. I also saw that you wrote a shader for casting shadows which is really sweet, I'll try and take a look at doing an alpha bend version if possible, but in the mean time I'm gonna be making unity colliders to match bounding boxes and integrate that to try a starting point for you and others to build on.
All the best,
Rob
Sounds great!
Hi Nate,
Have been working on this and all seems to be going well, just have a few questions though regarding the operation of Bounding Boxes to make sure I get things right. Firstly, am I correct in assuming that the corner coordinates (or points) of bounding boxes cannot be changed on a frame by frame basis, and that in order to do so I imagine a user would create several Bounding Boxes and toggle between them at runtime? Also, I think a user can turn on/off bounding boxes on a frame by frame basis. If so, I take it this will just mean at runtime, if a Bounding Box is 'off' it will not be found as a slot (as in, the slot count will decrease to reflect it being turned off) and therefore the collider can just be turned off for that frame. Also, can (or in future will) Bounding boxes be created with support for Holes?
It turns out that presently the Unity engine (or more PhysX) requires that a further 3D mesh based on the Bounding Box be built, which it then uses for physics. I guess this will be simplified with the release of 4.3 and the introduction of Box2D, but it still makes sense to support both. Anyway, I am rolling a solution that will allow the Bounding Box Colliders to be created as separate child GameObjects/Meshes that are relative to the parent Bone, rather than as a single mesh representing all Bounding Boxes per frame. Just wanted to check that only the mesh vertices need to change per frame and not the amount of vertices/the triangles need changing too (which would be more overhead on a frame by frame basis).
Anyway, looking forward to having something more to post soon. Many thanks,
Rob
Oh and I also noticed that in SkeletonComponent.cs, the Clear() function doesn't seem to be clearing the double buffered meshes. Hope this helps and thanks for all your hard work
The number of vertices for a bounding box won't change. Currently you can't move vertices, so you'd need to use multiple bounding boxes or use the scale of a bone to affect the attached bounding box size. Bounding boxes use slots to attach to a bone, so they can be hidden/shown as needed via code or animations, just like images. Bounding boxes will never support holes. They can be self intersecting (which was a huge pain in the editor!), but I doubt anyone will use this so you don't need to worry about that.
I'm not sure which would be better, a gameobject per bounding box or a single mesh with all bounding boxes. I'd guess for performance a single mesh would be better, but I don't really know for sure.
Thanks for working on this! It will be a great feature! Would you allow me to put it in the official runtime under the same license as the rest of the runtime?
I've fixed Clear, thanks.
Yeah absolutely Nate, it's for everyone and to give back to you guys for creating such a great tool. Thanks for the info as well, I will probably provide the user with the option to specify either individual or one big mesh for colliders in the Unity Editor. That way the user can decide which they want. :happy:
All the best,
Rob
4 jours plus tard
Hi Nate,
Will be posting in a new thread about this to make it easier for other people to find and post ideas on.
Cheers,
Rob