How and where did you get Anime Studio 7.0???
-G
Colorize bones - coming soon! Yeehaaa!
Moderators: Víctor Paredes, Belgarath, slowtiger
Pretty darn cool isn't it? I feel the same way. There's almost no end to what can be done.
I've learned a ton of stuff over the past week. I now know why a bunch of my other scripts didn't work so well with undo. Instead of using bones I will always use bone IDs. Bone userdata is the culprit when your scripts break using undo. My bone slave scripts had that problem.
The file writing/reading is so simple I plan to use this more. Now I think I can finally finish my "Action Export" for my face rigs.
I keep thinking I've hit the limit on what scripting can do and then I keeping going further. I also learned how to rotate matrices so I can fix my physics scripts.
You want to know something crazy? Most of this stuff was possible back with the original Moho when I first bought it. It's just been sitting there waiting for discovery. If I knew then what I know now... yikes!
-vern
Thanks for the suggestion Ovjeh.
I had thought to do this but the top of the window is getting pretty crowded. You can't change the size of the color picker box, plus for consistency I thought having a "default" highlight color would make more sense. All the bones would highlight in the same way. If you picked different highlight settings for each group it could become very confusing.
At the moment the highlight (and the strokes) are based on the group color (I changed it today. It is not the same as the video demo). I wanted something that wouldn't be too hard on the eyes.
For now the highlight is darker.
I played around with using the "AS red" as the highlight stroke but... blech!.... it tended to "vibrate" with clashing bone colors. I didn't like it.
I suppose I could have an option to make the highlight be darker or lighter than the unselected color. I am going to leave it for now. If later it doesn't seem to be working I can add in those options or come up with a better solution. I wish there was a way to check the pixel colors of what is "under" the bone to change the color. If the color was darker or lighter I could change the highlight or color slightly so it shows better. At the moment I can't do this.
It's very strange working with scripted color control in AS. There are two types; RGB and ColorVector. RGB is standard 0-255 values. A ColorVecter is 0-1. You need a ColorVector to add subtract and multiply colors, then you convert them to RGB. I wonder now if this conversion process may be the reason colors from imported AI files "shift" slightly.
-vern
I had thought to do this but the top of the window is getting pretty crowded. You can't change the size of the color picker box, plus for consistency I thought having a "default" highlight color would make more sense. All the bones would highlight in the same way. If you picked different highlight settings for each group it could become very confusing.
At the moment the highlight (and the strokes) are based on the group color (I changed it today. It is not the same as the video demo). I wanted something that wouldn't be too hard on the eyes.
For now the highlight is darker.
- The stroke for an unselected bone is approximately 50% "black" added to the color.
The highlighted "fill" is approximately 20% black added to the group color.
The highlighted stroke is 75% black added to the group color
I played around with using the "AS red" as the highlight stroke but... blech!.... it tended to "vibrate" with clashing bone colors. I didn't like it.
I suppose I could have an option to make the highlight be darker or lighter than the unselected color. I am going to leave it for now. If later it doesn't seem to be working I can add in those options or come up with a better solution. I wish there was a way to check the pixel colors of what is "under" the bone to change the color. If the color was darker or lighter I could change the highlight or color slightly so it shows better. At the moment I can't do this.
It's very strange working with scripted color control in AS. There are two types; RGB and ColorVector. RGB is standard 0-255 values. A ColorVecter is 0-1. You need a ColorVector to add subtract and multiply colors, then you convert them to RGB. I wonder now if this conversion process may be the reason colors from imported AI files "shift" slightly.
-vern
Holy COW!!!!
Save bone groups, load them back in!!! Works like a charm! Open the AS file and the bone groups are there!
I am sooooo happy!
You have to use ctrl + s to save bone groups though. Can't use the menu command to save them.
A bit of cleaning up and adding in some features for the demo tool and this should be ready for testing by tomorrow... I can't wait. Hope there are some guinea pigs out there willing to test it out.
I think I will have a COMBO bone tool for this as well. Bone rotation and translation in one tool. How cool is that?!?
-vern
Save bone groups, load them back in!!! Works like a charm! Open the AS file and the bone groups are there!
I am sooooo happy!
You have to use ctrl + s to save bone groups though. Can't use the menu command to save them.
A bit of cleaning up and adding in some features for the demo tool and this should be ready for testing by tomorrow... I can't wait. Hope there are some guinea pigs out there willing to test it out.
I think I will have a COMBO bone tool for this as well. Bone rotation and translation in one tool. How cool is that?!?
-vern
You're right! I can take bone out of that button. That would save space. I will see about adding in the alternate highlight check box. I just need one, on will be lighter, off will be darker. It should be simple since all I would do is add the "black" value instead of subtracting it. I'm not really "adding black" I'm just "shifting" the rgb values down (subtraction) by an equal amount. Instead i would shift them up by adding the same value.
I will make the group bone highlighing colors variables at the top of the script for easy changing. Just change the rgb values in the variable.
----
On a side note I have hit another bug. Deleting/adding bones. This totally messes up the groups. A bone ID number is just that... a number in the list of bones. If you delete a bone all the other bones ID's below that one will shift up. Very annoying. Then if you ADD a NEW bone it gets stuck on the end of the list and may or may suddenly become part of another group.
Imagine if you add a bone, then delete another bone, then add another one. All heck breaks loose.
When deleting and adding bones I will have to figure out a way to keep careful track of the groups bones and reorder them so this doesn't happen. This is why I need to create custom tools for all the bones. If I modify my own set of bone tools I can easily track deleting and adding bones.
-vern
I will make the group bone highlighing colors variables at the top of the script for easy changing. Just change the rgb values in the variable.
----
On a side note I have hit another bug. Deleting/adding bones. This totally messes up the groups. A bone ID number is just that... a number in the list of bones. If you delete a bone all the other bones ID's below that one will shift up. Very annoying. Then if you ADD a NEW bone it gets stuck on the end of the list and may or may suddenly become part of another group.
Imagine if you add a bone, then delete another bone, then add another one. All heck breaks loose.
When deleting and adding bones I will have to figure out a way to keep careful track of the groups bones and reorder them so this doesn't happen. This is why I need to create custom tools for all the bones. If I modify my own set of bone tools I can easily track deleting and adding bones.
-vern
It seems logically to me, also when you have so many bone tools you want to make unified interface for them or at least for more important ones. AS is a bit limited on that, everything is scattered all around the workflow. A new UI element (window/floater) with option to move freely or to dock left and right in workspace, and which could consist of tool buttons,list buttons,checkers, pickers and so on, would be ideal for tools like one you are writing now.heyvern wrote:This is why I need to create custom tools for all the bones. If I modify my own set of bone tools I can easily track deleting and adding bones.
But that requires some Interface redesign...
Ran into a problem.
Deleting bones and undo.
When deleting a bone or bones it changes the ID's of bones in the group list. This causes the list of groups and associated bones to be totally messed up. Given that, it will still be possible to track the deleted bones and update the groups table. Unfortunately since deleting the parent of multiple bones or chains of bones deletes those bones without any reference to the child bones deleted I will need to recursively track all the bones deleted, count all the children and account for there deletion. This is proving to be a chore but is not an insurmountable chore.
The other problem is the undo. If after deleting bones and updating the group list to account for the missing bones the undo is used, the groups once again are incorrect since the bones removed from the group table variable are not "undoable". Those bones removed from the table are not put back in and the list is once again... uh... totally messed up. This too can be remedied quite easily by creating a temporary table prior to deleting any bones thus restoring the group list.
I am confident I can solve these problems but it has delayed releasing this script as soon as I had hoped... I will need another day or two.
Also any solution found would require that all undo's be done using the key command and NOT the AS menu command since I can't track the menu commands using a script. I can only track the undo key command.
-vern
Deleting bones and undo.
When deleting a bone or bones it changes the ID's of bones in the group list. This causes the list of groups and associated bones to be totally messed up. Given that, it will still be possible to track the deleted bones and update the groups table. Unfortunately since deleting the parent of multiple bones or chains of bones deletes those bones without any reference to the child bones deleted I will need to recursively track all the bones deleted, count all the children and account for there deletion. This is proving to be a chore but is not an insurmountable chore.
The other problem is the undo. If after deleting bones and updating the group list to account for the missing bones the undo is used, the groups once again are incorrect since the bones removed from the group table variable are not "undoable". Those bones removed from the table are not put back in and the list is once again... uh... totally messed up. This too can be remedied quite easily by creating a temporary table prior to deleting any bones thus restoring the group list.
I am confident I can solve these problems but it has delayed releasing this script as soon as I had hoped... I will need another day or two.
Also any solution found would require that all undo's be done using the key command and NOT the AS menu command since I can't track the menu commands using a script. I can only track the undo key command.
-vern
Good grief. I almost gave up!
What a nightmare. Anyway got the whole "undo" and "delete bones" issue resolved after physically banging my head against the computer for two days. Seriously. I banged my head against the computer until all the 1's and 0's lined up properly...
... I'm kidding.
I had a big problem with what I think is variable "scope" or table references. I have learned painfully, that tables are very tricky. Items in a lua table aren't really "stored" as distinct copies of a value. Only a reference is stored as a variable. A field in a table is just another variable. If you add the same variable in a field of two separate tables and change the value in one table the value of the other one changes. You see? The same variable reference was added to both tables. Changing one changes both...
... I did not know this thank you very much.
The fix was quite simple once I figured out the problem. I keep two copies of the bone list for groups: One for the current list, one for the undo. I just "copy" them back and forth as needed by tracing the delete bone and "undo" key command.
This is not a perfect solution yet. Still some bugs to work out. The undo command at the moment is still causing trouble. Variables aren't "reset" during an "undo" so I am limited to how far back you can go with it.
For instance:
Delete a bone. Move a bunch of bones around. Undo. The groups reset to before you deleted a bone but AS doesn't. AS is undoing the last movement of the bone. I will probably have to use some sort of "undo" flag. This would mean after deleting a bone you have to undo immediately or it won't work. Or if you delete and move bones you would have to undo all the way back to when you deleted the bone. Deleting a bone can effect nearly ALL the groups depending on the order of the bone list.
Also the "redo" menu command can't be used with bone groups. There is no key command for "redo" so no way to trace it in the script. Hopefully a future update would fix this.
I may be missing something of course. Point groups works fine with undo and redo and deletion of points even though technically it works the same way. The difference of course is that point groups are part of the application. Probably some "magic stuff" going on behind the scenes I don't have access to.
-vern
What a nightmare. Anyway got the whole "undo" and "delete bones" issue resolved after physically banging my head against the computer for two days. Seriously. I banged my head against the computer until all the 1's and 0's lined up properly...
... I'm kidding.
I had a big problem with what I think is variable "scope" or table references. I have learned painfully, that tables are very tricky. Items in a lua table aren't really "stored" as distinct copies of a value. Only a reference is stored as a variable. A field in a table is just another variable. If you add the same variable in a field of two separate tables and change the value in one table the value of the other one changes. You see? The same variable reference was added to both tables. Changing one changes both...
... I did not know this thank you very much.
The fix was quite simple once I figured out the problem. I keep two copies of the bone list for groups: One for the current list, one for the undo. I just "copy" them back and forth as needed by tracing the delete bone and "undo" key command.
This is not a perfect solution yet. Still some bugs to work out. The undo command at the moment is still causing trouble. Variables aren't "reset" during an "undo" so I am limited to how far back you can go with it.
For instance:
Delete a bone. Move a bunch of bones around. Undo. The groups reset to before you deleted a bone but AS doesn't. AS is undoing the last movement of the bone. I will probably have to use some sort of "undo" flag. This would mean after deleting a bone you have to undo immediately or it won't work. Or if you delete and move bones you would have to undo all the way back to when you deleted the bone. Deleting a bone can effect nearly ALL the groups depending on the order of the bone list.
Also the "redo" menu command can't be used with bone groups. There is no key command for "redo" so no way to trace it in the script. Hopefully a future update would fix this.
I may be missing something of course. Point groups works fine with undo and redo and deletion of points even though technically it works the same way. The difference of course is that point groups are part of the application. Probably some "magic stuff" going on behind the scenes I don't have access to.
-vern
Holy cow!
Just came up with the perfect solution for this script!!! I can save the bone group data INSIDE THE AS FILE!
I plan to put the group data in the name of a bone in an extra bone layer. Amazing. Those bones have no limit on the size of the name string. You can put anything you want in there (except a return. No biggy). I just stick in the data, and read it out when the file is opened. If the bone layer doesn't exist no groups. Easy as pie.
I may even make this "invisible" to the user by reading in the data from the bone name and deleting it. The group "bone layer" would still be in the saved file and would be updated and saved each time you save the file. You just wouldn't see it in the document. Even if AS crashed or you quit or closed without saving the file the bone groups would still be in the file.
This is FANTASTIC!
-vern
Just came up with the perfect solution for this script!!! I can save the bone group data INSIDE THE AS FILE!
I plan to put the group data in the name of a bone in an extra bone layer. Amazing. Those bones have no limit on the size of the name string. You can put anything you want in there (except a return. No biggy). I just stick in the data, and read it out when the file is opened. If the bone layer doesn't exist no groups. Easy as pie.
I may even make this "invisible" to the user by reading in the data from the bone name and deleting it. The group "bone layer" would still be in the saved file and would be updated and saved each time you save the file. You just wouldn't see it in the document. Even if AS crashed or you quit or closed without saving the file the bone groups would still be in the file.
This is FANTASTIC!
-vern
I DID IT!!!!!!!!!!!!!!!!!!
YEHAAAAAAAAAAAAAAAAAAAAA!!!!
I will post it with instructions later tonight.
It will easily work with a slight modification to any tool. I've put all the working bits in the custom group tool script and a utility script.
It works GREAT! Fantastic! I love it!
I had to go with a separate saved preference file unfortunately. I decided not to try and save the group data inside the file via a bone name for now. It was too "risky". Deleting a single bone by mistake could accidentally remove all the group info. Plus it was a kludgy workaround anyway. I couldn't just load the info from the bone name and delete the bone because the bone got deleted before the save.
-vern
YEHAAAAAAAAAAAAAAAAAAAAA!!!!
I will post it with instructions later tonight.
It will easily work with a slight modification to any tool. I've put all the working bits in the custom group tool script and a utility script.
It works GREAT! Fantastic! I love it!
I had to go with a separate saved preference file unfortunately. I decided not to try and save the group data inside the file via a bone name for now. It was too "risky". Deleting a single bone by mistake could accidentally remove all the group info. Plus it was a kludgy workaround anyway. I couldn't just load the info from the bone name and delete the bone because the bone got deleted before the save.
-vern
-
Víctor Paredes
- Site Admin
- Posts: 5665
- Joined: Wed Jan 26, 2005 12:18 am
- Location: Barcelona/Chile
- Contact: