Attaching spline to follow mesh, but being able skin it back in?


#1

Hey peoples,

I’m currently coming up with some new facial rig stuff. I want to keep morphers (because they are quick to create and we need speed in our pipeline) but at the same time add some facial controls that are skinned in to allow me to push the face around on top of the morph target. Basically just get a little extra control for when we need it

I came up with a method that involves attachment constraining some points to the face mesh. Creating dummies on top of these points and linking them to the points, and then finally creating a bezier spline that is link xformed at different vertices along it’s length to the dummies. I would then skin parts of the face mesh i want affected back onto this spline.

This way as the morph targets targets mix in, the spline is completely following the shape of the mesh as it changes, and by moving the dummies it allows me to push the face around with the morphs still on top.

In theory this works, but of course by skinning the face back onto the spline i’m creating a dependancy loop. Is there a way for me to do this at all?

I’ve thought about making a proxy mesh and putting everything on that, but it is still involved in the loop so this idea won’t work either.


#2

That’s interesting. I’ve tried to do the same thing. I guess you are using max? Anyway, at least in max this seems to be bit problematic to do. Script controllers, position constraints, and parenting creates dependency loop.
I went the route of making secondary rig object like you suggested. Finally, with this method you can have tweak control riding morph, sort of parented to attached point on face.
Then you have a double transform, tweaking point will double the transform, as morph is already moving it, and then you add another transform on top of that. But you can counter it by using list controllers and back tranforming the point. I’m not quite sure if my setup worked properly, i didn’t run into loop, but opening trackview and tweaking the point caused noticable update lag.
So my solution wasn’t exactly nice setup, and i haven’t finished it yet. But it would be interesting to hear if someone has nice and clean solution for this. I might be able to post a video of my test later.


#3

Here’s the video: Morph tweak node


#4

I started to work on this some weeks ago. Still in process and with a lot of bugs (the video below is not the last version, and you can see red points ‘popping’ out its position, for example), but I guess I can make it work. I’m using an attached point to one vertex. Then, for avoiding dependency loops, I use an ExposeTM for reading that position, that is given to the Zero channel of the red point via an expression (but I think copying the controller could be fine). And then, a bone whose position depends on the Animation channel of the red point.

http://www.youtube.com/watch?v=U_Qr6jWrtmM

The problem with the ‘popping’ could be solved, I guess, using another head for attaching the points. ‘Attachment Constraint’ does weird things if the mesh below has noticeable deformations on it.

This is my third try to approach this problem… so it should the last one, hehehe! And very nice test, Sami :wink:


#5

Got it! The mesh where you skin the bones should be different from the one where you attach the points. So creating a reference from the original and adding another ‘Skin’ modifier on top of the stack solves the issue with the ‘popping’. And editing the curves goes as fast/slow as always :wink:

Wow, weeks after that and suddendly the inspiration comes…


#6

Hi IkerCLoN, thanks for the response, it looks like using your method works exactly how I need it to.

Unfortunately i’m a little lost when it comes to getting the expression controller set up. Is it possible for you to post an example file for me to take a look at?

Thanks,
Drew.


#7

dkennewell:

Look into script controllers or parameter wires. You could just add script controller to a point1 and make it follow point2:

Add script controller to $point1. Add a variable. in “create variable”:

Write “myobj” (replace with something which describes what you use). Then press “Create”.

Then browse a node, with “Assign node”. Browse $point2 for the variable, press “ok” and in “Expression” field write “myobj.position”, evaluate and close window.

Point1 will follow point2.

ikerCLoN:
Your script looks definitely promising!

If i may ask;

  1. You have an object with morpher + skin for skeletal deformation, which has a point attached to lip (using attach constraint)
  2. Then a reference of this head mesh, which has another skin as it’s “local” modifier for secondary deformation. I tried this quickly.
  3. But i run into problem with rotation. Bone which is deforming lip should only move when lip control object (red dot) moves, which means that actually this skin is working on non deformed head.
  4. This is fine for deformation caused by position offset, but if morph “moves” lip up, and then you rotate your red dot, bone is no more at the same location as red dot - which means it’s not rotating around center of red dot control? Does this make any sense?

Maybe i didn’t understand your method correctly. Anyway. I’ll try to find a solution for this as i’ll also try to include rotation control for tweak objects.


#8

Damn it! I swear yesterday it was working on some way, but I can’t reproduce the steps again (I started to tweak one test scene). As you could see in the video I posted, there were some glides on the red points. As I said, I think it was the Attachment Constraint (on a hidden point) that was causing this, because when the mesh that is driving this point deforms, something beyond my knowledge is happening internally. I’ll try to dig in it…

So the solution I came with is “OK, so let’s deform another mesh! Let’s make a reference and add a Skin modifier on top of that!”… and this, opposite as I thought in the first moment, does not seem to work: the skinned mesh seems to slide over the bone.I’ve attched a simple file so you can try this…

Sami, I cloned the “Animation” pos controller of the red sphere to the skin bone, so the bone is only moved when the red sphere moves by itself, not driven by the morpher. That way I guess the double transform is avoided.

The thing is that I tried to dive into this having almost no idea of scripting or complex behaviours on these things. Sorry if I’m mixing things up and it seems waht I want is to call all your attention on this. Here there are some interesting things related to this but for XSI:

http://www.xsi-blog.com/archives/209

… and for Maya:

http://www.keithlango.com/wordpress/?p=566

Gosh, why it seems soooooooo difficult to achieve the same in MAX? Hehehehehe…


#9

S-S, what codec do you use, i can never play your vids.


#10

Hi,

