JigglePhysics solves secondary motion with verlet bones on the Unity Jobs system

The solver is verlet-based and the parameters stay between zero and one

The mechanism is described in one line in the readme, a jobs-based relativistic squash-and-stretch jiggle physics solution for transforms in Unity. Two details in that sentence matter. The solver is verlet-based, which is a position-and-constraint approach rather than a force-and-velocity integration, and it is relativistic in the sense that the drag terms account for the motion of the thing being dragged, so an elevator or a moving vehicle carries its jiggle with it instead of dragging it behind. The README also states plainly that the solver keeps its configuration parameters within zero to one, and that it is designed to be authorable rather than physically accurate. That single sentence is the most important one for setting expectations, because it tells you the tuning is a control surface an artist works with, not a simulation that has to match a reference. Every parameter in the settings list is a normalised value, which is what makes a shared prefab with overrides a viable workflow.

The Jobs system is what makes many jiggling rigs affordable

The performance claim is specific and it is tied to a specific mechanism. The addon utilizes the Unity Jobs system for performance, allowing for 600 jiggling Stanford Armadillos within fractions of a millisecond, and the readme links a video of 600 Armadillos dancing as the demonstration. The number is a claim in the project's own documentation rather than an independent measurement, but the design follows from it, since the job system lets each rig's simulation run as scheduled work across worker threads rather than on the main thread, and a scene with a crowd of characters each with several jiggling bones is exactly the workload that would otherwise serialise. The second part of the claim is that collisions work with both scene colliders and personal colliders, where all jiggle physics collide with scene colliders, so a rig can push off the world as well as off other rigs. The third is the drag separation described above.

Adding the package means a git URL, and a version tag is better

Installation is a package manager entry, and the readme is unusually candid about the weakness of the obvious way to do it. You add the repository as a package using the package manager, with the URL pointing at the upm branch, but the author notes that ideally you would want to use a real version tag like v15.0.0 in place of upm in a build system. The upm branch is a moving target that the project publishes with a git subtree push, which the Makefile shows happening in one line.. The Makefile at the root of the repository shows how the package is published, with a single deploy target that runs a git subtree push of the Packages/com.gator-dragon-games.jigglephysics directory to the upm branch on the origin remote, which is how the package stays in sync with the main repository.

That command pushes the package directory to a branch called upm on the origin remote, which is how the package stays in sync with the main repository. If the package manager route does not work, the documented fallback is to add the dependency to manifest.json.

{
  "dependencies": {
    "com.gator-dragon-games.jigglephysics": "https://github.com/naelstrof/JigglePhysics.git#upm",
  }
}

So the practical advice for a shipped project is to pin a tag, and the practical advice for a team evaluating it is to install from the branch and then check what version you actually got.

The updater prefab drives the simulation, or you can drive it yourself

The usage section explains that the package includes a JigglePhysicsUpdater prefab, that this should be included in the scene to make JiggleRigs work, and that you can alternatively call the events yourself if you want precise control over when jiggle physics simulates or applies transforms. The fallback path is documented rather than implied, since the readme says to read JiggleUpdateExample.cs to execute the jiggle jobs yourself in your own update loop. That distinction is the one a technical user will care about, because an updater in the scene means the simulation runs on its own schedule, whereas driving it yourself means you decide when the jobs are dispatched and when the transforms are written back, which is what you want if your game already has a fixed-step update or if you need the timing to line up with something else. The package also ships a JiggleColliderExample Monobehaviour showing how to add and remove colliders from a scene, and those colliders will collide with all jiggle rigs.

Prefabs and overrides are how you configure this at scale

The configuration story runs through Unity's prefab system, and this is the part of the design that makes it workable on a real project. Jiggle physics works best in tandem with the Unity Prefab system, which allows you to create settings specifically for a tail, hair or breasts shared among assets, using overrides and applying them to the whole set. You can create some basic preconfigured prefabs with the right-click create menu within the Project tab, and from there you add them to your asset and override the Root Transform slot. In other words, the settings are not a global asset-wide configuration but a prefab you instance per body part, so a character with three different hairstyles can have three different jiggle behaviours from the same rig. The readme is blunt that this is the recommended way, and the two screenshots in the usage section show the create menu and the override slot. The related settings for the rig follow, starting with Motionless Root, which ignores the root bone completely and is useful when multiple jiggled objects branch from the same root that is not intended to move, which is how hair, breasts and skirts often work.

