xiaotao-02/wireframe-3d

O que wireframe-3d faz?

Converta um objeto físico ou processo de produção em uma obra tridimensional observável, desmontável e explicável. Atribua o foco de produção de acordo com o objetivo do usuário: divulgação científica prioriza a explicação do mecanismo; modelagem por referência prioriza a restauração da aparência visível, adicionando depois a estrutura, movimento e interface necessários.

O objetivo é aceito em duas dimensões: estrutura/interatividade utilizável e forma de referência/expressão visual correspondente. A primeira não pode substituir a segunda; a eficácia em casos antigos não prova automaticamente a qualidade de um novo tema.

Quando o usuário fornecer imagens e solicitar modelagem, reprodução ou feedback "não parece / não funciona", antes de escolher o método de construção, aplicar modelos ou gerar o corpo principal, leia Modelagem por Referência e Primeira Entrega. Primeiro, confirme o contorno, superfície curva, abertura e material que determinam a recognição; não altere automaticamente para um estilo científico simplificado por invocar esta skill. Em uma única solicitação do usuário, conclua ativamente a renderização, revisão de imagem e retrabalho necessário, sem esperar que o usuário atue como primeiro inspetor visual.

Ao executar este ramo, leia Ferramentas de Modelagem por Referência: use registros de origem para fixar a base de referência, utilize ferramentas de superfície subdividida/abertura real/superfície anexa conforme necessário, e depois gere um modelo cinza com câmera fixa e uma comparação de materiais. A aprovação na verificação da ferramenta não substitui a inspeção visual.

Para veículos e outras cascas contínuas que recebam feedback de simplificação excessiva, leia Retrabalho Iterativo de Cascas Contínuas: primeiro reconstrua formas controláveis independentemente e bordas compartilhadas, diagnostique a qualidade da malha após corte de furos, depois repare cavidades de luz e pintura contínua; a cada iteração, mantenha o código-fonte correspondente e a vista fixa.

Para produtos de referência que precisam de camadas de material, componentes adesivos ou muitos detalhes repetitivos, leia Integração Prática e Aceitação de Modelagem de Produtos: o material deve ser eficaz na malha entregue, as junções geométricas devem ser configuradas com verificação real; a fusão estática não pode comprometer a semântica, movimento e objetos de medição. Primeiro, salve a linha de base antes da melhoria; depois, mantenha o retrabalho real na mesma tarefa de referência. Casos já usados para ajuste são validação de desenvolvimento, não podem ser renomeados como teste cego independente.

Ao criar explicações estruturais ou de movimento, leia Método de Produção Migrado do Anatomy: determine "operação → mudança no componente → resultado observável", refinando os detalhes nas interfaces funcionais, guias, terminações e espaços negativos. Seu método de produção e a implementação Three.js desta skill são rastreados separadamente; não copie diretamente o sistema de ordenação SVG upstream.

Escolha a Rota de Entrega

• Se o usuário especificar um motor, siga-o. Se não especificado e for uma página web interativa: padrão Three.js, leia Rota Three.js.
• O motor de entrega web e o método de produção geométrica são escolhidos separadamente. Para superfícies curvas contínuas complexas, primeiro verifique se a construção pode expressar a forma chave; se necessário, crie uma malha editável no Blender disponível e depois importe para a web. Quando o usuário solicitar modelagem puramente procedural, respeite esta restrição e escolha um método que possa expressar superfícies curvas e aberturas locais; não aumente apenas o número de amostras de lofting simples.
• Para engenharia editável, renderização offline, animação de câmera: use Blender, leia Rota Blender.
• Para ambas as entregas: compartilhe IDs de componentes, geometria e semântica de estado; verifique ambos os lados separadamente; uma execução em um motor não representa aprovação no outro.
• Para modelagem de produtos comuns sem necessidade de explicação estrutural, pode-se usar o threejs-modeling-studio instalado; esta skill não exige sua presença.
• Ao mudar de tema ou se o modelo não se parecer com a referência, leia Temas e Métodos de Construção. Para edifícios, trate primeiro das plantas, cortes, volumes/aberturas e relações contextuais; para mecânica, trate primeiro de contornos/eixos/cavidades; para fábricas, trate primeiro de postos de trabalho e fluxo logístico; escolha o ramo de acordo com a tarefa real.

Da Referência à Estrutura

