Over the past week, I've been busy bashing away at an assignment that's tricky to get traction on, what with units handling and Java+XML to contend with. Hopefully I'll finally manage to put this to bed by the end of the weekend, so that I can get on to some far more interesting matters. Such as...
My Shape Key Transfer Tool
Thanks to all the wonderful feedback on this so far.
From a number of replies, it seems like it would be useful to be able to deal with extra edge loops added between vertices that have remained unchanged. I have some ideas on how to tackle this, involving creating a inverse-orientated map alongside the current direct-match-source-to-target map for describing the target vertices. This inverse-map could then be populated by checking the adjacency tables for suitable candidates in a manner similar to the way that "tweaked islands" are currently solved. If anyone has some test meshes with such situations set up already, these are welcome.
Another popular request it seems is for weight paint/vertex group information to get transferred as well (or instead). It's probably easier to implement support for this, so I don't think it should take too long once I get time to do it!
GSoC11 - First Steps
One of the major targets I've set for my GSoC this year is to work on a refactor of the animation editor channel filtering code, which is necessary to resolve a number of bugs which have been showing up in the tracker repeatedly.
For example, a lot (if not most) of these stem from the current use of an internal "visible" filtering flag. Since this code was originally designed for the Action Editor, keyframes and/or the F-Curves on which the resided could only be visible and edited when the parent channels (i.e. Group or Object expanders) were "open". However, with the Graph Editor, this is no longer the case, with two distinct types of "visibility" applying. By splitting these cases and then carefully reevaluating what flags each tool requires, things should be better.
I need to stress though that I AM aware of many of the requests surrounding this stuff (i.e. channel groups), though it's not directly related to what I'm going to be doing now, and is really something to worry about after this overdue bugfixing work is done first. It's also not to say I won't eventually get around to various todo's surrounding keyframing, NLA, drivers, and even constraints. Just understand that I won't be doing those now/immediately :)
Just a little thing i'm wondering:
ReplyDeleteYou seem to be really concerned about the animation system in blender :)
Maybe youc could also take a look at the driver code sometime in the future? I mean, it would make it a hell lot better if drivers were done through nodes.
Btw, constraints are basically driver presets. Maybe all those could be ported to node trees instead :P
Cheers.
@ FreeMind, Aligorith is aware of driver issues - he even says it in the post.
ReplyDeleteAlso, constraints are NOT just driver presets, as drivers don't incorporate any kind of matrices. See here :
http://aligorith.blogspot.com/2010/09/rigging-faq-constraints-and-rotations.html
"drivers don't incorporate any kind of matrices"
ReplyDeleteThey could in the node system... Just lots of math and boolean nodes...
Just give me an example and ill try to compose a node setup for ya.
But even if that's not possible, the show stopping part could just be a node.
FreeMind, interesting. Admittedly, I haven't checked out the new node system, I'm not up to speed!
ReplyDeleteWhat would a copy rotation constraint with the x-axis inverted look like in nodes?
" I haven't checked out the new node system,"
ReplyDeleteThere is no new node system. I can just make a mockup on how such a node setup could look like.
The whole point of this is, that you can take any number box from the Blender GUI, place it into the node editor, then place another number box and connect them with a line, which means, number on the right is driven by number on the left. And you can't edit the driven number unless you remove the driver.
Now, between the two numbers, you could place any math thing you want.
Your example is really easy:
http://www.pasteall.org/pic/show.php?id=12090
What's going on here is, the Obj1 rotation number boxes are connected directly to Obj2 rotation number boxes, except for the X axis number, which is multiplied by -1 to make it inverted. The Obj1 number boxes override the Obj2 number boxes.
Now, I have no idea how the UI for such a system could look like in blender, needs a little thinking.
But hey, noticed modo has this:
http://www.youtube.com/watch?v=1ikd-DX-gpc&feature=related
Neat mockup. It would definitely open up rigging to interesting possibilities, at least in theory.
ReplyDelete