- User Since
- Nov 5 2004, 8:22 PM (759 w, 2 d)
Wed, May 22
@Alexander Gavrilov (angavrilov) , if I may ask, maybe you know a fix for this?
Sat, May 18
It would be sad if it's not considered as a bug. Most 3D softwares out there can do this... it would be quite a limitation for rigging :'-(
Fri, May 17
Sat, May 11
Already reported here:
It's best to close it.
Fri, May 10
Wed, May 8
You're welcome, always glad to contribute when I can.
Here is a patch to fix it:
Tue, May 7
Sun, May 5
Tue, Apr 30
Apr 26 2019
Apr 23 2019
Apr 22 2019
As @Sebastian Parborg (zeddb) mentionned, apparently the "to_mesh" call in the fbx binary export script is not working as it should because it's converting to mesh the model with armature modifiers applied, whereas they are disabled a few lines above in the script (to reset to the rest pose).
Seems to be an update issue. Triggering the data update manually using bpy.context.scene.update() just before "tmp_me = ob.to_mesh..." make it work. Not sure it should be fixed this way though?
Apr 19 2019
Ok, Brecht, I'm still quite new to the Blender code but if it makes sense to you I can volunteer to propose a patch to clamp the channel colors so that's it's not too flashy. Please let me know your thoughts...
I'd rather go for clamping the channel color than adapting the text color.
Let's say you need very bright, flashy colors for the bones controllers to contrast with the dark viewport background.
You don't want the same flashy colors to be displayed in the action channels, otherwise it will look like a christmas tree :)
It would be nice at least to disable channel colors by default, waiting for a correct implementation of colors adaptation, wouldn't it?
Apr 18 2019
Hey, any news about it? Will it be committed to the code?
Apr 15 2019
Thanks for the fix!!
Apr 14 2019
Try to move it in all directions, it should happen at some point.
It works without jiggles in Blender 2.79, theoretically it's not a dependency cycles:
rig1[BoneStretch] parent of > rig1[Bone2.001] drives location > rig1[Bone2] drives location by constraint> rig2[Bone2]
Yes I can confirm it, the driver is causing it. Deleting the driver fix the issue here.
However, if I create a new valid driver, for example a new bone drives the location of Bone1, the jiggles are back (file attached below)
Awesome feature, thanks a lot!
Apr 13 2019
Apr 6 2019
Isn't Box Cutter an external addon? If so it's not maintained by the Blender developers, post the bug report to the addon developer.
I can confirm the issue here, the addons menus are not shown in File > Export, after opening the given file.
Mar 24 2019
This is a bit weird, seems some temporary causes are partly responsible for the performances.
I've just opened the blend file again, and now get 60 fps. However, when duplicating 3 times all bones to get 1152 bones, the fps drop is still noticeable:
2.79b : 90-100 fps
2.80: 28 fps
Weird, i'm pretty sure there was not such lag in previous builds. Where can the old builds be found?
Mar 23 2019
Mar 22 2019
Mar 17 2019
Alright, I think I got it... We have to create the proxy right on the linked collection, without instancing it like we did in Blender 2.79. Fine :)
Thanks for the feedback, but sorry I don't understand. How are we supposed to fix this then?
In Blender 2.79 we can link the group (which is now the "collection") containing the same objects hierarchy, and make a proxy of the armature without any issues.
Mar 14 2019
Mar 7 2019
Thanks for letting us know, glad to know. Fingers crossed.
Feb 25 2019
(it used to work perfectly in 2.79, so this is clearly a regression...)
Custom keymaps are often used when importing/exporting key maps, it happens all the time when switching computers. Not being able to choose the mouse selection button when using custom keymap is a serious design flaw.
If it's not fixed, bug reports will pile up...
Then it's a serious issue... If the user has a custom keymap active, how an addon can know if the user has set left or right click for selection?
There's a bunch of existing addons based on selection, it would break them all.
Feb 24 2019
@Brecht Van Lommel (brecht) Even if not perfect, the "bias" solution could work in many cases, it's still better than no solution at all.
As far as I understand, it's all about computing the shading ray starting slightly above the face normal. I assume you know the principle, but just in case see the page 2 of this doc:
Sorry if I'm missing something, but there's still an issue apparently...
Tested with the latest build, after reloading factory settings and deleting any existing custom keymaps.
Please try the following:
Feb 22 2019
Ok. I was thinking these were shadow issues, but actually it's not since turning off shadows does not fix the issue, it's more related to the way the faces themselves are shaded. I probably won't be able to help, I don't know how pathtracers work... Good luck with it :) Indeed, renderers such as Arnold and Guerilla have fixed it.
@Brecht Van Lommel (brecht) pardon me if I say something stupid, but... as far as I understand, this shadow issue happens when a face projects its shadow to one of its adjacent face. So isn't there a way to prevent faces from casting shadows to their adjacent faces? Dismiss them from the shadow ray, when smooth shading is on?
Feb 13 2019
Feb 4 2019
Does not seem fixed in the latest daily build.
Jan 24 2019
It's basically an update problem, the update can be triggered for example by unlinking-relinking the action from the armature.
"Clear Keyframes" is in the contextual menu when right clicking the Scale transform in the property panel of the viewport:
Jan 23 2019
Jan 22 2019
Jan 10 2019
Since you ask for feedback from artists, I'd support the per-object X-Mirror, as Julien Kaspar explained when working with several objects in the scene, it's the easiest way to keep it enabled for some objects and disabled for others. It may seem counter-intuitive but actually it's way more useful. I'm a 3dsMax and Maya user too, and I still prefer the way it's implemented in Blender.
Jan 7 2019
Jan 3 2019
Sorry, but the bug is still happening in the latest Blender 2.8 build.
Please test and confirm.
Jan 2 2019
Dec 21 2018
Dec 17 2018
Dec 11 2018
The bug seems to be fixed in the latest build! Must have been modified elsewhere. Thanks.
Dec 10 2018
Thank you, will try it!
I'm a little concerned by performances though, "to_mesh" creates a new mesh data block, so I thought it may be slower than the bmesh method. But maybe i'm wrong.
Dec 9 2018
Dec 7 2018
Evaluating the depsgraph first seems to fix it:
Dec 6 2018
Dec 5 2018
Dec 4 2018
Dec 2 2018
Oops sorry, I had searched for any "make_single_user" bugs, which did not output anything. Will search for more keywords next time.
Nov 29 2018
Ok, sorry did not know that. CPU acceleration is also the bottleneck I guess.
Blender 2.79 had both CPU and GPU acceleration, not sure what are the plans for 2.8
Faster animation playback when topology stays the same.
Sep 30 2018
Glad to hear it's working fine in 2.8, sure I totally understand 2.79 is no more developed.
Sep 23 2018
The main problem in this scene is the cyclic dependency, that is likely introducing issues when it comes to animation baking.
It's a common problem with Spline IK constraints. You can open the Blender console to see the error log, and when moving the rig bones, there's also a one frame lag which is due to the cyclic dependency issue.
The dependency graph is being re-written for Blender 2.8 to avoid this (as far as I know), for now only this kind of rig setup should be used with IK Spline constraints:
Seems like a scale/stretch related issue? If so, it's not a bug, Fbx does not support it: the scale value of each bone inherit the scale of the parent bone.
I've found a workaround for this bug.
Decomposing then recomposing the bone matrix fixes it magically in the fbx_utils.py file.
Mar 27 2018
While praying for this bug not to be forgotten in the dark, i've simplified at maximum the example blend file (attached) to help. It now only contains one mesh and two bones. When exporting to Fbx and importing in other apps, such as Unity, "bone2" is imported with Rot X = 179.8, instead of -90.
Rotating in Edit Mode bone2 1 or 2 degrees in Blender fixes the issue. However it's not a clean solution, it may happen in other situations. Seems to happen when a bone is making 180 degrees x-axis angle with its parent.
After further investigations with the Fbx exporter code, tracking the exported rotations values seems to output correct values. However it's the way these values are read in other app that is the problem. Likely to be an euler issue, if only Fbx used quaternions...
Jan 31 2018
Sure thing. Actually it's the same issue in Maya in case you're able to test it. Haven't tested with 3dsmax but i'd assume it may be the same.
Here is attached a screenshot.
Jan 26 2018
Oct 6 2017
Ok. Good luck for 2.8 then!