2.81 release is scheduled for november as far as I remember, I'd bet they won't release a corrective 2.80a version but rather count on 2.81.
Fri, Sep 13
Wed, Sep 11
Great news, thanks @Sergey Sharybin (sergey) !
Tue, Sep 10
These are very good news @Stefan Werner (swerner) , thanks for sharing!
Mon, Sep 9
Nope, Brecht said previously he's aware of it and it's on his Todo list. He just needs time, he has other priorities for now, or we need another skilled developer to pick it up.
Hey guys... please stop this everlasting feature/bug war :-) ... From a technical standpoint, it may be a feature (it's not expected to work in the current implementation), but from the users side, it may be bug (not working as we expect it to work).
Anyway, the problem is there are very, very few skilled developers to work on it. If it was easy, it would have been already fixed. There's not much to do, but waiting kindly for someone to fix it...
This issue is not fixed yet. There was a patch lately to fix terminator effects when using bump mapping, but this is a different context.
Fri, Sep 6
Thu, Sep 5
Thanks for these improvements! Shadows are now perfectly accurate, it even seems "contact shadows" are no more necessary.
Wed, Sep 4
I've just tried with another computer, Win 10, it worked.
Definitely weird bug, here's the workaround i've found to make it work:
File > Default > Load Factory Settings > opened the file and tried again... the weight options are no more greyed out and they can be clicked.
A local setting in the user preferences must be the cause.
Just tried again with the latest windows builds (both home compiled and builderbot), same issue.
Maybe OS related issue, @item412 (item412) what is your OS?
Made an add-on that does the toggling, aptly named: Toggle Normal Maps
Tue, Sep 3
Wed, Aug 28
Mon, Aug 26
Fri, Aug 23
Aug 14 2019
Jul 29 2019
Jul 27 2019
This particular file does not crash for me on Windows, but I have a similar crash when linking another character blend file and File > New leads to the crash. Really hope it can be be fixed for the final 2.8 release, thanks for your work.
Jul 17 2019
Jul 2 2019
Sorry, I inverted "All Actions" and "Baked Animations" buttons!
When disabling these two options, shape keys animation exports here as well, yes.
for me here, shapekeys key_blocks are actually coming over correctly [just the animation is missing with default settings]
I can't say i'm 100% sure of course, but i'm pretty sure the data_meshes dict should be filled with the shape keys data, while it's no more the case in the latest version.
Jun 30 2019
Jun 10 2019
May 22 2019
@Alexander Gavrilov (angavrilov) , if I may ask, maybe you know a fix for this?
May 18 2019
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 :'-(
Blender riggers were so happy to hear that 2.8 dependency graph is supposed to be more powerful than Blender 2.79 one... In this case it would be a regression.
May 17 2019
May 11 2019
Already reported here:
It's best to close it.
May 10 2019
May 8 2019
You're welcome, always glad to contribute when I can.
Here is a patch to fix it:
May 7 2019
May 5 2019
Apr 30 2019
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
If you are animating, you could certainly argue that it could be useful to use a certain pivot or orientation with a certain object or bone. You might also want to use a certain transform tool with certain bones always. You don't ever want to move a wheel, but you always want to rotate it. So X-Mirror is no different. It's just a tool setting.
This argument could be made for literally any tool setting.
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.