multiController.sifz (41.0 KB)
A little demo for multiple controller. Not so good face rig (I am so bad at characters design and animation)
Details
Face controller by joystick, a switchTemplate controlled by a joystick, and the circle is controlled by the slider.
You can follow some tutorials like this, and create awesome rigs with the tool
For now, my idea is to take the groups with names and create controllers based on them.
Example,
joysitck_faceRig
switchTemplate_rectangleGroup
slider_circle
If you want to connect multiple layer to one then, you can do something like
joystick_id2_faceRig
joystick_id2_eyes
Or
slider_id3_circle
slider_id3_rectangleColor
Note: This will be the name of group/layer, and the id must be unique irrespective of type of controller you are going to connect.
And nesting wouldn’t be supported, this means that
joystick_faceRig
----> joystick_eyeRig
wouldn’t work. Explained later
I am merging them together, one thing I would want to know from you people is that, do you think that nesting should be supported or is it that important.
Do you need nested support to create controller ?
Explained later:
Why?
For example, a user wants a joystick and slider for items within a group,
So joystick needs 5 waypoints on any animated parameter, otherwise it will ignore them, and the slider needs all waypoints on the keyframes, but sometimes it may be a thing that the user wants to control an item with slider and joystick at the same time, this is completely possible to do by animating and re-running the plugin more than once. But if the user wants to do everything at the same time (create joystick and slider, there isn’t enough information to decide what the user wants).
So let’s say that the user has the following group:
joystick_faceRig
--->joystick_eyeRig
So they need two joysticks one to control the faceRig and eyeRig, one thing I can think of a solution is to ignore the groups which are children (at any inner level of the parent) of the group which has a prefix of “joystick_” and then later construct the joysticks. So basically create the joystick for parents first and go in and create for children.
This solution will work for joysticks, but now let’s think for a case in which,
joystick_faceRig
---->joystick_eyeRig
-------->slider_eye
Let’s assume that the slider_eye is a slider that will control the color of the eye, of course, the slider_eye layer will have waypoints on keyframe (keyframes can be anywhere), so when constructing joysick_eyeRig, ignoring the content of slider_eye would be a good choice, we will leave them undisturbed and later connect them to a slider. But just think that users also have animated the slider_eye position (origin parameter) and they want to control it by joystick, that’s why it is in joystick_eyeRig, so now we have uncertainty to decide what waypoint user wants to be controlled by the slider and what waypoints the user wants to be controlled by the joystick. Even if we apply any solution users may require to run the plugin more than once, and running the plugin more than once also feels easier for the user.
Another solution can be to give an order of priority for controller example,
1. joystick
2. slider
So now joystick is always given more priority, it may suppress slider, or vice versa if the order is different. This seems easy to understand and implement too. But not always a good choice.
Another way is to force users to put everything on keyframes (or continuous frames), and we can get what waypoints to consider based on what keyframe a waypoint is this would also be easy.
So if they have nested
joystick_faceRig
---->joystick_eyeRig
-------->slider_eye
Then anything that would be connected to joystick_faceRig will be on the first 5 keyframes (or frames) and then anything that they want to connect to joystick_eyeRig will be on the next 5 keyframes (or frames) and anything that they want to connect to the slider would be on next keyframes,
so
joystick_faceRig = 1-5
joystick_eyeRig = 6-10
slider_eye = 11-n (n because this is how slider's work, generated based on number of keyframes)
we can work around for slider, to limit it to certain keyframes by taking group names like slider_2_eye, so this means that in the previous example it would be 11-13 keyframes used to connect to the slider. I think this solution is good for me, also for users, it’s predictable and understandable to expect the proper result, the only thing is that the user needs to create or make sure that waypoints are in the proper position based on keyframes (or frames).
What do you think must be done? Suggest me any other ways or better ideas to implement them.
,
, also I will implement a way for generating more controllers based on name of Group Layer, and submit a PR so that this code will be merged to Synfig. And it would be good to discuss this on Github than Forums.
.
for giving your time to test the plugin. Great you attached the your test cases, it would be beneficial if you also share the spreadsheet too.
