Capítulo 4 — Janelas auxiliares

Além da janela principal (viewport 3D mais Inspetor), o RadianceKit gerencia sete outras janelas, todas abertas pelo menu Help. A lista de cima para baixo: User Guide (⌘?), Keyboard Shortcuts (⌘/), Open Training Logs… (não abre janela do app, mas o Finder; por isso não tratado aqui), Manage Storage…, Pareto Dashboard… (⇧⌘D), Holdout Analysis… (⇧⌘H), BayesOpt Console… (⇧⌘B). Três delas — Dashboard, Holdout, BayesOpt — são ferramentas de análise autônomas. Cada uma tem seu próprio stack de view model, lê ou grava arquivos JSON no disco, e cada uma tem um argumento de CLI para apontar a janela já no início do app para um arquivo específico (–dashboard-dir, –holdout-file, –bayesopt-autorun).

As quatro janelas simples (User Guide, Keyboard Shortcuts, Manage Storage, mais os submenus Open Training Logs / Open Exports Folder) ganham uma entrada curta por controle. As três janelas de análise estão documentadas com mais detalhe — cada uma com uma introdução que explica o que você vê, quando deve abrir e como interpretar.

No fim do capítulo há uma seção de cross-reference para o Inspetor da janela principal: o que você consegue ler no live loss chart e no indicador de Gaussian Count durante um treinamento em andamento.

User Guide (W1–W4)

O que é: uma janela de ajuda embutida que renderiza o guide_<idioma>.md distribuído com o app. O idioma vem das Configurações (aba General → Language) ou, se estiver „System", das preferências de idioma do macOS. Layout clássico: sidebar de títulos à esquerda, texto corrido à direita.

Quando você precisa de uma lembrança rápida sobre um ponto isolado — como substituto de palavra-chave. A referência completa é este manual; a janela embutida é o equivalente a um –help na linha de comando. É atualizada a cada release, mas mantida intencionalmente superficial.

W1NavigationSplitView (sidebar + detalhe)

ONDE

Help → User Guide (⌘?)..

TÉCNICO

Layout em duas colunas com sidebar estreita (mínimo 180 pt) para a árvore de conteúdo e área scrollável de detalhe para o markdown. A janela tem tamanho mínimo de 700×500 pt. Na primeira abertura, carrega o guide_<lang>.md do bundle (fallback guide_en.md), parseia em blocos (cabeçalhos H1–H4, parágrafos, listas, tabelas, separadores) e extrai separadamente a estrutura de headings para a sidebar. Formatação inline (bold, italic, code span) renderizada pelo engine markdown embutido. O idioma vem das configurações, com caso especial para Chinês (zh-Hans) e Português brasileiro (pt-BR) mantidos como locale tags completos, porque essas variantes diferem de zh ou pt respectivamente.

W2List (sidebar de headings)

ONDE

Coluna esquerda da janela User Guide..

TÉCNICO

Lista de todos os títulos H2 e H3 do documento. Entradas H2 sem recuo e em peso medium; H3 com 16 pt de recuo esquerdo e foreground reduzido. H4 ou mais profundos são ignorados para não confundir a sidebar. IDs de âncora geradas por slug do texto do heading (lowercase + espaços virando hifens + filtro a letras/números/hifens — mesmo algoritmo do GitHub para âncoras markdown, de modo que URLs externos podem cair no mesmo ponto). Lista usa estilo nativo do macOS.

W3Button (heading → salto para âncora)

ONDE

Um botão por linha na sidebar..

TÉCNICO

Cada item da sidebar é um botão que define a âncora atual, mas tem aparência de item de lista. Uma variável observada dispara o scroll para a âncora correspondente com animação suave em 0,3 s. Após o salto, o valor da âncora é zerado, para que outro clique no mesmo dispare de novo (senão o observer não reagiria, pois o valor não mudaria).

W4ScrollView (conteúdo de detalhe)

ONDE

Coluna direita..

TÉCNICO

Área scrollável com pilha vertical e render lazy, porque guias maiores podem ter mais de 200 blocos markdown — uma versão não-lazy instanciaria tudo de uma vez. Cada bloco tem ID própria, seja a âncora do heading (para H1–H3 saltáveis) ou um placeholder de índice. Largura máxima 720 pt, padding 32 horizontal / 24 vertical, para linhas longas manterem layout legível. Tabelas são desenhadas célula a célula com stacks horizontais e divisores; código inline pelo engine markdown embutido. Blocos reais de código são tratados como parágrafo no momento — limitação conhecida da janela de ajuda.

Keyboard Shortcuts (W5–W6)

Lista estática de referência em cinco seções. Navigation: arrastar mouse (orbit/fly), Shift+drag/right-drag (pan), scroll (zoom), WASD (movimentação fly-through), Q/E (up/down), F (toggle orbit/fly), duplo clique (recentralizar), Cmd+scroll (ajustar FoV). Views: R (reset câmera), T (auto rotação), P (camera playback), B (ciclar background), 0–9 (saltar para training cam 1=10 %/5=50 %/0=último), seta esquerda/direita (cam prev/next). Capture: S (screenshot para Desktop), V (vídeo turntable), C (copiar info de câmera). Editor: Tab (modo edit), clique/arrastar (paint select), Option+clique (desselect), X / Delete (remove seleção), Cmd-Z (desfazer última remoção), [ / ] (reduzir/aumentar pincel), Esc (limpar seleção). Training: start, pause/resume, cancel, continue +5K/+10K/+20K via atalhos de menu em M9–M14.

