Technical Character Challenge : Non-flipping curve

[Jason]

Hi all,

Something which has me fairly intrigued is building a Spline Controller OTL which generates a spline connecting start and end points (manipulated by controllers). The spline needs to have N (normal) attributes that don't flip if you rotate one of the spline controllers more than 180 degrees. This to ensure bones that are attached to this curve with a Follow Curve solver don't flip when you twist the skeleton like this.

Many techniques come to mind - but basically this:

- each controller has two points, the end point and a point to define the tangency

- build a bezier betwen the points

- resample the curve so that we can have a higher resolution curve to define the rotation in the N attribute

- compute the interpolated N using the transforms of the controllers, either using VEX or CHOPs perhaps.

Ultimately the goal is to have a variable resolution curve that has normal attribs that don't flip. And is as fast as possible.

I can post a start position if anyone is interested?

Thanks,

Jason

[meshsmooth]

I am working on almost this very problem now. But I am focusing on making a spline that will not stretch. But at the moment the twist of the spine is an after thought, applied to the bones after they have been attached to the spline with spline IK with maybe a Z rotation in chops.

[Jason]

I am working on almost this very problem now. But I am focusing on making a spline that will not stretch. But at the moment the twist of the spine is an after thought, applied to the bones after they have been attached to the spline with spline IK with maybe a Z rotation in chops.

14337[/snapback]

Thats cool - perhaps we can combine solutions? Here is the basis of a system so that you dont have to build controllers for all this stuff, etc.

The setup is simple and should be easy for all to understand.

Cheers!

Jason

od_control_spline_v1.otl.zip

[meshsmooth]

This is what I have cooked up so far I am still refining the solution so I haven

spine_noStretch_9.zip

[Jason]

I got a couple of minutes today to look at this problem again, and I decided to try VOPs to solve the twist.

It works mostly ok ...mostly.

What I think I need to do is to use the dPdu (the vector pointing down the spline) to correct the the new normal I've stuck on there. Thats for another day.

od_control_spline_v1.otl.zip

[danteA]

If you use the Path tool to create your curve and then apply Bones From Curve on this, doesn't it just work?

[Jason]

Ha ha! You're totally right. For some reason I obsessed with point normals when the FollowCurve CHOP doesn't use them totally. Its cleverer than that:)

Ok well - I guess I can simplify that a little. I had normal indication along the spline to give a visual cue as to which way I thought the Bones would point, but since the CHOP doesn't use them, it's useless.

Sigh. Live and learn.

[thekenny]

umm,

doesn't the CHOP have a section for the curve Normal? default best guess?

does your pathObject create two point attributes along with N, twist and inital twist?

if it doesn't I never mentioned it.

honest:)

-k

[Jason]

umm,

doesn't the CHOP have a section for the curve Normal? default best guess?

does your pathObject create two point attributes along with N, twist and inital twist?

if it doesn't I never mentioned it.

honest:)

-k

14372[/snapback]

Heh, I discovered the initial_twist and all that all too late myself. I've figured it out - but that doesn't really excuse my foray into Normals on curves.

[old school]

You will pull your hair out. Without the initial object orientations embedding the right Normals and twist vector post hence, it would be very difficult and expensive to post-compute. Remember that if your spine rig is slow, everything is even slower. Everything hangs off the two ends of the spine. Touch any controller on the spine with IK on everywhere else and see everything else move as well. Watch out! I can speak with much experience, lost sleep and heaven knows what else!

Your spine rig needs to be the fastest thing in the character. Check out the Rabbit rig. It is a pretty good solution. It has some clever stuff in it and not by accident. If you want the end effector to stick to the end of the spine, then you may be delving in to mild recursion (you have to right?). That is the last thing you want. I think it is safe to say that the mainstream feature film rig approach is to have the animator manage the last key on the spine or have it stretchy. Flexibility like that is appreciated in the field. Just don't warn animators that they moved something too far as they will hurt you.

Obviously if you come up with a likety-split solution to keep the last curve controller at the end of a rigid spine, please share. Trust me, it is tricky to do for long bone chains.

[robert.magee]

The new skeleton character on the Houdini exchange has a spine solution that twists by clicking on the wedge control at the top of the spine with the Pose tool (make sure Select Entire Subnet is OFF). Please test it out and see if it meets the needs of your challenge.

[old school]

I apologize for such a negative post.

I too had a foray in to curve normals to allow resampling of the initial bezier spline curve very recently and it is not that much fun but had some progress. I ended up with a complex VOP network containing a few matrix transofrms and rotates. Got real close with only one naughty normal that looked like it was in gimbal lock. R&D is aware of the issue of resampling curves and fixed length spline solution.

