- User Since
- Oct 31 2006, 10:56 PM (672 w, 1 d)
Thu, Aug 22
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)
Wed, Aug 21
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?
hrmz, I disagree on the notabug decision. This is how I found it:
I realized during making the bug report that in the corner case where a text strip starts before frame start but ends after it we would probably want a subtitle (starting from time zero), this patch should achieve that.
Jan 9 2016
Looking back at my patch, it might be nice to check for the case where the start frame is negative and the end frame is positive, and export that strip with a start of zero (clip to zero)
Dec 2 2015
Oct 8 2015
Oct 7 2015
That's a good idea (I usually have been dropping in console and looping over my object's drivers, replacing the ids)
A smart copy addon might also be nice, however the worry is people will encounter the problem but not understand why it's happening... better than nothing tho.
Oct 6 2015
Thanks Campbell!!! Confirm that it works also in my more complex file :D
I have an addon that works around this problem; perhaps I should polish up and submit to blender's addons? currently it has the following issues:
Oct 5 2015
Jul 22 2015
Looks neat, I think the second varient where channel buttons are above the channels is more obvious; splitting channel specific settings there is much better than everything in the header.
Jul 2 2015
Jun 26 2015
I can confirm this is happening on Linux too.
I'd say this is a bug (albiet a low priority one): the scrollbar is suppose to calculate the window size, but in this case skips the window size is wrong, presumably not getting notification that the contents changed.
If it is a hard bug to fix, it might be best postponed, but if it is easy, maybe @Campbell Barton (campbellbarton) would like to add it to the 'easy tasks list for new developers' (sic) ?
May 3 2015
How about re-adding copy buffer to the top of the menu so as not to disrupt other users? Similar to copy pose in pose mode
Mar 15 2015
I've done a bunch of save and loads in current master (original file had a lot of rig stuff in it/ was huge) I wonder if it is incorrectly assuming I was editing a shape because no shape is active, and erroneously applying a difference to the basis?
It is still quite scary (I found the bug by doing totally unrelated things in the rig file - never looked at the elbow ) and then found all our anim files looked broken :/
luckily I have SVN!
Here's a short video of me doing the steps.
Feb 20 2015
My opinion: if you stick it as a checkbox in a submenu as a mode a big percentage of animators aren't gonna find it. Just like they don't find/get confused by the gagillion checkboxes already there.
Even I am finding the current state of that menu confusing to say the least - how do the different options interact with each other, etc.
Feb 19 2015
I understand the need for the feature but I don't like all these checkboxes in the view menu; I think it should be more visible/switchable.
Feb 12 2015
Jan 31 2015
what I mean is, the center of the modifier hook influence is afaik at the center of the selected vertices, and the sphere of influence might then intersect the surface oddly. That might explain why applying the modifier to all the verts is so different (and worse) than half.
If you snap the cursor to your hook, pop into edit mode on the monkey, and then click recenter in the modifier, it should give you nicer results. Might not be perfect yet, but nicer.
It was an intended change to fix this other user's bug:
could it just be that the center of the modifier is not where you want it to be? trysnapping the cursor to your empty and recentering