IKinema RunTime Indie 1.9.0 released with support for 4.19.

Hi guys,

With the release of IKinema RunTime Indie 1.9.0 and support for 4.19 we figured we should post the write up of the changes in the latest version of the plugin here to give everyone a heads up about the latest set of changes.

This patch has seen a number of bug fixes and quality of life improvements. For up to date patch notes, we keep the log here: https://ikinema.com/change-log

Our demo map has also been updated with a handful of new demos and converted to support the latest version of the plugin. You can find it here: https://www.dropbox.com/sh/18h2cfxz0…ygfAEuhza?dl=0

OK so, on to the changes.

**1) Automated Foot Placement Setup In 1.9.0 and later: **
With 4.19 we have reduced the steps needed to set up the typical foot placement behaviour significantly. Those familiar with the set up will still be familiar with the initial process which remains intact.

Select the bones you wish to be subject to foot placement logic in the IKinema rig and assign them ‘Feet Tasks’. Then when dropping the IKinema Foot Placement Node in your animation blueprint the other settings to get you up and running are automatically filled in.

2) Aiming Node and Behavior:

**Important Note: **(This is a breaking change to your project if you implemented weapon wielding using the old now deprecated handle offset method. We think the new set up is more straight forward and supports more features)

The aiming and weapon wielding behaviour support in our Foot Placement node has seen a ground up re-work. It is more responsive, featureful and simpler to implement.

Combining the new Aiming and Weapon Wielding features allows for some interesting behaviours such as modifying weapon reload or weapon switching animations based on both the aiming direction and weapon type. This is particularly useful for both first and third person scenarios in which you want to support multiple weapon types while providing fully body foot placement behaviour.

We have some cool examples of this on our demo map that I would recommend trying out if you are interested in this sort of behaviour.

For full info on the new settings exposed see the documentation here: https://ikinema.com/index.php?mod=do…how=184&id=384

We also have a tutorial that covers a set up featuring all of the below behabiours here:https://ikinema.com/index.php?mod=documentation&show=184&id=385

Generating FPS aiming animations and custom hand locations per weapon type from a single animation:

https://ikinema.com/UserFiles/tiny_files/a.gif

Aiming + Look at from a single node with minimal setup (see tutorial linked above).

https://ikinema.com/UserFiles/tiny_files/aimSplit.gif

Customize your aiming stance as you please (again, check tutorial):

https://ikinema.com/UserFiles/tiny_files/WepOverride.gif

**3) Maximum Leg Extension: **

This is little addition to the Foot Placement Node that boosts the control you have over the feet of your character.

It basically allows you to have full control over the maximum distance your characters legs will reach in order to be placed at the terrain. This works to prevent your character’s body from being pulled too far when trying to place the foot at the terrain which can result in unnatural poses. There are only three settings to take into consideration when setting up this behaviour as follows

To enable the behaviour tick the “Limit Leg Extension” bool in the “Maximum Leg Extension” section of the details panel in the Foot Placement Node.
https://i.imgur.com/6myFbWu.png

**4) Use FK Orientation on Ray Tracing Elements: **

The main use case for this setting will be quadruped foot placement where you want to the characters chest and hips to be aligned to the terrain positionally but not to follow the local rotation of the terrain (unlike feet). This way the chest and hips will move up and down with the terrain but do not rotate with the terrain. It can make a subtle difference to the overall look and feel of the animation in cases where the slope of the terrain is very slight or a big difference if the terrain slope is harsh.

If you enable the “Use FK Orientation” bool for a specific Limb Transform End effector (the ray tracing elements that are subjected to foot placement behaviour) the rotation demand for the task in question will be taken from the input animation and not the terrain.

This should be used to prevent unnatural rotation of your quadruped’s chest and hips although I am sure there are other interesting applications.

**5) Deprecated Nodes: **

Setup Task [Deprecated in favour of Setup IKinema Task]

Setup Lookat Task [Deprecated in favour of Setup IKinema Lookat Task]

We are deprecating a couple of our nodes to accommodate the quality of life changes in the 4.19 release without breaking any of your existing setups (excluding old weapon wielding behaior - keep the version of the indie plugin you are using around if you do not want to re-implement it).

The specific nodes in question are the “Set up Task” and “Setup Lookat Task” nodes which are primarily used with our generic solver or if you expose tasks in the foot placement node. When compiling animation blueprints with the old versions of the nodes, you will get a warning and notification to update to the new nodes but your existing set ups will still function.

The reasons for doing so are as follows:

**5.1) Splitting Alpha Values – Rotation and Position Alpha: **

