Forum rules - please read before posting.

Unity 2D animation progress, and issue

edited December 2019 in Technical Q&A

Hello,

Creating a new game and have been using Unity's new 2D animation package. Personally, it feels like the most natural way to animate characters within Unity, without having to buy another animation software and use two programs, etc.

To put it simply, figured out how to animate characters within it using instructions from other threads in this forum.
Though now having an issue where the new characters won't adhere to the Sorting Map and resize accordingly when walking. As Unity's 2D Animation package is newer, this is experimental, though am confident it will work given some advice.

The steps done so far have been written out in fairly good detail. (Note: These likely aren't "best practices" when it comes to Adventure Creator, but the 2D animation package is newer, so there aren't official steps to follow yet):
1) Character Wizard, select "Unity Sprites 2D" and use a placeholder sprite as the image.
-Drag .png into Scene
-Run Character wizard and drag .png as base graphic

2) Create the animated "bones" version by dragging in the PSB file into the project (bottom panel anywhere). Click on it and in the Inspector, click "Sprite Editor". Select "Skinning Editor" in the dropdown in top-left corner of the editor window that opens.
-After finishing all bone and mesh adding/adjusting, click "Apply" at top of editor window. Then drag character PSB (from bottom project panel) into main Scene window.
*Created bones/mesh in character like YouTube video shows:

3) Make into prefab.
-Replace the sprite in the hieracy with the PSB image with bones in it (If the character was made into a prefab earlier than/before this, may need to delete the old sprite character that's currently in Scene, open character prefab, and drag the PSB into the prefab's hierarchy.
-Then drag prefab into Scene. Then drag the PSB (from prefab hierachy view) into the character's "Sprite Child" in Inspector

4) Apply IK solvers/targets INSIDE PREFAB WINDOW.
-Click the base sprite/prefab, and add "IK manager" component (Click "Add Component" button, search for "IK Manager 2D"). -Add "Limb" solvers on arms, and legs. Click "+", rename to "LeftArmSolver", etc.
-Add "target" to each bottom-most bone (one closest/next to hand and foot). Right click on the bone, click "Create Empty". Use Transform/arrow to move the "X/Y arrows" to end of limb (hand/foot).
Click on the Solver, and drag the "Target" gameobject into its Inspector's "Effector" field, then click "Create Target" button.
5) Make/assign animator controller on PSB in Inspector (from prefab view) (Or, if there is already, on PSB layer click "Create" button in Animation panel, and should assign animator controller to it automatically)

7) Write "Idle", "Walk", etc. in Inspector fields under "Standard 2d Animations" (on top character heirarchy level - in both in-scene character, AND IN PREFAB VIEW)

8) Flipped PSB in Photoshop horizontally and saved as Walk_R.
-Open "Skinning Editor" for Walk_L PSB
-Copy skeleton (but not mesh) from Walk_L PSB (In "Sprite Editor", use "Copy" button at top)
-Then paste skeleton (but not mesh) from Walk_L PSB (In "Sprite Editor", use "Paste" button at top) to other Walk_R PSB (in Sprite Editor) (Check boxes: "Bones" and "Flip X")
*Using method from link: https://docs.unity3d.com/Packages/com.unity.2d.animation@2.2/manual/CopyPasteSkele.html

9) Generate mesh for the new Walk_R PSB

10) Drag and Parent all sprite/rig combinations under the top-level Player root (in Prefab view)
*All Sprites will be showing stacked on each other.

11) Put the Animator component on the top level / root "Nathan New Player" in prefab view (may need to copy/paste Animator comp. from another level). ALSO assign the Sprite Child as the top level / root, e.g. "Nathan New Player" (drag from the Prefab's heirarchy (left side window)

12) Make Animation clip for each direction
-In Animation panel, click "Record". Then Disable GameObjects (top-level of sprite/bones folder) that WON'T be showing for that direction. Need to click "Add Property" button, then right-click on the top-level folder/direction that needs to be invisible (e.g. MiraWalk_U). Then click "Add Properties" in the sub-menu item that appears. (Disable by unchecking the box next to the GameObject's name. Then Enable it again in the last frame of the animation by checking the box).