IkerClon nice to see you around here :D.

I've been looking at your method Iker, and that's look good, actually when i started to read this thread i thought the same as you "yeah just make a reference clone and set the extra skin there, and voila!", but yeah, that doesn't work at all.

The first reason: the mesh' weights seems to slide over the surface because you're using envelopes to skin it, if the bone stays still and the mesh's vertices transform bellow the skin modifier they're gonna get out the bone's envelopes and wont be influenced, others vertices will get in that envolope and will start to be influenced. So the way to fix that is to weight the vertices by hand, or bake them.

Second reason: About the rotation issue, if the bones inherits the rotation directly (instancing controllers or script controllers), it will deform the mesh with vertices' offset different from the red sphere. 

I though a way to fix it, if the bone is linked to the red Sphere and it doesn't have the controllers instanced, it's gonna deform the vertices like if they were influenced by the red sphere. Now, to remove the bone's transformation inherited from the attached node "L__0__DH" (to do not duplicate transformation to the vertices) we can use the attaced node's transform in respect to a neutral node (which has a transform initially equal to the attached node) and use its inverse in a script controller in the bone.

Here i included the file with the modifications (max 2008), the extra adventage of this is that the control point (the red sphere) can now be aligned to the surface, i linked it to the attached node instead of using expresion controllers in its position.

#11

eek:

It’s h.264, more exactly x.264 if i remember correcty. You can install codec from k-lite codec pack for example. I guess i should just use quicktime, as most of the time special codes are a problem.

edit: Replaced AVI with Quicktime. Should work with Quicktime 7.


#12

phoelix:

That’s VERY nice solution. I tested it quickly. There’s no need for extra objects like expose transform, all parts can be linked directly, and it seems like linking it to a hierarchy + instancing deformation between objects is also OK, so i think this is a better solution! It’s very nice that the need to bake weights and possibility to parent bone to control, gives also rotation and scale deformation “for free”!


#13

Here’s a test. Using phoelix’s transform tip. It seems like it works.

morph tweak nodes test

I ran into problems with deformation, teapot scenario works fine, but as character model (most of the time) has skin for body, neck and head deformation and then morpher for facial expressions, i had to use morpher to transfer this “shape” into mesh which is deformed by red dots.

I also made a small script to plant control points on surface by painting, and it automates creation of each contol object’s hierarchy. It’s simple, but it works.

So, currently bones will be left on place, even if the head turns (as you can see from the video), first you see the morph deformation, then lip is tweaked with bone, and then the head rotates back to neutral pose. It’s possible to see green bones left on place, so when rig walks forward, face bones will be left on place. Obviously, this was the case in teapot scene too.

I don’t know yet if it would be a problem, except for skin finetuning… have to test it a bit more. I think idea of making bones follow rig, is in conflict with the idea of this kind solution, but it would be convenient to have bones follow at least neck. Have to think about this a bit more.


#14

The first reason: the mesh’ weights seems to slide over the surface because you’re using envelopes to skin it, if the bone stays still and the mesh’s vertices transform bellow the skin modifier they’re gonna get out the bone’s envelopes and wont be influenced, others vertices will get in that envolope and will start to be influenced. So the way to fix that is to weight the vertices by hand, or bake them.

Phoelix to the rescue!!! Thanks, dude!!! So this was why sometimes the solution worked for me and some others not. Cool…

Tomorrow I’ll take a look at your solution. For what I read, it’s lss ‘heavy’ since you have less objects in the viewport and less connections. Awesome! Tomorrow I’ll go to work super happy, hehehehe :slight_smile:


#15

dkennewell, IkerCLoN, phoelix:

Here’s a test i did with my script. Phoelix’s solution works fine! I made a quick test. Works fine when rig is transformed and with bones in face (like jaw) , and you can also see that scaling and rotation too should work just fine, only not so nice thing is that bones stick to their original place, but i guess most of the time this would be just minor problem for skinning. Nice job Phoelix!

http://www.cgmill.com/main/?page_id=165&g2_itemId=3521


#16

it’s great that you could find it useful guys. I was thinking about what you said S-S about the rig transform, and i was worried about that, because the bones, as you said, will stay always in the same place, so if the character walks 10 feet, the face bones will stay 10 feet away from the character, well… fortunately the animator doesn’t have to interact with them (only with control objects that doesn’t have the same problem). it’s good to hide those bones always, like deleting their geometry or something like that.

see ya!


#17

Supercool test there, Sami! And phoelix, thanks again! I’ll rework my little script so I can make it production-ready :slight_smile:

Thanks!


#18

I did exactly the same thing some time ago and came to the same conclusion that part of the rig will stay behind. I wish there as some way to permanently disable drawing and on screen selection of an object. I haven’t looked at any of the files here but it sounds like what you guys have been playing with was exactly the direction that I went with it. I have never implimented it in production so I would like to hear if any one does use it how it stands up to animators bashing on it.


#19

I think I did very similar too, months ago, but I could never figure a solution “baking the vertices”. perhaps because I’m a bit against painting weights…
(I guess, the rig I have does not let controllers behind)


#20

Ha - the very reason I stopped working with spline for facial systems. Maybe I should have another go?

What are we trying to do here? Is this correct:
[ol]
[li]Have a mesh use morph targets[/li][li]have dummies control curves which ride ontop[/li][li]have the mesh skinned to the dummies or curve?[/li][/ol]If its the third i wouldnt skin to a curve your’ll get some oddities with buckling, and tangency stuff. If its the dummies riding the curves riding the mesh - then your’ll have to use another reference. Now the reference can be stored in a CA im assuming.