O Desafio da Animação em Massa no Unity

O sistema de animação tradicional do Unity, Mecanim, calcula as matrizes de transformação de cada osso diretamente na CPU. Em cenários com centenas ou milhares de personagens, essa abordagem linear rapidamente se torna um gargalo crítico. A arquitetura ECS (Entity Component System) introduz capacidades robustas de paralelismo de dados, mas a natureza matemática da animação por esqueleto (skinning) exige soluções específicas para escalar adequadamente.

Duas abordagens distintas emergiram no ecossistema DOTS para contornar esse limite: o Rukhanka, que recria o Mecanim sob o paradigma ECS com suporte a processamento híbrido, e o GPU ECS Animation, que elimina completamente o cálculo de ossos em tempo de execução ao pré-calcular os dados em texturas.

Rukhanka: O Motor de Animação Híbrido

O Rukhanka atua como uma camada de compatibilidade completa para o Mecanim dentro do ECS, permitindo alternar dinamicamente entre a CPU e a GPU para o cálculo das matrizes ósseas.

Seu design baseia-se em uma arquitetura dupla:

• Motor via CPU: Utiliza C# Jobs combinados com o Burst Compiler para paralelizar os cálculos, mantendo compatibilidade total com todas as funcionalidades.
• Motor via GPU: Delega o processamento em lote das transformações ósseas para Compute Shaders, gerando resultados idênticos aos do motor de CPU.

Essa solução preserva recursos avançados como máquinas de estado (Animator Controllers), Blend Trees, camadas aditivas, Avatar Masks, Root Motion e Inverse Kinematics (IK). O fluxo de trabalho não exige alterações nos assets originais; basta substituir os componentes tradicionais por suas contrapartes ECS.

GPU ECS Animation: Renderização Puramente Baseada em GPU

Em contraste, o GPU ECS Animation adota uma estratégia de otimização extrema. O objetivo é descarregar inteiramente a CPU, transferindo toda a responsabilidade da animação para a placa de vídeo através de dados pré-processados.

As características centrais incluem:

• Pipeline de Baking: Durante a edição, os clipes de animação são amostrados quadro a quadro. As posições dos vértices (e opcionalmente normais e tangentes) são armazenadas em formatos como Texture2D ou Texture2DArray.
• Execução em Tempo de Realidade Minimalista: A CPU apenas transmite sinais de controle básicos, como o índice da textura, o tempo atual e a velocidade. O Vertex Shader assume a leitura da textura, interpolação e posicionamento final dos vértices, ignorando completamente a hierarquia óssea.

Essa abordagem impõe limitações severas: suporta apenas a reprodução de clipes isolados com crossfade básico, dispensa máquinas de estado, IK e Root Motion, e apresenta restrições inerentes à interpolação no espaço dos vértices.

Comparativo Arquitetural

Detalhamento Técnico dos Pipelines

O Fluxo de Trabalho do Rukhanka

A arquitetura do Rukhanka divide a animação em três estágios. A máquina de estado — responsável por transições, pesos de mistura e resolução de IK — executa invariavelmente na CPU. O ponto de bifurcação ocorre no cálculo das matrizes locais de cada osso.

No modo GPU, a seleção do motor é feita através de uma simples configuração:

var runtimeConfig = new AnimationConfiguration {
    ProcessingUnit = ExecutionTarget.GPU,
    FramerateTarget = 60
};

O Compute Shader então itera sobre a hierarquia óssea. As curvas de animação são convertidas em texturas durante a importação, permitindo que a GPU leia os valores de posição, rotação e escala no tempo adequado, multiplique as mtarizes locais pela matriz do osso pai e armazene o resultado em um StructuredBuffer. O estágio final de skinning utiliza shaders de material padrão, extraindo as matrizes desse buffer.

A Lógica de Baking do GPU ECS Animation

Esta solução ignora a matemática óssea em tempo de execução. Em vez disso, o editor calcula a posição final de cada vértice para cada quadro da animação e mapeia esses dados em uma grade bidimensional.

O script de baking opera da seguinte maneira:

