Full IK and Unity (mini-rant)

Just wanted to share this here.

I mentioned previously wanting to setup a fullbody IK character.

Here's how it went.

* me: "Looks like BioIK is going to be useful for this."
* me (-$20):"Well, this didn't work out. What a mess"
* me (-$10): "why did I grab dynamic bones? Right it was on sale..."
* me:"I don't like pricetag on FinalIK"
* me:"Let's roll custom solution."
* me:"Let's check out FABRIK again."
* me:"Oh, this is awesome. Reminds me of the way ragdolls worked in Hitman 1/2/3"
* me:"Well, I have a single chain working, can upgrade to multichain, I guess, then add constraints"
* me:"How the heck is this supposed to work with twist?"
* me: "Huh. 1-4 iterations to solve the pose, with OCCASIONAL spike to a hundred?"
* me: "Oh those guys evaluated it for mocap data reconstruction. Huh, lots of problems, apparently"
* me:"Oh, someone talks about improved version of CCD and has a robot arm demo"
* me: *clicks random related link online*
* WEB: "Here's the node for setting up full ik solver in unreal 4. Already ready to use"
* WEB: "Oh, and it uses Jacobian dampened transform, which would be a pain to write"
* WEB: "But we also have Fabrik node you wrote. Also ready to use".
* WEB: "Oh and remember thinking about destructive terrain? We now have 3 different components for procedural geometry, and one of them supports collosal meshes via OctTrees. ".
* WEB: "Oh, and remember thinking about giving polygonal booleans a whirl? Here's how you can do it now. And here's a tutorial."
* me:

Spoiler

* WEB: "Oh, and that dynamic bones thing? We have this built in"

I mean, I'm not proposing anything. I'm not even angry, as the situation is hilarious. Reminds me of the time where I spent ton of time studying game engine programming, only to meet unity and realize that 6 months of work can be done in a few hours with it ("you thought your studying was useful? Hold my beer").

The feeling is similar.

 

Honestly this sort of thing would be a lot more funny to me if this wasn't the same place I ended up in three different contexts this week.

 

So the question to OP is, why none of the approaches worked for you?
Did you put enough of effort into any of these?
I was playing and actually made project with bioIK before. I wrote recently fabric IK solver for DOTS, still experimenting with.
But these will require a bit time, to set correctly. Some less, other more.
IK can be intimidating.
Depending how much familiar are you with IK, besides the knowing it exists and what can be used for.

 