Stiffness, stretch and soften are the three an artist actually touches

The settings list is long, and the parameters fall into groups by what they control. Stiffness is described as the core parameter, controlling how much force is applied to move the bones back to their target angle, where zero means bones can move without constraint, one half means bones are moved toward their target angle as defined by their animation or rest pose, and one means bones are moved all the way to their target animation or rest pose angle. Stretch allows bone chains to separate or crowd together to simulate squash and stretch, and it controls how much force is applied to enforce the target bone length, with its own zero, half and one descriptions relating the length target to the stiffness target. Soften is the subtle one, easing the stiffness the nearer a bone is to its rest pose, which the readme says allows breasts to move subtly more in a neutral pose without going all over the place. Excluded Transforms removes a transform and its children from the solve, and Jiggle Colliders are colliders created for one specific rig rather than global ones.

Angle limits and root stretch keep the motion inside believable limits

The second group of settings exists to stop the solver from producing results an artist would have to fix by hand. Angle Limit means that in some circumstances bones must never exceed a maximum angle offset, and the parameter prevents that, with zero meaning bones may not deviate from their rest angle at all, half allowing a deviation of up to 45 degrees and one allowing up to 90 degrees. Angle Limit Soften exists because hitting an angle limit hard looks wrong, and it softens the correction so that a bone is corrected only partially each simulation step rather than snapping. Root Stretch allows the root bone to move away from its pose position on a simple spring joint, where zero allows no root movement at all and half means the root bone may move freely and is pulled back to its rest position by a spring constraint. Drag is mechanical friction slowing the motion of bones in local space, and Air Drag is specifically drag from moving through space, used to cause the transforms to be pulled behind world space motion. Separating the two is what makes an elevator or a vehicle behave as the readme says it should.

Where JigglePhysics is the wrong choice

The first wrong case is a project that needs cloth simulation rather than authored jiggle. The readme says it plainly, that the solver is designed to be authorable rather than physically accurate, and if your requirement is that a cape drapes correctly against wind and a moving character, a verlet-based secondary motion solver with normalised artist parameters is the wrong instrument even though it is called verlet internally. The second wrong case is a project whose characters must respond to physics contacts in a way a real cloth solver would, since the collider interaction here is a simplification that responds to scene and personal colliders rather than to a full simulation. The third is a team with a strict supply chain, because the recommended install is a git URL pointing at a branch, and the author himself suggests pinning a tag instead, so the package is distributed in a way that a reproducible build pipeline will fight. The fourth is a game with a large number of skinned characters on low-end hardware, where the performance figure of 600 Armadillos is the promising case rather than the guaranteed one. The fifth is a project that needs the behaviour to persist across a save and load cycle, since the readme does not describe any serialisation of rig state, and a rig that resets on scene load is a different thing from one that remembers how it was moving.

Editorial conclusion

Unity developers who need hair, tails, skirts or soft tissue to move with a character and who want the tuning done through prefab overrides rather than per rig code are the people JigglePhysics is for, and the separation of mechanical drag from air drag is the detail that makes it usable on things like elevators and vehicles. It is the wrong choice for a project that needs physically correct cloth simulation, since the documentation says outright that it is designed to be authorable rather than physically accurate, and it is the wrong choice for a team that cannot accept a dependency distributed from a git branch rather than a registry release. Check three things before you add it: that you read the JigglePhysicsUpdater prefab and the JiggleUpdateExample.cs script, because the documentation points at them for how the jobs are actually run, that the stiffness, stretch, soften, drag and angle limit parameters are set per rig through prefab overrides rather than globally, and whether your build system can consume a git URL, since the recommended install uses the upm branch and the author suggests pinning a real version tag like v15.0.0 instead. The licence is MIT, the newest release is v15.0.8 from 2026-03-06, and the last push was on 2026-05-05.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. naelstrof/JigglePhysics on GitHub
4. README
5. Releases