Watch the creator’s explanation
just7 · Eclipse — Official Tutorial · IK-related control at 1:33. This is the creator’s video, accompanying our independent written guide.
Loading the player connects to YouTube. It is a separate choice from optional website Analytics. You can read every step without loading the video.
No player is loaded. Video privacy details.
What Eclipse Animator inverse kinematics is documented to do
The original Eclipse Animator listing names an Inverse Kinematics toggle among its features. The creator’s official tutorial chapter at 1:33 provides the relevant interface reference. That establishes a creator-described IK feature, not a tested compatibility promise for every joint structure or a complete written specification of its solver.
The chapter description includes an FK label in this IK context. We have not verified it as a universal keyboard shortcut, so this guide does not tell you to type the letters F and K or guess a key combination. Watch the demonstrated control and compare it with the current plugin version. The controls reference distinguishes confirmed key labels from controls that need visual context.
The practice below is our suggested way to investigate a single limb. It is not a report of an observed Eclipse bug or an animation we have made in Studio. If you need the original plugin first, use Get Plugin and complete the installation checklist.
IK and FK: understand the posing question first
As a general animation concept, inverse kinematics starts with a desired endpoint and resolves a connected chain toward it. Forward kinematics starts with joint transforms and produces the resulting endpoint. For an arm, these are two ways of approaching the pose: think about the hand’s destination, or think about the shoulder and elbow rotations.
Roblox’s inverse kinematics documentation explains connected-limb posing and separately documents the engine’s IKControl. That runtime object has its own chain, target and endpoint properties. The documentation is useful conceptual background; it does not prove that Eclipse’s editor toggle creates an IKControl or exposes the same fields. Do not add runtime objects to a rig solely to imitate a plugin control.
The practical question is not which method is always better. Ask which part of the motion you need to control. A hand reaching toward a point and an arm making a broad swinging gesture place different demands on your posing process. Try both approaches on a disposable copy before changing a developed shot.
Prepare a small Eclipse Animator inverse kinematics test
Start with the short project from the beginner tutorial, or another simple rig that already animates as expected without this new step. Preserve a working copy. Use one limb and one clearly visible pose; avoid adding a moving camera, physics or several constrained interactions at the same time.
Write down the result you intend to compare. For example: “At the middle pose, the hand is slightly in front of the body and the elbow bends in an acceptable direction.” Keep the desired position comfortably near the character. An extreme reach adds another variable before you know how the documented control behaves on your rig.
Use a stationary prop as a visual reference if it helps you judge the hand position. This is an observation aid, not an instruction to assign that prop to an Eclipse target field. The source chapter and current interface should determine the actual control you use.
Follow the creator’s IK control, then inspect one change
Open the 1:33 chapter and note the selected object, control label and resulting movement in the demonstration. Reproduce only a comparable change that you can identify in your installed version. If the label or selection differs, return to the tutorial rather than treating an unfamiliar button as equivalent.
Check your test in this order:
- Before the change: note the hand position and the visible elbow direction at the chosen time.
- After the change: inspect which connected parts moved and whether the endpoint stayed where you expected.
- At another time: scrub away and back to see what is actually recorded, rather than only the currently displayed pose.
- During playback: inspect the transition into and out of the pose, not just the best-looking still image.
Use the creator’s keyframe insertion chapter at 0:29 when you need to record a state. The distinction matters: a change visible in the viewport is not, by itself, proof that the required animation data has been saved at the intended time.
Compare IK and FK without changing everything else
Keep the rig, frame positions and intended endpoint similar between the two comparisons. Work on separate saved copies if you cannot confidently restore the initial state. Label the copies by the approach you used so that you can revisit the result without guessing which experiment produced it.
Compare effort and outcome separately. One approach might make the initial pose easier while still needing transition cleanup. Inspect the hand path, elbow direction, shoulder movement and the neighboring keyframes. If you move the camera or change the duration between tests, you have also changed the way you perceive the motion.
For a controlled timing example, use a one-second interval at your actual project FPS. The timing calculator converts that interval to frames. A different FPS should change the planned frame count, not the intended one-second comparison. This is a test setup, not a recommendation that Eclipse projects always use a particular rate.
Diagnose a surprising result by its first symptom
| Observation | What to inspect before changing more settings |
|---|---|
| Pose jumps when changing the control | Same selected limb, same timeline position, and the state immediately before the change |
| Elbow bends in an unwanted direction | Starting pose, reach direction and the rig’s joint arrangement |
| Hand does not stay where expected | What the source demonstration actually controls, plus any other keyed body movement |
| Pose looks right until you scrub away | The recorded keyframes and their positions |
| Saved or exported result differs | Saved project first, then the separate export and destination workflow |
These are investigation prompts, not guaranteed fixes or a claim that Eclipse has these defects. Avoid forcing a joint to an extreme position just to make the endpoint match. If the exercise stops being simple, return to the last known working copy and isolate one change.
What this IK lesson does not establish
We have not verified all rig types, supported chain lengths, automatic pole controls, IK-to-FK baking, or exact export behavior. The creator’s feature list should not be expanded into those promises. Roblox’s runtime IK documentation also does not answer plugin-specific implementation questions.
When asking for help, include the installed Eclipse version, rig type, selected control, time position and smallest action that produces the unexpected result. Separate an editor posing question from a runtime IKControl scripting question. Keep private place files and third-party assets out of public examples unless you have permission to share them.
Once the limb’s motion is understandable and recoverable from a saved project, use the graph editor lesson to investigate transition timing. For an additional motion contribution, read animation layers. Return to the tutorial directory if you want a simpler next task before combining these features.