Important note: If you are finding your look at set-ups are broken, the equivalent set up to LookAtAlpha = 1 is (RotationAlpha = 1, PositionAlpha = 0).

The first reason is that we have split the “Alpha” values into “Rotation Alpha” and “Position Alpha”. These alpha values interpolate between the position/orientation target you are passing to the solver for a particular task and the position/orientation from the input animation. This allows for full fine-grain control over the target generation. Say, for instance, that you wish to use the positional portion of the target you are passing in but want to take the orientation from the tasks bone in the input animation. To do so you would set the Position Alpha to 1 and the Orientation Alpha to 0 for that task.

**5.2) World Space Target Generation: **

The second reason is because we have streamlined the target generation work flow. Previously we expected targets to be passed into the IKinema node in component space or solver space. We find people have difficulty with solver space so the solver now expects World Space or Component Space targets instead.

For example, generating a component space target can take place as follows: Imgur: The magic of the Internet. In the new release, you can just pass your targets straight into the solver in world space like so: Imgur: The magic of the Internet. A bit smoother.

TLDR:
Change Logs here: https://ikinema.com/change-log
Updated Demo Map Here: https://www.dropbox.com/sh/18h2cfxz0…ygfAEuhza?dl=0

  1. Foot placement set up time has been reduced significantly. Set up your IKinema Rig as before. Drop the foot placement node - the relevant settings come preset
  2. Aiming/Weapon Wielding behaviour has been completely reworked. Enable “AimWithWeapon” in the foot placement node and drop a “Setup Aiming Task” node to access the new features.
  1. Max leg extenstion logic added to control the limits of how far a characters leg can be pulled when using IKinemas Foot Placement behaviour.
  2. Quadruped foot placement behavior improved with “Use FK Orientation”. Enable this on your Quad’s hips/chest if you are ray tracing from them.
  3. SetupTasks/SetupLookAtTask nodes deprecated in favour of “Setup IKinema Task”/ “Setup IKinema LookAt Task”
    5.1) Alpha value has been split into rotation/position alpha
    5.2) Can now pass targets into IKinema solver nodes in world space.

Special shout out to community member Jonas Mølgaard who provided valuable feedback and help identifying useabiity bugs leading up to this release. You can find his youtube channel here: Jonas Mølgaard - YouTube

As always, any issues, questions, comments or feedback are more than welcome.

Hi, I have a quick question. Is there a way to have rotation constraints? For example, I want the the elbow only rotates around Z-axis and only between -15° and 120°, is it possible to achieve with IKinema? I downloaded the trial version. I found “limits” section in bone properties, but the documentationsays that it’s not implemented yet?

Another thing. I have modified UE 4.19 built from source. The trial version of the project plugin don’t compile. I receive an error about IKinema module not found. Is it possible to compile it?

And yet another question. Can IKinema work with a 5 bones arm, like in the picture below (shoulder, shld.roll, elbow, elbow roll, hand) where roll bones and elbow have only 1 dof, then shoulder and hand 2 dof?

Ok , I found the answer about the limits and 5 bones myself. It all seems to work alright. Great!

Still, when I add the plugin to my project that uses source built engine it won’t compile. Error is:


1>UnrealBuildTool : error : Could not find definition for module 'IKinema' (referenced via Target -> IKinemaEditor.Build.cs)

Any help?

Hey, so our solver is full body which means it is compatible with any type of skeleton and any number of bones (performance runs ~linear with the number of bones included in the solver so that is something to keep in mind). Limits are implemented but they are intended for quite niche purposes, 99.9% of behaviours are achieved just tuning retargeting gains in the rig so you shouldn’t really need to set up limits.

Regarding the error you are seeing - Indie is not supported with source builds of the engine.

I was thinking of buying it but unfortunately I need to use a source build of the engine.
Also, I would like to know how much the full version costs before deciding to use it or not. Unfortunately the price of the full version is nowhere to be found of your website.

I mean, Indie license is limited by how much I earn from the game that uses IKinema. Rright now I sell nothing, so I’m qualified for Indie license. If tomorrow I manage to sell my game and earn more than the threshold you will come and ask to pay you some arbitrary sum of money. This is kind of scary, no? You should at least say how much it will be.

Hey Scha, for questions regarding licensing could you contact with your queries.

The same applies to me. I would also like to know if the license will change if I succeed as an indie developer with my product. I’ve just started developing a VR project, and I need your software if I want to finish my project as soon as possible.

Would you mind shooting an e-mail over to for licensing questions.