[3DSMax] Rigging bendy things, blendshapes and bones in tandem?

Raxastake

Hello polycounters. Here's a situation I'm not sure how to deal with,
I have a tube that I'd like rigged to a lot of bones so that it's nice and flexible, and I want it to have a sheath around it that uses a blendshape to scrunch down along the tube's length, but I'm unsure of how to get the sheath blending along with the tube. I tried using a skin wrap modifier above the morpher, it works nicely for the bendiness but it nullifies the morpher entirely

Any ideas?

Note: I'd like the tube to be part of a larger mesh that's got a regular skin modifier, I don't want any fuxery to get in the way of that


(Before you ask, yes, this represents a penis)

poopipe

Convert the skin wrap to skin, then it won't argue with the morpher

Raxastake

That gives the same result as not using a skin wrap at all and just diving straight in with a skin modifier, which is a complete no-go because the sheath mesh moves far enough in the morph that the bones it'd be skinned to are way further along the tube and it'd get completely the wrong posing, like so:

poopipe

Yes, of course..

Assuming this is for game export I think you're going to need to ditch the blendshape and use a load of  bones to deform it. 
You'll probably want to arrange them in a series of rings and constrain their movement to a spline driven by the shape the shaft bones take. 

You should at least be able to bake animation out that way - I'm not sure if ue4/unity will support that sort of thing as a procedural animation. 

Raxastake

This isn't for game export, everything stays inside Max until its rendered. I really don't want to rig hundreds of bones to replace the blendshape, because it doesn't make the situation any better. Either the sheath bones are part of the hierarchy, and end up exactly like that 2nd gif, or they're not and end up exactly like the first gif. In either case, I'd have to animate hundreds of bones, or counter-animate hundreds of bones.

Eric Chadwick

Why not just bind it to the same bones, using Skin. Then put a Morpher under the Skin.

Raxastake

I had tried that, skinning the blend targets before but it gave wacky results. Tried again just now with the final morpher above the skin modifier and it works!
Steps:

1. Skin base sheath
2. Skin each sheath blend target, (need lots of intermediates but that's fine, I was planning lots anyway)
3. Add a morpher to the base sheath and pop in the blend targets

Friggin awesome:

Eric Chadwick

Actually you want the Morpher under the Skin, so the bone deformation occurs after.



I feel a little dirty after doing this.

Raxastake

I dunno what to tell you, when I put the morpher under the skin, it freaks the heck out, but looks fine when it's above it. Why are we getting different results here?

Eric Chadwick

Probably because you added the targets while it was above Skin. Delete the Morpher, click the Editable Poly, add a new Morpher, add your targets... should work.

Here's a zip file in case it helps, Max 2018.

poopipe

You wouldn't need to counter animate anything if it was rigged right.

I'm slightly surprised Eric's fix works - it probably won't if you make explicit vert to bone assignments (now I think about it, that's why the skin wrap doesn't)  but I can see how it would if you use envelopes. 

Raxastake

Oh I see, you've skinned this to a spline instead of to bones. That's why we're seeing different results.
I've never skinned to a spline before, seems like a simpler way to get a smooth shape than a bunch of bones, but as a drawback of having less control (I can't see any obvious way to affect the twist like with a path deform modifier has?)

monster

Eric Chadwick said:

I feel a little dirty after doing this.

It's so lifelike. Did you you use reference?

Eric Chadwick

Wheee I can do 3d porn!

throttlekitty

Splines or Bones, that shouldn't be a difference, right? It's still a matter of deformation order?

I don't know why I'm so amused at your pr0n, Eric.

Obscura

Depending on the output, you should consider a vertex shader friendly one. I know you are currently struggling with making any correct output.

Eric Chadwick

Raxastake said:

This isn't for game export, everything stays inside Max until its rendered. 

Obscura

Right. Have fun then

Raxastake

I'm such a fool for not testing this earlier, but I've run headfirst into a massive problem!

For a morpher channel that uses more than a single target, the second-onwards use the current scene playhead's frame for evaluating their skin, regardless of which frame is currently being rendered. So if the playhead is at frame 5 and we're rendering frame 30, the base mesh and first morph target are deformed to wherever frame 30's bones are, but the second morph target onwards uses wherever the bones were at frame 5.
This makes rendering an animation using this technique somewhat.... difficult...

