Yeah it is a tonne faster for me. Awesome stuff!

Thankyou!

Pharan wrote

Ask your mother. (Mitch is your mother.)

Any info Mitch?

ProudLittlePinwheel wrote

Pharan wrote

but in case you're interested, some 20 to 40% mesh-updating performance gains are being worked on. Someone just contributed some changes to the code that works around some weird stuff Unity does.

I was wondering, are the 20-40% mesh updating improvements mentioned going to be merged soon before any big Spine 3.0 update or are they integral to that? It's just that I'm not sure everyone will be able to update to 3.0 straight away (due to the massive skew scaling changes introduced) but may still want those performance improvements in their runtime. Any info on this would be appreciated?

Also, if more info on the 'weird stuff' Unity is/was doing is possible that would be great too, just for our own education to ensure we avoid such things in future.

Many thanks

So any word on this? Pharan... Anyone...

Excellent! I imagine I just did something stupid on my end. You should be able to do alot with custom properties moving forward. Have fun with it!

My skeletonRenderer is heavily modified so I'm not so sure about line numbers...

But if you are referring to the place where the sharedMaterials are overwritten, then it is possible.
If you had a shader property "someColor" for example, then to change it for lots of different skeletons you could just do the following; (this is bad though, don't actually do it like this, cache propertyBlocks, don't create a new one each frame)

// Set materials.
        if (submeshMaterials.Count == sharedMaterials.Length)
            submeshMaterials.CopyTo(sharedMaterials);
        else
            sharedMaterials = submeshMaterials.ToArray();
        GetComponent<Renderer>().sharedMaterials = sharedMaterials;

// New stuff 

---


    MaterialPropertyBlock block = new MaterialPropertyBlock();
    GetComponent<Renderer>().GetPropertyBlock(block);
    block.SetColor("_someColor", someColor);
    GetComponent<Renderer>().SetPropertyBlock(block);

with someColor being, for example, a public serialized property I just added to skeletonRenderer to demonstrate. You can see two crap test skeletons below that have the same material, but different colors as specified per my new skeletonRenderer property someColor...

Anyway, it's perhaps a moot point since they didn't seem to batch on my end. Will keep digging for a bettter solution, but I think it should be totally doable without multiple material instances.

Can't you just use Renderer.GetPropertyBlock and Renderer.SetPropertyBlock on a per skeleton basis. I think it is meant to support not breaking dynamic batching but I can't be sure, it should work for different float, color or vector properties. If you set that though then you could modify the material properties without duplicate instances. You could then just modify propertyblock per skeleton with a script, or write some .txt, .json or .whatever file that you parse that contains info for each skeleton, and then instantiate the skeletons and change their property blocks based on that info, either within the Unity editor or at runtime... At least that way you would only have to maintain a text file or excel file (export to csv) for 150 different combinations.
Just throwing some ideas out there, hope it helps

Hi louiky,

Are you available for hire as an animator?
Looking forward to hearing from you,

Kind regards,

Rob

Pharan wrote

but in case you're interested, some 20 to 40% mesh-updating performance gains are being worked on. Someone just contributed some changes to the code that works around some weird stuff Unity does.

I was wondering, are the 20-40% mesh updating improvements mentioned going to be merged soon before any big Spine 3.0 update or are they integral to that? It's just that I'm not sure everyone will be able to update to 3.0 straight away (due to the massive skew scaling changes introduced) but may still want those performance improvements in their runtime. Any info on this would be appreciated?

Also, if more info on the 'weird stuff' Unity is/was doing is possible that would be great too, just for our own education to ensure we avoid such things in future.

Many thanks

Cheers Mitch, very useful info. Will focus on another code area for a bit instead

Mitch wrote

I don't want to make any changes to that part of the runtime until we get some efficiency improvements in from another contributor (will be a few weeks).

Hi Mitch. I was just wondering what you mean by this. Will there be a big overhaul of the underpinning code of the C# runtime or the Unity part which sits on top (SkeletonRenderer, etc...)? Also, is this going to coincide with Spine's fancy 3.0 update which you somewhere stated will result in a need to change the code anyway (because of bone transforms or something)? Basically I'm wondering whether I should hold off on adding new functionality on my personal branch if there is a radical overhaul/upgrade in the pipeline.