Ao criar uma obra nova ou revisar integralmente, escreva primeiro uma mensagem principal que o espectador deve entender e, a partir da solicitação do usuário, organize "deve aparecer / deve ser mantido / proibido de aparecer / formato de entrega". Registre o tamanho real de visualização e o estado padrão; se já houver requisitos, mantenha-os; não pergunte repetidamente para preencher tabelas. Produza de acordo com Comparação Visual e Retrabalho; pode reutilizar Registro de Produção e Verificação de Entrega; para pequenas alterações, atualize apenas os itens afetados.

1. Determine a partir da pergunta do usuário a necessidade real de restauração de aparência, explicação estrutural, demonstração de movimento. Modelagem por referência primeiro fixe a forma externa e características visíveis chave; problemas de mecanismo então determinam quais componentes internos devem ser visíveis. Mecanismos internos, animações de condição e painéis de controle não solicitados não são automaticamente o foco da primeira rodada.
2. Crie uma tabela curta de componentes: id / função / montagem a que pertence / parâmetros / objetos conectados / movimento / origem. Para problemas de mecanismo, primeiro determine a pertença, conexão e caminho causal; depois escolha expressão por corte, expansão ou linhas de chamada; verifique a origem do princípio do mecanismo e se a animação pode ser executada separadamente. Separe componentes reais, auxiliares visuais e partículas esquemáticas. Para fábricas, liste adicionalmente postos de trabalho, caminhos de material, transporte entre níveis e condições de processo.
3. Quando houver desenhos/modelos reais, priorize seu uso; quando não houver dimensões, declare a proporção esquemática e mantenha a consistência dos parâmetros internos. Não apresente exemplos originais como engenharia original, resultado de reprodução ou modelo público do trabalho de referência.
4. Primeiro faça o volume, contorno, conexões e cavidades internas; depois faça os detalhes funcionais. Use aberturas reais para furos, tubos com espessura de parede, suportes que mostrem a relação de suporte de carga. Não substitua a estrutura mecânica central por um conjunto de paralelepípedos com etiquetas.
5. O orçamento de modelagem é determinado pelo objetivo real, grau de visibilidade e recognição; não use um número fixo de componentes ou horas fixas. Para superfícies curvas complexas, use superfícies subdivididas adequadas, malhas subdivididas, lofting de seções, revolução, varredura ou ativos confiáveis; primeiro verifique as partes representativas, depois expanda para o todo. A origem dos ativos e a contribuição da modelagem procedural são explicadas separadamente.
6. Quando o usuário solicitar a restauração de um trabalho existente, primeiro crie uma tabela "característica de referência → arquivo-fonte/função → implementação → captura de tela/evidência de estado", fixando uma câmera comparável. A vista geral e os close-ups devem passar; a quantidade de registros de origem não substitui a similaridade de forma. Etapas específicas em Fidelidade de Referência e Verificação de Animação.
7. Primeiro alinhe o modelo cinza aos contornos principais, espaços negativos e conexões; depois adicione estrutura, material e iluminação; registre suposições quando os dados originais forem insuficientes. De acordo com Comparação Visual e Retrabalho, registre correspondência, diferença e não verificado separadamente; se encontrar problemas de forma chave, continue a reparar o modelo.

Ao migrar HTML de fábrica, leia Código de Exibição Original e Restauração de Dispositivos: restaure a casca e a orientação da seção de robotSvg/toolSvg posto por posto; verifique o deslocamento de tempo externo de draw() e a portão de carga. Primeiro aceite postos representativos; depois expanda com IDs estáveis; assets/lib/source-frame.js fornece orientação de segmentos de braço retangulares. Estados e dispositivos específicos de casos não podem ser tratados como geradores automáticos para qualquer tema.

Relações que Devem Ser Mantidas

Para novos temas com interfaces de ajuste, deslizamento ou tubulações, leia Verificação de Interfaces e Montagem; use assets/lib/assembly.js para entregar coordenadas de interface, normais, diâmetros, relações e verificações de malha real juntos. pass cobre apenas regras configuradas; itens acima do orçamento/não configurados devem ser marcados explicitamente. Teste o verificador com contraexemplos como interfaces intencionalmente desconectadas, diâmetros reais alterados incorretamente, etc.

A auditoria e a pré-visualização devem fazer referência à mesma raiz, componentes semânticos e suas malhas reais; cópias fora da árvore, caixas de seleção e envelopes de auditoria não podem substituir a medição. As sondas de furo/superfície de interface mantêm uma referência independente; alterações incorretas intencionais em componentes reais devem ser detectadas. Se os detalhes de exibição estão completos ainda requer julgamento por close-up.

