Step 9 is mandatory and doing this causes editing deleted Shape Key "Key 1".
Since editing Shape Key "Basis" should be equivalent to be editing mesh without any Shape Key, this is clearly bug.
@Jacques Lucke (JacquesLucke) was quicker (and I agree...)
This is for reusing same cloth simulation setup.
you can also swap the mesh datablock to another mesh datablock (which has its shapekeys setup correctly)
I don't think that this is a bug. Why should shape keys of vertices that have been removed be stored?
This is for reusing same cloth simulation setup.
And strange steps were actually meant to be workaround, but it was useless though.
This is true in 2.79 as well.
This is also true if shapekeys are not animated (and you dont need to remove the second shapekey as well)
[So basically you could skip steps 5, 6, 7, 8, 9 and still have a "broken" basis here]
Sun, Jan 20
Sat, Jan 19
- Key frames don't show in the Dope sheet but only in the Graph Editor:
Fri, Jan 18
Can confirm in that file indeed....
Sure. I simplified the project a bit and just left the object I'm having issues with. Gave it another test and it's still coming up with the same problem.
Cannot reproduce here [doing this from scratch]
Oddly enough I found one exception. I had an audio track in the video sequencer so I could time the animation to the audio. When I deleted the audio and tried to make a new keyframe with a different value, Blender let me make the adjustment. But now it's back to how it was before, snapping back to whatever value it's currently set to.
Thanks for the response but I don't think that's what's happening here. Coming from video, I'm familiar with keyframes and auto-keying, and this is odd behavior. I'm saying when I try to adjust the value at any point in the timeline after the first keyframe is set, the value will snap back immediately. Blender will not let me adjust the value at all. It doesn't matter if I set the second keyframe before or after adjusting the shape key value, or whether or not I use auto-keying. The value will not change.
Thu, Jan 17
This seems like normal behaviour, and should be affecting all types of animation, not just shape keys.
Wed, Jan 16
T59178 as well
Think there are a couple of reported instances of "this cannot be changed once it has a keyframe"
Will try to put them all together [and tag them with Animation]...
Tue, Jan 15
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.
Mon, Jan 14
i've just found this problem - keyframing renderability for a Plane object and a Point Lamp are not working in an animation file that worked at 2.79
The animator doesn't need to see the whole path all the time, its like onion skin, so this could be solved by limiting the number of frames evaluated, adding a start_clip and end_clip, maybe even with a pretty fading gradient.
The drawing is the easy part, it's efficiently evaluating the pose at many frames that is complicated.
Honestly, I use more in 2d animations, it's not an essential tool for me, but it helps in a few moments. Really, ghosts based on geometry would be interesting! I adapted using custom shapes to help in the silhouette, because my focus is to use sprites in the bones on Unity3D. Another thing, I think it would be interesting to have an option to recursively show the ghost bones, for example: with the "Selected Only" and "Recursive" options activated, selecting only the shoulder bone, you would see the ghost silhouette of the whole arm. But I understand if this tool needs to be removed. Thank you!
No one seems to be using the ghosting currently, or really considered it. Performance is really poor and it doesn't work correctly with the depsgraph, so difficult to judge.
Still don't work with today build (downloaded from blender.org / beta section / windows 64).
The plan here was initially that we'd move all the ghosting settings out of armature into the bAnimViz ones, so that, like Motion Paths, we could have the same set of functionality available for both Objects and Armatures/Bones. That is why they were marked as deprecated. (Unfortunately, within about a month of doing that, "Life" (TM) happened and I didn't get around to putting in place the necessary changes then)
I'm not sure it's really deprecated, since those are comments from 10 years ago. @Joshua Leung (aligorith) would know what the status is here I think. Maybe ghost drawing needs to be restored in 2.8, and the comments updated?
@Brecht Van Lommel (brecht), actually, in Blender 2.79b, ghost_step is still doing something...
@Jacques Lucke (JacquesLucke), indeed, ghost_step should be removed since it has done nothing for many years. I guess this comment was added during 2.5 development with the intent of updating/replacing it, but that never happened.
Looking at the code it seems like this property is deprecated since 6 years at least.
@Brecht Van Lommel (brecht), do you know why e.g. the ghost_step property still exists even though the comments say it is deprecated for such a long time already?
Of course! But I did in linux, where I am there is no Windows.
Ah I see, maybe there was a bug in 2.79b as well then. Could you prepare a simple .blend file that shows the issue? Just to make it easier to reproduce the issue for others.
Hi! To me both modes are with bugs. I said in 2 bones or more because I tested it in Blender 2.79b and with only one bone it did not show the ghost.
To me it looks like this Ghost feature is not working at all currently? Is there any reason why you need "2 or more bones" to reproduce this bug?
Do the other Ghost modes ("In Range" and "On Keyframes") work for you?