Solução de Problemas

Sintomas, o que os causa e o que verificar.

Cada item abaixo é uma falha medida numa máquina real, não uma hipótese. Onde o OVB escreve a explicação no log, a linha do log está citada para você poder buscá-la.

Onde fica o log

O OVB escreve um log do lado Python na sua pasta temporária:

%TEMP%\ovb_python_debug.log

No macOS ele fica em $TMPDIR. O log sobrevive ao crash que explica — então, se o Harmony fechar durante um import, esse arquivo é a primeira coisa a abrir, e a primeira a enviar se você for reportar o problema.

As linhas que interessam começam com uma etiqueta: [raster] para o caminho do bitmap, [apply] para o laço de import.

Imports longos

O Harmony fechou durante o import de uma sequência longa, sem mensagem nenhuma.

Versões anteriores guardavam a sequência inteira em memória dos dois lados da ponte — os frames já lidos e o JSON entregue ao Harmony. Medido numa máquina de 16 GB com 840 SVGs reais: cerca de 0,9 GB retidos só na lista de frames, e Import JS error: bad allocation pouco antes de o Harmony sumir. Com 240 frames funcionava; com 840, não.

O import vetorial agora é em streaming: a memória depende do tamanho do bloco, não do número de frames. Atualize para a versão atual e tente de novo.

O import levou mais de uma hora.

Também resolvido, e a causa não era o desenho — era número de processos. Cada frame de bitmap disparava até dois utransform, e cada um é um new Process2 mais o launch: cerca de 1.700 processos numa sequência de 840. Hoje o PNG vira TVG dentro do próprio processo, na densidade da cena, o que transformou o passe "base" numa conversão TVG→TVG que só copia bytes — e ela é pulada quando a entrada já é TVG. Uma chamada por frame em vez de duas, e zero para uma trilha sozinha de line art.

Desfazer um import longo leva vários passos.

É de propósito. Um único bloco de undo cobrindo centenas de frames faz o Harmony segurar todas as criações de desenho até o fim, que é exatamente a falha de memória acima. Passado um limite, o bloco é fechado em fatias, e o OVB avisa no log em vez de deixar você descobrir depois:

[raster] 840 frames > 100: committing the undo block every 100 frame(s) to bound Harmony's memory — undoing this import takes 9 steps

A caixa "salvar a cena a cada N frames" está travada.

Essa opção salva a cena periodicamente durante um import longo, para o Harmony ir liberando memória; e o que já foi salvo permanece se você cancelar. Ela precisa de uma cena que exista em disco:

Locked: save the scene first.

Salve a cena uma vez e a caixa destrava — o OVB verifica de novo no Apply, então não é preciso reabrir a janela.

O import parou no meio. Dá para continuar de onde parou?

Dá — se o Checkpoint save estava ligado. A cena em disco guarda tudo até o último checkpoint, e o log diz qual foi:

[checkpoint] scene saved at frame 100 of 840

Importe o resto no mesmo Read node, com Start e Range começando no frame seguinte. Digamos que 1–100 já entraram e você quer 101–200:

1. Abra a cena que o checkpoint salvou.
2. Selecione esse Read node no Node View do Harmony.
3. No Outliner, + → Add drawing from Node View — o drawing aponta para o node existente em vez de criar um novo.
4. Vincule a mesma sequência na mesma art layer.
5. No card Drawing (não na subartlayer): Start = 101, Range = 101–200.
6. Deixe o Checkpoint save ligado e dê Apply.

Os frames que já estão lá ficam intactos: o Replace limpa um frame por vez, só os que estão sendo escritos, e cada frame vira um drawing com o nome do próprio número — então 101…200 nunca colidem com 1…100. A cena cresce sozinha para caber nos frames novos.

Range é quais frames da sequência importar; Start é onde o primeiro deles cai na timeline. Ao retomar, dê o mesmo número aos dois — Start = 1 com Range = 101–200 escreveria esses frames em 1–100 e sobrescreveria o que você já tem.

Sem o Checkpoint save não há de onde retomar

Desenhos que o Harmony escreveu mas não salvou existem só na memória dele. Se o import nunca salvou e o Harmony foi morto, o trabalho se perdeu — recomece com a caixa ligada.

A cena não salva depois do import

O Harmony recusa salvar, com "Missing folder …/Temp/ovb_raster_xxxx" e "Cannot write palette list".

Quem escreve um TVG escreve o PALETTE_LIST ao lado dele. Em versões anteriores o desenho final era montado a partir de TVGs intermediários que viviam num diretório temporário — então o desenho pronto herdava uma referência de paleta apontando para uma pasta que o próprio import apagava na saída.

