MarkAH
New member
The Rig Ripper...
The basis of this method is constructing rigs in modeler using skelegons.
I find it much easier than in layout because of layers.
And also due to the possibility of hiding any part of the geometry.
For rigging that requires very accurate location of bones it's the best choice.
Most of my rigged object designs are machines, so my methods are machine oriented.
I prefer using a 'Root' bone even though very little of machine-like rigging involves chained heirarchy.
Sometimes it works fine to have bones parented to the object.
All depends on the nature of the object's actions in animation.
So keep those skelegons, because with this 'system' they are always required.
This replaces the use of scenes for saving the rigging and thus avoids the associated problems.
But it is always good practice to save that scene in which the rigging was finalized.
Because of the requirement of having differently named versions of an object in order to put more than one in a scene,
using the 'Load From Scene' method does not work for multiples.
Although layout enumerates the object name, it does not resolve the conflict of named references in the object itself.
The process with this is to use modeler to save the object as is with a new name, as stated in the documentation.
It's also possible to save some variations of the object, as long as the rig (skelegons) remain the same.
If weight mapping is used, any changes to geometry should be appropriately mapped to the correct skelegons.
After finalizing the rig setup in layout, and establishing any actions between bones with expressions in the graph editor,
use the 'Rig to XML' script to save the setup.
The scripts will save and restore the expressions library, and re-establish the assignments.
However, this depends on giving each expression a name identical to the channel it is assigned to, without the object prefix.
For example, if the channel name is 'Toaster01.Lever.Position.Y' the expression name should be Lever.Position.Y
In this way the script can use the name to assign the expression to 'Toaster02.Lever.Position.Y'.
It also makes it very easy to establish assignments in the case of just loading the expression library from file.
The script will also rename the references to the object in expressions by replacing the original object name, for example 'Toaster01' with the new object name 'Toaster02'
So when the renamed object is loaded from file into layout, running the 'XML to Rig' script will fully set up the rig in an instant.
The 'XML to Rig' script will prompt for the name of the 'source object', which would be the object from which the rig setup was created (sans extension) by 'Rig to XML' script.
They are not plug-ins, and are just run from the 'Python' button in the Utilities tab.
These are really just examples of what can be accomplished.
They are designed for my own style of rig design, but could be extended for other applications.
For example, there is no support for IK, which I never use in machines.
You might notice that the expressions.exp file is loaded, edited and saved back out by the script and then used in the lwsdk.command 'GE_LoadExpressions'
This is because the lwsdk.command 'GE_CreateExpression' crashes layout.
So, do what works. It's the main idea behind these scripts.
The 'MotionPath' global strings in the scripts should be replaced with the path where you want the files to be saved and loaded.
Two caveats:
Scripts and xml files both have vulnerabilities.
If you cannot read and understand both, approach with caution.
I would not deliberately post malicious content but use these at your own risk.
When the xml.etree writes the elements they are not formated for readability so the files should be inspected in an xml editor that can format them.
View attachment 144765
The basis of this method is constructing rigs in modeler using skelegons.
I find it much easier than in layout because of layers.
And also due to the possibility of hiding any part of the geometry.
For rigging that requires very accurate location of bones it's the best choice.
Most of my rigged object designs are machines, so my methods are machine oriented.
I prefer using a 'Root' bone even though very little of machine-like rigging involves chained heirarchy.
Sometimes it works fine to have bones parented to the object.
All depends on the nature of the object's actions in animation.
So keep those skelegons, because with this 'system' they are always required.
This replaces the use of scenes for saving the rigging and thus avoids the associated problems.
But it is always good practice to save that scene in which the rigging was finalized.
Because of the requirement of having differently named versions of an object in order to put more than one in a scene,
using the 'Load From Scene' method does not work for multiples.
Although layout enumerates the object name, it does not resolve the conflict of named references in the object itself.
The process with this is to use modeler to save the object as is with a new name, as stated in the documentation.
It's also possible to save some variations of the object, as long as the rig (skelegons) remain the same.
If weight mapping is used, any changes to geometry should be appropriately mapped to the correct skelegons.
After finalizing the rig setup in layout, and establishing any actions between bones with expressions in the graph editor,
use the 'Rig to XML' script to save the setup.
The scripts will save and restore the expressions library, and re-establish the assignments.
However, this depends on giving each expression a name identical to the channel it is assigned to, without the object prefix.
For example, if the channel name is 'Toaster01.Lever.Position.Y' the expression name should be Lever.Position.Y
In this way the script can use the name to assign the expression to 'Toaster02.Lever.Position.Y'.
It also makes it very easy to establish assignments in the case of just loading the expression library from file.
The script will also rename the references to the object in expressions by replacing the original object name, for example 'Toaster01' with the new object name 'Toaster02'
So when the renamed object is loaded from file into layout, running the 'XML to Rig' script will fully set up the rig in an instant.
The 'XML to Rig' script will prompt for the name of the 'source object', which would be the object from which the rig setup was created (sans extension) by 'Rig to XML' script.
They are not plug-ins, and are just run from the 'Python' button in the Utilities tab.
These are really just examples of what can be accomplished.
They are designed for my own style of rig design, but could be extended for other applications.
For example, there is no support for IK, which I never use in machines.
You might notice that the expressions.exp file is loaded, edited and saved back out by the script and then used in the lwsdk.command 'GE_LoadExpressions'
This is because the lwsdk.command 'GE_CreateExpression' crashes layout.
So, do what works. It's the main idea behind these scripts.
The 'MotionPath' global strings in the scripts should be replaced with the path where you want the files to be saved and loaded.
Two caveats:
Scripts and xml files both have vulnerabilities.
If you cannot read and understand both, approach with caution.
I would not deliberately post malicious content but use these at your own risk.
When the xml.etree writes the elements they are not formated for readability so the files should be inspected in an xml editor that can format them.
View attachment 144765