Estrutura de RIG
Para usar as Bibliotecas do BirdoApp, é necessário utilizar algumas regras de estruturação de RIG. A ferramenta para salvar os RIGs na "BirdoAsset" depende dessa estrutura para funcionar.
Tipos de RIG
Existem dois tipos de RIGs possíveis para as Bibliotecas:
- FULL: completo com um node group MASTER de "banco" definido;
- SIMPLES: um rig com estrutura mais simples, e SEM um group node de banco principal. Não podendo ser salvo itens para este tipo de RIG na "BirdoLibrary"
Basicamente, o que define se um ASSET vai ser um RIG FULL ou SIMPLES é se será necessário criar um banco de BirdoLibrary para este RIG. Por exemplo, geralmente banco de reaproveitamento do Poses, ou Animação são mais necessários para personagens. Então um Prop não se faz necessário criar um banco de BirdoLibrary, e pode ter um RIG do tipo SIMPLES.
Estrutura de Nodes
O RIG precisa seguir a seguinte estrutura de grupos:
Top / {Grupo MASTER do RIG} / {Grupo MASTER de banco do RIG} / {Nodes do RIG}
Para exemplificar a estrutura de um RIG, vamos usar a versão
v03do personagemCH001_LUPIdo projeto com prefixoLEB:Top/CH003_LUPI/LEB.LUPI-v03/...
- Grupo MASTER do RIG
- Grupo MASTER de banco
- Grupo de Nodes do RIG
O grupo MASTER é o primeiro groupo de node do RIG, na raiz Top, e geralmente é usado uma Peg acima desse grupo chamada 'Stage' para definir o tamanho e posição inicial do Rig na cena:

A nomenclatura é o nome completo do "ASSET", no caso:
Ch003_LUPI
Este sub-grupo não é usado no tipo de RIG SIMPLES!
O Grupo MASTER de "banco", é o grupo de banco principal do RIG.

Este subgrupo que definie o "RIG FULL" tem como sugestão esta organização:
- PEG 'PATH' ou 'DESLOCAMENTO' para ter uma opção de deslocamento a mais pro personagem;
- Grupo do "banco";
- Saídads para conexão de props do grupo de banco (opcional);
- node de sombra (opcional);
Este grupo é onde fica toda estrura de nodes do RIG, com membros.
Exemplo de nodes de um RIG:

Grupos de Banco
Um grupo de BANCO, consiste em um grupo de nodes com uma nomenclatura padrão que o define como passível de banco da "BirdoLibrary". Esse padrão consiste em:
{PREFIXO do PROJETO}.{Nome do ASSET SEM PREFIXO}-{["versão do RIG no padrão v01"](#versionamento-de-rigs)}
Ex:
LEB.LUPI-v03
Todo Grupo de nodes salvo com essa nomenclatura padrão, será reconhecido como um banco da BirdoLibrary e poderá ter itens salvos com a "BD_BirdoLibSave"
Versionamento de Rigs
O que define o versionamento de um "grupo de banco" de um RIG, é a estrutura de nodes dentro deste grupo.
Todo RIG na hora que for salvo na "BirdoASSET", terá registrado toda lista de nodes do grupo de banco que conter dentro dele em um arquivo _rigINFO.v00.json na "estrutura" de pastas do BirdoASSET, e esta lista definirá sua versão. Sendo assim, o banco gerado pela BirdoLibrary somente estará disponível para aquela versão.
Somente crie banco da "BirdoLibrary" quando já estiver na versão final e aprovada do RIG para evitar gerar banco para uma versão não mais utilizada na produção.
Exemplo de Versionamento
Exemplo prático de versionamento com um RIG fictício de um personagem chamado CACHORRO de um projeto com prefixo FOO:
- Versão 'v01'
- Versão 'v02'
Este é a estrutura de nodes do RIG do CACHORRO, definido como 'v01', no grupo de banco FOO.CACHORRO-v01:
Estes nodes são listados com o caminho relativo do node de grupo de banco da seguinte forma para definir a v01:
{
"nodes": [
"Composite",
"Multi-Port-In",
"Multi-Port-Out",
"CACHORRO_CABECA",
"CACHORRO_ORLEHA_A",
"CACHORRO_ORLEHA_B",
"CACHORRO_OLHO_A",
"CACHORRO_OLHO_B",
"CACHORRO_FOCINHO",
"OLHO_A-P",
"FOCINHO-P",
"OLHO_B-P",
"ORLEHA_A-P",
"CABECA-P",
"ORLEHA_B-P",
"MASTER-P",
"Peg",
"OLHO_B-P-P"
]
}
Digamos que foi adicionado um node Cutter neste RIG, modificando a contagem de nodes internos do grupo de Banco. Nesse caso, o grupo de banco 'FOO.CACHORRO-v01' passa ser 'FOO.CACHORRO-v02'.
A lista da versão nova, ficaria dessa forma, com o node "Cutter" adicionado:
{
"nodes": [
"Composite",
"Multi-Port-In",
"Multi-Port-Out",
"CACHORRO_CABECA",
"CACHORRO_ORLEHA_A",
"CACHORRO_ORLEHA_B",
"CACHORRO_OLHO_A",
"CACHORRO_OLHO_B",
"CACHORRO_FOCINHO",
"OLHO_A-P",
"FOCINHO-P",
"OLHO_B-P",
"ORLEHA_A-P",
"CABECA-P",
"ORLEHA_B-P",
"MASTER-P",
"Peg",
"OLHO_B-P-P",
"Cutter"
]
}
Clone de Membros
Para um RIG mais eficiente, uma técnica que sugerimos usar é o Clone de grupos de membros do _RIG.
entende-se como "grupos de membros" um grupo de nodes de braço, ou pernas por exemplo!
Essa técnica se baseia em estruturar os membros do RIG (como braços e pernas) em grupos, e clonar o membro oposto com a opção "Clone Drawings Olny" do Harmony, e reposicionar o grupo clonado usando o node "Static-Transformation";
Node FULL
Uma sugestão para estrutura de RIGs é, além de separar os membros em grupos, adicionar um node que convencionamos em chamar de "NODE FULL". Basicamente, se trata de um node vazio, para ser usado como alternativa de animação full, somente para o membro do RIG em situações que faça sentido, em quantos frames julgar necessário.
Exemplo de uso: Criar um frame de "smear" de um braço, você pode usar o node FULL para desenhar tudo mais simples em uma única camada, em vez de precisar fazer individualmente por peças do RIG do braço.
Uma sugestão é usar o parametro "" nas propriedades do node drawing FULL, como "". Isso vai forçar o pivot da peg variar conforme o desenho do node FULL!