Be able to set Limits for column Transformations (position, rotation, sacle), for setting up controls in rigs.

106 views
Skip to first unread message

Gabriel Gazzán

unread,
Jul 23, 2018, 9:11:28 PM7/23/18
to OpenToonz Users Forum
Currently OpenToonz has all the basic stuff needed to set up visual controls for using in character rigs (i.e. it has expressions, hierarchical relations between columns, etc.).
Still, currently there is one thing that makes using visual (joystick like) controls impractical, and that is the lack of a way to establish limits for a column transformations.

Not being a programmer myself, yet it seems that such a feature should be a lot less complicated to implement than, for example, the already existing Expression interpolation system, and it would allow for a more practical way to control characters (and possibly other things).
So I wonder if there could be someone who is willing to put such a system in place for OT.

What should it include?
The Limits system should be able to set absolute Min and Max values for each of a Column's transformations (i.e. ew, ns, rotation, scale, etc.). These Limits would be properties of each column.

Why is it important?
When building visual controls for rigs, they normally consist of a "frame" column (one with a rectangular shape), which visually establishes an area inside which the actual control column (usually in the form of a small circle/square) can move.
By currently not having a way to set transform limits for columns, the small circle/square of such a control system is allowed to freely move outside of that visual frame area, undermining the whole purpose of such a control.

How is such a system implemented in other CG software?



Thanks for considering it!
If anybody needs more input I'm at your disposal.



Jane Eyre

unread,
Jul 23, 2018, 9:23:11 PM7/23/18
to OpenToonz Users Forum
I agree that this would be helpful - especially when setting up a rig with the skeleton tool. It’s not as big a deal in the animate mode of the skeleton tool but animating using inverse kinematics can get a bit out of control. Being able to limit the rotation of the different bones would really be beneficial in that case. I think it’s a pretty standard feature that is missing.

openanim

unread,
Jul 23, 2018, 10:01:50 PM7/23/18
to opento...@googlegroups.com
This request is similar to this one. ?  https://github.com/opentoonz/opentoonz/issues/1571

It would be very beneficial. I am a big fan. But if already the different columns were accessible on the same space/view with the animate mode, it would be a BIG first step towards for this functionality. Same for Sub xsheet, if it could allow to scroll the framebar in animate mode or IK. It's really frustrating because OT has most of the functionality needed. But, it's a little scattered. It's even troubling ... It lacks an interface to put all this in place. But with all the advantages of OT features. 1- The interpolation is there 2- The framebar is there, just have to relook 3- The notions of angles are already existing in the plastic tool 4 Q / W work on sub xsheet why not the framebar? Personally, I think that Moho pro has the best functionality with smart bones, very powerful in thi purpose . Opentoonz has all the elements, by far to maximize this kind of workflow. In principle, if we have access to the level strip of the different columns no matter where, if we got angles and the possibility of choosing which image Q and W we stop, we will have made a big step.

When you do a headturn for exemple it's frustrating not being able to stop on specific points. Like here

https://www.youtube.com/watch?v=SAxRZXxiRpI

Rodney

unread,
Jul 23, 2018, 10:17:02 PM7/23/18
to opento...@googlegroups.com
While there is much that needs to be worked at to get at the full rigging capability required for modern day rigging of characters OpenToonz likely has much of this capbility already it's just not easily accessible.  As an example here's a proof of concept I just put together after reading your topic.  In time someone will surely champion the art of rigging in OpenToonz and develop some effect UI controls to exploit the various constraints and limits.  For those that can't wait for that... there are expressions....