BioIK is unusable on a humanoid rig with fingers. Partly due to horrible ui design (probably the worst I've ever seen), and partly due to it being pretty much uncontrollable. It also hasn't been supported for past two years or so.

It would perfectly work on a robot arm, yes. But not on a humanoid char.

Eh, what kind of question is that?
Implementing fabrik is not an issue, as it is neither difficult nor requires dots. I mean, it is trivially easy.

The fun part is trying paid solution, not liking it, implementing your own, and half way running into "Hey, psst! We have all of this implemented for free, along with things you only wanted to try implementing one day! How's that?"

That's hilarious.

 

My intention wasn't to be smirky. My point was, any of these have humanoid solutions. That why I also asked, why they didn't worked in your case.

Granted, for robotics works marvels.

There is also character solution, which I did quite like it. But you got valid point on fingers, if you indeed need them.

I think this project was running for the duration, while author was at the academia. Still, is mostly c# code, so should work in future as well.

I probably miss read / miss interpret that sentence last night. So my apology.

 

Final IK is nice though since it's implemented in C# and with mono being Mono jt doesn't scale all that well.

 

My Issue with BioIK is that it can't really be controlled, and if you slap it onto a character you'll have no idea what it is going to do. It will reach the target, even multiple targets, but it is going to twist the character in a weird way, and to fix that you'll need to slap more constraints, which requires dealing with awful UI.

Example. Start pose:

Spoiler

Here's the solution BioIK solver arrives at:

Spoiler

Unwanted torso twist.

If I kill two elbow target constraints, back straightener, head straightener constraint I added in order to "encourage" the character to retain sane posture....

Spoiler

There's no torso twist now, but the char is leaning back and isn't holding balance.

If you restart the scene, you might get a completely different pose.

Spoiler

Hilarity ensues if you start moving targets.

Spoiler

UI also does poor job displaying rotation limits and they frequently do not match actual orientation of the bones. Because configuration is done through custom UI, you can't quickly copy-paste them. The UI is awful.

But like I said, it will do wonders if you're trying to control some six axis arm.

Yup, the dude pretty much abandoned it once he was out of the university/whatever it was.

The thing is, if the code was under MIT, it could've been adapted or altered into a more sane state with better ui, but it is proprietary.

No harm done.

 

@Antypodish ( I hit the picture limit).

In comparison to BioIK unfinished single chain FABRIK solution:

Spoiler

Does perfect job always reaching the same solution from the same starting pose. You can also predict what it is going to do.

Actually it seems to be behaving quite well, if rather than reusing previous pose from previous frame you start over from the initail pose every time. Then it acts as a "springy IK" of sorts.

It is also ridiculously easy to understand, because it is a particle system, pretty much.

The problem with it is that it is unclear what the heck am I supposed to do with chain of twisting elements, as FABRIK operates on points and sticks, and doesn't deal with twist at all. Also it acts in interesting way if you reuse previous frame data and do not start over every time.

Spoiler

In this case it acts as if you're trying to drag a shoelace through some sort of jello by pulling at its end.

 

have been using SAFullBodyIK which worked relatively well

but don't know about fingers and if other issues come up

 

Still you are here looking for alternative solutions it didn't take 6 months active development time.

I can recommend final IK if you only have a dozen active at any given time. It has finger IK, obviously since we use that. Though only on first person rig so only one set of fingerik at any given time.

 

Things didn't go your way and you're trying to abscond, as usual. "Stir S*** up, and then ask everyone not to steer S*** up". Good job.

You need to heed your own advice. The one derailing the threads is you. The one mocking people and behaving poorly is you. You six month trigger pull is a royal screwup on your hand, and it is something you'll carry to your grave, as people will never forget it and will keep bringing it up to rub it in. It is a memetic level mistake worthy of Guiness book of records.

In all honesty, you should've behaved in polite and civil manner. The benefit of doubt has been given to you and you squandered it.

So now, reap what you sow.

It doesn't matter what title and experience you claim to have, your progress on your project clearly indicates that you're unable to afford development of side projects by yourself.

Your trigger pull fiasco has following possible explanations:
* You are incompetent and waste inordinate amount of time on ordinary things.
* You have zero time, and could only find 2 hours to finish the feature in 6 months time. That's why it took so long.
* Mix of #1 and #2.

Pick one you like.

All of the three are solved by hiring a subcontractor. Or several.
----------

P.S. And now we're going to wait until moderators nuke this thread too.

 

Guys please, no battling again
I don't want this thread to be closed.


@neginfinity thank you for comprehensive description.
Ia am just trying to recall, how I solved twisting in robotic arm, similar as you had twisting in torso.
But probably as you mentioned, it was constrain settings.

I agree regarding BioIK UI. It is generated based on bones chierarchy, if remember correctly.
And for 7DoF was already a bit pain.

With fabric is true, there is no twist co train. And that may be an issue in certain cases. For. Y need using poles does works.

But if you try to makesomething like spike ball on the chain, with rotating ball, hmm that is a bit of a challange. I suppose, it would require additional code, which chains twist rotatation along the chierarchy.

Do you think this may be feasible in your case scenario?

 

I'd rather not see it closed either, hopefully mods will just cut some messages and not axe the whole thing as they often do.

There was a reddit thread mentioning a replacement algorithm dubbed CCD-IK.
https://www.reddit.com/r/robotics/comments/6paxf7/this_is_the_simplest_inverse_kinematics_solution/
That could've been something custom and had a live demo here:
https://makeshifted.itch.io/dexter-arm-ik

But I think it is usual cyclical descent with its usual weaknesses.

Yup. And with a full character with fingers it is torture. Especially when you need to setup numerous constraints, and rotation limits aren't displayed properly.

Fabrik paper used this kind of thing for humanoids.

Spoiler

Here is a more advanced setup used for IK-based mocap reconstruction.

Spoiler

Basically, here they, as far as I can tell, maintain relative positions of the markers, and have marker groups act as solid objects.

Spoiler

In this scenario it starts resembling early implementation of rigid body physics where rigid body objects were implemented as physical particles connected with infinitely stiff springs. This is similar to hitman 1/2/3 ragdolls, which were very cheap, because ragdolls were also implemented as particles.

So, I guess in case of modeling proper twist on a long chain, I'd need to implement a relatively complex system of points that woukd force a part to twist.

Another possibility would be to use the idea of fabrik (iteratively pulling parts one after another while adjusting their orientation), and isntead of usual points use "oriented points" which also store their rotation. But here things will get hairy, and the result might not be as intuitive as the original fabrik algorithm.

 

I'll be likely moving the IK experiment to Unreal Engine.

After partially implementing FABRIK and then encountering "Hey, we have this thing implemented", I barely have any motivation to continue messing with custom IK.

It is fun to program, but feels like it might be an "Amazingly Interesting Problem (tm)", meaning a timewaster.

https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/ControlRig/index.html

 

I assume, you are open for an option, of moving into Unreal entirely?

 

Probably not entirely. There are some existing obligations and clients tied to unity. So it'll stay as a part of toolbox.

I originally was a C++ programmer, you know?

However, because unity offers insane prototyping speed, I started using it. At that time unreal wasn't even free yet, and when it became free it was a mess.

Now the situation with the IK reminds me of the moment when I first managed to quickly build a demo in unity that would've taken months of developing from scratch in C++ (it was a "This is an important lesson" moment). It is worth keeping in mind that the difficulty is not the same, as it would likely take a day of dedicating coding to implement a FABRIK solver from nothing vs spending months writing collision system and (potentially - if you're feeling stubborn and want to make your own everything) physics engine from scratch.

