- User Since
- Oct 31 2006, 10:56 PM (728 w, 6 d)
Mon, Oct 12
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
Thu, Oct 1
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)
Jul 4 2017
please look at this short thread: I didn't post this for no reason - first I asked on IRC, got told "ask on the ML" then I posted on the ML, then got told "post on the bug tracker, it's a bug" - sergey specifically asked me to assign it to him.
the bug ISNT that something is or isnt an int. Rather that a hard limit is set that does not do what is intended. It's clearly the case that if someone enters e.g.
an fps of 100 (legal, an int and under 120) it will work
and then enters an fps_base of .001 (under 120 so it will also work)
they will get an fps of 100000 - way over the 120 number.
Jun 23 2017
Jan 16 2017
Nov 2 2016
I think this is fixing a longstanding problem.
However, this should also be checked with linked proxies, that have own challenges with undo.
Sep 29 2016
hey it's a mac thing, the function keys are not always easily remappable. Once you've install the addon you can assign it a new hotkey in your input settings.
and yeah, not really a blender bug :)
Sep 15 2016
Thanks for fixing what seems to have been a tricky bug (and fixing our farm!)
Sep 13 2016
Output of git bisect:
thanks brecht! trying to use git bisect to pinpoint the commit where it breaks, not sure I'm doing it right ;)
Sep 12 2016
So I narrowed it down to the simplest element.
You'll see there is a single particle system on the single mesh in the file, called 'lashes'
The file crashes on render unless the particle system is deleted, again. only on macos. it is 100% reliable crash here.
Since Brecht couldn't replicate (are you using the release candidate or your own build) I would like to try bisecting till I find the commit. (2.77a works)
Are the buildbot builds saved somewhere or is only the most recent one available? I haven't built blender on macos so far.
I've narrowed it down to one asset, our main character. I'm going to see if I can get it down smaller:
- once again, all you need to do is press 'render', using the standard features, on CPU
Hey folks, so:
OS is 10.11.6 also
2.77a does not crash
I copied the report and pasted it here http://pasteall.org/79074
Sep 11 2016
I'll get one tomorrow when I'm at the uni. as far as I remember it's really short, just a few lines.
(this is from the crash.txt)
Sep 8 2016
Hey guys, some extra info:
seems like all tube/wires for empathy files are crashing now. Our lab just upgraded macos, somehow this didn't happen on the old version :/
Sep 7 2016
Aug 14 2016
thanks for the check bastien! I just tested adding a bevel on a default cube, save and reload, that doesn't crash, so there must be something specific about the geometry in that file that triggers the crash (or possibly some other factor, like a material or uv)
Jul 27 2016
wow! thanks sergey and mont, that was an interesting/ difficult case!
Jun 29 2016
I added a bpy.context.scene.node_tree.update_tag()
just in case, to the overkill_update() function. Same result.
Jun 5 2016
Thanks Dingto! confirming 'FIXED' both on the test .blend I uploaded and on the original tube files that exposed the bug in the first place. Great work!
Jun 4 2016
that seems to be the case, at least in the example file. Well spotted (and thanks Thomas for adding Cycles project... I should have done so)
Jun 2 2016
thanks Campbell! Blender devs continue to amaze with the speed of bugfixing :D
Apr 20 2016
From a user perspective, I'd prefer (strongly) to see this on a per bone/object bases, perhaps close to where the rotation mode option is (UI wise) . Having it as an armature wide setting feels like a production kludge, aka 'old blender' ;)
Apr 1 2016
hehe, yes, it definitely feels like a quick solution that 'works' but not something defined - and it does work in the sense that you can for sure input numbers that do the right thing.
Mar 31 2016
btw, on reflection, we're awefully close to in point / out point as is:
Mar 30 2016
Fixing the tooltips would help a lot but IMO the following is functionally correct and matches how most editors work:
aggh, sorry misread your comment
indeed adding that line fixes.
Mar 29 2016
I can see two ways around this:
1- going back to the operator=None instead
2- implementing a draw function for the operator that explicitly draws only the desired properties.
I think that's it?
Mar 23 2016
Thanks, both of you!
Mar 21 2016
- removed operator instead and removed trailing paren
- remove operator argument instead
Feb 9 2016
so I'd suggest splitting the patch into two:
- the no normalization option (without smoothing)
- the smoothing option on top
and commit only the first one.
there's a use case for the former, but as a rigger, I'm not sure where I'd use the latter; it might be that laplacian deform or corrective smooth does the trick here anyway, if needed?
if it comes up as a need, then it's possible to then commit the smoothing as a second patch, as a result.
Feb 6 2016
ASC CDL is in the Offset/Power/Slope (ASC-CDL) in the color balance node, The default correction formula there is Lift/Gamma/Gain so it's a bit hidden.
Jan 29 2016
I think this is OK as is from a user perspective - it adds an option that makes things simpler for some use cases, and keeps the defaults working.
using a deform armature with spline-IK - modifier on top of stack
using another armature for spline twist - modifier on bottom of stack
Jan 26 2016
Here's what I would like to do:
Jan 24 2016
Jan 17 2016
hrmz the numbering on my comment above is wrong, it reads as 1, 1, 2 should be 1, 2, 3 sorry bout that.
Hi , this is my first stab at adding properties to the operator as initially discussed. Some comments/questions:
Jan 16 2016
Hi sorry for the really late reply - I built the patch and tested.
I don't have a problem with this personally, it might be tricky to find a good wording for the option. "Layered Weights" is a bit vague, I actually thought this was about a totally different feature Daniel had been proposing on IRC.
Jan 12 2016
BTW I'm still not convinced with the counter-argument we have for this is that there is no such option for video and audio export - Those both clip and timecode based on the start and end frame range:
Ok cool, I was thinking you wanted a cryptic 'keep old behavior' or 'legacy' option which would be confusing. This sounds ok.
Two (really 5) new options:
Jan 11 2016
I'm happy to do it but first I would like to know why, namely:
Jan 10 2016
ok, now it is clipping the end frame as well as the start frame. I think the patch is now correct (commulative) too.
ah I see, you want to clamp by the end of the scene frame range! makes sense, I'll do that, makes perfect sense.
what are your current thoughts on making it an option but keeping the default in sync with audio and video output? I actually don't have/see a use case where a user would want an out of sync srt file, and it seems more logical to just set the scene frame start/end frame instead. Perhaps I could ask around on BA? having too many options also clutters interface, especially if they are unneeded.
btw, I don't mind making it optional; but the default should be that the tracks align. (video/audio/srt)
I didn't intend to make my second patch this way, might need some help making a proper one; this is the command I used:
git format-patch HEAD...origin/master
where I had previously git commit ed both those changes locally. How do I tell git make a 'complete' diff?