The last bone in the spine spline chain given some contorted end curve tangency can leave that bone flapping in the wind even with the stretchy spine. Not good, even though the position is extreme and unnatural, perfect for character animators as they will gravitate towards that immediately!

The only way to reliably have an end effector that always snaps to the end of the curve for a fixed lenght spline is if there is a specific handle designed for curves and the spline IK solver a la IK bone solvers. Perhaps an entirely new spline solution just for bones.

If we had de-select or de-manipluate scripts for objects in the viewport (handy to have), then I could easily reset the position of the end spine controller to the end of the bone chain. Where would the curve twist and bend control would have to live at the end of the bone chain as the curve would change shape as you let go.

[meshsmooth]

Adding twist to a spine is a non trivial affair, and it would be a grate benefit if we could just whack down a spline IK chop and it work for spine twist. my solution takes 13ms to calculate the whole spine with my twist applied, 5ms of that is in making the curve for the spline IK to be placed on but the spline IK chop is like .06ms, it has speed on its side. my spine had the trick of having a twist value for the pelvis shoulders and head. But if SESI made a twist inside the spline IK chop i am shore it would be lightening quick.

My current method uses single IK chops using a the links of a spline IK chain as the goals, then applying twist to the IK chops. a bit messy but it works.

I was working on a VOP chop to add twist to the outputted Euler angles, it kinda worked, until the third bone. and it processed a vector at a time so that meant it had to process the VOP an extra 2 times. but on 4 bones it took 4 ms, i don't know how it would have scaled if it had worked.

So how are you people adding twist to spines?

[edward]

@old school: You never replied to my email as to why you can't use just use the sampled curve to drive your bone lengths. To me, that seemed like a workable solution. Of course, I haven't tried it myself.

Another solution is to evaluate the u-positions of your joints on the curve itself and then just use the distance between world space points to drive your bone lengths. I think this will solve the issue on the wiki.

@meshsmooth: I thought that the need for twist on the follow curve was no longer needed if to do "Bones from Path"? (Damn, that's what we should have called it!)

I'm not sure I agree with this fixation on having an automatic stretchy spine. But then I'm not an animator.

Speaking of spines, has anyone animated on a setup like this one?

http://www.peachpit.com/articles/article.a...102262&seqNum=4

1. Be able to move the hips of the character without changing the location or moving the shoulders, and be able to move the shoulders without changing the position of the hips.

2. Still be able to grab a control and rotate it in any direction. It should intuitively rotate the character's back hierarchically as if it were a simple FK joint hierarchy.

3. Be able to grab the same character control and translate it, and intuitively translate the character's spine like a spline IK setup.

4.Be able to compress and stretch uniformly between vertebrae when the controls are animated.

5.Be controlled by a minimal number of control joints, yet still allow for a large number of actual spine joints.

6.Be stable, predictable, and production-worthy. It should not use some forced mathematical function to compute secondary motion that will make the animator "fight" with the motion.

[meshsmooth]

I'm not sure I agree with this fixation on having an automatic stretchy spine. But then I'm not an animator.

I am no fan of a stretchy spine. unless you specifically set it a spine should stay the same length. If you want a bit of toony stretching that comes after having a spine that can keep its length, in my book.

I don't see how creating the bones with "Bones from Path" results in you being able to control / animate the twist of the spine?

[edward]

You can rotate the RZ of the PathCV objects.

[meshsmooth]

I never knew that the parameters "initial_twist" and "twist" factor into the solver.

now i can pull them into my solution. i find this out after only I "finish" my spine solver.

[old school]

@old school: You never replied to my email as to why you can't use just use the sampled curve to drive your bone lengths. To me, that seemed like a workable solution. Of course, I haven't tried it myself.

Yes we did try this. The original bezier curve unsampled was fed in to the IK solution to drive the bones. The curve was then carved and resampled to give us two bone lengths (lumbar region and thorax region) with even subdivisions of the two different curves. We then used the subdivided segment length to drive each bone length on a 1 to 1 basis.

Fine in theory but breaks down when the underlying bezier curve undergoes extreme bends. The last bone would loose it's orientation and point wildly in to space on some frames during playback. I personally thought that the extreme bending cases were exceptional but was troublesome to some others.

This case was sent on to R&D. It may be that we are fighting with the arc length value precison?

[edward]

Here's an example file. I can't seem to find anything wrong with technique. The only gotcha was that you need to be careful as the InverseKin CHOP will always use the display sop of your path object so you need to make sure you set that up correctly.

Note that I've taken the rather slow way of computing the lengths. A better way is probably to write a VEX SOP to do it.

bone_stretch_path.zip