- User Since
- Aug 20 2015, 12:17 PM (182 w, 5 d)
I made a github branch specifically for this specific diff: https://github.com/angavrilov/rigify/tree/upstream-D4364
Fixed broken Add Sample UI.
Fixed the reported exception, but noticed another issue (it fails if the Widgets collection is selected)
How are nodes relevant? The problem here is the armature modifier depends on evaluation of the whole armature, instead of just the relevant bones (i.e. the set based on vertex group names). In the majority of cases that is correct, and probably more efficient (fewer graph links to process), but in some specific use cases it is a problem.
Mon, Feb 18
Removed another big chunk of unrelated code from MAD.
Sat, Feb 16
Wed, Feb 13
There are no keys for object Z beyond 20.
Tue, Feb 12
I don't see anything wrong here. If you delete the last keyframe updating the object Z position, it will obviously reset to the previous key that is now the last one.
Mon, Feb 11
Btw anyway, what is the precise status of this repository, and the branches in it? https://github.com/eigen-value/rigify
Mon, Jan 28
How about nuking the AnimData->recalc field completely? With COW it is totally broken anyway because it's never cleared once set in the main instance.
It could be useful to e.g. have a checkbox in the modifier to specifically limit the dependencies to relevant bones (it would be more expensive performance wise than depending on everything, but nowhere as much as a separate armature), but supporting that would likely require some careful refactoring of the modifier code.
Well, the problem here is that Armature modifier always depends on all bones, without taking the vertex groups into consideration at all. Thus to support this (very realistic and useful) use case, it is necessary to use a workaround:
Fri, Jan 25
@Sergey Sharybin (sergey) IIRC the problem here is that there is a magic recalc flag that makes that call to evaluate drivers also update keyed animation, and that flag is never cleared once set - so presumably the solution is to get rid of adt->recalc?
Wed, Jan 23
Mon, Jan 21
The reason for the default is because the original code used the type of the active object, and this default specifically implements it. I'd suggest not changing it without consulting with whoever actually wrote the actual original code.
Jan 14 2019
Jan 13 2019
Month-long delays in reviewing and accepting major changes to the core systems, as well as keeping things in a relatively unknown separate repository, get in the way of fixing issues the longer that goes on. This patch will be impossible to merge with the refactorings that are going on, and has to be rejected. However, the issue also can't be fixed in the new branch, because reviews are completely stalled.
Don't touch that code, it's going to be rewritten in the next version of rigify, whenever it happens.
Jan 12 2019
Renamed to Combine, plus some tweaks.
Jan 11 2019
Jan 10 2019
Jan 7 2019
Jan 5 2019
Dec 31 2018
Renamings and tweaks.
Dec 27 2018
Dec 23 2018
Dec 21 2018
Dec 19 2018
Naming changes; removed the assign all defaults operator from the Object mode Ctrl-A menu.
Dec 18 2018
Dec 17 2018
To elaborate on the NLA design concerns that motivate this a bit more:
Dec 16 2018
Dec 14 2018
Dec 11 2018
My new Target Normal Projection mode in the shrinkwrap modifier (basically intended to address a vaguely similar mapping continuity problem to this) simply uses the vertex normals and thus won't be smooth with edge split either.
Dec 10 2018
Didn't test, but if it works I guess it should be fine now.
Dec 8 2018
@Sergey Sharybin (sergey), I wonder if this is fundamentally the right approach? It feels that the whole thing of calling modifiers outside of depsgraph context in the first place is going against the design (e.g. if the object was invisible, the dependencies aren't guaranteed to be up to date, and so on).
Dec 7 2018
Dec 5 2018
Curve shapekey data is more complicated than coordinates, and even more so in 2.8 after rB12788906. I suspect python API wrappers don't take that into account.
Dec 4 2018
No idea about bmesh stuff, but with regular meshes the ORIGINDEX layer doesn't exist if the object only has deform modifiers and thus the topology is unchanged from base, and you have to account for that.
Moved do_work = false to main function.
The scheduling is really simple: during COW phase it skips actually scheduling any tasks for non-COW nodes, and then at the start of next phase it goes through all nodes again with schedule_graph and schedules everything that is now ready.