13) After each animation is made, drag the animations from the "Animations" folder, into the Anim. Controller window (They may be automatically added. If so, no need to drag into Anim. Controller window)

14) Make Idle animations too, then drag them from the "Animations" folder, into the Anim. Controller window

15) In the Anim. Controller window, choose "..Idle_D" animation as "Set as Layer Default State", by right-clicking on the animation box, and clicking "Set as Layer Default State" in sub-menu that pops up.

16) In character's inspector (in Prefab view), un-check "Turn root object in 3D?" (under "Movement Settings") to fix the problem when character turns sideways to a "flat" / invisible state when turning directions.
And check "Turn before walking" (if deciding to keep that feature in game)
-Also check "Ignore gravity?"

17) Add "Follow Sorting Map" component. Check boxes: "Follow default Sorting Map", "Offset original Order, and "Also affect children"


The last step is where there is an issue occurs. With the "Edit-mode preview" box checked, the main character "Nathan" resizes fine (NPC "Mira" does not though). But in "Game Mode:" and the character doesn't resize when walking. They just remain in their original size.

The attached screenshots will show this. In this first screenshot it shows how the main character resizes in "Edit-mode preview":
https://imgur.com/a/jrEa9mA

This second screenshot shows how the characters aren't adhering to the Sorting Map in "Game Mode".
https://imgur.com/a/KO2cSCv

Any ideas are greatly appreciated! Feeling like a lot of progress has been made with 2D Animation Package, though need some assistance to continue!

«1