• Um único conjunto de parâmetros gera geometria, posição de montagem, animação e leituras. rest + explode * offset é o modelo básico de desmontagem; reset retorna à pose de repouso salva, evitando translação cumulativa.
• A animação primeiro lista estados e condições de transição, depois renderiza. Após a desmontagem, inicie; espere a montagem realmente convergir antes de reproduzir a condição de trabalho; pausa congela molas, ruído, partículas e leituras; ao parar, se houver rastro, não delete o efeito diretamente. Quando molas precisam ser defasadas, acione com estado de componente independente; não use o valor alvo do controle deslizante como posição real.
• Web prioriza reutilizar assets/lib/motion.js e scene-runtime.js, permitindo que UI, amostragem de estado e verificação de captura de tela passem pelo mesmo setPose; condições de trabalho complexas podem estender módulos de estado puro. Leia Estado Compartilhado e Aceitação Reproduzível, evitando reescrever o relógio para cada caso ou acumular deslocamento em chamadas repetidas.
• Pivôs colocados no eixo de rotação real ou interface de montagem; subcomponentes se movem com sua montagem. Nomeie os componentes antes da interação; não adivinhe objetos pela ordem de criação.
• Ao encontrar sobreposição na expansão, seções pretas, verso de lâminas finas ou desvio de ação, leia Reparos de Expansão e Ação: configure estágios por módulo semântico, verifique o espaçamento real da malha e injete contraexemplos de sobreposição; não verifique apenas botões ou porcentagens. A biblioteca de execução aplica expansão após setPose; ao migrar código antigo, evite deslocamento duplicado.
• O fluxo do processo adere ao caminho real e ao estado atual. Conexões quebradas após a desmontagem não continuam exibindo fluxo de material ou fluido "desobstruído"; as linhas de fluxo podem ser ocultadas ou alteradas para linhas tracejadas explícitas.
• Ocultação de componentes, visualização transparente, planos de corte e corte sólido com tampas são funções diferentes; nomeie de acordo com a implementação real. Planos de corte sem tampas não devem ser declarados como corte sólido concluído.
• Fases esquemáticas e velocidade de demonstração podem ser exibidas; velocidades reais, temperaturas, vazões, tempos de ciclo, pressões, etc., precisam de origem ou cálculo. Fluxo de partículas não é CFD, rotação de engrenagem não é solução dinâmica.
• Cenas de fábrica organizadas por andar/oficina/posto de trabalho; o estado do processo é então mapeado para dispositivos e materiais. As descrições do processo vêm de dados; agrupamento visual é uma escolha de implementação; não confunda.
• A migração da fábrica verifica o deslocamento externo de draw(), janela HOME e pertencimento de carga. Pode reutilizar assets/lib/process-timing.js com relógio independente e amostragem de borda; verifique um quadro antes, durante e depois de cada ponto de transferência; não use apenas amostragem em intervalos iguais para pular bordas.

Visual e Interação

Quando for necessário manter o estilo visual de dois projetos originais, leia Renderização de Ilustração Unificada; use illustrationPalette() e renderStyle:'anatomy-light'. Compartilhe fundo de papel, sombreamento normal controlado, contornos finos com teste de profundidade e cores de ênfase semântica; compare a captura de tela final na mesma posição de câmera; não substitua a aceitação de estilo por mesmo valor de cor ou aprovação no teste.

Para divulgação científica e sem especificação de estilo visual, herde o contorno claro, material contido e cores de ênfase semântica do Anatomy. Para reprodução por referência, o estilo é determinado pela referência e pela solicitação do usuário: produtos realistas escolhem explicitamente materiais iluminados adequados e ponto de partida renderStyle:'studio'; use anatomy-light apenas quando a expressão de ilustração for necessária. Mudar de estilo não pode reparar superfícies curvas erradas; é preciso realmente inspecionar a imagem.

Para divulgação científica, a primeira tela mostra o corpo principal, estrutura interna chave e movimento compreensível; para exibição de aparência, a primeira tela mostra principalmente o corpo principal da montagem completa; não use casca totalmente transparente para exibir estruturas internas sem suporte de referência. Forneça uma vista principal com espaço suficiente; as etiquetas seguem a posição real dos componentes, filtradas por oclusão e espaço de tela; evite dezenas de linhas de chamada em uma tela.

