O Movimento De Rotação Dura

O que é, na prática

O movimento de rotação dura (hard rotation ou instant rotation) é simplesmente uma rotação que vai do ponto A ao ponto B sem qualquer interpolação. Não tem easing, não tem suavização, não tem slerp. Você define o ângulo final e o objeto pula direto para ele. No Unity isso é o que você vê quando usa Quaternion.identity ou transform.rotation = target num único frame. No Blender, é o que acontece quando você insere keyframes com modo de interpolação constante (constant interpolation). É isso. Nada mágico. Eu comecei a usar esse conceito de verdade quando estava trabalhando num protótipo de RTS onde as unidades precisavam girar instantaneamente para apontar para o alvo. Qualquer tipo de interpolação cria atraso perceptível, e em jogos táticos rápidos esse atraso quebra a sensação de controle. O jogador clica e quer que a unidade já esteja virada. Rotação dura resolve isso em um frame. Mas isso é só um dos cenários. Também uso quando preciso de snaps precisos para encaixe de peças, alinhamento de UI elements, ou quando estou fazendo animações procedurais que dependem de poses exatas para cálculos subsequentes. O problema é que muita gente aplica rotação dura indiscriminadamente porque é mais fácil. É mais fácil escrever duas linhas do que configurar uma transição suave com damping e tudo mais. Mas isso gera problemas visuais óbvios: o objeto parece teletransportar-se angularmente, o que é aceitável em alguns casos e terrível em outros. Se você está rotacionando uma câmera principal do jogo, por exemplo, rotação dura quase sempre vai causar nauseante snapping. Se é um ícone de UI ou uma seta direcional, ninguém vai reclamar.

Como implementar corretamente

No Unity, a forma mais direta é atribuir diretamente a propriedade rotation do transform. Vou mostrar o que eu usava no projeto de RTS que mencionei, com a correção que descobri depois de dor de cabeça. A implementação básica é:pegar a rotação alvo, que pode vir de um quaternion calculado com Quaternion.LookRotation ou de um float em eulerianos, e atribuir diretamente ao transform. O código é literalmente três linhas. Mas o detalhe importante que as tutoriais costumam pular é o problema do gimbal lock quando você trabalha com eulerianos. Se você calcular a rotação alvo usando Quaternion.Euler e passar ângulos grandes, você vai ter results estranhos de vez em quando. Sempre use quaternions para o cálculo e só converta para euler se precisar ler o valor. Um cenário onde isso me pegou desprevenido foi quando estava desenvolvendo um sistema de torreta que precisava girar exatamente 180 graus para mirar em um alvo atrás. Usei rotação direta com eulerianos e, em uma ocasião específica, a torreta girava 180 graus no eixo errado porque o ângulo de euler estava ambíguo (a mesma orientação pode ser representada por combinações diferentes de ângulos eulerianos). A solução foi forçar a conversão para quaternion antes de aplicar e usar SetPositionRotation num contexto de Rigidbody, evitando que o motor tentasse interpolar de alguma forma.

Se você está num motor diferente do Unity, a lógica é a mesma. Godot usa transform.basis = basis.rotated() com o ângulo direto. Unreal Engine tem SetWorldRotation que também é instantâneo por padrão. A diferença entre motores costuma ser apenas na API, não no conceito.

Pegadinhas que ninguém conta

A primeira pegadinha é que rotação dura não respeita delta time. Isso parece óbvio, mas quando você mistura rotação dura com outras movimentações interpoladas no mesmo frame update, o objeto pode pular visualmente enquanto o resto do movimento continua suave. A solução é manter o sistema de rotação dura isolado ou usar um fixo timestep para atualizações que exigem precisão angular instantânea. A segunda pegadinha, mais sutil, é a questão da ordem de atualização. Se você tem uma hierarquia de objetos onde o pai gira com rotação dura e o filho também, a rotação do filho é afetada pela transformação do pai antes que ela seja aplicada. Isso significa que o resultado final pode não ser o que você espera se calcular a rotação do filho baseada na rotação anterior do pai. Eu resolvi isso calculando todas as rotações duras na mesma iteração, em ordem topológica correta (pai primeiro, filhos depois), lendo os valores já atualizados. Existe ainda um problema de performance que raramente importa mas pode importar no seu caso específico: se você estiver aplicando rotação dura em milhares de objetos por frame, a alocação temporária de quaternions pode gerar garbage collection spikes. Em projetos mobile, isso é real. A workaround que funcionou para mim foi usar Quaternion.SetFromToRotation em vez de calcular LookRotation com novos quaternions a cada frame, e reutilizar uma variável de instância para evitar alocações.

Limitações reais

Rotação dura não serve para tudo. Se o seu projeto precisa de transições suaves entre orientações, especialmente para câmeras, personagens ou objetos que o jogador observa com atenção, você vai precisar de slerp ou damp rotation. A rotação dura também é problemática quando você está sincronizando estado entre cliente e servidor em jogos online, porque um snap angular não pode ser interpolado de forma previsível em diferentes taxas de frame. Nesses casos, o padrão é enviar a rotação alvo como estado e interpolar localmente. Se o seu caso é simplesmente alinhar objetos numa grade, snap de rotação para múltiplos de 90 graus, ou qualquer situação onde a precisão angular importa mais do que a fluidez visual, o movimento de rotação dura é a ferramenta certa. Fuja dele quando a experiência visual depende de continuidade, e lembre-se de testar nos casos de borda antes de.commitar o código para produção.