Howdy, Stranger!

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

something wrong with the parenting nodes

edited September 2016 in Issues
So I think something's wrong with Fraenir's parenting nodes.  Anytime I parent Illinir to his shoulders, after the animation, she slides right off of him.  I've only tested this on his shoulders, and with Illinir/Fraenir so far, but here are the snapshots I took:

Before animation:

focus on the Green Illinir and Fraenir in the chair- ignore the couple near them. So far, nothing out of the ordinary.

After Animation:

She moved up some.  The thing is, when I parent Fraenir to someone, it seems fine, everything's working.  But when I parent someone to Fraenir, in my case on his shoulders, things get buggy.  

Comments

  • odesodes Administrator
    edited 10:35AM
    Can you send me this pose file.
  • edited 10:35AM
    @odes pose file?
  • odesodes Administrator
    edited 10:35AM
    Ok, I see some pose corruption when using parenting with shoulders. This is most likely due to the way shoulder drivers work. It becomes more apparent when using control 0 with humping.
  • jei3jei3 Moderator
    edited 10:35AM
    he means the interaction, you can get to the .yiff files by going to:
    %appdata%\yiffalicious\interactions\local\



  • odesodes Administrator
    edited September 2016
    Disabling drivers with F10 sorta "fixes" the issue. Basically what's happening is that because the shoulder driver calculation spans several frames and not just a single frame, that means the calculation will bleed into history and distort it when it's undone.

    Definitely a bug and something I will fix for the next release.
  • edited September 2016
    Been testing this myself and I think I spotted what is doing it.. I believe it's a combination of the the 'spine' of the Dragon with his 'leaning' in the test I did. It also only seams to happen after you hit the stop, during the animation with multiple changes to from snapshots didn't effect them. Just when the animation is stopped to they try to find where they were and get it all wrong.. and it't not just the shoulders as I found this on other parts aswell such as the hip/ass. Also.. it's not just the dragon as I just found it on the Dragoness aswell.

    Normal:

    After hitting stop a few times:

    After stopping during a different snapshot:

    Dragoness hands floating from legs:

    You can check yourself with this one that I uploaded titled: "Dragon Group fun - quicky"

    Hope this helps
  • odesodes Administrator
    edited 10:35AM
    I think this is fixed Shadow drake, but can you send me that pose file so I can test on this one too?
  • edited 10:35AM
    Sure thing.. um... how do I go about sending it to ya :P
  • odesodes Administrator
    edited 10:35AM
    You can just upload it anywhere and post the link.
  • odesodes Administrator
    edited September 2016
    Thanks for that. These issues (because there were several) are now fixed.

    The first issue was that we remade the way shoulder drivers work, and thus we don't have a correct rotation for the shoulder until a couple of frames after the targets have been placed. So when resetting the target anchors (after play or when undoing), we have to wait until the shoulders have adjusted for some frames.

    The second problem was that the hip doesn't reset correctly when going from play to edit mode. You can even see this if you play and pause that the hip of a thruster sort of slowly glides back into its original position. So basically what happens is that hands are moved into their correct location, then the hip moves slowly back and thus offsets the hands a little bit each time (if they're parented to the hip).

    Now it doesn't do that anymore. Hips are moved instantly into their correct reset position with no gliding.
  • edited 10:35AM
    @odes are these fixes already in the game now, or do we have to wait for a patch release?
  • odesodes Administrator
    edited 10:35AM
    We haven't made a new build with these fixes, so they're not available yet. Not sure if we're gonna do a patch release or just jump straight onto 0.6.2. I don't think 0.6.2 will take as long as 0.6.1 did.
  • edited 10:35AM
    what about now?
  • odesodes Administrator
    edited 10:35AM
    It should have been fixed but some are still reporting issues. If you run into problems with parenting, please share that yiff-interaction with us so we can study it.
  • edited November 2016
    Grab this:
    http://www.mediafire.com/file/jtoow0ysnhn0ami/balconyhug.yiff

    Various things are screwed up in the interaction as it is. I fixed the cat's hands, but hit Test and then stop and they'll be out of place again. Sometimes severely. I'm not sure what all's going on there. Illinir's left hand and wings get moved around too.

    If it's helpful, I have all the settings maxed out except reflections is off. Translucency, tessellation, etc are all maxed.
  • jei3jei3 Moderator
    edited 10:35AM
    ragepro said: . I fixed the cat's hands
    i think this is the same thing lovalicious mentioned here

    lovalicious said: if you parent to a brown node, it's more likely to corrupt than parenting to a colored one.  
    you have the cats hands parented to the dragons spine, and the dragons hands parented to the cats spine.

    i don't think this is your graphics settings, i think it's how the dark node position is resolved vs the lighter ones.
  • edited 10:35AM
    Yeah, I mean, I agree. Just trying to offer all the useful information. :)
  • odesodes Administrator
    edited November 2016
    I think I found the problem. When using Transform->Rotation offsets, the spine solver doesn't work properly. I forgot to take the transform settings into account, so basically what happens is that the spine solver undoes the transform settings' influence, but in a weird order that causes this behavior.

    You can even see this if you just play and stop the interaction (in this instance I removed the parenting). The spine sort of bends forwards and then back again:



    By setting the spine solver's sliders to zero, it "fixes" the issue, but it's not supposed to do this in the first place. (As you can see right now - it doesn't even target the spine anchor which is completely wrong.)

    By properly configuring the order in which things are executed, we now get this behavior (with parenting):



    Better quality video here:
    https://gfycat.com/LeanFinishedLabradorretriever

    Do note that this affects how poses are interpreted, because now it actually properly targets the spine anchor. So this pose will load like this right now:



    But you can easily fix that by just placing the spine anchors where you want them.


  • edited 10:35AM
    Roger that. Thanks for the fixes. I'll eagerly await the next patch.
  • edited 10:35AM
    Seems like there still might be some problems with the parenting nodes, specifically with Fraenir. Previewing this pose causes Illinir's legs to move every time you stop. (It's obviously not done, please don't judge it for artistic merits. :)
  • odesodes Administrator
    edited 10:35AM
    ragepro said: Seems like there still might be some problems with the parenting nodes, specifically with Fraenir. Previewing this pose causes Illinir's legs to move every time you stop. (It's obviously not done, please don't judge it for artistic merits. :)
    Thanks for pointing that out, ragepro.

    It seems like Rotation offset X and Y corrupt poses. For now you can just reset those sliders until fix is available.
  • edited 10:35AM
    Hmm! Some of my other poses seem alright. Thanks for the rapid response anyway.
  • odesodes Administrator
    edited 10:35AM
    I think this will be fixed in the upcoming release (0.6.3).

    0.6.3 is scheduled for release in a day.
  • odesodes Administrator
    edited 10:35AM
    Build with fix is out. Let us know how it works!

    https://www.patreon.com/posts/yiffalicious-0-6-7367239
  • edited 10:35AM
    Issue appears to be fixed. Thanks for the prompt response as always odes. :)

    I am not super pleased about paying montly for an app that I feel like should be a one-time $40 purchase, but rapid support responses like this make me feel better about it anyway.
  • odesodes Administrator
    edited 10:35AM
    Glad to hear it!

    I understand that paying repeatedly like this isn't for everyone. But the only reason apps like Yiffalicious are possible to do is thanks to people who are willing to support projects in this manner. Crowd-funding really is an amazing thing. Before it, there wasn't any viable method to pour this amount of time into this kind of content.

    You can always try to snipe interesting releases or simply just grab the free public release at the end of each cycle.
Sign In or Register to comment.