Web normalmente fornece rotação/zoom, desmontagem, seleção de componentes, pausa/reset; fábricas adicionam filtros de andar e processo conforme necessário. Controles de formulário nativos podem ser operados por teclado; respeite reduced-motion; pause cálculos quando a tela sai da vista ou a página é ocultada. Não adicione painéis de instrumentos não relacionados à explicação apenas para preencher funcionalidades.

O ponto de partida padrão da web usa barra superior compacta, painel de etiquetas, controles de demonstração permanentes e modo de foco; explicações complexas expandem conforme necessário. Ao criar ou otimizar a interface de pré-visualização, leia UI de Pré-visualização; reutilize assets/web/preview-ui.css/preview-ui.js; verifique a margem de segurança da vista do modelo e a operabilidade em tela estreita. O layout pode ser ajustado conforme o estilo do usuário.

Pontos de Partida Executáveis

Novos temas Three.js priorizam o uso de buildScene() com construtor independente e prepare_web.py --builder; a pré-visualização padrão funciona pelos IDs de componentes fornecidos, não precisando mais emprestar hub/rotor/cover da bomba. Leia Biblioteca de Componentes e Interface de Temas; chame assets/lib/ para rotação oca, tubo de diâmetro variável, flange/piso furado, parede de pedra com abertura/moldura, canal de rio de declive suave e ferramentas de câmera/iluminação conforme necessário. Estes são componentes primitivos modificáveis, não um modelador automático de objetos arbitrários.

--example river-pavilion / --example flanged-chamber são problemas de verificação de ferramentas de construção/mecânica originais; não podem substituir o objeto de reprodução especificado pelo usuário. Os scripts/make_demo.py, prepare_web.py --scene e build_blender.py originais mantêm a rota da lista compartilhada da bomba centrífuga. Novos componentes JS e pré-visualização geral não suportam automaticamente o Blender; implemente e verifique separadamente.

--example pneumatic-press fornece novas interfaces, características de malha real, curso, diagrama de conexão e exemplo de renderização de ilustração. A nova verificação de interface JS e shader não são migrados automaticamente para o Blender; não escreva verificação web como verificação de motor duplo.

--example contact-switch fornece uma reconstrução 3D independente do mecanismo de botão do Anatomy: furo guia real, mola de passo variável, seis terminações, distância do fio à placa base e leitura real acionada pela folga do contato. É um exemplo de desenvolvimento; não pode ser tratado como resultado de teste cego para todos os novos temas.

--example indexed-workcell é um exemplo de desenvolvimento de processo original; demonstra construtores de dispositivos diferentes, ciclo independente e HOME, pertencimento de material e cache dinâmico multicolorido. Reutilize factory-process.js com mapeamento explícito de dispositivos e amostragem de condição; dispositivos desconhecidos não podem ser silenciosamente degradados para cubos genéricos. Execute verify_migration.py --three <caminhoThree> --report <JSON> para verificar essas relações e contraexemplos de cor/sombra; depois, inspecione a página real.

• Convenções de Dados Compartilhados: coordenadas, geometria, estado e limites de verificação.
• Mapa de Origem e Migração: heurísticas precisas até o arquivo/função upstream, partes reimplementadas, autorização.
• Quando o usuário especificar um caso de código aberto existente, leia Migração 3D de Trabalhos Existentes: geometria de exibição e proxy de auditoria, extração de estado puro, instanciação e aceitação em navegador real.
• scripts/validate_scene.py: verifica IDs, números finitos, faces degeneradas, malhas fechadas e volume de orientação positiva. Verifica apenas sólidos fechados aplicáveis; superfícies abertas precisam ajustar regras e explicar.
• Após modificar a verificação de interface, execute scripts/verify_assembly.py --three <caminhoThree instalado> --report <JSON de saída>; depois configure furos/superfícies de interface/lacunas reais e contraexemplos de erro para o novo tema; atualmente implementa apenas verificação Three.js.
• Após modificar componentes JS compartilhados, execute scripts/verify_components.py --three <caminhoThree instalado> --report <JSON de saída>; verifique aberturas, espessura de parede, diferentes tamanhos e zona de segurança da câmera; depois abra os exemplos afetados. A verificação numérica não avalia estética.
• Após modificar a expansão ou o enquadramento, execute scripts/verify_explosion.py --three <caminhoThree instalado> --report <JSON de saída>; configure explosionChecks para o tema real e aceite com verify_scene.py; não configurado não conta como aprovado. Pré-visualização com serve_preview.py --root <diretório de saída> --port <porta inicial>; vincule apenas a portas livres locais e desabilite cache de desenvolvimento; recarregue após a geração para verificar o produto atual.
• Novos temas podem executar scripts/verify_scene.py --builder <subject.js> --three <caminhoThree instalado> --report <JSON de saída>; depois, use ferramentas de navegador permitidas no ambiente atual para operar e capturar telas. Quando a automação de navegador independente for permitida, execute node scripts/verify_preview.mjs --url <URL de pré-visualização local> --out <diretório de evidências>; registre capturas de tela, estado e erros; depois, revise as imagens manualmente. Uso, limitações de ferramentas e escopo em Estado Compartilhado e Aceitação Reproduzível.

