feature request - inherit rotation of mesh bone option for Levels parented to a mesh level bone

[blurymind]

Here is a simple user case scenario example, where I have attached a hand level to one of the mesh bones of the arm:

(sorry for the crude drawings)

When you do that in opentoonz, the hand level would only inherit the translation of the bone that we attached it to, but not the rotation. So it is not patented the way levels in opentoonz parent other levels (inheriting location, rotation and scale). It inherits only the location world space.

In some cases we would want that, but in others (like this example) we would need it to inherit both rotation and location.

My proposal is to make that possible by simply plugging the the mesh bone (3) port to another letter of the hand level. If there is a input port letter that is currently not in use - we could reserve it for rotation&translation port.

Alternatively the schematic node could have a tick box. Similar to how blender does it. In blender we can set it with a simple tick box like this: It needs to be enabled in the child object (hand).

This will not only be useful for mesh bones, but also for parenting in general in opentoonz. it will greatly improve character rigging - having that control.

[blurymind]

I think that by default the levels connected (B port) to a mesh bone (3) should act the same way a B to a B port act - parenting - inheriting location, rotation and scale - because the child node's input node is B. The user is taught that using B for input would make it a child. The current design has a behavior that is not consistent with connection of level to level nodes.

We should keep the option to limit it to only location by using a different input port letter for the child (C?)

These letters are kind of cryptic, so perhaps hovering over the port letter could show a hint of what it does. For example: Hovering over a B input port could display a text "input:B - child of - inherits worldspace location,rotation and scale from parent" . hovering over a B output port - "output:B - parent of - outputs world space". Perhaps for a much later feature proposal? 'Port hints'

[BrundleThwaite]

You can use an expression on the rotation of the hand:

vertex(3,"Vertex__4").angle

3 would be the mesh column number and "vertex__4" would be substituted for the vertex name. it the lasts bone is out of the mesh it will not affect the mesh but will control the hand only.

[blurymind]

@BrundleThwaite Yes I saw in the manual. There is a bug that prevents us from doing so btw: https://github.com/opentoonz/opentoonz/issues/221

Is it possible to animate rotations on top of the expression? I want the hand to be a child of a bone and inherit rotations of world space - but still be able to animate it's rotation and translation in a standard way. I dont want it to have an expression that completely overwrites my animation. So then I have to complicate my rig needlessly with pegs to keep that control and be able to rotate the hand.

I will try using an expression, but my question is why not be able to just connect them in the schematic view. It is much more user friendly for artists. :) isn't it cryptic enough that input and output nodes are cryptic letters? Now we have to teach the users syntax to do such a simple common thing that 100% of all character rigs with a mesh level can make use of.

[BrundleThwaite]

Opentoonz only crashes when you change to expression with nothing selected in the function editor. make sure that you have a value selected and it should be okay.

[blurymind]

@BrundleThwaite can you report this at #221 :) Might help them fix it. Thank you for the workaround. I will try out a setup with an expression - see if it has more disadvantages.

[BrundleThwaite]

Expressions have more advantages in terms of control but it would be better to have both options so i definitely second the request :)

I also only learned about the crash after your post. I played around a bit to figure out what would case the crash (best to be safe and know what not to do until it is fixed)

[blurymind]

@BrundleThwaite They are definitely very powerful. The more I find about opentoonz, the more I like it. I wish the documentation had more information about the scripting api. Thank you for looking into this too.

[BrundleThwaite]

Unfortunately the scripting is extremely basic at the moment. It is probably one of the weakest and least developed part of toonz from what I can see.

But then again I am a average programmer at best so I may be missing things.

[blurymind]

There are definitely some things that can be improved from harlequin. I think that once opentoonz catches up with harlequin, it will most probably surpass it - if the development keeps being as active as it is.

[BrundleThwaite]

Unfortunately the expressions are not an option as expressions relating to plastic seem to corrupt the scene file.

[blurymind]

@BrundleThwaite seems like another serious bug. Can you report it as a separate issue with steps to reproduce the problem? :)

[blurymind]

without inheriting rotation of bone, the attached level will almost always have to be conter-animated. This creates much unneeded work for the animator. I have never seen any other software let you parent an object to a bone, but wont allow it to inherit the bone's rotation.

[BrundleThwaite]

The expressions should be fixed now

[blurymind]

