Majicpanda

  • 2021年11月15日
  • 注册于 2014年11月23日
  • Sorry to necro this again.. we finally got around to art side of prototyping this and I misunderstood thinking you could key frame SLOT visibility... but this does not appear possible.

    How do you key frame attachment visibility if you are using a programmed equipment system to set attachments per slot? I thought we could make a Torso_Front / Torso_Back slot and when walking down vs up it would simply toggle that SLOT visible with a key framed slot.

  • Passed this info along to the artist... mere programmer myself here also 😃 I really appreciate the time taken to get this process ironed out. I almost feel the Spine workflow will be one of our top 3 systems in the entire game at this point, lol.

    Ultimately, do you feel all of this is absolutely necessary or what is the draw back compared to letting spine spit out many, many sheets of atlases and just use basic slot swap API?

    The biggest thing we wanted to support was modding in the future which will require static atlases players can draw over, but if it becomes too cumbersome to get all of this working quickly we would need to skip that for now and just get a prototype working. It sounds like maybe the export script for Photoshop may not natively support the slices idea at the moment?

  • I finally understood the 0,0 origin for weapon attachments and those are working great with the custom atlas packing, but when moving to all the different pieces of equipment like each foot, leg, chest, arms, etc I'm not quite understanding how all of that equipment will work. It would be quite cumbersome of a flow not to be able to have our artist draw directly onto the skeleton in the PSD or deal with figuring out the pivot of every single slot required to then draw each piece into a separate PSD with 0,0 origin. Is this what's required to make a robust equipment system?

  • Harald :
    Majicpanda :

    but the rotational info is not in the exported Weapons atlas like the example in the project.
    ..
    I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

    I'm not sure I understand your question correctly. Please note that the atlas only contains packing rotation of 90, 180 and 270 degrees to fit the attachment better into the available atlas space. Skeleton attachment rotation is not stored in the atlas. It cannot be stored there, since you can use the same attachment (e.g. a dagger attachment) multiple times at a skeleton, with each instance rotated differently to e.g. position one dagger attachment in a mouth, one in each hand and one at a belt.

    The Skeleton has each attachment rotation stored at the parent Slot. So when exporting your skeleton, your individual attachment rotations are exported in the .json or .skel.bytes file.

    Please let me know if I misunderstood your question.

    Wow my mistake then... we were going to use spine a few years ago for a project that got too big and I recall simply dragging everything to a slot, rotating and then exporting and it all just worked. I guess the actual workflow is every item needs to be drawn on the X axis pointing right but pivot wise that's something to figure out also since that info is not stored? I assumed I had to drag every item as an attachment to the proper slots and then rotate then move them all so the handle of an axe etc pivot was set.

  • This new process worked perfectly for being able to use the individually packed atlases, but the rotational info is not in the exported Weapons atlas like the example in the project.

    Weapons.png
    size:1024,256
    pma:true
    Weapons/axe
    bounds:2,2,500,250
    Weapons/sword
    bounds:504,2,500,250

    I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

  • Harald :

    Regarding equipping items and different directions, it will not make much of a difference: you would then equip the goldensword-up attachment at your weapon-up slot and your goldensword-right at your weapon-right slot, while the respectively playing animation will show and hide the respective attachments. You could also see each equipment item as a skin, attaching multiple attachment images at multiple slots, like trousers are also a skin in the Mix and Match example Spine project. You can check out the code in spine-unity example scene Spine Examples/Other Examples/Mix and Match Skins.

    This actually makes a lot of sense. I was concerned of the performance problem of constantly changing attachments every direction change, but you're suggesting to run the equip item logic over all slots any equip change and then let the Spine animation itself dictate the slot visibility. Thanks for all the insight, we will see what kind of damage we can do 😉

  • Ok thank you for that I will start over and follow the video exactly to get a baseline working.

    When doing a character with Right/Left + Up directions and equipment is it best practice to do a separate skeleton for the up direction? For performance reasons, it seems most logical to do this so that skeleton image changes aren't called every time the character changes directions. The idea would be on equipping a weapon/armor I would call the attachment change on both skeletons that way it's just hiding/showing the correct skeleton on left/right vs up.


    Harald :
    Majicpanda :

    I tried doing this but it's quite cumbersome and isn't exporting any rotational or positioning data so I assume I've got a workflow issue somewhere.

    What do you mean by it isn't exporting rotational or positional data?

    Majicpanda :

    Is this archaic way still the most up to date?

    Please see the documentation page here.

    Packing by folder structure is one possible way, and is still up to date, yes. There are multiple ways to trigger export by folder structure, either manually via the Spine - Texture Packer menu shown in the video, during export of your skeleton, or via the command line interface. Using the command line interface is the recommended way to avoid a lot of repeated manual work.

    Attempting to follow but getting errors saying there's no matching regions for either Atlas. I have a human skeleton root, exported it with no textures. Ran the packer over the Base Character folder and Weapon folders independently. Dragged the atlas file and png to a Weapons folder in unity and it generated the mat, atlas and everything required no problem for both the Base Character and Weapons.

    There's not much in the weapons.atlas.txt is what I was referring to whereas the example "AtlasRegionAttacher" in Unity has a totally different setup than what the video does. It uses a shared atlas but only for equipment. It doesn't try to use 2 atlases in one skeletonData.

    Weapons.png
    size:1024,256
    pma:true
    axe
    bounds:2,2,500,250
    sword
    bounds:504,2,500,250


  • Sorry to dig and hijack but we're also trying to incorporate a system of equipment and wondering if we should go the shared atlas route. I tried doing this but it's quite cumbersome and isn't exporting any rotational or positioning data so I assume I've got a workflow issue somewhere.

    Is this archaic way still the most up to date?
    https://www.youtube.com/watch?v=Im0RB6musvA

  • EDIT (Solved)
    Sorry just realized every sprite simply needed Full Rect mesh type enabled.. instant problem solved.

    I am trying to use a single default skin to swap out all the images at runtime to accommodate basically an endless amount of characters into the game and when I use the following code I get the attached visuals. I am following the MixAndMatch example and my sprites are all set to 32PPU that I am loading at runtime. The default character in red is the default Spine character that is my player that I have not called the following code on and renders properly.

    //set spine animation
    var skeletonAnimation = GetComponentInChildren<SkeletonAnimation>();
    if(skeletonAnimation != null)
    {
        var customSkin = new Skin("Custom Skin");
        var skin = skeletonAnimation.Skeleton.Skin;
        var sourceMaterial = skeletonAnimation.SkeletonDataAsset.atlasAssets[0].PrimaryMaterial;
        List<Sprite> sprites = Resources.LoadAll<Sprite>($"Sprites/Spine Textures/{npcData.spineSkinName}").ToList();
    
    foreach (var attachment in skin.Attachments)
    {
        int slotIndex = attachment.Key.slotIndex;
        Attachment templateAttachment = skin.GetAttachment(slotIndex, attachment.Key.name);
        Sprite sprite = sprites.Find(x => x.name == attachment.Key.name);
        if (sprite != null)
        {
            Attachment newAttachment = templateAttachment.GetRemappedClone(sprite, sourceMaterial);
            //Attachment newAttachment = templateAttachment.GetRemappedClone(sprite, sourceMaterial, useOriginalRegionSize: true); //This did not help either
    
            customSkin.SetAttachment(slotIndex, attachment.Key.name, newAttachment);
        }
    }
    
    skeletonAnimation.Skeleton.SetSkin(customSkin);
    skeletonAnimation.Skeleton.SetSlotsToSetupPose(); // Use the pose from setup pose.
    skeletonAnimation.Update(0); // Use the pose in the currently active animation.
    }
    
    

    Any help is appreciated, thanks!

  • Experimenting more with this I noticed the character is not 100% exactly the same size as the original 32PPU character.

    I played around with the skeleton data scale and came up with .0313 scale which eyeballed out to as close as possible to simulating using 32 PPU in unity. Do you have any better magic math or ways to achieve matching unity's PPU to ensure it's scaled the same as our tilesets that are designed in the same resolution?

  • Harald :

    Have you tried the officially included shaders Spine/Sprite/Unlit, Spine/Sprite/Vertex Lit and Spine/Sprite/Pixel Lit? These should perform the required Unity pixel snapping.

    I haven't used Spine for 2 years... catching up on what has changed has been a whirlwind and I wasn't doing pixel perfect on the last prototype. Using Unlit and clicking the Pixel Snap checkbox did in fact round everything off, thank you 🙂

  • There may not be a known solution for this but it's a bit of a deal breaker if it doesn't work, so I was wondering if anyone has figured out a way to perform pixel perfect on Spine exported pixel art.

    The Experimental Pixel Perfect package in Unity removes all the odd 2px wide left eye and 3px right eye etc issues that has plagued their engine for years, so if there is a solution for this it would be pretty amazing. I'm not sure why it works on Sprite Renderer and not mesh.

    Spot the culprit 😃

    I'm wondering if this is because I couldn't figure out how to mimic using 32 PPU on the mesh renderer since changing the PPU on the atlas has zero impact on the size of the object in game?

  • What was the solution for this? We are using the built in pivot point sorting in unity and custom axis XYZ 010 and it works perfect, but I was going to start toying with the idea of using Spine for a pixel art game and just ran into this "issue."

    Edit: Ensuring I put the root pivot at the feet and then adding Sorting Group to the object seems to have auto allowed sorting by pivot in the draw order. Phew. Must be some sneaky code somewhere in Sorting Group that sorts by pivot automatically..

  • Any reason you're not using mecanim for that? It can serve as an input -&gt; transition system as well.

  • I would highly suggest against Playmaker for a programmer. NodeCanvas is imo one of the best programmer friendly tools (though with a decent learning curve to adapt yourself to a front end tool) to visualize FSMs etc.

    I'm currently using the Dialog Tree of NodeCanvas to create a very complex event system like Faster Than Light where there's tons of branches that fire tons of different, unique options and it is working out quite well for us.

    The FSM side of the tool is nice because you code your transitions as separate code blocks and can then just click the connecting lines to assign 1 to many transitions.

    I used it for a few quests.. an Injured Blacksmith who needed to stand up, run a dialog tree, then continue on when he was done talking. The tool is nice like that in you can create nested FSMs, BTs, Dialog Trees and fire one another back and forth to create some really unique gameplay.

    Hope that's helpful.

  • From what I read it's basically supported out of the box because it uses Mecanim?

    http://reunono.github.io/CorgiEngine/animations

    You "can" use SpineAnimation with Mecanim if you put a behavior on every state and use it to set the animation name on state enter, but that's a lot more complicated. I did it, but I can't explain how because I'm just dense 😉

  • Well that makes sense because on iOS you're probably running 30fps.

    Are you lerping your camera movement? I wouldn't ever expect anything to be smooth by simply setting the Camera pos to translate the bone in real time.

    Try something like:

    void LateUpdate()
    {
            Vector2 newPos = followedBone.position;
    
        // Lerp the camera's position between it's current position and it's new position (change smooth to fit game needs)
        transform.position = Vector3.Lerp(transform.position, newPos, smooth * Time.deltaTime);
    }