- User Since
- Oct 26 2005, 7:41 AM (659 w, 4 d)
Thu, Jun 14
Here's a proposal doc for how the annotations could work:
Wed, Jun 13
@Sergey Sharybin (sergey) Agree with some points, but strongly disagree with many of the rest (particularly some of the larger high-level concerns raised).
Tue, Jun 12
Most of the problems should be solved by rB3721b857c697e3b9bc369f3b3afa0a6894e0584b
IIRC, Shift-O is currently used for "Sample Keys". That said, maybe we don't need a dedicated hotkey for it (and the Smooth Keys - Alt-O) operators, as I don't think they're actually used that much that they necessarily need the hotkey.
Mon, Jun 11
It will be removed - in due course :)
Sun, Jun 10
Sat, Jun 9
@Daniel Lara (Pepeland) (pepeland) I'm not really arguing that you don't need AA to be applied to GP strokes. What I am wondering though is whether we really need the settings to enable it in the first place. IMO, it seems that you really shouldn't need to be worrying about this at all, or if you do, it's mainly a quality setting that ends up being more of a render setting (like how you can control AA strength in normal renders)
As I mentioned here, I'm not convinced that this should be a user pref setting. This is something that affects the look of rendered output (and should stay consistent across different workstations). For this reason, IMO it'd be much better if this was some kind of per-file/scene render setting - in fact, is there any reason why we don't just reuse the standard anti-aliasing settings in render settings if it really is necessary to have control over this? Conceptually, these are practically similar issues, so I don't see the need for a separate setting for this?
Hmm... why is this even a user-pref option when it will affect the final quality of how strokes will get rendered? At this point, GP objects will mainly be used for creating 2.5D art. Therefore, I wonder why you don't just reuse the rendering anti-aliasing settings instead for this even?
Fri, Jun 8
The crash happens when you've got ASAN enabled on Linux. It only crashes in release (not debug) builds.
Sat, Jun 2
Fri, Jun 1
Thu, May 31
Wed, May 30
Unassigning from self - this low-level requires a bit more trickery than I have time to explore right now.
Calling the OBJECT_OT_duplicate operator directly seems to work ok.
Tue, May 29
Mon, May 28
Just a note - if the performance woes are due to animation editors (specifically the timeline), I've got some plans already for optimising a bit there. I was going to try to work on that this week if time allows. (Specifically, my plan would also help resolve some other issues animators were having with functional side of things, by deduplicating a lot of the calculations that go into drawing the keyframes).
Checking the code, the addon needs to be modified to read the original pose from evaluated data (e.g. context.depsgraph.id_eval_get()). Most likely, we should just modify get_current_pose() (or the store_bone()) inside it.
This is a blocking issue for Spring animators - particularly as @Hjalti Hjálmarsson (hjalti) needs it to do facial animation soon.
- Auto calculation is a separate topic - it's not related to the drawing.
- The main interesting features of that mockup are the explicit display of the start/end frames. Otherwise, it's actually pretty much just the standard display
- "Tangent editing" or just general motion path editing is actually a lot harder than it looks - especially in everything other than the most basic case. Unfortunately, you can't just support that simple case, as people will want the others too. Anyway, again this is separate from the issue of just getting drawing code working
Fri, May 25
Thu, May 24
Probably this wasn't ported yet in the cow taskforce... (T54829)