O que é: um overview estático simples dos atalhos — Navigation, Views, Capture, Editor, Training. Conteúdo hardcodado, sem markdown loading.

Quando você procura o caminho mais rápido para algo no viewport. Movimentação WASD, R para resetar câmera, B para ciclar background — tudo está aqui.

W5ScrollView (área de conteúdo)

ONDE

Help → Keyboard Shortcuts (⌘/)..

TÉCNICO

Área scrollável simples com lista vertical dentro. Padding 20 ao redor, sem árvore de navegação na sidebar (a lista é curta o suficiente). Conteúdo agrupado em cinco seções (Navigation, Views, Capture, Editor, Training). Por atalho, uma linha com texto traduzível nas duas colunas. Coluna esquerda (código de tecla) fixa em 180 pt para alinhar verticalmente. Sem interação além de scroll — clicar numa linha não dispara nada; os atalhos são modificadores de teclado reais no menu e no viewport.

W6VStack (seções de atalhos)

ONDE

Dentro do ScrollView..

TÉCNICO

Seções empilhadas alinhadas à esquerda com 16 pt de espaçamento. Em cada uma das cinco, heading + sequência de linhas. Headings usam estilo subheadline secundário — deliberadamente sem formato título, porque as seções não precisam ser navegáveis. Conteúdo proposital plano (sem disclosure, busca, filtro), para o componente rodar inalterado em toda versão de macOS e o arquivo continuar legível.

Manage Storage (W7–W12)

Visão em tabela de todos os arquivos gerenciados pelo RadianceKit. Cabeçalho conta 693 itens, 16.74 GB. Toolbar acima: „Show in Finder" + „Refresh". Cada linha: ícone PLY, nome do arquivo (p. ex. training_20260527T211321Z.ply), data de export, tamanho (variando de 7 KB a 218 MB), ícone de lupa (Reveal) e ícone de lixeira (Move to Trash). Arquivos ordenados por data, mais novos em cima. Nesta captura demo, exports PLY dominam por causa do uso intensivo de –benchmark.

O que é: um overview de uso de disco para tudo que o RadianceKit grava em ~/Documents/RadianceKit/ — logs, exports, scenes, capture bundles (do companion iOS), imports (cópias staging das imagens de entrada). Por item um tamanho em bytes e dois botões: „Show in Finder" e „Move to Trash". NÃO é limpeza automática — o app não apaga nada por conta; você decide por item.

