Tue, Mar 20
Mon, Mar 19
Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Sun, Mar 18
Wed, Mar 14
Thu, Mar 8
Tue, Mar 6
@Joshua Leung (aligorith) , any updates here?
Mon, Mar 5
My first reaction is that this is probably a oversight. All of the settings you mention were actually introduced after the basic strip creation code was written, so there was no need to support these.
Tue, Feb 27
Praise God for showing me the solution! In the outliner, type "Animation", then right click on the object's animation data you want to remove and click "Clear Animation Data"; or just hit Spacebar and type "Clear Animation". It's too bad there's no interactive context for clearing this as we have with Actions, however, it's great that a simple solution is available. :-)
Hi, New dev here! I wanted to claim this task. I propose performing an armature scan after bone removal was done, reset or remove handle settings in affected bone.
I'll post my diff later.
Thu, Feb 22
Closing. The previous commits should implement the desired functionality now. (But somehow, I ended up quoting the wrong task number when making the commits)
Wed, Feb 21
Feb 20 2018
Feb 19 2018
Can confirm the bug.
Feb 16 2018
Nothing changed with the opengl32.dll.
However, I couldn't say if the Intel graphical drivers are up to date (it's a company computer and I'm not admin on it).
Ensure both your OS and drivers are fully up-to-date (and use official GPU drivers, not those provided by windows or tablet/laptop maker).
Launch Blender from the command line with -d option and attach as text file here any error printed out in the console (do not paste it directly in comment).
Try to run Blender through Software OpenGL, this will be much slower however, if everything works then it means that the bug is spefic for your GPU/Driver and you should report the bug to your GPU vendor instead.
Feb 13 2018
Hmm.. that sound strange. Assigning to self to investigate
Feb 12 2018
Feb 9 2018
Processor: i3-6100 @ 3.7GHz ; 64 bits
RAM: 8 Go
OS: Windows 7 Pro SP1
Graphics: Intel(R) HD Graphics 530 chipset
Feb 8 2018
I've taken a look at what the code is currently doing. Basically, it makes several assumptions (based on the grabbing/translating keyframes case):
- You're only moving a few keyframes at once (and mostly not a whole set of consecutive points that may end up overlapping after the transform)
- You're more interested in the ones that you're currently moving (i.e. the selected ones) than the ones not moving, so it only keeps the selected ones if they come in conflict with anything
Feb 6 2018
Feb 5 2018
Please always follow bug report guidelines and provide exact steps needed to reproduce the issue. If the issue can not be reproduced within few steps from factory startup, attach .blend file.
Feb 4 2018
Unfortunately I'll only be able to look at this in April again, so let others take over....
Feb 3 2018
Jan 30 2018
Jan 29 2018
Ok, so carefully re-reading the bug description, it sounds like there are two parts to this: 1) Animation Data, 2) Constraints
Jan 26 2018
Thanx for reporting back.
(That script was just a quick hack to have animation playing for 10secs and report back how many frames actually played...)
As written above, a workaround would be manually renaming the bones before joining the armatures. This means that it wouldn't be too difficult to make it automatically rename them for us when joining. Manually renaming all the bones would be a long lasting pain
Weird, I don't know what that script is supposed to do.
I can confirm this behaviour (though this is probably a known limitation).
Having a hard time reproducing this