But there's definitely a feeling of a missing important feature there, on unity side. Implementing it is not impossible, and it would be a wicked fun, but having fun does not mean getting things done.

I gotta add, Unreal still gives a very messy feeling when you use it. I managed to find an unfixed minor glitch on the first try, and there was that amazing moment when it decided to weld surface normals in a low poly model upon import, destroying sharp edges in the process and making the model smooth.
Then again, I guess each engine has their own strong and weak sides.

The current idea is to try messing with control rig, once I get to it.

 

@neginfinity I havent been following the entire thread but if you are trying out Control Rig in Unreal, also take a look at Power IK in Unreal : https://www.unrealengine.com/marketplace/en-US/product/power-ik

Its been a really great learning sample for me in conjunction with usage of Control Rig

 

Well, here we go. Pretty much exact thing I wanted to implement. For free.

Spoiler

I'll check it out. Definitely.

 

After watching that video, care to explain what exactly is PowerIK doing that Unity default procedural tools cannot achieve?

 

This thread just boils down to Unreal vs Unity which is not really a productive conversation. Both engines have pros and cons, go use whatever works best for your situation.

 

Well.

Apparently Unity does awful job advertising what functionality is available in it. Which is probably a side effect of introducing package manager and fragmenting the engine into packages.

https://docs.unity3d.com/Packages/com.unity.animation.rigging@1.1/manual/index.html

Also, animated images fail to play completely there.

People looking for IK will end up at "FinalIK" page, and people looking for "floppy" semi-procedural movement will end up on DynamicBones asset store page which gives impression that such feature is not built into the engine.

-------
Getting back to your question, ControlRig allows more precise control over what's getting overriden and in which order through animation blueprints, meaning an interface similar to animatorcontroller. The contents of "animation rigging" seem to be monobehavior based, meaning at some point things may get hairy if you try to do more complex chaining effects.

No, there's information exchange going on, which, as far as I can tell, so far is useful.

 

This is about a specific failing of Unity that has a lot of broad scale implications and has existed for some time, while an alternative exists in a competing product. It is entirely reasonable to interrogate this from both the angles of "why doesn't Unity have this option outside of a $90 paid asset when it exists in a competitor for free" and "why are the offerings for Unity so poor to begin with?"

 

<Sarcasm Mode On> But surely DOTS can solve this data problem for you with just a few Systems and some SIMD code you could write your own bespoke IK system from scratch <Sacrasm Mode Off>

Is there a DOTS IK system in the works, maybe as part of the DOTS Physics system?

 

We don't even have skinned mesh support on that front.

 

Still, I thought there was early animation demos using DOTS and specialised shaders, surely they should have been made into a clean/user friendly solution by now?

 

If you talking about old DOTS based on shader solution, it uses prebaked textures for animations. Hence it is not suitable for IK applications.

On other hand, DOTS have animation package, but is stil in early works and leaves plenty to wish for.
However, this solution is not suitable for +10k characters, with complex bones structure.

Most likely none of these are suitable for OP use case.

 

You're just not a true Unity fanboy like us...

However, it does have the usual Unity issue of not handling use-cases that I've seen in games since 2003. I have found it difficult to make a character both aim and look at a target, while twisting their torso, due to the additive rotation. The head will end up looking somewhere completely different. Maybe there's a solution, but I wasn't able to figure it out.

 

Use Headlook to LookAt the target and for a pistol you can align the shoulder joint and wrist IK goal along the target vector. If you do this you can twist the torso any which way you choose.