In it I used a max (maximum) expression to limit the rotation of three segments parented together in a chain.
Because I didn't want to have to go back into the Function Editor (or subxsheet... which I must assume most rigs in OpenToonz will have) I added an on screen controller that assists with adjusting the the value of the limit.  That controller adjusts the high value of the rotation.  The low value is initial set (manually) to zero.  At the beginning of the video a have the low setting set to zero and you can see where later I change one of the expressions manually to 45 and then adjusting the controller won't allow me to rotate that segment (or it's child) less than 45 degrees in rotation.

Someone that actually knows what they are doing could demonstrate these processes more clearly but I'm just vaguely aware of what is there.
Much work (and education) lies ahead to be sure... my holy grail would be an Aim at or Target constraint.
If I knew more math I could probably write an expression for that.

At any rate... here's my cheesy proof of concept for creating a simple limit constraint via expression (in this case using the 'max' expression to limit rotation via a manual value as well as one adjusted via an ad hoc onscreen controller).  Note that the on screen controller is limited to move in only the up/down direction as it's right/left (east/west) has also been constrained/limited..  in this case by the oddly simple expression '0'.

openanim

unread,
Jul 23, 2018, 11:06:37 PM7/23/18
to OpenToonz Users Forum
Do you know how this works in synfig? It seems to me that it also has controllers ?

joshua shute

unread,
Jul 24, 2018, 6:37:34 PM7/24/18
to OpenToonz Users Forum
a useful expression is clamp. 

clamp basically makes a series of "if" statements for you and sets values. clamp has three values which are x, a, b. 
x is the number being compared
a is your minimum 
b is your maximum

clamp(x,a,b)

in practice

setting column1's ew position with constraints based column2's ew position.

clamp(col2.ew,-68,100)
column1 now takes column2's ew value but any value below -68 is replaced with -68 and anything above 100 is replaced with 100.

expressions and rigging

 a huge piece that is missing from expressions in opentoonz is "value". this clamp expression would be a lot simpler if we could say to column1, "look at your own current ew value and compare" typically this is done by using the expression called "value". without value we are forced to reference out to another column to drive the expression. additionally, "value" would allow us to create true parenting with offset via expressions.

the ability to define variables would help simplify things further while simultaneously making expressions more powerful.

what Rodney is showing is incredibly powerful but is essentially wrong on the software's side of things. in the video, rodney references col1 which should be referencing column1 in the current subxsheet since there's no way to specify subxsheets via expression. instead, opentoonz references col1 in the xsheet where the column was initially created. as a rig starts to develop this begins to complicate things. this is taken even further when columns are moved, let's say we move column2 to column3 leaving column2 blank, any expression referencing col2 still says col2 while looking at values for col3. creating art in the previously empty col2 and referencing that column via expression now leaves us with two expressions, both referencing col2 but looking at two different columns. now let's start copying columns between xsheets and see how crazy things get.

a lot needs to be added to expressions and work needs to go into how opentoonz views those expressions as well as the columns those expression reference before we can have a useable controller.



Rodney

unread,
Jul 25, 2018, 9:40:33 AM7/25/18
to OpenToonz Users Forum
@joshua shute    Thanks for the tip on use of the Clamp expression!

I follow what you say about the referenced columns and the ability to specify the target more clearly would be optimal where it comes to subxsheets.
I do find myself wondering if there might not be an undocumented way to do this already using a dos-like folder navigation using one dot to specify current xsheet and two dots to move to the parent xsheet.  This is the way I've seen expressions work in a few other programs.  The dots would then be followed by the pipe key symbol "|".  It's probably not there but... 

I read what you are saying about the downside of all subxsheets using the column reference of the primary xsheet and I see some good things in that approach.
The idea being that whatever xsheet the user is looking at at any given moment is likely the main interface for all other subxsheets it contains.
As such, it makes sense to me that the simple controls would control the more complex.
Of course the downside of this (assuming we cannot use expressions that maintain relative references) is that nested controls cannot be created.
Having those would indeed be powerful because we could build expression widgets that control other expression widgets.

But.. back to the topic at hand of setting Limits...
The two most useful expressions I know know of to set limits are:

- Entering the actual value of the limit into the expression (for quickly lock a transform down enter the number zero as the expression)
- Clamp which is useful for establishing values inside and outside of specific ranges.

I'm sure there are many other useful expressions and I look forward to exploring those as users discover their uses and post more about them.


joshua shute

unread,
Jul 26, 2018, 7:41:49 PM7/26/18
to OpenToonz Users Forum
 nested controllers can be created so long as the expression isn't referenced back to itself. you can reference down through multiple subxsheets and back out again assuming the column was created in the appropriate xsheet. 

"The idea being that whatever xsheet the user is looking at at any given moment is likely the main interface for all other subxsheets it contains.
for this to work, columns being driven and the controller doing the driving would need to be created within the same xsheet and then moved to the appropriate subxsheets, rigging hierarchies would need to be established (or reestablished) afterwards.

Reply all
Reply to author
Forward
0 new messages