Thanks as always for you efforts and time

Hi louiky,

I saw your recent post in the showcase forum and was extremely impressed with your animations. I also looked at your work on deviantart and was also very impressed by your pixel art animations.

Are you available for hire as a freelance animator at all? If not, would you possibly be able to create some animation tutorial videos explaining you approach and technique which I would pay you for.

You can contact me at robert.f.a.laird@gmail.com

Many thanks for your time, I look forward to hearing from you.

Robert Laird
Proud little pinwheel studios

Wish I had seen this earlier. This was fixed a few days ago in latest runtime. [Unity] Small bug causing garbage for meshes each frame viewtopic.php?f=9&t=3814
Updating to latest runtime would have sovled the issue...

Posted something to try and help out here along the lines of what Pharan and Mitch were indicating you should do...

viewtopic.php?f=7&t=3587

Rob

As Pharan said, you want something simple along the lines of

using UnityEngine;
using Spine;

public class SpineRefs : MonoBehaviour 
{
    public SkeletonDataAsset[] skeletonDataAssets;

void Awake()
{
  if(skeletonDataAssets == null)
     return;

    for (int i = 0; i < skeletonDataAssets.Length; i++)
    {
     if(skeletonDataAssets[i] != null)
        skeletonDataAssets[i].GetSkeletonData(false);
    }
}
}

If you throw all the skeletonDataAssests that you use in a particular scene in there then you will pre-load the data into memory from the json. The json associated with each skeletonDataAsset should not be reloaded, unless you somehow null the skeletonData you create with the call to GetSkeletonData.

I have not personally encountered much issue with lag associated with playing a single animation. You could take a look at the underlying code of 'set' and 'add' animation but I think they are fairly lean already.

Sorry if you have already tried this, if so I apologies for the redundant info.

Rob

Great
As you said Pharan I figured this was the desired behavior as soon as I found it, but it took a while to hunt down where those bytes were being allocated each frame. Can't say I really saw any performance improvement, but less garbage is always a good thing
To be honest I have extended the functionality of SkeletonRenderer to meet my own devious requirements quite a bit now, so my benchmarks are probably off the leaner code in the repo by a bit. Hopefully soon I can showcase what I have added
Take care guys

Hi Nate,

Was hunting down some garbage SkeletonRenderer.cs was generating and think I have identified and fixed a small issue.

Currently at the Setup Mesh Stage (line 201) you do:

float[] tempVertices = this.tempVertices;

with this.tempVertices initially being set to a size of 8 for RegionAttachments.

However, for meshes you re-allocate as necessary to accomodate their (mostly larger) vertice length. I noticed though that you re-allocate the local copy and not the global copy.

Changing the lines 246 and 267 from

tempVertices = new float[meshVertexCount];

to

this.tempVertices = tempVertices = new float[meshVertexCount];

or something along those lines updates the global array too and solves the issue, which results in 0 bytes of garbage for me now once the skeleton has been around for a while and displayed all potential meshes/triangles etc.

I imagine for others with a lot of meshes and vertices this was probably generating quite some garbage over time. Hope you can update the source accordingly. Anyway, pretty simple bug that just slipped under the radar.

Cheers, Rob

P.s. Maybe also get rid of the global private variable mesh, as at the moment you only try and destroy then null it in Reset, but it is never assigned to, you use a local with the same name in LateUpdate instead

Wow, this game is looking great! I would dearly love to know how you are creating/rendering those trails for the sword swipes (especially with the hint of color in them). Oooh and how you're making the death animation, the one where they sort of disintegrate in a haze of blue. Such great visuals!

Rob

I ran into this issue recently too, but I think the functionality has just been re-assigned to be more friendly for multi image selection/parenting. I believe now you first select a parent bone, then CTRL+click your images, then draw a bone normally wherever you fancy and it should assign the parented images as slots under the bone you drew and rename the bone.
Anyway, could be wrong as this was off the top of my head but give it a go and let us all know how you get on

Rob