Here's a nice gif of the rendered output (viewport gif is earlier in the thread):

As you can see, the skin from the base mesh and the first morph target in the list work absolutely perfectly, but the second target in the list onwards (my real-world case has a dozen, this example case has three) evaluate frame 0's position.

Since the viewport and the render disagree I can only assume it's a bug

Anyone got any ideas how I can work around this?
NinjaEdit: Using a Point Cache modifier does not work, the cache is the same as the render

musashidan

Have baked all the weights in the Skin mod?  If your morpher changed the shape of the base mesh enough then the mesh may have passed outside one of the envelopes. You can find the 'Bake selected verts' button(looks like an oven) under Weight Properties.

Raxastake

I don't really use envelopes when skinning, so they're all already baked, but I double checked and baking has no effect

Mark Dygert

I came here just for Eric's porn... carry on.

Alright, alright, alright I'll help out.
Eric is right it's an order of operations issue. Morphers should go under skin, that's how it's always worked. Since the beginning of time... forever... ever ever ever... (echo echo echo)

What do your morphers look like? They shouldn't bend or wobble side to side, they just goes up and down, squash and stretch. Any bending or lateral movement will push the verts past the skin deformation and off the model.

It sounds like what you might want to use are joint angle deformers, they are part of the skin modifier, under the Gizmos rollout.

They blend specific morphs based on the angle of the joints so you get specific morphs turning on only when specific joints bend a certain way. Typically they are used as "corrective shapes" around problematic areas like shoulders, hips, elbows and knees, to give shape to those joints in extreme poses where the skinning can't do everything you need it to to hold the shape. They can also be used to drive muscles flexing and clothing wrinkles either through a dense mesh or, if you pair it with a wrinkle map blend. They even get used for some secondary giggle motion.
https://www.youtube.com/watch?v=5rX8i-ZKdsQ


Also, engines like Unreal support morphs/blendshapes and while the tools are still relatively new and in need of some work they do a lot of impressive work.

"725 blendshapes across 10 meshes"
https://youtu.be/_OuCrbwEJW4?t=40m19s

musashidan

There's also the Skin Morpher modifier. Works like 'corrective shapes' as well.

Raxastake

Mark Dygert said:

Eric is right it's an order of operations issue. Morphers should go under skin, that's how it's always worked. Since the beginning of time... forever... ever ever ever... (echo echo echo)

I really want to dig down into this, because it's been said a few times and it seems very counter to what I'm experiencing

The verts move so far in the morph that a skin above can't do nice deformation. The verts get separated from their original bone by a long way. I need a situation where the skinning updates as the morph does

Giving every morph target a skin, and putting the morpher above the base's skin means all of the morphs are moving with the bones all the time, then sing 'Automatically reload targets' the morpher is always blending between correctly positioned morph targets.

The only part of this that doesn't work is evaluation when rendering a sequence. Because I can render any single frame correctly, I feel like the solution I'm looking for maybe uses MaxScript to force evaluation to update between frames. Or perhaps caches the mesh deformation prior to rendering.

monster

I think your observation earlier was correct. It works if you skin to a spline, but not to bones.

Mark Dygert

It works in 3dsmax 2017 with biped. Abandon all hope for bones tho... 
(This arm motion feels oddly appropriate for this thread...)
 
They've royally screwed up bones in newer versions of 3dsmax, at least 2017 and 2018. It does the same thing you guys are running into.

EDIT: I just tried it out in 2019 and it works with bones. Upgrade to the latest version.

EDIT2: It's not working...
Or... wildly inconsistent. It's weird, on some shapes like "fat" it plays along fine, but then on others it pops to an odd shape as soon as it hits 100 or slides off over time. If I recreate it, I get weird results. The problems seem to amplify if I mess with the shapes after they've been added to the morpher.



I usually didn't move the verts around this much, especially not past a joint onto another. Usually they just get nudged around a little.

