ok, thank you
Thu, Sep 20
@Joshua Leung (aligorith) not sure about that one, animation of those properties is not explicitly disabled in RNA code, so I guess animation is prevented by missing valid RNA path handling for FCurve modifiers? But I kind of doubt we'd want to support that, would be some sort of inception (animation within animation)…
Wed, Sep 19
Mon, Sep 17
@Sergey Sharybin (sergey) you worked on hair recently, maybe you can check on that one? Thanks.
Thanks for your response.
Does this still happen within 2.8? Otherwise there is very little chance this get fixed in 2.7x series now… ;)
Sun, Sep 16
Crash still occurs, but very intermittently. Hard to see an obvious cause.
Mon, Sep 10
Thanks for the report, but bugs about new depsgraph in old 2.7x series are really not relevant at all now, new deg is only developed and maintained in 2.8 branch.
Sun, Sep 9
One have to wiggle a lot to make it crash indeed… Looks like yet another COW/threading issue (threaded code from deg evaluation using some COW data already freed from somewhere else)…
Sat, Sep 8
@Joshua Leung (aligorith) not sure how to fix this, looks like recalcData_actedit() does not have access to fcurves, so it cannot check whether re-ordering of keyframes is actually needed… Maybe we should just always call remake_graph_transdata() there?
Mon, Sep 3
Reminds me of similar issue with some VSE properties in 2.7x… IIRC, animation gets re-evaluated when editing those values, hence they get reset to animated value immediately…
Seems to be an update issue, clicking on the show/hide 'eye' icon, or on the render 'camera' one in the outliner fixes to visibility too, but clicking again on the viewport 'grid' one exhibits again the problem. As if driver eval was not updating things properly. not suer what exactly is the problem here, would suspect again some COW/depsgraph thingy, @Sergey Sharybin (sergey)?
ok. you are the coder.
That’s the last time I say it: THIS BUGTRACKER IS NOT A USER SUPPORT SERVICE!
I think that it not necessary to look into the code as first thing to check. Maybe I used wrong configuration on the settings of the FBX panel,or it's necessary to use a "special" combination of settings,that I don't know. The best solution I think could be to make some attempts by the cross users,users who uses/know blender and nuke. I think that it worth trying before to close this post. It was not strictly a bug,but it was very close to be a bug,because each combination of setting should produce a different kind of effect,but since it could work only in some circumstances,it could be a bug.
You’ll have to give proof that issue is from Blender side, not from Nuke side first… afaik meshes are pretty reliable in our FBX io addon. Not our job to investigate that kind of issue, especially not with a closed-source software we don’t have access to.
Sun, Sep 2
ok for the armature,but not good for the mesh. Nuke should import correctly the FBX file format.
Thanks for the report, but this sounds more like user support than bug to me - we don’t even know whether Nuke supports rigging at all, even less if it can import it correctly from FBX…
Cannot confirm here on linux, might be something specific to OSX… @Arto Kitula (akitula), maybe you can check? Thanks.
Wed, Aug 29
Thu, Aug 23
@Yevgeny Makarov (jenkm) am beyond being tired to repeat the same over and over and over, this has already been explained gazillions of times.
Aug 18 2018
Closing. I fixed it in another, much better way.
Aug 16 2018
Registered specifically to say that I found a solution for the same problem I was having with a different animation.
Aug 13 2018
Aug 9 2018
More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.