"Baking" mesh animation based on hooks/constraints?

[Orum]

I have a set of deployable solar panels similar to the stock 1x6 panels, with rigged animation and all that goodness. This imports into Unity just fine. The problem, however, is the mesh collider I'm trying to use to approximate the panels in both compacted and deployed states, and everything in between. It's essentially a bounding box that I've tied to to the rig via an ugly mess of empties, hooks, constraints, and parenting (empties to the rig).

This mesh deforms just fine within Blender, but as soon as I import into Unity, nothing happens. "Ah," thought I, naïvely, "I'll just bake the animation and that will solve all my problems!" Unfortunately, since the animation of a mesh is not the same as object animation, and it's not tied to simple editing of the object's transform, this doesn't seem to work within Blender. So, is there some way to bake the animation on a mesh-level instead of an object level?

I'm open to other ways of doing this as well, if you think this is the wrong way to approach the problem.

[lo-fi]

Can't you just animate the vertexes movement directly in blender to enlarge the box as the panel deploys? I use 3D studio myself, but that would be my approach.

You could set up a skinned mesh, of course, but I can't think of a way to make that work in Unity.

[Orum]

Can't you just animate the vertexes movement directly in blender to enlarge the box as the panel deploys?

Whether I do it via the vertices directly or object scaling and movement, both have the same issue--tracking the expansion of the panels. Though it makes a sine-ish shaped curve, even playing with the bezier handles and keying at both ends I couldn't get it anywhere close to the motion of the rig. To truly track it well over 180 frames requires an immense amount of keyframes, and calculating and entering the variables by hand is unbelievably tedious. I thought I could do it with a Python script, but Python makes Malbolge look like an easy language to script in, and more often than not I ended up doing horrible and essentially irreversible (if not for reverting to a save) damage to the mesh.

[nli2work]

split the panels out to individual pieces and link them in a chain. skinned mesh colliders don't work in Unity AFAIK. I don't think blendshapes works for colliders either. Closest thing I've seen to what I think you are trying to do are the procedural wing/tank plugins like pWings by DYJ or B9.

if you want a smooth unfurling motion you can animate them in max using spline IK or wire paramters, and bake the frames down, then apply box/mesh collider to each panel in Unity. You can use frame reduction in Unity to lighten up the animation clip a bit. or do it in Max before exporting.

[Orum]

split the panels out to individual pieces and link them in a chain.

This is already working, as I said in the first post. The problem is just with the collider.

skinned mesh colliders don't work in Unity AFAIK. I don't think blendshapes works for colliders either. Closest thing I've seen to what I think you are trying to do are the procedural wing/tank plugins like pWings by DYJ or B9.

It's not, strictly speaking, a skinned mesh collider, as it's just moving hooks around based on empties, though the empties are linked to the bones. Here's an example frame part-way through the animation, with empties visible:

I don't think pWing's is the proper analog as it has no animation of the colliders. Anything using "ModuleDeployableSolarPanel" should be much closer to my needs, but the only ones I know of are of course in mu format, and the blender mu plugin will not load animation

if you want a smooth unfurling motion you can animate them in max using spline IK or wire paramters, and bake the frames down, then apply box/mesh collider to each panel in Unity.

As I said, the panels are already unfoolding smoothly, and while the bounding box is "smooth", it's still not something I can approximate without a huge number of keyframes. And baking the animation is the whole problem, as it doesn't seem possible to bake a mesh animation in blender. As for "max", are you referring to 3ds max? Because, I don't own that and have no plans on buying it, as I just can't justify it with the small number of parts I've made/plan on making, and having to spend the time to learn a new 3D modeling program.

Lastly, as for using a collider for each individual part linked the rig, I don't think that's an option performance-wise. Right now with a bounding box I'd have a total of 92 tris for the colliders alone (for the entire part; already pretty high), and if I went to per-piece I'd have 308 tris.

Edited March 16, 2015 by Orum

[lo-fi]

You're way over thinking this, I think. Does it really matter if the collider doesn't perfectly match the panel for the whole extension animation? I understand your reasoning, but really an approximation is fine, and nobody is going to notice a small difference while playing the game.

[nli2work]

I misread earlier posts and thought you were using max as well.

split the panels out to individual pieces and link them in a chain. then apply box/mesh collider to each panel in Unity. a collider that changes shape don't work in Unity AFAIK, and definitely don't work in KSP. There's nothing in KSP that has collider boxes that changes shape in Flight mode. the only ones that allows it are the mods I mentioned, and they only work in Editor mode where there's no physics.

primitive colliders are very cheap, use those unless your panels are trapazoidal or 5+gon shaped. If you have 90+ colliders you might need to reconsider the design. but if I read correctly you have half a dozen total of few hundred triangles. not a performance issue. If the panels use box colliders that's less than 50 triangles total between 7 colliders, that's nothing really.

Edited March 16, 2015 by nli2work

[Orum]

a collider that changes shape don't work in Unity AFAIK, and definitely don't work in KSP. There's nothing in KSP that has collider boxes that changes shape in Flight mode. the only ones that allows it are the mods I mentioned, and they only work in Editor mode where there's no physics.