Thank goodness i use Maya to animate, this stuff isn't broken in Maya, of course it's broken in a bunch of other ways... Blender and Modo are looking pretty attractive now, because Autodesk charges insane prices for broken buggy software.

Mark Dygert

So... This actually makes sense. The verts are still being affected by the joint that they where bound to, moving them so far away from where they where bound is going to make for all kinds of whacky transformations. There still could be some weird issues going on because the results are unpredictable but you can't move a vert into another bones "air space" and expect it to obey that bone, skinning isn't dynamic like that.

You might be able to do something with a FFD cage? But that seems, janky.

I was giving this some thought and I don't think I would handle this with just a single set of bones and morphs. You would probably have to rig the outter tube and inner separately to their own bone structures and constrain or pathdeform them to a driver object, something like a spline with splineIK might work or the bones of the inner tube. 

You animate the driver which controls both of the tubes, and then you animate the position of the outer tube to slip up and down the driver object.

Raxastake

Thanks for looking into that further Mark.
I've been looking into MaxScript to force correct evaluation and this seems to work.

I can set everything up using the normal render settings dialogue and instead of pressing render there, I run this script. It'll run the range specified in render settings. There's no nice time estimate window, but I'm sure if I really wanted I could figure that out

--// assign a bitmap to prevent creation of N bitmaps in memory
tex = bitmap 

--// default to defined range
startFrame = rendStart
endFrame = rendEnd

--// use active time segment if that's selected instead
if rendTimeType = 2 do (
	startFrame = animationRange.start
	endFrame = animationRange.end
)
	
for frame = startFrame to endFrame  do (
	
	-- filename prep
	framePath = rendOutputFilename
	framePath = trimRight framePath ".png"
	
	frameString = frame as string
	if (frame < 1000) do ( 
		frameString = "0" + frameString 
	)
	if (frame < 100) do ( 
		frameString = "0" + frameString 
	)
	if (frame < 10) do ( 
		frameString = "0" + frameString 
	)

	
	sliderTime = frame
	tex = render outputFile:(framePath + frameString +".png") vfb:false
)

musashidan

@Raxastake so just to clarify: you have your rig set up and working correctly in the viewport, but when rendered(without having to hack the render) the rig breaks?

Raxastake

Yes. That is correct. Now with the rendering script, the render matches the viewport

musashidan

That's weird. Any idea why?

Raxastake

My guess is that it's a bug in the morpher modifier as the 1st morph target seems to work but 2nd and beyond don't.
There may be a solution in splitting the multi-target morph channel into multiple single target channels and wiring them up to a single spinner with some math, but honestly replacing my render button with that script is simpler.

musashidan

It seems that the more bloated Max gets the more broken the legacy features become. Must be an absolute nightmare for the Max/Maya devs working on such behemoths, bloated to the gills with decades of code.

Glad you got it sorted. I did set up a test myself using CAT, but I pretty much got the same results as everyone else.

Raxastake

Guess who didn't check if their fix for rendering also worked for fluid sim collisions >_________<

EDIT: Ok, so since it's only the 2nd morph and beyond, I separated out the 3 targets into 3 channels and that allows the whole system to work. It more than triples the animation work required though so I'll write some MaxScript when I'm not so tired that will put all the separate channels back into one spinner

monster

Raxastake said:

...fluid sim collisions...

I don't even want to know what kind of fluid.

Raxastake said:

Guess who didn't check if their fix for rendering also worked for fluid sim collisions >_________<

...I separated out the 3 targets into 3 channels and that allows the whole system to work. It more than triples the animation work...

You can use a wire parameter to each channel so that it works similar to a progressive morph. I have to do that often because game engines don't support progressive morphing.

Raxastake

I did go down that route @monster, have a nice little script that hooks it all up.
Aaaand it's still not really an effective solution. (modifiers above the morpher were causing issues this time)

But I did finally find something that's working nicely. Point Cache modifiers were, like renders and fluid sims, only using the current frame's data. But by creating a point cache for every frame individually with a script, then doing a quick edit to the XML I was able to get the point cache modifier working exactly as it ought to. I like this solution because it means I can just animate to what I see in the viewport, then when it's all done, cache it out and forget all this struggle ever happened.