Não copie todo o repositório upstream para o projeto em execução apenas para usar a skill. O iso-kit, tube, lathe upstream são sistemas de geração SVG; a geometria Three.js/Blender, teste de profundidade e interação desta skill são implementações independentes.

Aceitação e Entrega

Execute de acordo com a funcionalidade real e mantenha resultados reexamináveis:

1. Geometria: verifique parâmetros/ID/unidades/números finitos; furos chave, espessura de parede, eixos, contato e lacunas têm verificação direcionada. A verificação de dados não substitui a verificação de imagem.
2. Estado: verifique montado, semi-desmontado, totalmente desmontado, reset; as leituras em tempo de execução são consistentes com a fase geométrica; pausa não causa saltos. Colisões testadas apenas para pares de peças que não devem estar em contato; não considere contato normal de montagem como erro.
3. Imagem: verifique no tamanho real de visualização a primeira tela padrão, vista principal e vista traseira/lateral; verifique proporção do corpo principal, oclusão, penetração, suspensão, diferença de material, sombras e legibilidade do texto. Teste uma tela estreita na web; reabra .blend no Blender para verificar objetos, drivers e estado do quadro. Quando houver original, adicione comparação de vista geral na mesma posição de câmera e close-ups funcionais; quando houver transparência, fumaça ou chamas, verifique sua oclusão frontal/traseira e processo de parada. Após geometria e estado puro serem aprovados, ainda é necessário compilar o shader e observar a imagem.
4. Releitura de Entrega: Reabra a entrada ou arquivo que o usuário receberá; no visualizador alvo, registre PASS / FAIL / NOT_RUN item por item de acordo com os quatro tipos de requisitos. Quando houver exportação, verifique separadamente o projeto nativo, o produto exportado e o veículo final; quando houver animação, reproduza completamente o fluxo que o usuário experimentará; verifique ações, texto e leituras; amostragem de quadro não substitui verificação contínua. Verifique o console ou o log do Blender; relate desempenho apenas após medição.

O template Three.js atual é gerado por prepare_web.py com lista hash de arquivos e build-info.js. Use verify_preview.mjs --expect-build <id da lista> para vincular capturas de tela à versão real, página, câmera, estado e viewport lido; as imagens ainda precisam de inspeção humana. Quando a versão ou viewport correspondente não puder ser lida, não reutilize capturas de tela antigas como novos resultados. Após alterações em instâncias em lote, sincronize a matriz e a quantidade de faces e contornos; mantenha a semântica de material original; não crie detalhes engrossando todas as hastes finas.

Entregue o ponto de entrada, fonte editável, recursos necessários e algumas capturas de tela chave. Relate fatos de origem, partes originais/adaptadas, verificações executadas e itens não verificados. Quando o usuário solicitar reprodução, corresponda à referência real; não substitua com o exemplo de bomba anexo.

Quando houver exportação, múltiplas versões ou requisitos de entrega explícitos, leia Evidências e Ferramentas de Entrega: corresponda os requisitos à releitura final; vincule código-fonte e hash de captura de tela; impeça registros desatualizados; inicie a pré-visualização local em porta exclusiva; mantenha snapshots independentes verificados para preservar versões. As ferramentas só podem verificar a associação de evidências e integridade do arquivo; não podem avaliar automaticamente o grau de restauração visual.

Ao iterar a própria skill, escolha problemas independentes e entradas reais de evals/evals.json de acordo com a mudança; estas são instruções de avaliação a serem executadas, não registros de aprovação. Exemplos de desenvolvimento, regressão histórica e avaliação de novos temas são registrados separadamente; evite generalizar resultados apenas ajustando repetidamente o mesmo caso.