@BrundleThwaite I couldnt get it to rotate that way. Have you had any luck setting it up that way? The expression seems ok, but the level doesnt rotate :(

[BrundleThwaite]

It definitely works for me.

This is how I am setting it up. I could actually do a far more complicated setup but that would not really be good for this kind of tutorial.

https://vimeo.com/164225129

[blurymind]

ooh, I missed the *.angle part at the end xD

[blurymind]

@BrundleThwaite I tried doing some animation with the expression rotating the bone.

We still have the same problem and have to counter animate the hand. To see what I mean, try rotating the arm bone.

Copying rotation values from the hand bone will not rotate the hand accordingly to the arm's new angle. Because when you rotate the arm, the hand bone does not really rotate - it inherits the world space of its parent - the arm and thus the actual bone's world's orientation changes - changing it's angle globally, but not locally. Locally the rotation of the bone is 0.

We cant do what I am proposing here with the expression. We need this feature to copy the world space orientation of the hand, but also allow us to animate on top of it.

The best way to experience how this should work is to open up Blender and create an armature. Parent a cube to one of the bones, then rotate the bone in pose mode.

We need it to both inherit world orientation of the hand bone AND it's local rotation value! Not just one or the other. Can you come up with an expression for that?

[blurymind]

here is a gif to illustrate what I mean. Notice how the hand level rotates when I rotate the hand bone, BUT it does not rotate to the hand bone's rotation when I rotate any of the parent bones. Then we still have the same problem - because the attached hand level does not inherit to world space of the hand bone, it only copies the rotation value.

vertex(3,"hand").angle will not work on a rig. Solves nothing

@shun-iwasawa this is a big limitation of the software!

[blurymind]

Only workaround is to just make the hand level a part of the mesh. Then edit the mesh to include it

[Juls3000]

I fully agree that this is not inverse kinematics, but I think that by the moment, it is a big step in comparation with v1.0.1. Now animating accordingly the last two nodes, to some extent, you can get results.

e.g. If you plan to animate the face step by step, I think it sounds easier to animate like this, one level of just the face, that to animate one level of face and body together.

[Juls3000]

Blurymind I think your exemple above is not correct, is the reason why it rotate in this way.

(1) You have to connect head ("cabeza") with node 5, and move to this node the center of cabeza. (2) With the expression you give to level "cabeza", the same rotation than the node "cabeza".

To animate the ensemble you have to move coordinately both node 5 and node "cabeza".

[blurymind]

@Juls3000 a good rig should never make the animator counter animate. it makes life difficult for the artists who will use it.

On Mon, May 2, 2016 at 8:38 PM, Todor Imreorov blurymind@gmail.com wrote:

@Juls3000 you have obviously not tried to rotate your character's chest bone yet xD My point stands valid that you will have to counter animate the head's rotation every time you rotate the chest - therefore the rig is still very broken.

On Mon, May 2, 2016 at 8:22 PM, Juls3000 notifications@github.com wrote:

Blurymind your exemple above is not correct, is the reason why it rotate in this way.

(1) You have to connect head ("cabeza") with node 5, and move to this node the center of cabeza. (2) With the expression you give to level "cabeza", the same rotation than the node "cabeza".

[image: cats4] https://cloud.githubusercontent.com/assets/19145844/14965086/b32a0eac-10ab-11e6-9e7a-f9ebbbc6fa42.jpg

To animate the ensemble you have to move coordinately both node 5 and node "cabeza".

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/opentoonz/opentoonz/issues/218#issuecomment-216335033

[blurymind]

@Juls3000 Your solution does not solve the problem. If you rotate your character's chest bone, or root bone - the head will not rotate accordingly to the bone. I explained earlier why simply copying a rotation from a bone will never work.

I tried it - still very broken rig. Actually this inability to properly parent the bone makes this way of attaching it almost completely useless to me now.

[Juls3000]

You have to rotate head manually with node "cabeza", I said is not IK, but is somethig ;( (not mine, I learn it from Simon, and I plan to use it meanwhile there are nothing else)

[blurymind]

You have to create more keyframes - which you have to keep track of. Its counter animating however you cut it.

My point is that we should never make the animator do that.

[Juls3000]

You have reason, but we are here now and we have to do animations.

[blurymind]

@Juls3000 Just dont attach the bones that way - as it currently is very broken imo. it's almost useless for rigging. Until open toonz devs add the feature I am proposing here, this is the best solution I found for myself:

You are going to have to edit the mesh, so as to include the new level - otherwise the hand will get clipped off. Mesh editing tool in open toonz is a pain in the neck to use, but its the only solution Hope it helps

[BrundleThwaite]

I was aware of this problem before I posted that video I just have not had a chance to finish part 4. the answer is pretty simple (if a little ugly).

vertex(1,"elbow").angle + vertex(1,"wrist").angle + vertex(1,"hand").angle

you then get the cumulative rotation of the vertices.

[blurymind]

@BrundleThwaite that is an incredibly ugly solution. Basically you have to combine the rotation of ALL parent bones? xD What about the rest of the body? All the spine bones, way down to the root.

But it's another alternative :+1:

[BrundleThwaite]

The reason I did not put the longer version in that video is even more of a pain. Because you are using the column number instead of a specific name you can't swap around the columns. So you check the basic rotation is working. When everything is ready for export and you get rid of any reference drawings you then have to change the numbers,

Because you do basically have to do it for all the spine bones ect. it becomes painful if you have to change every column number. So I chose to fix the expression for the lib right at the end.

At least it give you a workable result.

[blurymind]

@BrundleThwaite the workarounds are a pain to use for sure. Maybe someone will implement proper bone parenting when the number to letter ports are connected. One where world space of the bone is actually inherited, rather than simply copying the transform value.

We can do that without connecting ports anyways - with an expression.

[Juls3000]

@BrundleThwaite I like that expression, it shows the possibilities of functions editor, and sure there are cases where it is of application.

@blurymind your proposal really brings plastic animation to the limit, as it is now.

Thank you both.

I have been analyzing this issue, face off my needs just now, and finally I decided to use pure plastic animation with help of paint rigid in some cases. Not too bad.

Me too, I keep waiting to one proper bone parenting. Then this software will be even more excelent.

[blurymind]

It would be good if there was a way to merge two plastic levels into one On 3 May 2016 13:34, "Juls3000" notifications@github.com wrote:

@BrundleThwaite https://github.com/BrundleThwaite I like that expression, it shows the possibilities of functions editor, and sure there are cases where it is of application.

@blurymind https://github.com/blurymind your proposal really brings plastic animation to the limit, as it is now.

Thank you both.

I have been analyzing this issue, face off my needs, and finally I decided to use pure plastic animation with help of paint rigid in some cases. Not too bad.

[image: untitled2_gif_001] https://cloud.githubusercontent.com/assets/19145844/14983204/0758b98e-113c-11e6-9eaf-d0e74db38c21.gif

Me too, I keep waiting to one proper bone parenting. Then this software will be even more excelent.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opentoonz/opentoonz/issues/218#issuecomment-216513957

[Juls3000]

@blurymind Creating a mesh from one sub-Xsheet you can do this. But then, how to edit it in context ? (I hope that "edit sub-Xsheet in place" comes soon!!! https://github.com/opentoonz/opentoonz/issues/264) :

More explanations here (Tip for the Forum) And here: Toonz Harlequin Plastic info: https://youtu.be/T50aOjWUr6E?t=4m (4:00 to 4:11)

[Juls3000]

@blurymind @BrundleThwaite If you have opportunity to try the above mentioned, please tell me your opinion.

[blurymind]

@Juls3000 indeed - without #264 the solution of using a sub x sheet has no advantages as we can not animate the levels inside the mesh change frames as we pose the character.

It is crazy that ghibli decided to remove it in order to unclutter the interface. It just goes to show that they dont do cut out animation I hope the code is still there and someone brings it back. :)

[blurymind]

@shun-iwasawa It's good to note that the one advantage of this feature request's approach over putting everything in a mesh is that drawings in the mesh always have to be constrained to the mesh silhouette!. If for example you draw another hand with a different silhouette to the first - the mesh of the first is going to clip off parts of it.

That is why I thought that it makes more sense to put inside the mesh elements that are constrained to the silhouette of the character. For other elements that change the silhouette, using a number connection port makes much more sense. The problem is that of course it does not inherit rotation accordingly and it is not in a parent-child relationship to the bone - as it should be.

@Juls3000 no matter what you do, you will need to edit the mesh and move edges around to expand the silhouette.

In that case -it's always a good idea to create a less dense mesh - because OT doesnt have any tools for mesh sculpting or moving multiple edges.

[Juls3000]

@blurymind If you apply the command "create a mesh" to one level strip with several drawings, OT create several meshes associated to each drawing, even you can use sequentially differents skeletons for each of these meshes.

[blurymind]

Does it also allow you to add new drawings and create mesh for them that is attached to the old skeleton?

[Juls3000]

You can use the same skeleton to animate several drawings>Meshes:

Or you can also use several skeletons to animate several drawings>Meshes:

[blurymind]

Ah nice . I am going to give this a try On 12 May 2016 09:53, "Juls3000" notifications@github.com wrote:

You can use the same skeleton to animate several drawings>Meshes:

[image: cats] https://cloud.githubusercontent.com/assets/19145844/15209075/69ac27ac-182f-11e6-9eff-019b676a3b4f.jpg [image: cats1] https://cloud.githubusercontent.com/assets/19145844/15209076/6d9503e8-182f-11e6-85df-304da1fc8241.jpg

Or you can also use several skeletons to animate several drawings>Meshes:

[image: cats2] https://cloud.githubusercontent.com/assets/19145844/15209100/8ddd87d8-182f-11e6-8ad0-b3c5f1cddce5.jpg

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/opentoonz/opentoonz/issues/218#issuecomment-218697845

[Juls3000]

Don´t forget to select all drawings in the column before comand "Create Mesh"

[ghost]

Based on the discussion in #1207 feature requests are going to be closed here on GitHub unless there is a developer actively working on the feature. Feature requests can be discussed at the OpenToonz Google Group: https://groups.google.com/forum/#!forum/opentoonz_en