I know this isn't true, and I've verified it experimentally with another part I created recently. Mesh colliders I created & animated (via scale) in Blender imported into Unity worked just fine.

primitive colliders are very cheap, use those unless your panels are trapazoidal or 5+gon shaped. If you have 90+ colliders you might need to reconsider the design. but if I read correctly you have half a dozen total of few hundred triangles. not a performance issue. If the panels use box colliders that's less than 50 triangles total between 7 colliders, that's nothing really.

Yeah, the main issue with primitive colliders is they have to be created in unity, and can't be done in blender.

You're way over thinking this, I think. Does it really matter if the collider doesn't perfectly match the panel for the whole extension animation? I understand your reasoning, but really an approximation is fine, and nobody is going to notice a small difference while playing the game.

No, but I'd certainly like it to be as good as possible, given that it's already an approximation. An approximation of an approximation can start to really show. I did find someone on IRC though who was willing to help with scripting this in blender, and using only scaling/translation (which unity can import) and keying every single frame. Ugly, but there's no other way to it Blender and have it import correctly into Unity.

[nli2work]

I think you are confusing mesh collider and skinned mesh. mesh colliders don't scale, much less animate as skinned mesh, in Unity4. if you wanted to scale a collision mesh, you have to export a new mesh with the scale changed baked in to use as a collision mesh. Unity5 supports collision mesh scaling with new physx implementation, but KSP won't be on Unity 5 for a while. You can animate some mesh in Blender and import to Unity 4, but whatever it is, it won't work as a collision mesh.

Skinned mesh will work in Unity4 and KSP. Skinned mesh has a bounding box, that appear similar to a collision mesh, but isn't a collision mesh. it's only for checking visibility in relation to camera frustum.

Squad's solar panels are simple heirarchy chains with panels as separate objects. each panel has it's own box collider. if your panels are odd shapes, then use a mesh collider, otherwise use primitive colliders.

Edited March 18, 2015 by nli2work

[Orum]

I think you are confusing mesh collider and skinned mesh. mesh colliders don't scale, much less animate as skinned mesh, in Unity4. if you wanted to scale a collision mesh, you have to export a new mesh with the scale changed baked in to use as a collision mesh. Unity5 supports collision mesh scaling with new physx implementation, but KSP won't be on Unity 5 for a while. You can animate some mesh in Blender and import to Unity 4, but whatever it is, it won't work as a collision mesh.

No, this just isn't true. Here's an example (an "iris" style door) as proof, in Blender first, with colliders visible:

And then in Unity 4, again with colliders visible:

And finally in game, first with doors closed, Jeb standing on top:

...And falling through as the door opens:

[nli2work]

I am wrong, thanks for the pics. I assume the shutter blades have mesh colliders? I think there is still a performance cost to do it based on this "In Unity 5.0 we’ve reduced the cost of scaling Mesh Colliders. Previously, when scaling a Mesh Collider, you would have to create a new mesh with scale baked into the vertices, and that required valuable time and memory. With PhysX3 we are able to support non-negative scaling without any baking. It’s basically free."

The same does not work for

nor

; which is what I think you are attempting to do from the OP.

nevertheless, based on how your solar panel part appears to work, separate objects with box colliders is the best way to go performance and setup complexity wise. if your solar panel works like the shutter, then rotating and/or scaling colliders would certainly work better.

Edited March 22, 2015 by nli2work

[Orum]

I assume the shutter blades have mesh colliders? I think there is still a performance cost to do it based on this "In Unity 5.0 we’ve reduced the cost of scaling Mesh Colliders. Previously, when scaling a Mesh Collider, you would have to create a new mesh with scale baked into the vertices, and that required valuable time and memory. With PhysX3 we are able to support non-negative scaling without any baking. It’s basically free."

Yes, I think this may at least be due to how animation is imported into Unity ("Legacy" mode), though I'm unsure if this is a Unity or a KSP/.mu requirement (but I generally assume the latter as the other import methods appear to work in Unity as far as I can tell).

EDIT: I also think it's worth noting that I would have liked to use true "Box" colliders from within Unity, but matching the opening of the iris is harder to do there compared to just doing an animated mesh in blender. Yes, it's probably less efficient than doing box colliders, but I have even less success at scripting things in Unity compared to blender, and it's as simple as adding two key-frames in blender and it matches the blades of the door very closely.

The same does not work for

nor

; which is what I think you are attempting to do from the OP.

nevertheless, based on how your solar panel part appears to work, separate objects with box colliders is the best way to go performance and setup complexity wise. if your solar panel works like the shutter, then rotating and/or scaling colliders would certainly work better.

Right, I'm trying to get the bounding box to scale. I know it's possible via scripting, but Python is such a...unique (being as polite as possible here) language that it proves to be very difficult for me to script in it. I have an offer from someone to help but real-life obligations have kept me extremely busy as of late, and I haven't been on IRC when he is and had time to spare.

Edited March 23, 2015 by Orum

[nli2work]

well, keep us posted on your progress. I know I'm not the only one interested in seeing what you have cooking.