Godot 4.6 trouxe o IK de volta. Pra quem faz jogo 3D, isso importa mais que o Jolt.

Faz três anos que game devs trabalhando com personagens 3D em Godot escutam a mesma resposta quando perguntam sobre Inverse Kinematics: "vai voltar". O IK do Godot 3.x foi removido durante a reescrita para a 4.0, e a partir daí quem precisava de IK 3D no Godot 4 tinha duas opções: esperar, ou escrever o próprio solver em cima do SkeletonModifier3D.

Em 26 de janeiro de 2026, a 4.6 foi lançada e o IK voltou. E ele voltou diferente do que era na 3.x.

Quase todo mundo que comentou a release na imprensa internacional focou na adoção do Jolt Physics como engine padrão para 3D. Faz sentido, é uma mudança grande. Mas pra quem está fazendo jogo de personagem (RPG, ação, plataforma 3D), a feature que de fato muda o que dá pra fazer no Godot é o IKModifier3D.

Por que IK importa pra quem faz jogo

Inverse Kinematics resolve um problema simples de descrever e horrível de codar manualmente: você quer que o pé do personagem fique grudado no chão mesmo quando o terreno é irregular. Ou quer que a mão do personagem alcance uma maçaneta sem importar a altura. Ou quer um braço de robô que aponta pra um alvo móvel sem você ter que animar cada osso.

Sem IK, a alternativa é animação manual quadro a quadro pra cada variação. Com IK, você diz onde o ponto final do osso deve estar e o sistema calcula as rotações de cada osso na cadeia.

Isso não é luxo. É a diferença entre um personagem que parece estar "flutuando" sobre o terreno e um que parece estar caminhando nele.

O contexto brasileiro

Pra entender o tamanho da plateia que isso atinge no Brasil: O BIG Festival 2026 recebeu 966 inscrições de 75 países, com 451 títulos brasileiros (quase metade do total). É a maior edição da história do festival, e mostra o tamanho da comunidade indie nacional.

A maioria dessas equipes é pequena (1-3 pessoas) e não tem animador dedicado. Pra esse perfil, ter IK no engine padrão muda os jogos que dá pra fazer sem contratar gente. Fazer um personagem 3D com pés que respondem ao terreno deixou de ser "preciso pagar um animador" e virou "configura o nó certo".

Como o novo framework está organizado

A documentação ainda está em construção, mas o post oficial do contribuidor Tokage explica a estrutura. O sistema agora tem 7 classes principais:

IKModifier3D (base)
├── TwoBoneIK3D       (determinístico, 2 ossos)
├── ChainIK3D
│   └── SplineIK3D    (segue uma curva)
└── IterateIK3D
    ├── FABRIK3D      (cadeias longas)
    ├── CCDIK3D       (multi-junta com soft constraints)
    └── JacobianIK3D  (genérico complexo)

Na prática, o solver que você vai usar depende do tipo de cadeia óssea. Pra braço ou perna (cadeia de 2 ossos), TwoBoneIK3D resolve rápido e de forma previsível. Pra cauda, tentáculo ou coluna, qualquer coisa longa e flexível, FABRIK3D é o caminho. CCDIK3D aceita um pouco de esticamento e funciona bem em rigs estilizados. SplineIK3D força os ossos a seguirem uma curva específica. E JacobianIK3D é o último recurso pra rigs complexos onde nenhum dos outros dá conta.

A separação dos solvers em famílias (determinístico, chain, iterativo) parece pedante, mas tem um motivo prático: o Tokage queria que devs implementando IK customizado tivessem o mínimo de código pra reutilizar. Implementar um solver novo agora é só herdar de uma das três famílias.

Exemplo prático: pé no chão

O caso de uso mais comum em jogo de personagem é foot planting com TwoBoneIK3D. A configuração básica é:

extends Skeleton3D

@onready var foot_target: Node3D = $FootTarget
@onready var ik: TwoBoneIK3D = $TwoBoneIK3D

func _ready():
    ik.root_bone = "Thigh.L"
    ik.tip_bone = "Foot.L"
    ik.target_node = foot_target.get_path()

func _physics_process(_delta: float) -> void:
    var space_state = get_world_3d().direct_space_state
    var origin = global_position + Vector3.UP * 0.5
    var end = origin + Vector3.DOWN * 2.0

    var query = PhysicsRayQueryParameters3D.create(origin, end)
    var result = space_state.intersect_ray(query)

    if result:
        foot_target.global_position = result.position

Você lança um raycast pra baixo, posiciona o FootTarget onde o raio bate, e o TwoBoneIK3D cuida do resto. O joelho dobra na direção certa, o pé fica plantado mesmo quando o terreno tem inclinação.

Antes da 4.6, fazer isso significava ou portar manualmente um solver de FABRIK pro SkeletonModifier3D, ou usar a GodotIK extension da comunidade, ou animar manualmente.

Onde ainda dói

Não é tudo perfeito. Alguns pontos importantes pra quem vai usar agora:

1. Documentação ainda incompleta. O Tokage avisou no post oficial que tutoriais detalhados ainda vão chegar. Pra rigs complexos, vai ter que ler o código fonte ou perguntar no Discord.

2. Ordem das cadeias afeta o resultado. Já tem thread no fórum oficial reportando que a ordem em que você adiciona modifiers muda o resultado final em rigs com múltiplas cadeias. É previsível matematicamente, mas não é óbvio na primeira vez que você esbarra.

3. Sem suporte 2D direto. O IKModifier3D é, como o nome diz, 3D apenas. Pra IK 2D continua tendo que usar SkeletonModifier2D com solver próprio.

4. Performance ainda em otimização. O Jacobian especificamente é caro de rodar a cada frame. Pra cenas com muitos personagens, vale considerar atualizar IK a cada N frames em vez de cada frame.

Release de polish, ou mudança estrutural?

A 4.6 foi descrita pelo time como uma release focada em polish e fluxo de trabalho. Pra quem usa Godot pra fazer jogo 2D ou prototipagem rápida, faz sentido. O editor está mais arrumado, o Jolt acelera 3D, performance melhorou em geral.

Mas pra quem desenvolve jogo 3D de personagem, o IK é uma mudança estrutural. Antes da 4.6, fazer um personagem 3D bem animado em Godot exigia conhecimento de matemática de skeleton que a maioria dos indies não tinha. Depois da 4.6, é uma questão de configurar nós e fazer raycast.

A previsão honesta é que ainda vai ter dor durante 2026. A documentação está atrasada, há pelo menos um bug conhecido com ordem de cadeias, e alguns rigs vão exigir tentativa-e-erro pra encontrar o solver certo. Mas o piso subiu. Quem antes precisava optar por Unity ou Unreal pra fazer um RPG 3D decente porque "Godot não tem IK" não tem mais esse argumento.

Pra time pequeno, o Ziva resolve o boilerplate via prompt direto no editor (configurar Skeleton3D, criar AnimationTree, anexar IKModifier3D), o que economiza algumas horas por personagem. Mas isso é acelerador, não a mudança que importa. A mudança que importa é a do engine.

A pergunta técnica em aberto agora é simples: FABRIK3D aguenta uma cauda de 12+ ossos a 60 FPS em hardware modesto, ou vai precisar atualizar a cada N frames? Quem já mediu, pode publicar. Quem não mediu, em algum momento de 2026 vai precisar medir.