Comments

  • When it comes to 2D, there should generally be a separation between a character's position/scale on screen, and the animations that it uses. The hope is that there should be little difference to a character's behaviour, regardless of whether he uses flipbook-style animation, or skeletal animation.

    I notice that the "Follow Sorting Map" component is unchecked in your second screenshot, but aside from that - make sure that this object/root does not have its scale baked into any animations, as this will override the behaviour of the Follow Sorting Map.

    If Turn root object in 3D? is making a difference to behaviour, you may not have assigned the character's sprite child. The character's sprite (or root sprite, if using bone-based animations), should be a child of the root object (the one with the NPC / Player component), and assigned in the character Inspector's "Sprite child" field. If this is already the case, it may be that the baking of this child's rotation is also affecting behaviour, in the same way as above.

    One thing to note is that all of the animations/graphics can be non-immediate children as well. If you create an "interim" child between the root, and your rig/sprite set up, and place the "Follow Sorting Map" component in this middle GameObject, then that should scale properly without interfering with the behaviour of the character's animation.

  • Thank you Chris for your ideas and explanations. It's appreciated!

    "Follow Sorting Map" was checked when I looked again -- must've just been un-checked accidentally before taking the screenshot.

    The animations and resizing on the Sorting Map now work correctly after adding a new GameObject, then adding the "Follow Sorting Map" component on it like you mentioned. This image shows that component:
    https://imgur.com/a/tHz74N7

    Just to give more details of how the characters are set-up, here's a screenshot showing the Player's root object and its' inspector view, and one of the sprites / bones folders expanded (the rest of the folders look the same):
    https://imgur.com/a/6Hh9Ez4

    Regarding "Turn root object in 3D?", yes, it does have issues when that's checked (they become "invisible" and resize in various ways)
    The animations and movement now appear to have the correct functionality without having it checked -- though is there a reason you'd recommend it to work when it's checked? Might other issues appear later if it isn't?

    Regarding assigning the character's sprite child, there's no one sprite "level" (like the Brain character) to assign since there's different folders containing all the sprite pieces. When setting it up originally in the Character Wizard, I used a generic idle sprite "placeholder". Later on, the placeholder was replaced. All of the sprites/bones' folders were moved onto the Player's root (parented). Finally, the Player's root was set as the Sprite child.

    That's what I thought your instructions from another forum post meant to do: "moving the whole hierarchy onto your Player's root, making that the new "Sprite child" transform":
    https://www.adventurecreator.org/forum/discussion/8382/cannot-play-animations
    Unfortunately the screenshots weren't visible in that post, so had to do a bit of testing to get the animations working.

    All the animations now work correctly when selecting the in the Animation panel and playing them in a scene, as well as when clicking to move/walk around the scene's navmesh, and when having the Player (and NPC) move to Markers using an ActionList.

  • If it works, it works! My point about the sprite child, though, was that the child object itself doesn't need to be a sprite specifically - just that your sprites are children of it.

    Since the Follow Sorting Map component is not a parent of your sprites, it won't be able to affect their Sorting Orders as you move in front of / behind scene sprites. As you haven't brought this up, I'm not sure if it's an issue for you - but if so, it's best to arrange things closer to the way AC expects it.

    By this, your hierarchy would be more like the following:

    -Nathan (root Player)
    --Sprite Child (an Empty with the Follow Sorting Map)
    ---NathanWalk_R
    ---NathanWalk_L
    ---(etc)

    I'm assuming your Animator component is on the root object, which means you'd also have to move the Animator onto the Sprite Child to avoid having to rebuild the animation clips. AC will auto-detect that the Animator is now on the SC and not the root.

  • edited December 2019

    Thank you for your explanation, Chris! That makes sense.
    I arranged the hierarchy like you showed, and it animates correctly!
    https://imgur.com/a/T1cJ00H
    It fixes the "Turn Object in 3D" issue, as well.

    Very good point about moving in front of / behind scene sprites.
    I did some testing after re-arranging the hierarchy, and the Sorting Map also works fine when moving in front of / behind scene sprites.

    May need to give some extra thought to the different characters' (main Player and NPC's) "Order in Layer"s to keep some of their sprite layers in each folder from overlapping when the characters are near each other. The circle colliders don't appear to be working (yet). Also, if there's ever a story instance when they need to be closer than their colliders allow.

    Got some ideas about the layers/sorting map from the post here, though haven't completely solved it:
    https://www.adventurecreator.org/forum/discussion/8806/unitys-new-2d-animation-package-and-sorting-map-layer-problem

    Everything else seems to work well for now!
    Thanks again for your time and help.

  • edited December 2019

    Actually, the next step was that the NPC needs to have a Box Collider 2D added to the empty GameObject that was created. That solved the collider part.

    There is still a bit of overlapping of each characters' (Player and NPC) sprites at the line where the Sorting Map divides the NavMesh into its Sorting Areas (If they're in front of / behind each other)

    Will continue to think about both of their "Order in Layers" so that each can move in front of / behind scene sprites - while not overlapping some of each others' separate sprites.

    It'd be something that would improve the experience. If there's any advice, it's welcome and appreciated!

  • There is still a bit of overlapping of each characters' (Player and NPC) sprites at the line where the Sorting Map divides the NavMesh into its Sorting Areas (If they're in front of / behind each other)

    As this is a visual problem, can you elaborate on this with screenshots?

    If two characters are each in separate regions of a Sorting Map, then their Sorting Orders should be different, and so they should be drawn in the correct order.

    If two characters are both in the same region, their Sorting Orders will match. In this scenario, AC will shift their "Follow Sorting Map" GameObjects down the Z-axis by a tiny amount in an attempt to force the correct display.

    This amount is actually configurable via the Shared Layer Separation Distance property of the Scene Settings component on the scene's GameEngine GameObject.

    Having more complex characters with child sprites and offset orders does complicate things. You have Also affect children? checked in your Follow Sorting Map component, and this works by offsetting each child sprite's final Order In Layer value by its original value.

    See the 2D Demo's Player character, Brain2D, as an example. His shadow sprite's original order is -1, so this will always be one less than the base sprite, whose original order is 0.

    You'll have to make sure, then, that your Sorting Map's Order values are separated by an amount larger than any of these offsets - so that each sprite's possible order values are always unique. If in doubt, just split up your Sorting Map's Order values by large amounts, e.g. 0, 10, 20, 30, etc.

  • edited December 2019

    Thank you for your explanation, Chris!

    Here's a screenshot showing the overlapping:
    https://imgur.com/yraQOmm
    Also here's one showing the Sorting Map:
    https://imgur.com/a/jpSi6Tf

    After more testing, it actually doesn't appear to overlap at the Sorting Map's line. It can happen anywhere in the Navmesh.

    To give some detail, I set each character's sprites with same names (e.g. "left arm") to have the same "Order in Layer" for a couple reasons:
    1) Unity's Sprite Editor (where you add bones) auto-assigns the "Order in Layer" values to each individual sprite ("left arm", "body", etc.) inside each folder set (e.g. Walk_L, etc.).

    Each character's sprite "Order in Layer" numbers were separated by large amounts (by 30). For example, the Nathan (main Player) character's "body" sprite originally had an "Order in Layer" of 40, and the Mira (NPC) character's was 10.
    That made it difficult to determine which number to set the lower "Sorting Area" so the characters can walk in front of / behind a scene sprite. So, I changed the "Order in Layers" to smaller numbers.

    2) It's likely necessary to set them to be the same. I tested separating the values of each character's different sprites by 4. Long story short, it solved the overlapping but it didn't work completely as it always showed the character with the "Order in Layer" difference of 4, in front -- even if they were standing behind the other character.

    So, using amounts corresponding to the same order/layer values that Unity's Sprite Editor auto-assigned (and tweaking slightly to compensate for obvious fixes, like the "down" and "up" animations having arms on the same levels), I set both characters to:

    Walk_L:
    body: 1
    head: 2
    left arm: 1
    left leg: 0
    right arm: 0
    right leg: 0

    Walk_R:
    body: 1
    head: 2
    left arm: 0
    left leg: 0
    right arm: 1
    right leg: 0

    Walk_D:
    body: 1
    head: 2
    left arm: 0 (Note: Tweaked this from Unity's auto-assigned "1" value, to "0", to match the other arm)
    left leg: 0
    right arm: 0
    right leg: 0

    Walk_U:
    body: 1
    head: 2
    left arm: 0
    left leg: 0
    right arm: 0 (Note: Tweaked this from Unity's auto-assigned "1" value, to "0", to match the other arm)
    right leg: 0

    In this example, the two "right arm" sprites are overlapping. When running in "game mode" I checked their values. The RIGHT-facing Nathan character's "right arm" in this first image is "2":
    https://imgur.com/a/9givr3W
    The DOWN-facing Mira character's "right arm" is "1":
    https://imgur.com/a/sxWE9MT

    The "body" sprite for both were actually on the same plane of "2".

    AC seems to increase the values by 1 (likely for the reason you mentioned in your previous post: shifting "their "Follow Sorting Map" GameObjects down the Z-axis by a tiny amount in an attempt to force the correct display")

    In this case, I see why the sprites overlap. Even the original values listed above would also create an overlap (since "right"-facing "arm" and "body" are above the "down"-facing arm).

    Perhaps these numbers can be tweaked where all instances work to not overlap.

    From reading other forum posts I'm aware that AC doesn't yet support Unity's 2D Animation Package.
    It ultimately still feels worth it to use Unity 2D Animation Package. It's intuitive to create realistic animations and allows easy editing of animations later on, all within the same program! And seems like it will become widely used for Unity 2D animation soon.

    Hope some further advice can be offered to improve, if there's any!
    Thank you again.

  • An understanding came to mind after posting last: Instead of shifting down the Z-axis, AC likely increased the values by 1 since that's what the Sorting Map did. It's top half Sorting Area was set to 1.

  • Each character's sprite "Order in Layer" numbers were separated by large amounts (by 30). For example, the Nathan (main Player) character's "body" sprite originally had an "Order in Layer" of 40, and the Mira (NPC) character's was 10.

    Each character should have the same set-up - their respective body parts should match (i.e. both Body sprites should be 0 or 1 or whatever). It seems you've now done this. By "separating by large amounts", I was referring to the different Sorting Map regions - not the character sprites.

    AC seems to increase the values by 1 (likely for the reason you mentioned in your previous post: shifting "their "Follow Sorting Map" GameObjects down the Z-axis by a tiny amount in an attempt to force the correct display")

    Moving along the z-axis does not affect the "Order In Layer" value - only the drawing order of two sprites that have the same Order In Layer value. If the "Right arm" is 1 by default, and is now 2, then it should be because they're in a Sorting Map area set to 1. As above, separate your Sorting Map areas by larger amounts, i.e. 0, 10, 20. If a character is z-shifted, see the Position values of their Sprite Child transform.

    In your example, where two characters had different arm order values, were they both in the same region?

  • edited December 2019

    Thank you!
    After posting last, yes, I realized that the sprites increasing by 1 was indeed due to the top Sorting Map region's value of 1.

    The Sorting Areas; values are 1 (for the top region), and 20 (for the bottom).
    https://imgur.com/a/jpSi6Tf

    If the example you're asking about is the one where the two characters' arms overlap (shown in in the screenshot with the right-facing main Player, and the down-facing NPC), then to answer your question: Yes, they were in the same Sorting Map region.

    Wondering about the shifting down the Z-axis -- I realize it's meant for characters composed of one singular sprite.
    Would it also work for characters with several child sprites, as long as the sprites are all
    named the same and have the same hierarchy setup (in folders with same names)?
    Also how does that work -- by shifting the Sprite Child / GameObject (with Transform) AND the Child Sprites under it -- so that it essentially sees the group like one whole sprite?
    My thought was that all the Child Sprites' "Order in Layers" were still influencing the order they appeared in some way.

    --
    A "mistake" made when setting up the Player character "Walk_R" animation was accidentally switching the names for the left / right arms, and legs, sprite names in the PSB (Photoshop) file, so that they didn't follow the naming pattern all the other directions' had.
    Only noticed this recently, so to keep the corresponding name pattern, I renamed the "right arm", and "left arm" names in the hierarchy. In this image, notice the arms and legs in "Walk_R" are not in the same "order" in the hierarchy as "Walk_L" below it:
    https://imgur.com/a/02u11zr

    Unsure if this has anything to do with it. Though if you believe so, I'll recreate "Walk_R".

  • No, the ordering in the Hierarchy shouldn't affect things.

    Z-shifting works by affecting the "sprite child's" z-position. Any children it has will be moved along with it as a consequence. I don't see why it shouldn't work with characters that are made up of multiple sprites.

    Try increasing the "Shared Layer Separation Distance" property that I mentioned above, and you'll see the effect it has when viewing the scene at an angle. If two matching body parts (e.g. Torso for Player, Torso for NPC) have the same Sprite Order, then their display should be based on their relative Z positions.

    When both characters are in the same region, are they being correctly separated along the Z-axis (increase the above property to see it more pronounced), and do their respective body parts have the same order values? Also, are you using an Orthographic or Perspective camera?

  • edited December 2019

    Thank you again, Chris.

    It was using the Orthographic camera. Out of curiosity I changed the camera to Perspective though that didn't have an effect on the overlapping.

    Tested increasing the "Shared Layer Separation Distance", from the original value (.001) to an exaggerated number (5) to see the separation clearly. In Game mode, I viewed the scene at a different angle (in Scene view) to see the distance between each -- as you mentioned.

    To give some visuals, here's screenshots showing the scene view with the characters in the same Sorting Map area.
    The first one shows the distance between the characters. The rest show the scene turned slightly showing the NPC head sprite overlapping, etc.
    https://imgur.com/a/8kfUyZE

    It feels like the "Order in Layer" is overriding the sprite group's Z-axis shift in some way, and wants to draw the sprites with the higher "Order in Layer" in front of the ones that have lower numbers.

    Seems to make sense from what you said: "If two matching body parts (e.g. Torso for Player, Torso for NPC) have the same Sprite Order, then their display should be based on their relative Z positions."
    Each matching body part for each character does have the same Sprite Order. Although certain matching sprites like the Heads for each character have a Sprite order of "2" (higher than the Torso / Body sprites of "1").

    If the characters are both in different Sorting Map Areas, it draws the sprites stacked correctly and shows the characters how they should appear (likely since the Order in Layer numbers for each character are far enough apart then)

    It seems the animations with bones are dependent on having the different Sprite Orders to show the characters' body parts stacked correctly, so they can't all be on the same Order in Layer (which I also tested).

    Will continue to look further into ways to solve, or improve. Any other advice is of course welcome.

  • Ah, so the issue is with non-matching body parts? Right, that would make sense.

    Back when Unity was promoting Anima2D as the go-to asset for creating 2D skeletal animation, it included a "Sprite Mesh Combiner" component that was able to merge multiple sprites into a single mesh. Perhaps there is a technique to achieve something similar with this system.

    Alternatively, try giving each body part the same sprite order value, and then re-arranging their orders in the Hierarchy (which, IIRC, should affect their relative drawing order), or their relative Z-positions. If you can have all body parts using the same order value, but still have a single character display correctly, then you should be able to also have characters display together correctly as well.

  • edited December 2019

    Thank you again for your advice, Chris!

    My understanding is that the Unity 2D Animation Package needs the separate sprites to work. There's also no equivalent to a "Sprite Mesh Combiner" (my understanding is it's because the 2D Animation Package already creates a "mesh" within its Sprite Editor).

    Looking further into the idea of having all body parts with the same Order value:
    I found a solution to get the characters' sprites to be "grouped", yet still remain separate from each other. It fixes the overlapping of the separate sprites like what was happening.

    I used a component called "Sorting Group" to "group" the multiple sprites together. It's main purpose is to keep multi-sprite characters together. The component doesn't actually merge them, it just "views" the group as one complete character sprite.
    Here's more info on the component (and example images with similar overlapping character issues) for anyone interested:
    https://docs.unity3d.com/Manual/class-SortingGroup.html

    I added the Sorting Group component to each of the characters' Sprite Child (the empty GameObjects created earlier with the Follow Sorting Maps).

    After that, everything worked fine except just one small issue where the main Player was being rendered on top of the NPC, if he was on the top Sorting Map area and the NPC was on the bottom Sorting Map area. This screenshot shows this:
    https://imgur.com/a/6Blm49s

    I was able to solve this by setting the Sorting Map's "Affect Sprite's" to: "Sorting Layer" (instead of "Order in Layer").
    This worked great and solved all overlapping issues with the characters.

    Though, there's one more small issue.
    When testing the scene with a scene sprite (tree) in it, I found that the "Sorting Group" component's "Order in Layer doesn't get updated from AC (understandably -- it hasn't been coded into AC to do so yet).

    Basically, the values of the characters' "Sorting Groups" always stay at "0" -- and the characters are behind the tree since the tree's "Order in Layer" is "10".
    When manually changing the characters' Sorting Group value to "30", for example, they do appear in front, as shown here:
    https://imgur.com/a/fukFDKZ

    Wondering if there might be a way to copy the original "Order in Layer" values which AC generates for each character (based on their position in the Sorting Map), and transfer the values to the "Sorting Group" component?

    I've used your scripts before, for example, to copy values from Unity UI textboxes, and paste them in a Text Mesh Pro UGUI component.
    Also, I've discovered another similar script for Anima2D to copy / paste values to a component:
    https://adventure-creator.fandom.com/wiki/Anima2D_and_sorting_maps

    Might there be some similar way to solve this using a script?

    Will continue to look into this.
    Any advice is greatly appreciated. Also, Happy Holidays to you!

  • edited December 2019

    After more testing, it appears that changing the "Sorting Map Affect sprite's": "Order in Layer", to "Sorting Layer", only "worked" because it had no values yet entered to its different "Layer" fields.
    If "Sorting Map Affect sprite's": "Order in Layer" also doesn't have any numerical values entered (just 0's) it has the same "working" behavior.

    Just sharing some screenshots to help give a better visual of the overlap issue that happened before making those changes:
    https://imgur.com/a/lm2U7aD
    When they're both in the same Sorting Map Areas, it appeared correctly.
    Also, the order appeared fine in the Scene view running in Game Mode.
    Just not when one character is in a separate Sorting Map Area from the other character.

    Though, I still feel this could work with some way (e.g. script) to copy / paste values.
    "Order in Layer" values (e.g. "1" and "20") can be entered in the Sorting Map's different Areas -- it just shows like the above overlap example.
    These images show the values being transferred to the sprite renderers:
    https://imgur.com/a/BMeuhlk
    From testing, these values are overridden by the Sorting Group's values (e.g. "Order in Layer").

    When manually entering the characters' "Sorting Group" "Order in Layer" value to "0", or "30" respectively -- they appear correctly in front of / behind each other, and correctly in front of / behind the scene sprite/tree (which has an "Order in Layer" of "10"):
    https://imgur.com/a/fukFDKZ

    Thank you again for any continued advice!

  • When testing the scene with a scene sprite (tree) in it, I found that the "Sorting Group" component's "Order in Layer doesn't get updated from AC

    This is an oversight on my part. From what I gather, if the Follow Sorting Map updated the Sorting Group, instead of each sprite individually, things would then work as intended.

    I shall look to have this incorporated into the upcoming v1.70 update. This should be out early in the the new year.

    Also, Happy Holidays to you!

    And to you!

  • edited December 2019

    Thank you! Sounds like a great update to look forward to for the new year!

    Just to share some more info regarding your reply:
    It may work if the "Sorting Group's" "Order in Layer" value is updated, and the other individual sprites' Sprite Renderers' values are still updated.
    The "Sorting Group's" value appeared to override and take priority over the values of the individual sprites.

    Thanks again, and have a Happy New Year!

  • Yes, it does seem that the Sorting Group overries the Sprite Renderer components.

    I shall have it so that the presence of a Sorting Group component, either on the same GameObject as the Follow Sorting Map, or as a child, causes the FSM to only affect this - and not the Sprite Renderers.

  • edited January 2020

    Thank you! The new AC update works great! Updating the "Sorting Group" does the trick.

    Others may be interested in using the Unity 2D Animation Package workflow as well, so I'll just mention that "Frame Flipping" also works for animations created within it. For example, all you'd need to do is create "left" walking/running animations, and the "right" walking/running ones can be automatically mirrored with their bones and mesh.

    For instance, on the Character's top-level (root) inspector under "Frame Flipping", select "Right Mirrors Left" (Or "Left Mirrors Right", whichever direction you choose).

    Since "down" and "up" animations (e.g. Walk_D and Walk_U) can't realistically be flipped for obvious reasons, those bones would still need to be copy / pasted from one PSB to the other, and new meshes generated for each (using the method mentioned in the first post).

    Thanks again for the update!

  • Very confused by a simple animation. I've done animations before and never had this problem. ANY help would be extremely appreciated. Thank

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.