- User Since
- Oct 31 2006, 10:56 PM (840 w, 2 d)
Feb 17 2022
Feb 3 2022
This is what I'm doing in python to work around it currently (no need to debug or improve this python code - it works well enough) - it feels a bit inelegant, and pretty hard for a lot of scripters to figure out, I'm also not happy with passing context over to the function (I could pass the current frame by itself I guess):
I think it makes sense to add this API. Python doesn't have knowledge of the inserted keyframe (nor even the fcurve) - you have to find it, locate the correct keyframe on the curve (loop over keyframes in py, looking for the correct frame) and then finally set the type. This could be a problem speedwise (not 100% sure - inserting keyframes is slow anyway and you're likely not doing it in any sort of tight loop but who knows! maybe when keying lots of things)
For me interpolation type is more useful than Needed/Available/etc in most cases. (which is part of the api)
In the absence of adding api, I think the docs should be explicit that it does not follow the preference - I was actually quite surprised by this personally.
Dec 10 2021
It creates images, there's just nothing in them, I'll post the rusults and the -d output.
(It also doesn't replicate on macos for me, just on this linux box - I'll try on another when I get a chance)
Dec 7 2021
Hmmm, could it be a graphics driver related problem? It has persisted through at least one driver update.
Nov 13 2021
A couple of questions from a user standpoint
Is it possible to create hierarchical action groups in this fashion automatically on keying based on Bone Groups?
Would it be a good change to make Location / Rotation / Scale sub-groups under transform for objects, and the bone name for bones? That could get rid of the variability of group names in objects depending on what got keyed first.
Nov 9 2021
The crash no longer happens here! (newer build) - I hope it is fixed (or it won't come back)but it was probably a bug with blender not this script.
I'm personally good with the changes, and I encourage renaming things to be a bit more readable.
(I'd like to approve this but I don't see how - do I even have the ability to?)
Nov 6 2021
For reference, the crashing build was:
Also please update the version, and blender version bl_info (this diff is not compatible with 2.80) - I don't know if you would like to add your name to authors, but I encourage it :)
The line that seems to trigger the crash is line 290 in copy_custom_property():
Hi Demeter, here's what I found:
- initially I tested in 2.93
- I saved the file in 2.93 (added the patched addon in the script editor for convenience)**
- loaded in 3.00 beta -> ran the script -> copy the 'color' property - > crash
- redownloaded the test file
- loaded and saved in 3.00 (no saving in 2.93)
- no crash
Hi Demeter, investigating;
It looks like the addon doesn't work for blender 2.9x (I assume because of api changes):
Oct 22 2021
Hia folks, just a couple of other perhaps relevant tasks/discussions, T89069 ? It touches on similar areas and it might be nice to do a UI cleanup at the same time. Also T83710 has some analysis of snapping modes that miiiiight be relevant.
I kinda agree here. The problem (too many handles) is less likely to occur with simple animations/new users, and not worth the confusion. More advanced animators should have an easier time/tendency to customize to their liking / task at hand.
Oct 19 2021
Aug 17 2021
From what I understand, the functionality is dependent on the position of the playhead, the strip, and the mouse cursor when invoking the operator - this might make running it from a menu inherently ~impossible as you can't reasonably control that relative position (technically, you'd do it by panning the view relative to the menu position.
I think the functionality is a bit weird, and might benefit from re-evaluation (not the scope of this bug) - but I feel unqualified to open a design task for it as I'm not a member of the VSE module, and I have never used this operator or understood why I might want to.
Jun 24 2021
Jun 15 2021
Jun 12 2021
Jun 11 2021
Based on suggestions from Hans Goudey, replaced "Only Selected Curves Keyframes" with an enum - the boolean is a bit confusing as turning it ON turns OFF keyframes on unselected curves. The enum currently has "All" and "Selected" as options, it could be "Selected Curves" if that is too cryptic.
Jun 10 2021
Apr 3 2021
Mar 16 2021
Mar 6 2021
Ok, from a chat on blender.chat, here is a proposal that could make Luciano's idea work.
Mar 2 2021
I like the outline = keyframe color rather than than the outline = selection state (idea 2) a bit better as I'm more interested in selection state usually. Other than that I don't have very strong feelings about this proposal, it would need to be coordinated with grease pencil though; right now the interpolation tool creates breakdown frames, and you can delete breakdowns preferentially - I much prefer the "delete breakdowns" to "delete blue frames" and there's a consistency there.
Keep breakdowns in Grease pencil, but replace everything else with these colors?
Or something else? I wouldn't want to lose that functionality/simplicity. Thoughts?
Feb 18 2021
Hi Sebastian, great work so far, I'll put here some responses from a usability perspective.
Feb 16 2021
It seems like the operator should take a custom center? like maybe cursor position? or optionally it could use the entire range of the pivot selection (active/bounding box/individual/cursor/etc.) with maybe some of those that 'don't make sense' falling back to the default?
Jan 19 2021
#0 0x00007fffbf121d52 in () at /lib64/libnvidia-glcore.so.460.32.03
#1 0x00007fffbee28a0b in () at /lib64/libnvidia-glcore.so.460.32.03
#2 0x00007fffbed1abaf in () at /lib64/libnvidia-glcore.so.460.32.03
#3 0x00007fffbed1afff in () at /lib64/libnvidia-glcore.so.460.32.03
#4 0x00007fffbed1c5f2 in () at /lib64/libnvidia-glcore.so.460.32.03
#5 0x00007fffbf0f1c20 in () at /lib64/libnvidia-glcore.so.460.32.03
#6 0x00007fffbed2db7c in () at /lib64/libnvidia-glcore.so.460.32.03
#7 0x0000000001381af9 in ()
#8 0x00000000013828b8 in ()
#9 0x000000000138318f in DRW_draw_pass ()
#10 0x00000000013ad414 in ()
#11 0x000000000137acde in ()
#12 0x000000000137af52 in DRW_draw_render_loop_ex ()
#13 0x0000000001beeb9f in view3d_main_region_draw ()
#14 0x0000000001799d41 in ED_region_do_draw ()
#15 0x00000000012319fe in wm_draw_update ()
#16 0x000000000122f8a0 in WM_main ()
#17 0x0000000000de68de in main ()
Dec 21 2020
Further Notes on Snapping modes (worth thinking through):
Dec 15 2020
Dec 14 2020
Agreed. Note you'd still have some of the corner cases pop up, but I think a brief animated highlight after you click would make it quite understandable (and it would be less likely)
Dec 13 2020
A slightly more radical proposal:
Dec 12 2020
Nov 16 2020
I've played with the patch and I feel it could be improved a bit more
Oct 31 2020
So it seems the algorithm should subdivide the curve into straight lengths based on the length of the bones, rather than taking the fit to curve factor and scaling? I'm a bit out of my depth but I can see how the latter will lead to the issues we're seeing - it seems the bone original mode needs to have a different algorithm or you'll see these issues - curve resolution is a compounding factor (In the example I uploaded, I took the 'working' curve at a resolution of 64, and subdivided it a looot of time and made it gnarly- now even with the the high resolution, apply pose as rest pose results in the recursive shrinking)
Don't know why the image didn't show in my previous post!
Capturing a realization from talking on blender.chat for reference: upping the value of curve resolution preview seems to fix both the scaling down with apply pose in the top chain and the error reports in the bottom one.
Is there a way to use 'limit curve' without getting too slow/recursing infinitely (or using a higher resolution independent of the settings?)
Oddly improving this might make https://developer.blender.org/T77330 seem worse, if the bones are snapping to a high resolution curve, but the render preview is much lower.
Oct 30 2020
Thanks a bunch! glad we caught it early :)
Oct 29 2020
Oct 27 2020
Having looked at the example case, I feel like this is a good candidate to fix in 2.92; the case is somewhat rare, and as pointed out above, will often result in the rigger coding a workaround (I sometimes have an un-animated bone that I copy scale from, plus an extra child bone as a target, for many cases and I feel perhaps this one)
working rigs will have the workaround, and not be affected by fixing the bug (workarounds should still work while becoming un-needed) - broken rigs in this case will mainly be too broken to animate, so I doubt we'll break many (any?) files in the wild with this bugfix.
I've been opening existing animation files with it, so far so good. I encourage any testers to do the same (open it on your files with existing rigs and animations)
I don't know if Blender's general (something can be active but not selected) is strictly useful - though it would be nice from a Blender perspective if behavior in the graph editor is as close as reasonable to the rest of the program - maybe a general UX task about selections could also be created?
Oct 26 2020
I'd love to test the patch as it is if possible - I'd also like to see us fix bugs like this in the constraint system, but I'm aware of compatibility issues.
- 'good' riggers avoid problems is by using 'too many' bones, to isolate the issue, for instance, adding a bone with a tracking constraint, or adding more constraints on top to fix the problem, or by finding alternate solutions
- these workarounds should continue to work regardless of the fix.
- in some cases, rigs make it to animation with the shear behavior still present, and the animator 'did stuff' to make it work, in this case it is possible that fixing the bug will break the animations.
Maybe in that last case introducing a 'compatibility' checkbox - something like legacy mode - might help
Oct 12 2020
I couldn't reproduce this on linux (nvidia also) so far using the example file. Perhaps it is a windows specific issue? I'm on fedora 32/AMD Ryzen 9/nvidia 2080ti
Oct 1 2020
Aug 10 2020
Looks good to me!
Jul 28 2020
Looking at how blender behaves in other cases (e.g. the same flag but with particles as opposed to faces/verts) or using e.g. Bounds Display only in viewport settings, blender seems to always show the mesh (but transparent) in edit mode. Therefore this behavior is an anomaly / bug.
Indeed it appears fixed in current master.
Jul 23 2020
Jul 8 2020
I haven't seen this for a while, and I don't know if it still happens (I switched my main machine to an nvidia only desktop) - I can test if needed.
Jul 2 2020
Here's the .blend as uploading the crash.txt seems to have removed it?
May 6 2020
Also the laptop is a Dell XPS15:
Yes it is hard to reproduce! I'm not sure at all, it could be:
- a problem on intel in general
- a problem on fedora and/or gnome in combination with intel
- only a problem when you have dual video cards?
- only on X11
It's also quite random.
May 5 2020
Ok I've opened it as I have more information
This is for now the better system information:
Operating system: Linux-5.6.8-300.fc32.x86_64-x86_64-with-fedora-32-Thirty_Two 64 Bits
Graphics card: Mesa Intel(R) HD Graphics 630 (KBL GT2) Intel 4.6 (Core Profile) Mesa 20.0.5
May 4 2020
I can't get it to happen again - not sure if the change is in my config or in blender, I'll mark as invalid untill it happens again , if it does.
May 3 2020
May 1 2020
Perhaps the vertices could be colored with the weights?
in conjunction with the Zero weights option, you could see black mesh with a blue dot, indicating a zero weighted vertex? (zero weights option has another issue, that you can't really see black verts/black mesh)
My image is a bit unclear, I'm playing with two seperate ideas; distinguishing zero weight and not belonging (black/blue, but we could also use the purple color for not belonging, and coloring the vertices with a slightly brighter color than than the faces.
Apr 20 2020
whether this is a bug or not, it's not desirable behavior, as the animator has no way to hide the unwanted channels; and there could be good reasons (not too lazy to delete error channels) for instance, if the action is intended for multiple armatures with extra bones. Maybe the only show error channels could be used to filter this behavior?
 Aah, I see, fixing it involves fixing the other bug first.
Mar 29 2020
Jan 14 2020
Nov 27 2019
if it has an active developer it seems fine to keep )
Nov 26 2019
Is this a valid setup in iTaSC? It certainly doesn't look like it's predicatably working in the top armature either - in both armatures, if you reduce the chainlength of the tip IK solver from 4 to 3 so the too IKs don't 'collide' it works fine.
It could be that this is just not a supported configuration - I don't know enough about iTaSC but it would be in standard IK.
(aside - does anyone use or develop the iTaSC solver? is it a candidate for removal?)
Sep 28 2019
I agree, it also fits with e.g. how use_deform and vertex groups currently work
Aug 22 2019
I posted a workaround in [[ URL | https://developer.blender.org/T69014 ]]
Basically if you parent everything to the rig that you then proxy, moving the rig object should be sufficient to keep everything in sync (and not moving the instance origin)
Note that workarounds can be more complex in more complex rigs (my original rig is like that)
Aug 21 2019
I'm not 100% sure this is a bug. would need a depsgraph or cycles dev (or both) to comment.
Jun 17 2019
sorry confirmed here too - it was the subdiv and not the dynamic paint (and I just didn't notice it because of the simplify setting *blush* )
May 24 2019
May 22 2019
PS: I would *love* a fix or a workaround suggestion before June 1st, when this is due ;)
Apr 24 2019
small addendum: I'm on gnu/linux (fedora 29), using intel cpu and nvidia gpu (i7/1080)
I'm not sure if it's the same bug, but I've got an exr (a zbrush displacement map) that renders black in eevee, shows up black in the image / UV editors, but renders greyscale in cycles. It shouldn't have a Z pass, so maybe this is a similar bug. I'm attaching an exr and a test .blend (toggle between lookdev and rendered to see it in eevee/cycles)
Feb 19 2019
Just confirming the bug here so you know it affects other users. (Currently toggling the option in operator redo as a workaround)
Feb 13 2019
It looks like facemaps-> bone selection is pending design changes to precisely allow tying them to custom widgets - https://developer.blender.org/T51675
So you can ignore my comment :)
Jul 31 2018
Jul 5 2017
The issue is that the limit does not work. It tries to limit final frame rate (fps/fps_base) to 120 by limiting both fps and fps_base to 120... this is mathematically wrong, and allows users to get astronomically high frame rates simply by choosing a tiny value in fps_base (this one is a float), as well as preventing 1 to 1 conversions from commonly reported values from actual videos without a workaround (it seems those videos use ints for both numerator and denominator)