Hoje todo TVG intermediário nasce na pasta do elemento e é varrido depois; o PALETTE_LIST fica, que é o lugar dele. Se você já tem uma cena nesse estado, reimportar com a versão atual conserta a referência.

Import de bitmap

Uma segunda trilha de bitmap apagou a primeira.

O Harmony 24 só carrega um desenho uma vez, então duas trilhas escritas no mesmo {elemento}-{frame}.tvg faziam os pixels da segunda irem para o disco e nunca serem carregados. Hoje todas as trilhas de bitmap de um desenho são compostas em um TVG antes do create, e chegam juntas. Se você está numa versão anterior, importar as trilhas separadamente é o que dispara o problema.

O bitmap não bate com a arte vetorial — parece outra resolução.

Converter um PNG em TVG na densidade da cena usa o DrawingTools.vectorize, que exige o recurso de licença Vectorize. Harmony Premium e Advanced o incluem; sem ele o arquivo vai para o utransform na densidade padrão dele, que não vai coincidir. O OVB não falha calado nesse ponto:

[raster] frame 12 art 2: vectorize unavailable — importing at utransform's default density (may mismatch the vector art)

Duas trilhas com modos de alpha diferentes deixaram o import muito mais lento.

O -premultiply é por invocação do utransform, então ele só carrega um modo para o frame inteiro. Quando as trilhas concordam, a conversão acontece em C++. Quando discordam, cada trilha é convertida em Python — um laço por pixel. O log avisa quando isso acontece; dar o mesmo modo de alpha às duas trilhas devolve o caminho rápido.

A trilha ficou fora de centro, ou aquém de onde eu a coloquei.

O offset do gizmo é assado nos pixels aumentando a tela com preenchimento transparente — é a única forma de expressar "fora de centro" para uma ferramenta que centraliza tudo que recebe. A tela tem teto de 16.384 px, para um erro de digitação não pedir uma imagem de vários gigabytes:

[raster] gizmo offset clamped to 16384px canvas — the track will land short

Se essa linha aparecer, o offset é maior do que o desenho consegue expressar: mova o objeto em vez de deslocar a trilha.

Frames e exposição

Alguns frames seguram o desenho do frame anterior.

Um frame que falhou ao escrever não deixa nenhuma entrada na coluna, então aquela célula mantém o que estava lá — e todo frame seguinte lê como deslocado em relação às trilhas que entraram. Buraco silencioso é exatamente como uma sequência sai "desalinhada" sem erro nenhum, então o OVB os reporta:

[raster] HOLES — 3 frame(s) never written: 47(base rc=1), 48(base rc=1), 49(base rc=1)

Um frame entrou vazio.

Se a origem não tem arte naquele número de frame, a exposição é escrita vazia de propósito. Sequências são alinhadas por número de frame, não por posição numa lista, então um buraco na origem continua um buraco na cena — e escrevê-lo vazio é o que impede um reimport de deixar o desenho anterior na célula.

O Frame Range importou a sequência inteira, ou escreveu além do fim da cena.

O Frame Range indexa a sequência, com base 1 e inclusivo — 5–20 de uma sequência de 100 arquivos significa esses 16, não os 100. O OVB estende a linha do tempo a partir dessa mesma faixa para nenhum frame importado ser descartado. Se a cena parecer truncada, confira se a faixa e o comprimento da cena concordam; a timeline é estendida por você, nunca encurtada.

Paleta

O botão "−" removeu uma cor que eu tinha acabado de criar no OVB.

Corrigido na versão atual. O botão de remover do painel de paleta e as cores criadas pelo app eram dois elos soltos da mesma corrente, e remover um podia levar o outro junto.

Exportador do Blender

Um passe saiu vazio, ou mostra o que está atrás do objeto.

No EEVEE, um material em Blended não escreve os passes de Normal e Position — o que você recebe é o que estiver atrás dele. Se a superfície é de fato opaca, use Dithered. Isso é comportamento do Blender, não do OVB, e nenhuma opção do OVB contorna.

Uma linha de horizonte sumiu, ou virou um fio.

Geometria quase de perfil para a câmera colapsa num sliver de menos de um pixel antes de o tracer vê-la. Dê espessura real à superfície, ou separe a linha num passe próprio.

Continua travado

Envie o %TEMP%\ovb_python_debug.log junto com a versão do seu Harmony e o número de frames da sequência. Essas três coisas respondem quase tudo que uma resposta teria de perguntar.

Suporte: octo-tools.com/support