- User Since
- Oct 26 2005, 7:41 AM (600 w, 2 d)
Mar 27 2017
From memory, last time we tried removing it, we ended up putting it back eventually as various studios were using it (including the institute). I'm not sure if anything's changed, but I suspect this is still very much the case. If anything, we should be padding it out to make it even more useful.
Mar 25 2017
At least in the 3D view, there's also the option of just using Image Empties that can be manipulated in these ways. AFAIK, it seems quite similar to the "textured plane" approach you mention, except it's not really "real" geometry that hangs around. That said, I haven't really used these enough to tell if there are some serious downsides to doing this (or whether they're already considered the "better" way of doing this).
Mar 10 2017
Thanks for helping narrow this down to a nice tidy window. It really helped looking for the cause. :)
Mar 6 2017
This is very strange...
As I guessed before opening the file (and confirmed afterwards), it looks like you're running into several things here:
- If you've got cyclic dependencies, expect to see errors if you do not strictly advanced the timeline in forward order, and/or if you ever cancel transforms.
- The Transition track assumes that the channels you've got keyed on strips A and B both have the same set of channels to blend between.
- Make sure that if there are some channels which you only key in a "later" occurring strip that you've got that property keyed in some low-down strip that spans the entire timeline. For example, to avoid trouble with controls glitching out (i.e. usually scaling to zero) you'll typically want to ensure that at the bottom of the stack you've got a "Rest Pose" strip that has a keyframe for the "default" value for every property you have/will keyframe anywhere in that NLA stack, and that this strip is set to extend forward and back.
This is a known issue that's on my todo list for when I get enough time to have another decent look at the NLA evaluation backend.
Technically, the old driver is still there, and should still work perfectly fine.
Doing this, I noticed that you have to zoom out the view at lot more to see the entire bone (when it is created using cm units). It looks like the bone isn't especially thin; it's more that the thickness doesn't automatically scale to match a 100 BU (i.e. 100 BU = 100 "cm", assuming 1 BU = 1 cm) high bone. In other words, BBone sizes are in absolute units (which are not adjusted to deal with the unit scaling stuff).
I looked into this a few weeks back, but only figured out what was going wrong when I saw one of the forums posts somewhere about this.
Mar 3 2017
Feb 12 2017
Feb 9 2017
Jan 27 2017
The problem here is that your various clips have different framerates (i.e. 30fps for the screencast, 25fps for the camcorder, 30fps for the camera, and 26.57fps for the phone).
Hrm... this is strange indeed...
Jan 26 2017
Have you got 'Only Needed' enabled in the user prefs?
Jan 21 2017
@Steffen Mortensen (stifan): Thanks for identifying the problem! Fixes committed to master now :)
Jan 20 2017
I tested this again just now, and overall I think it should be fine to include :)
Jan 18 2017
Indeed, this tool doesn't take NLA tweakmode into account (as it wasn't expected that people should/would be doing a lot of animating that way). But, with a few tweaks in a few places, it should be relatively easy to fix.
Jan 10 2017
Ah yes, there's that problem.
Jan 9 2017
The purge orphan data operator works by saving and reloading the file. That in turn triggers the current context to be destroyed, and a fresh one to be created.
Perhaps I'm missing something, but since the original problem was that the user was trying to use Flip Names to swap the names of a pair of selected bones, wouldn't it make sense to just swap the names of a pair of matching bones (if both are selected)? All the other cases we could leave as-is for now.
Jan 2 2017
Hey Campbell, thanks for the tips!
Great to see someone tackling this at last! :D
Please include a file so that we can see what's going on.
Dec 29 2016
Dec 28 2016
Dec 10 2016
Dec 9 2016
Dec 2 2016
Ah, I was referring to https://developer.blender.org and not https://developer.blender.org/maniphest/project/2/type/Bug/
IIRC, on last check we weren't doing any of the fancy color management stuff yet. Previously, as a UI tool, this didn't matter so much, but now that GP is being used for art, we'll have to tackle this I think.
I've had a look at what's going on here:
- If you create a task via Maniphest (i.e. via the '+' in the top-right corner -> Create Task) the description box is left empty (since the task could be for anything). That page is simply titled "Create Task"
- If you create the task via the "Report Bug" button on the homepage, you'll instead see a page title "BF Blender Bug Report", complete with instructions on what to include in the bug report, as well as a pre-populated description box with a basic template.
Dec 1 2016
Nov 27 2016
Actually, even just trying to print the mycolor variable (before changing the name) caused a crash in current master.
Nov 23 2016
You mention some crashing issues when trying to render: IIRC, there have been some recent fixes for crashes related to sequencer stuff.
Nov 18 2016
Could you check with latest master (i.e. buildbot builds)? IIRC, sergey committed a fix for this sometime in the past few weeks-month.
Hmm... this looks suspiciously like a bug in the UI code related to the way that it trims off excess zeros off the end of numbers. Some observations:
- Once it has removed the zero, it doesn't remove any more digits/characters in subsequent editing cycles
- If we replace the 0 with a 1 (or add a 1 after it), no truncation occurs.
Nov 15 2016
Eek! Indeed it is!
Nov 5 2016
@Bartosz Moniewski (monio): From the looks of things, this is something we will enable on specific operators on an "as-needed" basis. So, for most operations (e.g. standard transforms and stuff like that), this is grouping behaviour isn't likely to be enabled.
This seems like a step in the right direction.
Oct 30 2016
Ah that clears things up a lot :D
I'm missing a bit of detail here about the nature of the cache. One thing to be very careful about if you do implement a list of pointers to FCurves is that those references can get invalid/not linked correctly after doing:
- Some combination of library linking madness
Oct 24 2016
Why is this option stored in the sculpt settings, when it's clearly an option that's supposed to be used for controlling how the screenspace strokes get projected into 3D space?
Are there any docs on how this whole PreviewImage system currently works?
Oct 23 2016
Ack! Looks like I forgot to force the keyframe_insert() method in the PyAPI to add these keys to the NLA Strip instead of into the action as per normal.
IIRC, 2.74 and earlier had a bug where the animated strip influence wasn't actually working at all. It might appear to have worked, but that was only an illusion (there was actually a 1-frame lag).
Oct 21 2016
Not a bug.
Oct 13 2016
Indeed, I noticed this very problem here (Note also that the "if (debug)" sections one of the related commits around this time for stroke drawing are used when the "Show Points" option is enabled)
In general, it's hard to reproduce or fix issues which only occur on specific/uncommon hardware that we don't have access to ourselves, so unless something changed here recently, it's likely to be quite hard to find a fix for this.
Oct 12 2016
What sort of snapping are we talking about here? The Shift-S or the transform snapping?
Oct 3 2016
Oh, and two other points:
- I thought it might just be worth noting that the thing with armature ghosting is it currently works by evaluating the armature's pose for all bones for each ghosting step shown, and once more for good measure (to ensure that everything is restored back to the original state). There's a reason why we don't support ghosting for objects currently (e.g. imagine the lag on a deformed mesh, not to mention the complexity of updating all the objects within the old depsgraph framework!)
Currently there isn't enough info to pinpoint what might be going wrong in this case. But, just to get the ball rolling, here are a number of candidates:
- You're trying to show ghosts for too large a frame range. Depending on how heavy the rig/scene are, I don't recommend doing more than 10-20 in total
- The rig you're using has a lot of bones (or a lot of those bones have custom shapes with high vertex counts, etc.)
- Are there any dependency cycles in your rig? What about pydrivers? New or old depsgraph?
- Does any part of your rig depend on "geometry" (e.g. spline ik/followpath/shrinkwrap constraints)?
Sep 30 2016
Er... I think there might be a way to have markers-with-cameras-attached created in master by users without using py/rna. IIRC we have an operator to copy the current set of scene markers (or maybe just the selected ones) to be action markers instead. Check the action editor markers menu.