ryancbaker

  • 25 июл
  • Регистрация: 12 окт 2014

    I do like the improved rendering of bones - you guys did great work on 4.0.xx. I just wish the minimum size of the bones was smaller than currently, or that you had a few more bone icons that were at a smaller size (just a dot or a very tiny crosshair). That's really all it would take to help me out.

    If I have some time in the coming months, I'll write up a full explanation of my skeleton and post it on the forums. AFAIK, the only ways that you could change Spine such that I could simplify my skeleton would be as follows:

    1. I have many bones that rely on their parent being scaled on one axis so that upon rotation, their rotation is distorted in an oval. It's very similar to the top face of the diamond in this tutorial, where the rotating bones' parents have a scale of <1 on the vertical axis: Blog: Rotating diamond tutorial
      In my case, I set all of the parent bones that have that <1 scale (let's call them "D2" bones for distortion) to constrain to a single bone (D1) that controls that distortion scale. But since they are at different places in the skeleton hierarchy, I have constrain them individually. Anyway, the child bones that rotate (let's call them "R2" bones for rotation) are also constrained to a single bone that controls rotation (R1). However, this could be greatly simplified for me if we could do away with the D2 bones, and if the R2 bone could pick up both rotation AND scale distortion from the R1. The problem is that all R2's must have an immediate parent with a scale <1 in order to create that distorted ovoid rotation.

    I'm wondering if I can come up with some kind of hack using the new 4.0 feature that separates X and Y in constraints, but I haven't had a chance to work on it yet.

    1. Create an interface for mesh vertex sorting that does not rely on the order of bones to which they are bound.

    And it would speed up my workflow if one could....

    1. Duplicate a constraint. After duplication, you could then reassign the two bones that are constrained to each other.

    2. When creating a constraint, include the name of the bone that's being constrained, rather than the bone it is constrained to. The reason is that I often set several bones to all be constrained to one parent, so they all need a unique name rather than the parent's name. I know I could just constrain them simultaneously, but the order of the constraints becomes important, and I often have to do them individually in a specific order (which is why it would also help to be able to duplicate constraints).

    My constraint nomenclature is normally "200_bone_that_is_constrained <


    100_bone_constrained_to". I number the bones in groups, with the parents having the lowest numbers (100 in this case), and sets of children having higher numbers (200). This way I can quickly look through the constraints and sort them by number, which means the order of constraints is (usually) correct so that they don't conflict or override each other.

    Here is the file. My goal is indeed to control the "zoom level" of the bones - I just want them to be incredibly small and precise. I would like for their minimum scale (0.1) to be at least 25% of the current size, if not smaller.

    As for the use, rotate m700_AIM_000_shortcut and you'll see that the skeleton has isometric rotation that looks 3D. One of our biggest time sinks in creating our humanoid characters was having to re-animate each skeleton in every direction (8-directional) for every animation state. So I built a skeleton that could be fluidly rotated (with mesh distortion for tweening, still in the works), so it can be animated in one direction, and then just rotated and texture-swapped (with texture draw order re-sorted) for the other 7 directions.

    The number of constraints is to create the isometric rotation on a number of bones at each lateral layer of the skeleton. Effectively, to achieve the isometric distortion, I have to create a special set of bones at every "vertebrae" of the skeleton.

    I'm going to be able to simplify some of the bones in the head that control mesh distortion in the face (what you see in the screenshot above), but unfortunately, due to how vertex sorting is handled, I may have to keep many of them. If you allowed us to sort vertices manually rather than relying on the order of the bones that the mesh is constrained to, I could drastically simplify the skeleton.

    I also really need a way to quickly view sort order, attachments, constraints without having to scroll through miles and miles of the tree. See thread here: Ease of Use UI Proposals - Improved Tree & Animation
    Specifically, this suggestion about the interface:

    Your reply:

    Annotations in the tree should help jumping to constraints. We added the Animations view some time ago as an easier way to access animations. We could do a similar thing with separate views for skeletons, skins, constraints, and maybe draw order. This may be simpler than your proposal and seems like it would address the problem about as well?

    • Изменено

    In settings in 3.8.xx, I have bone scale set to 15. This allows me to see and easily select from the large number of overlapping bones (crosshair bone type, bone length = 0) in my skeleton:

    However, in 4.0.xx, with the new high-res bone graphics, I have set bone scale to 0.1 (apparently the smallest setting), and the bones are still huge compared to 3.8.xx. This makes it almost impossible to see and select these crosshair bones when they are near each other:

    This is the same area of the same skeleton - sorry that textures are on/off in the different screenshots.

    Second Request: I would love it if there was a bone type that was simply a dot or a very small +

    • Изменено

    In Spine 4.0.49, I am unable to create new transform constraints. If I select a bone and then click New > Transform Constraint, nothing happens; normally you would be prompted to select a bone to constrain to, but this never occurs.

    My guess is it may be due to the number of bones and constraints I have. I've experienced bugs (see below) due to this in 3.8.xx, but the constraint bug is new to 4.0.xx.

    (Second bug):
    For some time, even in Spine 3.8.xx and previous (possibly back to 3.7.xx or before), the Metrics panel has not displayed any data. See screenshot - all metrics are "0". I have hundreds of bones and constraints, unsure of the exact number.

    Spine file is attached.

    char_OMNI_v139.spine

    Yaaassss, I know! :grinfake We are dying over here trying to get the v4 beta ready. There's so much we want to do. We will get there, I promise!

    I can't wait! Mostly looking forward to the new curves editor, but there are tons of goodies in the list. Keep up the good work!

    Add another +1 to copying constraints for me!

    • Изменено

    Hi, everyone.

    Maybe I'm missing a trick shortcut, but as far as I'm aware, there is no easy way to easily select all keyed bones to make them visible in the Dopesheet. I'm working in a very large project, and it's currently pretty time-consuming to scrub through the tree to find all bones with the key icon beside them, then select them, then lock the dopesheet to keep those bones visible in the dopesheet.

    If there is not an easy way to do this, I would suggest a feature along the lines of one (or both) of the following:

    • Ability to filter the tree (and/or dopesheet) by keyed bones
    • A button in the dopesheet to instantly show all keyed bones. Would be a nice addition between the filter and lock buttons in the existing dopesheet UI.

    Reusing animations for an iso character is possible, but you have to set up the skeleton to accommodate this animation from the beginning. So there may or may not be a way for you to reuse the animations you've created. Could you post some screenshots, GIFs, or YouTube videos of what you have so far?

    Hey, Nate.
    I just wanted to check back in on this topic. I am still hitting a serious wall with this, and I will either have to do some crazy masking to hide the back faces of some textures (which is probably not even possible to do in my case), or duplicate a bunch of textures and flip them in photoshop... which would obviously double the game textures, and is also not viable.

    I would really like a way to do one or more of the following:

    1. Allow texture mirroring without using the back side of the texture
    2. Have a "texture flip" option available on the slot (that does not use the back side of the texture)
    3. Add the ability to turn back-face culling on/off on a per slot or per texture basis.

    Thanks as always for your responsiveness and hard work! I'm loving 3.8 (especially animation state folders).


    Speaking of which, I helped develop the faux-3D mesh for the truck in this game: http://www.nickjr.com/blaze-and-the-monster-machines/games/blaze-tow-truck-tough-sandbox/

    All animation was done in Spine (at my recommendation) 🙂 That tire I was asking you about at the beginning of this thread was the tire for the main truck character in this game.



    Hi, Nate.

    I'm still running into issues that I can't find a way to work around for our game, regarding this back-face culling topic.

    I really need to be able to mirror textures for left/right facing characters and objects. But I also really need to be able to do back-face culling in many many places to give things a 3D effect. I haven't been able to find a work-around, and I'm either going to have to double all of the textures to include the mirrored versions of assets, or I'll have to turn back-face culling off, and sacrifice the really awesome 3D-esque effects that Spine is capable of pulling off.

    It seems that the easiest single solution would be to add a "reverse culling" (or "invert texture") checkmark on a slot, which can be keyed. When checked, it would display the "back side" of the texture... meaning the culling would work in the opposite direction on that slot, culling the front face rather than the back. This way when I set the texture to -1 scale (with back-face culling turned on), the texture would be visible. If set to any positive scale, it would be invisible, since the front face would be culled. This would totally solve my problem.

    There are probably other solutions as well, but this seems like the easiest.

    Thanks for your time and attention!

    I see what you're saying - that by changing the FPS to 12, it effectively can set it to 12 hashmarks per second on the timeline. So if you wanted to do what I was suggesting, you would set the FPS to 12 before animating. However, this is both unintuitive, and duplicates the function of the "speed" slider in the same menu, because you have 2 methods to modify playback speed, but neither of them modifies the timeline hashmarks or keys.

    Question - when exporting to AVI or MOV, does the "Dopesheet FPS" setting remain in effect in the export? Or does it export at 30 FPS regardless of this setting?

    What I was actually suggesting is that the FPS slider (or rather, a slider in the settings menu) would change the timeline's number of hashmarks per second, without 1) changing playback speed, or 2) modifying the position of keyframes relative to seconds. So the animation would play at the same speed, but simply changes the hashmark interval. This would allow you to animate at 12 "hashmarks per second" (allowing you to be more efficient at animation), and then change back to 30 for polishing the animation. But this only works if the hashmark interval changes WITHOUT changing the speed... which you currently cannot do with the FPS slider as indicated. I suppose you could set it to 12 FPS, animate, and then set it to 30 and stretch your keys out to 30, but that would be a lot of repeated adjustment.

    I'm assuming that the hashmarks themselves must be arbitrary, since the editor has an effectively unlimited FPS, and keys can be set to arbitrary positions between hashmarks... so why would the frame hashmarks themselves be the one thing that can't be edited? You can freely edit speed and keys, but not the frame interval?

    I also wish that the "Editor Frame Rate" option in settings could go below 30 FPS, and that this was in the Playback panel rather than settings. Currently the only way to view the animation at true 12 or 24 FPS would be to key every frame and set it to Stepped interpolation. It seems like this would be easy to implement?


    Also, is there a way to easily view all keyed bones in the dopesheet? I've tried using the lock, but if I ever deselect the lock, it's almost impossible to find all of the keyed bones again in a complex skeleton.

    • Изменено

    Hey guys!

    I have a suggestion that I think would not be terribly complicated. Would it be possible to make the Dopesheet's time scale - that is, the number of frame hashmarks displayed per second - changeable in the preference settings? I understand that the framerate is not dependent upon these hashmarks, or the number of hashmarks per second. I also realize that you can put a keyframe at any arbitrary point, and they do not have to be on the exact hashmarks. The reason I'm requesting this change is for a couple of reasons:

    1. Animators who want to do stepped interpolation for animations at exactly 12 or 24 FPS (standard traditional animation production framerates) would be able to do so easily. This would allow people to convert traditional animations to Spine easily, and might make Spine more usable for non-game purposes, such as animating characters in Spine and exporting/re-importing into After Effects, etc.
    2. For my purposes, I'd like to be able to animate on even divisibles of 12 or 24, so that my keyframes can be at specific fractions of a second, like a keyframe exactly at 1/4 second, which is currently only possible by putting a keyframe at roughly 7.5 "frames" in. But this is obviously more of an edge case.

    Thanks, as always.

    Really looking forward to the full release of 3.8 - I hope to see it soon!

    Thank you for your responses!

    I'm so sorry I misspelled your name - I have no idea how I did that, and I apologize sincerely.

    Hi, Eraki.

    I have a couple of questions:

    1. Where has the Spine Waffle been moved to now that Waffle is shutting down? I tried searching the forum and blog, and couldn't find any posts about it.

    2. On the forums, I cannot click on a user to view their profile or message them. I thought that previously I could click on someone's profile image to message them, or compose a new message and "find a member." Right now when I try to do that, I get an error message: "You are not authorised to view the member list or profiles."

    Thanks for your help!

    -Ryan

    I tried using the 1-bone IK with stretch, but it will just rotate to 180 when it's flipped rather than scaling into negative numbers. I also tried every combination of setting the scale offset to -1, setting the scale constraint to -100 (which I guess does not do anything), and every combination of setting the constraint target and child to + or - scale.

    Here is an example of what I'm actually trying to do:
    SpineRotateLeg_RCB - YouTube

    Our game is top-down, with a slight perspective. I'm simulating perspective through bones scaled to 0.8. What you are looking at in the video is an updated version of the character's leg, which I'm trying to improve to make it look a bit more 3D. We are controlling character rotation programmatically, so I'm trying to create a single animation that can be rotated without changing animation states.

    As you can see, the leg looks like it's in perfect 3D-esque perspective until the bone rotates past the vertical (any angle between 90-270 degrees). The leg flips around backwards. This could easily be corrected through negative scale, but as mentioned, I can't key this in every case because the code is controlling rotation. What I'd like to do is use a constraint to flip the leg backwards (in other words, to the correct orientation) when the angle of the leg crosses that 90/270-degree threshold.

    • Изменено

    I have tried a number of different methods, but I cannot find a way to use a constraint to invert the scale of another bone


    causing it to go from positive to negative scale (or vice versa). From what I can tell, if a bone is set to positive scale, it remains positive even if the bone to which it is constrained is set to a negative scale. The opposite is also true.

    Example: I would like to be able to use a constraint to invert scale in a case where I want to flip some textures (but not all) when I flip a character in a specific animation state.

    Obviously I could do this on a bone by bone basis, but in my case, I will actually need to do it via a constraint.

    Specifically, my actual use case is much more complicated, because I am attempting to flip certain bones to negative scale based on another bone’s rotation - I want scale to be positive when the bone is rotated toward the right (0 +/- 90), and scale to be negative when the bone is rotated toward the left (90-270). But if a normal scale constraint could be used to invert (-1) the scale, then that would provide the solution I need.