Quando o disco enche. Os logs são os maiores acumuladores (um JSONL por tentativa de treinamento, mais o _qualityMetrics.json); exports também (PLY 100 % cru, um por export). Também útil após um crash, quando o diretório de staging de imports ainda tem cópias antigas das imagens de entrada (veja „Disk-pressure incident" em dev_v549f-needle-reduction.md).

W7Botão „Show in Finder"

ONDE

Cabeçalho acima à direita no Storage Browser..

TÉCNICO

Abre todo o diretório do RadianceKit (~/Documents/RadianceKit/) no Finder, para você ver a estrutura de pastas e mexer com o próprio Finder. A ação abre uma nova janela do Finder e não muda para o container sandbox do app — ~/Documents/RadianceKit/ é a domain Documents acessível regularmente a apps, não um caminho de container sandboxed.

W8Botão „Refresh"

ONDE

Cabeçalho, ao lado do botão Finder..

TÉCNICO

Dispara um scan em background numa task assíncrona iniciada pelo usuário, para que escanear árvores grandes não bloqueie a UI. O walk percorre cada subpasta conhecida (Logs, Exports, Scenes, Captures, Imports) e cria uma entrada de Storage por filho direto. Por entrada o tamanho recursivo é apurado — preferencialmente o uso real em disco (incluindo compartilhamento de hardlinks APFS) com fallback no tamanho lógico.

W9List (entradas de Storage)

ONDE

Conteúdo principal abaixo do cabeçalho..

TÉCNICO

Lista com layout por linha: ícone SF Symbol específico da categoria (documento para Logs, seta de upload para Exports, cubo para Scenes, bandeja para Imports), nome + subtítulo (rótulo de tipo + data de modificação formatada), contador de bytes à direita (alinhado à direita, monospaced), botão Reveal (lupa), botão Trash (lixeira). Ordenação: primária por tipo (Scenes primeiro, depois Exports, Logs, Captures, Imports, Other), secundária por data de modificação descendente (mais nova em cima). Se o scan ainda roda, aparece um indicador „Scanning…". Se nada foi encontrado, um empty state com ícone de bandeja.

W10Botão de linha „Reveal in Finder"

ONDE

Por linha, ícone de lupa à direita..

TÉCNICO

Abre o Finder e seleciona o item específico (arquivo ou pasta). Diferença para W7: W7 abre o diretório raiz; W10 marca exatamente essa entrada. Fluxo prático: identifique uma entrada grande, clique na lupa e copie para um volume externo, por exemplo.

W11Botão de linha „Move to Trash"

ONDE

Por linha, ícone de lixeira à direita da lupa..

TÉCNICO

Dispara o diálogo de confirmação (W12). Só após confirmar roda a operação padrão do macOS „mover para lixeira" (reversível, sem apagar de fato). Após sucesso, a entrada some da lista e o contador de bytes total é atualizado. Em erros aparece um diálogo modal.

W12ConfirmationDialog (confirmação de remoção)

ONDE

Disparado pelo W11, exibido como sheet do macOS..

TÉCNICO

Diálogo de confirmação padrão com título dinâmico „Delete <name>?" e mensagem explicitando que a entrada vai para a lixeira e pode ser restaurada de lá (até esvaziar). Dois botões: „Move to Trash" como destrutivo (vermelho) e „Cancel" com binding automático em Esc. Diálogo não modal no sentido de só bloquear essa janela, não todo o app — padrão macOS para remoções reversíveis.

Pareto Dashboard (W13–W22)

Estado vazio (na primeira abertura) — empty state com call to action „Open Reports Folder…". Os pontos aparecem assim que training reports são carregados; ver próxima captura.

A toolbar mostra „129 reports of 129" (todos parseados com sucesso — 21 outros não puderam ser parseados por formato antigo; veja lista de hint à direita). Eixos: seletor X em Gaussians, Y em PSNR (dB). Scatter plot: pontos verdes = estratégia Classic, azuis = MCMC. A linha tracejada da frente de Pareto segue os melhores valores de PSNR e platô em PSNR≈30 dB a partir de cerca de 500K Gaussians. Filtros à direita: 7 cenas (bicycle, bonsai, family, flowers, kitchen, stump, truck), 2 estratégias (classic, mcmc), 3 opções de Mip Splatting (All, On, Off). Nesta demo, todos os filtros abertos — daí o cluster denso.

O que é: uma ferramenta de comparação multi-run. Você treinou várias cenas, ou a mesma cena com várias predefinições, e cada corrida produz (quando você usa –benchmark ou a função de benchmark) um arquivo JSON de report com, entre outros, PSNR final, SSIM, LPIPS, Gaussian count e wallclock. O dashboard lê uma pasta inteira de reports e plota em scatter 2D com eixos selecionáveis. Além disso, a frente de Pareto (conjunto dos não dominados) aparece como linha tracejada.

Depois de pelo menos três ou quatro reports de treinamento. Com menos pontos, a linha de frente não é significativa. Caso típico: você tentou reconstruir uma cena externa rodando sequencialmente P3 Balanced (Classic), P4 Quality (Classic), P7 MCMC Quality e P9 Outdoor (tuned) — e agora quer saber qual config entrega o melhor PSNR por segundo de treinamento ou qual precisa de menos Gaussians para um dado PSNR.

Os dois eixos são livres (X:, psnr, ssim, lpips, …; Y igual). A lógica ParetoFront2D.indices sabe por métrica se „menor é melhor" (p. ex. LPIPS, loss, time) ou „maior é melhor" (PSNR, SSIM) — a linha vai de baixo esquerda para cima direita, ou de cima esquerda para baixo direita, sempre na melhor combinação. Um ponto é Pareto-ótimo quando NENHUM outro é pelo menos tão bom em AMBAS dimensões (ninguém o domina). Os Pareto-ótimos ficam na linha; outros ficam à direita/acima dela. Pontos NA linha são candidatos a „melhor preset"; pontos LONGE da linha são tempo de treinamento desperdiçado.

Você pode restringir a uma cena (p. ex. só Outdoor), a uma estratégia (Classic ou MCMC), ou Mip Splatting on/off (relevante pós Fase Q1.5, onde Mip ficou como flag opt-in avançado).

Você tem três reports da cena „truck" em ~/Documents/RadianceKit/Reports/: Run A (P4 Quality, 40K iter, 524K Gs, 105 s, PSNR 23.4), Run B (P7 MCMC, 200K iter, 150K Gs, 693 s, PSNR 24.6), Run C (P9 Outdoor, 100K iter, 1.25M Gs, 312 s, PSNR 25.8). Eixo X em trainingTime, Y em PSNR. Run B fica acima à direita, Run C ainda mais acima à direita, Run A abaixo à esquerda. A frente de Pareto liga A e C — ambos não dominados. Run B fica „perdido" (C melhor em tempo E PSNR). Conclusão: para „truck", o default MCMC não vale; ou rápido+ok (A) ou longo+muito bom (C). Salve a config de C como predefinição própria (Inspetor → I1 Save Preset).

Próxima ação: salve a melhor config como predefinição. Concretamente: olhe os pontos Pareto (hover mostra PSNR/SSIM/LPIPS/Gs/Time num tooltip), decida qual trade-off time-vs-quality combina, abra o report (nome contém timestamp), copie sua TrainingConfig num novo run ou salve como predefinição após a próxima sessão.

W13Botão „Open Reports Folder…"

ONDE

Toolbar em cima à esquerda..

TÉCNICO

Abre um seletor de pasta com instrução „Select a folder containing benchmark .json reports". Após confirmar, uma task em background parseia sequencialmente todos os .json. Reports com falha (JSON quebrado, schema errado) são coletados e listados embaixo na sidebar como „N file failed to parse" — sem crash. Se um segundo clique acontece durante um load anterior, o task anterior é cancelado, evitando dois resultados gravando no state.

Também via CLI: –dashboard-dir /caminho/para/reports carrega a pasta logo no início.

W14Picker „X-Axis"

ONDE

Acima do chart, à esquerda..

TÉCNICO

Picker de menu com todas as métricas disponíveis (PSNR, SSIM, LPIPS, contagem de Gaussians, tempo de treinamento etc.). Padrão é Gaussian count. Ao trocar, o ponto em hover é resetado, porque uma posição realçada não faz sentido em novo sistema de eixos. Limitado à largura do conteúdo, para não esticar por toda a largura.

W15Picker „Y-Axis"

ONDE

Acima do chart, ao lado do X-Axis..

TÉCNICO

Idêntico ao W14, mas o padrão é PSNR. A escolha é gravada independente, ou seja, o usuário pode pegar combinações sem sentido (X=PSNR, Y=PSNR — tudo na diagonal). Combinações assim não são impedidas; é decisão proposital, porque comparar „SSIM vs PSNR" pode ser interessante para ver consistência entre métricas.

W16Toggle „Show Pareto Front"

ONDE

À direita dos pickers de eixo..

TÉCNICO

Toggle padrão macOS. Quando ativo, além dos pontos é desenhada uma linha com a frente de Pareto 2D computada. Estilo: tracejado (4-4), cinza semi-transparente, 1.5 pt. Cálculo no main thread — para a quantidade típica de reports (≤~50) é rápido. Quando desligado, a linha some.

W17Chips de filtro „Scene"

ONDE

Sidebar à direita..

TÉCNICO

Chips de filtro para cada cena nos reports carregados. Layout flow próprio, que quebra chips em várias linhas quando a largura acaba. Chips ativos têm cor de destaque; inativos, material padrão. Multi-seleção via set semantic; sem nada selecionado, todas as cenas passam — ou seja, „seleção vazia = tudo", não „seleção vazia = nada".

W18Chips de filtro „Strategy"

ONDE

Abaixo do filtro Scene..

TÉCNICO

Exatamente como W17, mas para estratégias — tipicamente os dois valores „classic" e „mcmc", do campo strategy dos reports. Útil quando você tem reports das duas estratégias misturados e quer ver só uma (p. ex. „só MCMC porque Classic já tirei").

W19Chips de filtro „Mip Splatting"

ONDE

Abaixo do filtro Strategy..

TÉCNICO

Filtro de três valores (em vez de set como em W17/W18): „All" / „On" / „Off". Contexto: Mip Splatting foi avaliado como melhoria multi-escala experimental na Fase Q1.5 e o veredito final foi „sem ganho consistente; mantido como flag opt-in". Quando você compara Mip on/off, quer separar nítido. Daí o filtro ternário dedicado com „passar tudo", „só Mip on", „só Mip off". Seção só aparece quando há pelo menos um report Mip E um não Mip (senão filtrar não faz sentido).

W20ChipButton (toggle de filtro, all/on/off)

ONDE

Componente helper usado em W17/W18/W19..

TÉCNICO

Wrapper minimalista. Conteúdo: rótulo em caption + padding 10 horizontal/5 vertical. Background condicional: ativo → cor de destaque com texto branco; inativo → material neutro com texto preto. Forma capsule (pílula). Plain button style para o material capsule não ser sobreposto por borda do sistema.

W21Chart (scatter Pareto)

ONDE

Área central do dashboard..

TÉCNICO

Gráfico Swift Charts com dois layers: 1. um ponto por report — posição pelos X/Y escolhidos, cor por estratégia, símbolo por status de Mip. Tamanho normal 80, highlighted 200 (se a ID bate com o report em hover). 2. uma linha para a frente de Pareto, só com toggle on.

Overlay do chart: um retângulo transparente registra movimento de mouse; por frame, o ponto euclidiano mais próximo no plot frame é determinado e o report em hover atualizado se a distância < 24 px (senão reset). Tooltip sem clicar — hover basta.

W22Tooltip (detalhe em hover)

ONDE

Abaixo do chart, exibido em hover..

TÉCNICO

Stack horizontal: nome da cena (headline), tag de estratégia (caption), divisor, depois métricas PSNR/SSIM/ LPIPS/Gs/Time em grupos verticais (label + valor monospaced). Se Mip estava ativo, tag „Mip" capsule em cor de destaque. Background semi-transparente com blur, cantos arredondados 8 pt. Aparece só se o mouse está sobre um ponto; some ao sair.

Holdout Analysis (W23–W29)

Estado vazio com empty state e call to action „Open transforms.json…". Aceita formatos NeRF Studio e Instant NGP.

Estado vazio (na primeira abertura) — os marcadores de câmera aparecem assim que uma transforms.json é carregada, veja próxima captura.

Cabeçalho mostra arquivo carregado (transforms_train.json) e contagem de câmeras („100 cameras"). Sidebar à esquerda: picker Strategy com duas opções — Angular (longitudinal) ativo (alinha folds por setores long/lat na esfera, cada test fold fica geometricamente denso) vs Linear (round-robin) (baseado em ordem, todo k-ésimo frame como test set). Slider de k folds em 5, picker de test fold em fold 1. Botão Export gera um fold-assignment.json para Nerfstudio/Instant NGP. Painel central: projeção em globo 3D das 100 câmeras — pontos verdes = train, vermelhos = test fold atual (fold 1 com 20 câmeras). Sidebar à direita (Angular Correlation): por fold 20 cams + Mean Nearest Angle (Fold 1: 7.9°, Fold 2: 7.8°, Fold 3: 7.7°, Fold 4: 7.0°, Fold 5: 6.3°) — menor valor significa câmeras dentro do fold mais próximas entre si, ou seja, holdout split coerente espacialmente.

O que é: um visualizador 3D do arranjo de câmeras com lógica de cross validation. Você carrega um transforms.json (formato padrão Nerfstudio/Instant NGP para poses de câmera); o app lê todas as câmeras, projeta suas direções de vista numa esfera unitária e mostra como pequenos marcadores num globo virtual. Em seguida divide as câmeras em k folds (pela estratégia: angular ou linear), marca em verde o train e em vermelho o test (holdout), e calcula por fold um score de correlação angular dizendo quão longe o test está do train no espaço de ângulos.

Quando for fazer avaliação de holdout — ou seja: quão bem o modelo generaliza para ângulos não vistos? O padrão no treinamento é „toda 8ª view como holdout" (convenção Mip-NeRF360), mas é uma divisão muito linear. Se suas imagens estão clusterizadas no tempo (primeiro um lado do objeto, depois o outro), „toda 8ª" não é representativo — uma posição aleatória vai para test, mas todas as vizinhas estão em train, é fácil demais. Com „angular" você estratifica pelo espaço de ângulos: cada fold contém câmeras de todas as regiões da órbita, e o test mede de fato lacunas de generalização.

Angular vs Linear: - Angular (padrão): divide as câmeras pelo longitude φ (coordenada em torno do eixo Y) em k setores iguais. Fold 0 são câmeras com φ ∈ [0°, 360/k°), Fold 1 as próximas, etc. Vantagem: cada fold cobre um sub-setor da órbita; o test fica espacialmente compacto mas amplo sobre o dataset mundial. Bom para capturas orbit clássicas. - Linear (round robin): fold index = (image_index modulo k). É o simples „every-k-th". Funciona se a ordem das imagens NÃO tem viés espacial (p. ex. drone aleatório). Funciona mal se imagens clusterizam no tempo.

No globo 3D você vê na hora: pontos verdes (train) e vermelhos (test). Se os vermelhos estão todos num canto, o holdout está ruim (sem bom teste de generalização). Se ficam distribuídos entre os verdes, está bom. O score de correlação angular por fold (sidebar à direita, em graus) também diz: menor valor = test próximo do train (cada cam de test tem cam de train próxima, teste fácil); maior valor = test distante do train (generalização mais dura).

Você capturou sua cena Truck com 251 imagens, exporta via menu M33 (Export SfM transforms.json) um arquivo nerfstudio. Abra a janela Holdout (⇧⌘H), carregue o JSON via „Open transforms.json…", veja o globo. k=5 (padrão) dá 5 folds. Clique em „Fold 3" — veja se os vermelhos ficam mais ou menos uniformes. Se sim: „Export fold-assignment.json", coloque na pasta Reports e no próximo treinamento com –benchmark (ou as configurações correspondentes do Inspetor), essa partição é usada como test holdout — em vez do padrão „toda 8ª".

W23Botão „Open transforms.json…"

ONDE

Toolbar acima à esquerda..

TÉCNICO

Abre um seletor de arquivo restrito a JSON. Após confirmar, o módulo holdout carrega. O loader parseia tanto o formato nerfstudio (intrínsecas + lista de frames com caminho e matriz transform) quanto instant ngp (mesma estrutura). Por frame extrai a direção de vista da matriz (eixo Z da base local da câmera) e salva. Se o parse falha, aparece uma mensagem de erro no status.

Também via CLI: –holdout-file /caminho/para/transforms.json inicia a janela já com arquivo carregado.

W24Picker „Strategy" (angular/linear)

ONDE

Sidebar à esquerda, em cima..

TÉCNICO

Picker radio com duas opções: Angular e Linear. A troca dispara recalculo automático dos folds. As direções de vista são uma lista de vetores unitários 3D na esfera; a estratégia Angular projeta no longitude φ e ordena, a Linear faz divisão modulo pelo índice de frame.

W25Slider „k Folds"

ONDE

Sidebar à esquerda, no meio..

TÉCNICO

Slider de 3 a 10, passo 1. Mudança dispara recálculo automático dos folds; a lista de folds, índices de train/test e o score por fold são recalculados em seguida. O valor é exibido como texto monospaced à direita do label.

Regra prática: k=5 padrão (20 % por fold, usual em cross validation). k=10 com muitos dados e mais folds para força estatística. k=3 com poucos dados.

W26Picker „Test Fold"

ONDE

Sidebar à esquerda, abaixo do slider k..

TÉCNICO

Picker de menu. Opções dinâmicas 0..<k, rótulo „Fold 1" a „Fold N" (1-indexed na UI, 0-indexed internamente). Se o índice escolhido antes ≥ k (p. ex. você reduziu k de 10 para 5), é resetado para 0. O test fold escolhido aparece em vermelho no globo; os outros em verde.

W27Botão „Export fold-assignment.json"

ONDE

Sidebar à esquerda, embaixo..

TÉCNICO

Abre um diálogo de salvar com nome padrão fold-assignment.json. Após confirmar, o módulo holdout codifica a partição atual num schema JSON (atribuição por frame + bloco meta de estratégia). O arquivo pode ser passado no próximo treinamento com –benchmark, usando o mesmo holdout para a avaliação de métricas final. Erros de gravação aparecem como texto de erro; sucesso em texto verde como „Saved to (filename)".

W28SCNView (globo de câmeras 3D)

ONDE

Painel central da janela Holdout..

TÉCNICO

Globo SceneKit. A cena consiste em: uma esfera wireframe (raio 1.0, 36 segmentos, cinza escuro), três pequenos cotos de eixo (vermelho/verde/azul para X/Y/Z, 1.2 de comprimento) e, por câmera, uma esfera marcadora (raio 0.03) na posição da direção de vista na esfera unitária (ligeiramente fora para não desaparecer DENTRO do wireframe). Os marcadores NÃO são reconstruídos a cada mudança de fold — rebuild só quando a lista de frames muda (novo JSON carregado). Por update há atualização in-place das cores de material: vermelho para test, verde para train, cinza claro para nenhum. Assim, os ticks do slider ficam performáticos mesmo com N > 1000 câmeras.

O controle de câmera está ativo — você rotaciona, dá zoom e faz pan com o mouse. Iluminação evita marcadores chatos. Fundo cinza escuro.

W29FoldCard (toque para selecionar fold)

ONDE

Sidebar à direita, seção „Angular Correlation"..

TÉCNICO

Por fold um card view — retângulo arredondado raio 6 pt, padding 10, layout vertical em duas linhas (em cima „Fold N" + número de câmeras; embaixo „Mean nearest angle:" + valor em graus). Background condicional: fold ativo = cor de destaque semitransparente; inativos = material neutro. Tocar seleciona o fold; o globo recolora ao vivo.

O „Mean nearest angle" é o menor ângulo médio por câmera de test para a câmera de train mais próxima (cálculo interno em radianos, exibido em graus).

BayesOpt Console (W30–W39)

Estado vazio com picker de search space (RadianceKit defaults (6-dim)), slider de trial budget (default 40), random seed (42) e três painéis vazios para convergence chart, trial log e lista de parâmetros do search space.

Estado vazio (na primeira abertura) — convergence chart e tabela de trials enchem assim que um run inicia; veja próxima captura.

Status acima à direita „Finished — best 0.9943 after 40 trials". Sidebar à esquerda: picker em RadianceKit defaults (6-dim), trial budget 40, random seed 42. Lista de parâmetros mostra os seis hiperparâmetros a ajustar e suas faixas: mipSmoothing3DScale [0.05, 0.5], mipFilter2DVariance [0.1, 0.6], densifyGradThreshold [5e-07, 5e-06], ssimWeight [0.05, 0.5], mcmcNoiseScale [1e-05, 0.0001], mcmcRelocationInterval [50, 200]. Centro: convergence chart (X = índice de trial 1–40, Y = objective value 0–1) — pontos cinzas = samples iniciais (LHS), azuis = acquisition BayesOpt, laranjas = trials restart (#22 e #31). Linha de best so far sobe íngreme até trial ~7, depois melhoria marginal até trial 15; daí plateau em 0.99+. Sidebar à direita: trial log #1–#34 com score + tag (init/bo/restart). Save Best Config no topo direito grava bayesopt-best.json.

O que é: um console de otimização bayesiana para busca de hiperparâmetros. BayesOpt é um método automático que tenta, com o mínimo de experimentos possível, encontrar o ponto ótimo de uma função desconhecida — tipicamente: „qual combinação de mcmcMaxGaussians, capMultiplier, ssimWeight e gradThreshold dá o melhor PSNR para minha classe de cena?" Em vez de um grid de 6^4 = 1296 trials, BayesOpt tenta cerca de 40–100 trials informados e chega perto do ótimo.

Importante: a versão atual no app não executa a otimização contra runs reais de treinamento (levaria dias), mas contra uma demo objetiva sintética — uma paisagem multimodal com caráter de hill climbing e ruído leve. Foi proposital: a janela deve te mostrar o comportamento do otimizador (curva de convergência, samples, best so far) e te fazer entender as definições de search space. Para runs reais BayesOpt orientados por treinamento (como na Fase Q7 para os Scene Class presets), um workflow offline de CLI é usado separadamente; a janela é a variante UI live.

Três casos: 1. Você quer entender como BayesOpt trabalha — inicie um run demo e veja o convergence chart. 2. Você planeja uma nova classe de cena (p. ex. „aquários" ou „móveis antigos") para a qual os 10 presets embutidos não encaixam. Defina mentalmente um search space, teste aqui com „Bowl demo" ou o preset „Densify", exporte a melhor config como JSON e use como ponto de partida para um run real. 3. Você quer inspecionar os search spaces default definidos no package RKBayesOpt (Mip subset, RadianceKit defaults) — eles aparecem no painel de parâmetros da sidebar à esquerda.

- Convergence chart (coluna central): Y = melhor valor objetivo até agora. X = índice de trial. No início sobe íngreme (BayesOpt sorteia samples iniciais; alguns dão sorte); depois fica mais plano, porque a vizinhança próxima do ótimo foi explorada. Se a linha fica plana por 20+ trials, pode parar — mais trials não trazem nada. Os pontos individuais são os valores de trial (não „best so far"), coloridos por fase: cinza = sample inicial, azul = acquisition, laranja = restart. - Tabela de trials (coluna direita): #1, #2, #3, … com valor e tag de fase. O melhor trial tem estrela amarela. Da tabela você identifica o melhor e vê os valores de parâmetro no export. - Search space inspector (sidebar à esquerda): mostra, para o preset escolhido, todos os nomes de parâmetro e suas faixas [lo, hi]. Em „RadianceKit defaults (6-dim)" você vê, p. ex., „densifyGradThreshold [5e-7, 5e-6]" — log-uniform entre os dois.

Escolha o preset „RadianceKit defaults (6-dim)", trial budget 40, seed 42. Clique „Start". Observe: os primeiros 8 trials são cinzas (samples iniciais, LHS Latin Hypercube); os próximos azuis (acquisition). O convergence chart sobe íngreme até trial ~15; depois achata. Em trial ~30–40 o melhor estabiliza. Clique „Save Best Config" — bayesopt-best.json é salvo com nome do preset, índice do trial, valor e parâmetros decodificados. Pode levar manualmente para sua definição de preset.

W30Botão „Start"

ONDE

Toolbar à esquerda, em idle/finished..

TÉCNICO

Reseta a lista de trials, vai para running, gera novo run ID (para detecção de stale em cliques múltiplos) e cria pause gate fresco. Em seguida inicia uma task em background que roda o otimizador como stream assíncrono. O tamanho de samples iniciais sai de min(8, budget / 4 + 1) — típico 8 LHS com budget ≥ 28, menos com budget pequeno. Updates incrementais são anexados à lista. Stale run protection: se um segundo clique em Start define novo run ID no meio do caminho, updates do run anterior são descartados.

Primary action style para um botão proeminente.

W31Botão „Pause"

ONDE

Toolbar à esquerda, em running..

TÉCNICO

Ativa o pause gate e vai para paused. Efeito real: o runner espera num polling de 50 ms antes da próxima avaliação. O trial em curso termina (sintético, dura microssegundos), mas nenhum próximo é disparado. Em resume, continua de onde parou.

W32Botão „Stop"

ONDE

Toolbar à esquerda, em running e paused..

TÉCNICO

Cancela a task do runner, zera a referência, solta o pause gate (se em paused) e vai para finished (se há trials) ou idle (se nenhum). Trials já calculados permanecem visíveis — Stop não apaga. Role de botão destrutivo (mostra em vermelho), porque cancela.

W33Botão „Resume"

ONDE

Toolbar à esquerda, em paused..

TÉCNICO

Solta o pause gate e volta para running. A task já está rodando (esperando no polling); assim que o loop percebe o release, segue e dispara o próximo trial.

W34Botão „Save Best Config"

ONDE

Toolbar à direita, sempre visível (mas desabilitado sem bestTrial)..

TÉCNICO

Abre diálogo de salvar com nome padrão bayesopt-best.json, restrito a JSON. Após confirmar, monta um dicionário payload: nome do preset, índice do trial, valor (objective score), parâmetros (dict de nomes de parâmetro decodificados → valores). A decodificação projeta as coordenadas normalizadas em [0,1]^d de volta na faixa original (com escalas log-uniform/linear/inteira). JSON pretty printed com chaves ordenadas. Em erro (na versão demo atual) ignora em silêncio — sem UI de erro, é um caminho demo.

O botão fica cinza enquanto nenhum trial rodou.

W35Picker de preset „Search Space"

ONDE

Sidebar à esquerda, em cima..

TÉCNICO

Picker de menu com quatro opções: - „RadianceKit defaults (6-dim)" — search space completo com hiperparâmetros Q7. - „Mip subset (2-dim)" — só mipSmoothing3DScale [0.05, 0.5] log-uniform e mipFilter2DVariance [0.1, 0.6] linear. Útil para tunar Mip Splatting numa classe de cena. - „densify-until + ssim-weight + grad-thresh" — três parâmetros densify-relevantes (densifyGradThreshold log-uniform, ssimWeight linear, densifyUntilIter inteiro). - „Bowl demo (1-dim)" — search space pedagógico de um parâmetro para demos „assim funciona BayesOpt".

Com um run ativo, o search space não pode ser trocado (confundiria o otimizador).

W36Slider „Trial Budget"

ONDE

Sidebar à esquerda, abaixo do picker..

TÉCNICO

Slider de 10 a 200, passo 5. Padrão 40. Significa: BayesOpt pode fazer no máximo N trials. Destes, os primeiros são samples iniciais (Latin Hypercube); o resto são BayesOpt reais. Regras práticas: um search space com d dimensões precisa de cerca de 10d a 20d trials. Em 6-dim defaults, 60–120; em 2-dim Mip subset, 20–40; em 1-dim Bowl, 10–20.

Durante o run, slider desabilitado.

W37Slider „Random Seed"

ONDE

Sidebar à esquerda, abaixo do slider de budget..

TÉCNICO

Slider de 1 a 100, passo 1. Padrão 42. Seed é repassado tanto para os samples LHS iniciais quanto para o componente de ruído da demo objective. Reprodutibilidade: mesmo seed + mesmo search space + mesmo budget dá sequência de trials idêntica. Útil para „seus colegas pegam o mesmo run ao refazer a demo?". Desabilitado durante o run.

W38Chart (convergência)

ONDE

Coluna central da janela..

TÉCNICO

Gráfico Swift Charts com dois layers: 1. uma linha para „best-value-so-far" por trial — curva monotonicamente crescente ou constante na cor de destaque. 2. um ponto por trial com o valor objetivo individual, colorido por fase. Tamanho de símbolo 40. Três rótulos de fase: „init" (cinza), „bo" (azul), „restart" (laranja).

Pequena legenda mostra as cores em cima à esquerda. Se a lista de trials está vazia (antes do primeiro start), aparece um empty state com ícone de chart e a dica „Press Start to begin a BayesOpt run.".

W39Table (trial log)

ONDE

Coluna direita da janela..

TÉCNICO

Área scrollável com linhas de trial empilhadas lazy. Por linha um stack horizontal: número do trial (3 dígitos monospaced, à esquerda), valor (monospaced, alinhado à direita, 70 pt), tag de fase (capsule, cor da fase em 25 % opacity); opcionalmente uma estrela amarela se for o melhor. Auto scroll automático: o painel salta para o fim sempre que um novo trial chega — assim você acompanha o fluxo ao vivo no rodapé sem rolar.

Janela principal: curva de loss e Gaussian count (I39–I41, cross-reference)

Três indicadores do Inspetor na janela principal merecem uma explicação à parte, porque ficam visíveis durante o treinamento todo e existem regras práticas importantes sobre quando o curso está saudável. Os indicadores estão na seção „Loss Chart" do Inspetor (Capítulo 2 — Inspetor) e complementam a Holdout Analysis da janela auxiliar acima.

Quando a curva de loss está saudável? Uma curva sadia mostra três fases: (1) Warmup — as primeiras 200–500 iters caem íngreme de alto (típico 0.15–0.25 para L1+SSIM combinados, conforme a cena) para mais ou menos metade. Se o loss NÃO cai nesta fase, em geral a entrada está errada (imagens quebradas, poses SfM ruins, número de Gaussians iniciais baixo demais). (2) Densification — entre ~500 e densifyUntilIteration (classic 15K, MCMC 20K ou 25K), o loss cai mais, com pequenos saltos para baixo conforme densify insere novos Gaussians que o otimizador usa. O Gaussian count sobe nesta fase. (3) Refinement — depois disso o loss corre num tail cada vez mais plano. Valores típicos: Tanks & Temples Truck com P4 Quality em L1 ≈ 0.023, Horse com Full Classic V546 em L1 ≈ 0.0230, Mip-NeRF360 externas piores (0.04–0.07).

O que significa um plateau? Um plateau (curva de loss horizontal por vários milhares de iters) tem duas leituras: (a) o modelo convergiu, treinar mais não traz nada — caso bom. (b) o modelo está stuck (mínimo local, gradiente ruim, cap no buffer) — caso ruim. Os dois parecem iguais no chart. Distinguir: olhe o Gaussian count. Se também está plano E perto do cap MCMC (p. ex. 150K de 150K em .fullMCMC), você está no limite — ou aumente o cap ou aceite o plateau. Se o count ainda cresce mas o loss não cai, é stuck.

Cancelar ou continuar? Regra: 10K iters sem melhora do Min loss → cancele, mais iters são desperdiçadas. Antes disso, via Cmd+T (Training → Continue Training → +5K iters) você pode anexar mais, se houver melhora marginal. Atenção: em MCMC o plateau costuma ser real — o cap é o limite natural.

Plateau de Gaussian count NÃO é sinal de „pronto". Significa só que MCMC bateu no cap ou Classic exauriu densification. A pergunta „pronto" mesmo só a Holdout Analysis responde — PSNR/SSIM/LPIPS em test set independente, avaliado na janela Holdout (W23–W29) ou via –benchmark.

PSNR/Holdout é a verdade; loss é só proxy. O loss é métrica relativa: cai conforme o modelo se ajusta às training views. Loss baixo não significa modelo bom — se decorou as training images (overfitting), o loss é pequeno mas o PSNR em views não vistas (holdout) é ruim. Por isso: para avaliação final, sempre olhe métricas de holdout, não só end-loss.

Caixa de regras práticas

- User Guide e Keyboard Shortcuts são ajuda estática — rápido para palavra-chave; para profundidade, este manual. - Manage Storage assim que o disco tiver menos de 10 % livre. Logs e staging de imports são os principais culpados. - Pareto Dashboard só faz sentido depois de pelo menos três ou quatro reports. X = custos (time/Gs), Y = qualidade (PSNR/SSIM). Pareto front mostra as combinações eficientes. - Holdout Analysis antes de publicar benchmarks PSNR — garante que seu test set é representativo. - BayesOpt Console é sobretudo ferramenta de aprendizado e inspeção dos search spaces. Para tuning real de hiperparâmetros por treinamento, use o workflow CLI offline. - Plateau de loss e plateau de Gaussian count são interpretados separadamente. Cap não é sinal de „pronto". Qualidade real só holdout PSNR mede. - 10K iters sem melhora de Min loss → parar.