Texture2D GenerateAnimationTexture(GameObject targetModel, AnimationClip clip, int totalFrames) {
    int meshVertexCount = targetModel.GetComponent<SkinnedMeshRenderer>().sharedMesh.vertexCount;
    var outputTexture = new Texture2D(meshVertexCount, totalFrames, TextureFormat.RGBAFloat, false);
    var tempMesh = new Mesh();

    for (int currentFrame = 0; currentFrame < totalFrames; currentFrame++) {
        float timeStep = (float)currentFrame / totalFrames * clip.length;
        clip.SampleAnimation(targetModel, timeStep);
        targetModel.GetComponent<SkinnedMeshRenderer>().BakeMesh(tempMesh);

        Vector3[] bakedVertices = tempMesh.vertices;
        for (int i = 0; i < meshVertexCount; i++) {
            Vector3 pos = bakedVertices[i];
            outputTexture.SetPixel(i, currentFrame, new Color(pos.x, pos.y, pos.z, 1.0f));
        }
    }
    outputTexture.Apply();
    return outputTexture;
}

Durante o jogo, o Vertex Shader utiliza as coordenadas UV (especificamente o canal UV0, que é reutilizado para atuar como índice do vértice) para buscar a posição exata na textura:

struct VertexInput {
    float4 basePosition : POSITION;
    float2 animationUV : TEXCOORD0; 
};

struct VertexOutput {
    float4 clipPosition : SV_POSITION;
};

Texture2D _AnimationDataTex;
SamplerState sampler_AnimationDataTex;
float _CurrentAnimTime;
float _TransitionWeight;
Texture2D _TransitionDataTex;

VertexOutput vert(VertexInput input) {
    VertexOutput output;
    float2 sampleCoord = float2(input.animationUV.x, _CurrentAnimTime);
    
    float4 primaryPos = _AnimationDataTex.SampleLevel(sampler_AnimationDataTex, sampleCoord, 0);
    float4 finalPos = primaryPos;

    if (_TransitionWeight > 0.0) {
        float4 secondaryPos = _TransitionDataTex.SampleLevel(sampler_AnimationDataTex, sampleCoord, 0);
        finalPos = lerp(primaryPos, secondaryPos, _TransitionWeight);
    }

    output.clipPosition = UnityObjectToClipPos(finalPos);
    return output;
}

Interpolação de Vértices versus Interpolação de Ossos

Uma distinção matemática crucial separa os dois métodos. O Rukhanka realiza a interpolação no espaço dos ossos (usando quaternions e multiplicação de matrizes), aplicando a transformação resultante aos vértices. Isso preserva o volume do modelo durante rotações complexas.

O GPU ECS Animation, por outro lado, interpola posições no espaço do vértice. Se um braço transita de uma rotação de 0° para 90°, a interpolação linear (lerp) entre as posições iniciais e finais dos vértices criará uma trajetória retilínea, fazendo com que o membro encolha visualmente nos quadros intermediários. Esse fenômeno, conhecido como colapso de volume, é uma limitação intrínseca da ausência de dados rotacionais por vértice.

Análise de Cenários e Tomada de Decisão

A escolha entre as arquiteturas deve ser guiada pela densidade de personagens e pela complexidade comportamental exigida pelo projeto.

MMOs e RPGs de Ação: Cenários que exigem centenas ou poucos milhares de entidades com comportamentos distintos, reações a terreno irregular (IK) e sincronização física (Root Motion) beneficiam-se imensamente do Rukhanka. A retenção da máquina de estado é fundamental para a lógica de jogo.

Jogos de Estratégia (RTS) e Simulações de Multidões: Quando o objetivo é renderizar dezenas de milhares de unidades executando animações cíclicas simples (como correr ou atacar), o GPU ECS Animation é imbatível. A CPU é completamente liberada para processar IA e pathfinding, enquanto a GPU assume a carga visual através de instanciamento massivo e amostragem de texturas.

Considerações de Implementação e Limitações

Ao adotar o Rukhanka, desenvolvedores devem atentar-se à compatibilidade entre a versão do plugin e o pacote Entities do Unity. O modo GPU exige suporte robusto a Compute Shaders, tornando-o inadequado para plataformas WebGL mais antigas. Além disso, depurar lógicas compiladas via Burst requer a desativação temporária da otimização no editor.

Para o GPU ECS Animation, a gestão de memória é o principal desafio. Texturas no formato RGBAFloat garantem precisão absoluta das coordenadas, mas consomem VRAM rapidamente à medida que a duração dos clipes ou a contagem de vértices aumenta. O uso de formatos de 8 bits (RGBA32) reduz o custo de memória, mas introduz imprecisões que podem resultar em micro-vibrações visíveis na malha. Adicionalmente, a ausência de Root Motion exige que o deslocamento espacial das entidades seja calculado e aplicado manualmente via scripts de controle. Por fim, esta técnica exige a construção de pipelines de baking personalizados e a adaptação dos canais UV dos modelos, já que as coordenadas de textura tradicionais devem ser deslocadas para o canal UV1.