xiaotao-02/wireframe-3d

¿Qué hace wireframe-3d?

Convierte un objeto físico o un proceso de producción en una obra tridimensional que se pueda observar, desmontar y explicar. Asigna el enfoque de creación según los objetivos del usuario: para divulgación estructural, prioriza la explicación del mecanismo; para modelado de referencia, prioriza la restauración de la apariencia visible y luego añade la estructura, el movimiento y la interfaz que el usuario necesite.

El objetivo se divide en dos criterios de aceptación: estructura/interacción funcional y coincidencia de apariencia/expresión visual de referencia. El primero no puede sustituir al segundo; los resultados de casos anteriores no demuestran automáticamente la calidad de un nuevo tema.

Cuando el usuario proporciona imágenes y solicita modelado, réplica, o informa de que "no se parece/no es utilizable", antes de elegir el método de construcción, aplicar plantillas y generar el cuerpo principal, lee Modelado de referencia y primera entrega. Primero confirma los contornos, superficies curvas, aberturas y materiales que determinan el reconocimiento; no se debe cambiar automáticamente a un estilo de divulgación simplificado por invocar esta habilidad. En una sola solicitud del usuario, completa de forma proactiva el renderizado, la revisión de imágenes y las correcciones necesarias, sin esperar a que el usuario actúe como el primer inspector visual.

Al ejecutar esta rama, lee Herramientas de modelado de referencia: utiliza grabaciones de origen como referencia fija, emplea según sea necesario herramientas de superficie dividida/aberturas reales/accesorios de superficie, y luego genera un modelo en gris con cámara fija y una comparación de materiales. El pase de la herramienta no sustituye a la inspección visual.

Cuando se informa de que vehículos u otras carcasas continuas están demasiado simplificadas, lee Reparación iterativa de carcasas continuas: primero reconstruye las formas y los límites compartidos controlables de forma independiente, diagnostica la calidad de la malla después de perforar agujeros en la superficie, y luego repara las cavidades de las luces y el pintado continuo; cada iteración conserva el código fuente correspondiente y una vista fija.

Cuando un producto de referencia necesita capas de material, piezas adheridas o muchos detalles repetitivos, lee Integración práctica y aceptación de modelado de productos: el material debe aplicarse a la malla entregada, las uniones geométricas deben configurarse con comprobaciones reales, y el batching estático no debe romper la semántica, el movimiento ni los objetos de medición. Primero guarda la línea base antes de la mejora, y en la misma tarea de referencia conserva las correcciones reales; los casos utilizados para la optimización son desarrollo y validación, no pueden denominarse pruebas ciegas independientes.

Al crear explicaciones estructurales o de movimiento, lee Método de creación migrado desde Anatomy: determina "acción → cambio en el componente → resultado observable", y aplica el nivel de detalle en interfaces, guías, terminaciones y espacios negativos funcionales. Su método de creación y la implementación en Three.js de esta habilidad se rastrean por separado, sin copiar directamente el sistema de ordenación SVG ascendente.

Elegir la ruta de entrega

• Si el usuario especifica un motor, hazlo. Si no se especifica y se necesita una página web interactiva: por defecto Three.js, lee Ruta Three.js.
• El motor de entrega web y el método de creación geométrica se eligen por separado. Para superficies curvas continuas complejas, primero verifica si la construcción puede expresar las formas clave; si es necesario, crea una malla editable en Blender (si está disponible) y luego impórtala a la web. Cuando el usuario solicite modelado puramente procedural, respeta esta restricción y elige un método que pueda expresar superficies curvas locales y aberturas; no aumentes simplemente el número de muestras de un barrido simple.
• Para proyectos editables, renderizado offline o animaciones de cámara: usa Blender, lee Ruta Blender.
• Para ambas entregas: comparte los ID de piezas, la geometría y los significados de estado, y valida por separado en ambos extremos; una ejecución en un motor no representa un pase en el otro.
• Para modelado de productos normales sin necesidad de explicación estructural, se puede usar el threejs-modeling-studio instalado; esta habilidad no requiere que exista.
• Al cambiar de tema o si el modelo no se parece a la referencia, lee Temas y métodos de construcción. Para arquitectura, primero procesa las plantas, alzados, secciones, volúmenes/huecos y relaciones con el sitio; para mecánica, primero procesa contornos/ejes/cavidades; para fábricas, primero procesa las estaciones de trabajo y el flujo de materiales; elige la rama según la tarea real.

De la referencia a la estructura

Al crear una obra nueva o una reparación completa, primero escribe una frase con el mensaje principal que el espectador debería entender, y a partir de las solicitudes del usuario, organiza "debe aparecer / debe mantenerse / no debe aparecer / formato de entrega". Registra el tamaño de visualización real y el estado por defecto; si ya existen requisitos, úsalos directamente, no preguntes repetidamente para llenar un formulario. Sigue Comparación visual y reparación para la creación; se puede reutilizar Registro de creación e inspección de entrega; para cambios pequeños, solo complementa los elementos afectados.

1. A partir de la pregunta del usuario, determina las necesidades reales de restauración de apariencia, explicación estructural y demostración de movimiento. Para modelado de referencia, primero fija la forma externa y las características visibles clave; para temas de mecanismos, determina qué componentes internos deben ser visibles. Los mecanismos internos, animaciones de condiciones de trabajo y paneles de control no solicitados no se convierten automáticamente en el enfoque de la primera ronda.
2. Crea una tabla breve de componentes: id / función / ensamblaje al que pertenece / parámetros / objetos conectados / movimiento / fuente. Para temas de mecanismos, primero determina la pertenencia, las conexiones y la ruta causal, luego elige la expresión mediante corte, explosión o líneas de guía; la verificación de la fuente del principio y si la animación puede ejecutarse se registran por separado. Separa los componentes reales, los accesorios visuales y las partículas esquemáticas. Para fábricas, lista adicionalmente las estaciones de trabajo, las rutas de materiales, el transporte entre niveles y las condiciones del proceso.
3. Cuando haya planos/modelos reales, úsalos primero; si no hay dimensiones, declara la proporción esquemática y mantén la coherencia de los parámetros internos. No presentes ejemplos originales como el proyecto original de la obra de referencia, el resultado de la réplica o un modelo público.
4. Primero crea el volumen, los contornos, las conexiones y las cavidades internas; luego añade los detalles funcionales. Los agujeros deben ser aberturas reales, los tubos deben tener espesor de pared, y los soportes deben mostrar la relación de carga. No utilices un grupo de cuboides con etiquetas para reemplazar la estructura mecánica central.
5. El presupuesto de modelado se determina según el objetivo real, la visibilidad y el grado de reconocimiento, no se aplica un número fijo de piezas ni un tiempo fijo. Para superficies curvas complejas, utiliza superficies divididas adecuadas, mallas de subdivisión, barridos de sección, revoluciones, recorridos o activos fiables; primero valida las partes representativas, luego expande al conjunto. La fuente de los activos y la contribución del modelado procedural se explican por separado.
6. Cuando el usuario solicite restaurar una obra existente, primero establece una tabla "característica de referencia → archivo fuente/función → implementación → captura de pantalla/evidencia de estado", y fija una cámara comparable. Tanto la vista general como los primeros planos deben ser aceptables; la cantidad de registros fuente no puede sustituir a la similitud de la forma. Los pasos específicos se encuentran en Fidelidad de referencia y verificación de animación.
7. Primero alinea los contornos principales, el espacio negativo y las conexiones con el modelo en gris, luego complementa la construcción, los materiales y la iluminación; cuando falten datos originales, registra las suposiciones. Sigue Comparación visual y reparación para registrar por separado: coincidencias, diferencias y no verificadas; si se encuentran problemas de forma clave, continúa reparando el modelo.

Al migrar HTML de fábrica, lee Código de visualización original y recuperación de dispositivos: restaura la carcasa robotSvg/toolSvg y la orientación de la sección por estación de trabajo, verifica el desplazamiento temporal externo de draw() y la puerta de carga. Primero acepta las estaciones representativas, luego expande por ID estable; assets/lib/source-frame.js proporciona la orientación de los segmentos de brazo rectangulares. El estado y el dispositivo específicos del caso no pueden utilizarse como generador automático para cualquier tema.

Relaciones que deben mantenerse

Para temas nuevos con acoplamiento de interfaces, deslizamiento o tuberías, lee Verificación de interfaces y ensamblaje, utiliza assets/lib/assembly.js para entregar coordenadas de interfaz, normales, diámetros, relaciones y verificación de malla real. pass solo cubre las reglas configuradas; las que exceden el presupuesto o no están configuradas deben marcarse explícitamente. Para probar el verificador, utiliza contraejemplos como interfaces intencionalmente desconectadas o diámetros reales modificados incorrectamente.

La auditoría y la vista previa deben hacer referencia a la misma raíz, los mismos componentes semánticos y sus mallas reales; las copias fuera del árbol, las cajas de selección y las envolventes de auditoría no pueden reemplazar la prueba. Las sondas de orificios/superficies de unión deben mantener una referencia independiente; la modificación intencional de componentes reales debe poder detectarse. La integridad de los detalles mostrados aún debe determinarse mediante la inspección de primeros planos.

• Un mismo conjunto de parámetros genera geometría, posición de ensamblaje, animación y lecturas. rest + explode * offset es el modelo básico de despiece; el reinicio vuelve a la pose de reposo guardada, evitando la acumulación de traslaciones.
• La animación enumera primero los estados y las condiciones de transición, luego el renderizado. Si se inicia después del despiece, debe esperar a que el ensamblaje converja realmente antes de reproducir la condición de trabajo; la pausa congela resortes, ruido, partículas y lecturas; si la parada tiene estela, no se puede eliminar el efecto directamente. Cuando se necesiten resortes con fases escalonadas, se impulsan con el estado de componentes independientes, no se utiliza el valor objetivo del control deslizante como posición real.
• En la web, prioriza la reutilización de assets/lib/motion.js y scene-runtime.js, para que la interfaz de usuario, el muestreo de estados y la verificación de capturas de pantalla pasen por el mismo setPose; las condiciones de trabajo complejas pueden extender módulos de estado puro. Lee Estado compartido y verificación reproducible para evitar reescribir el reloj para cada caso o acumular desplazamientos en llamadas repetidas.
• El pivote se coloca en el eje de rotación real o en la interfaz de ensamblaje; los subcomponentes se mueven con el ensamblaje al que pertenecen. Nombra los componentes primero, luego interactúa; está prohibido adivinar objetos según el orden de creación.
• Si se encuentran superposiciones en la explosión, cortes negros, partes traseras de palas delgadas o desviaciones de movimiento, lee Reparación de explosión y movimiento: configura las fases según módulos semánticos, verifica el espaciado real de la malla e inyecta contraejemplos de superposición; no solo verifiques botones o porcentajes. La biblioteca de ejecución aplica la explosión después de setPose; al migrar código antiguo, evita desplazamientos duplicados.
• El flujo del proceso se adhiere a las rutas reales y al estado actual. Las conexiones que se rompen después del despiece no deben seguir mostrando un flujo de material o fluido "sin obstáculos"; se pueden ocultar las líneas de flujo o cambiarlas a líneas discontinuas explícitas.
• La ocultación de componentes, la observación transparente, los planos de recorte y el corte de sólidos con tapas son funciones diferentes; nómbralas según su implementación real. Los planos de recorte sin tapas no deben presentarse como si se hubiera completado un corte de sólidos.
• Se pueden mostrar fases esquemáticas y velocidades de demostración; las velocidades reales, temperaturas, caudales, tiempos de ciclo, presiones, etc., necesitan una fuente o cálculo. El flujo de partículas no es CFD, la rotación de engranajes no es una solución dinámica.
• Las escenas de fábrica se organizan por planta/taller/estación de trabajo, y luego el estado del proceso se asigna a los equipos y materiales. Las descripciones del proceso provienen de la información; la agrupación visual es una elección de implementación; no se deben confundir.
• Al migrar fábricas, verifica el desplazamiento externo de draw(), la ventana HOME y la pertenencia de la carga. Se puede reutilizar el reloj independiente y el muestreo de límites de assets/lib/process-timing.js; verifica un fotograma antes, durante y después de cada punto de transferencia; no se deben utilizar intervalos de muestreo iguales para omitir los límites.

Visual e interacción

Cuando se requiera mantener el estilo visual de dos proyectos originales, lee Renderizado de ilustraciones unificado, utiliza illustrationPalette() y renderStyle:'anatomy-light'. Comparte fondo tipo papel, sombreado de normales controladas, contornos finos con prueba de profundidad y colores de énfasis semántico; compara las capturas de pantalla finales en la misma posición de cámara; no se puede sustituir la aceptación del estilo visual solo con los mismos valores de color o pruebas aprobadas.

Para divulgación estructural sin un estilo visual especificado, hereda los contornos claros, los materiales sobrios y los colores de énfasis semántico de Anatomy. Para la réplica de referencias, el estilo lo determinan la referencia y los requisitos del usuario: los productos realistas eligen explícitamente materiales iluminados apropiados y el punto de partida renderStyle:'studio'; solo se utiliza anatomy-light cuando se necesita una expresión de ilustración. Cambiar de estilo no puede reparar superficies curvas incorrectas; se debe inspeccionar visualmente.

Para divulgación estructural, la primera pantalla debe mostrar el cuerpo principal, la estructura interna clave y el movimiento comprensible; para exhibición de apariencia, la primera pantalla debe centrarse en el cuerpo principal del ensamblaje completo, sin usar carcasas completamente transparentes para mostrar estructuras internas no respaldadas por la referencia. Proporciona una vista principal con suficiente espacio; las etiquetas se posicionan con componentes reales, filtradas por oclusión y espacio en pantalla, evitando docenas de líneas de guía en una sola pantalla.

La página web normalmente proporciona rotación/zoom, desmontaje, selección de componentes, pausa/reinicio; las fábricas añaden filtrado por planta y proceso según sea necesario. Los controles de formularios nativos son operables por teclado, respetan reduced-motion, y pausan los cálculos cuando la pantalla está fuera de vista o la página está oculta. No añadas paneles de instrumentos irrelevantes para la explicación solo para completar funciones.

El punto de partida web predeterminado utiliza una barra superior compacta, un panel de etiquetas, controles de demostración permanentes y un modo de enfoque; las explicaciones complejas se expanden según sea necesario. Al crear u optimizar la interfaz de vista previa, lee Interfaz de vista previa y reutiliza assets/web/preview-ui.css / preview-ui.js, verificando al mismo tiempo los márgenes de seguridad del encuadre del modelo y la operabilidad en pantallas estrechas. El diseño se puede ajustar según el estilo del usuario.

Puntos de partida ejecutables

Para nuevos temas de Three.js, prioriza el uso del constructor independiente buildScene() y prepare_web.py --builder; la vista previa predeterminada funciona según los ID de componentes pasados, ya no es necesario tomar prestado hub/rotor/cover de una bomba. Lee Biblioteca de componentes e interfaz de temas y llama según sea necesario a assets/lib/ para revoluciones huecas, tubos de diámetro variable, bridas/losas perforadas, aberturas/marcos de ventanas de muros de piedra, canales de pendiente suave y herramientas de cámara/iluminación. Estos son componentes originales modificables, no un modelador automático de objetos arbitrarios.

--example river-pavilion / --example flanged-chamber son ejercicios originales de verificación de herramientas de arquitectura/mecánica; no pueden sustituir al objeto de réplica especificado por el usuario. Los scripts existentes scripts/make_demo.py, prepare_web.py --scene y build_blender.py conservan la ruta de la lista compartida de la bomba centrífuga. Los nuevos componentes JS y la vista previa general no admiten automáticamente Blender; se implementan y verifican por separado.

--example pneumatic-press proporciona nuevas interfaces, características de malla reales, recorridos, diagramas de conexión y un ejemplo de renderizado de ilustración. La nueva verificación de interfaz JS y los shaders no migran automáticamente a Blender; no se debe escribir la verificación web como una verificación de doble motor.

--example contact-switch proporciona una reconstrucción 3D independiente del mecanismo de botón de Anatomy: orificios de guía reales, resortes de paso variable, seis terminaciones, distancia libre del conductor a la placa base y lecturas impulsadas por la holgura real del contacto. Es un ejemplo de desarrollo, no puede considerarse como el resultado de pruebas ciegas para todos los temas nuevos.

--example indexed-workcell es un ejemplo original de desarrollo de procesos, que demuestra diferentes constructores de equipos, ciclos independientes y HOME, pertenencia de materiales y caché dinámico multicolor. Reutiliza el mapeo explícito de equipos y el muestreo condicional de factory-process.js; los equipos desconocidos no pueden degradarse silenciosamente a cubos genéricos. Ejecuta verify_migration.py --three <ruta de three> --report <JSON> para verificar estas relaciones y los contraejemplos de color/sombra, y luego inspecciona la página visualmente.

• Convenciones de datos compartidos: coordenadas, geometría, estado y límites de verificación.
• Mapa de fuentes y migración: heurística precisa hasta el archivo/función ascendente, partes reimplementadas y atribución.
• Cuando el usuario especifique un caso de código abierto existente, lee Migración 3D de obras existentes: geometría de visualización y proxy de auditoría, extracción de estado puro, creación de instancias y aceptación en navegador real.
• scripts/validate_scene.py: verifica IDs, números finitos, caras degeneradas, mallas cerradas y volumen orientado positivamente. Solo verifica sólidos cerrados aplicables; las superficies abiertas necesitan ajustar las reglas y explicarlo.
• Después de modificar la verificación de interfaces, ejecuta scripts/verify_assembly.py --three <ruta de three instalada> --report <JSON de salida>, y luego configura agujeros reales, superficies de unión/holguras y contraejemplos de error para el nuevo tema; actualmente solo está implementada la verificación Three.js.
• Después de modificar componentes JS compartidos, ejecuta scripts/verify_components.py --three <ruta de three instalada> --report <JSON de salida>, verificando aberturas, espesores de pared, diferentes dimensiones y la zona de seguridad de la cámara; luego abre visualmente los ejemplos afectados. Las comprobaciones numéricas no evalúan la estética.
• Después de modificar la explosión o el encuadre, ejecuta scripts/verify_explosion.py --three <ruta de three instalada> --report <JSON de salida>; configura explosionChecks para temas reales y verifica con verify_scene.py; si no está configurado, no se considera aprobado. Para la vista previa, usa serve_preview.py --root <directorio de salida> --port <puerto inicial>, enlace solo a un puerto libre local y deshabilita la caché de desarrollo; después de generar, recarga para verificar el producto actual.
• Para temas nuevos, se puede ejecutar scripts/verify_scene.py --builder <subject.js> --three <ruta de three instalada> --report <JSON de salida>; luego, con las herramientas de navegador permitidas en el entorno actual, opera y toma capturas de pantalla. Si se permite la automatización independiente del navegador, se puede ejecutar node scripts/verify_preview.mjs --url <URL de vista previa local> --out <directorio de evidencia> para registrar capturas de pantalla, estados y errores, y luego el usuario revisa las imágenes. El uso, las limitaciones y el alcance de las herramientas se encuentran en Estado compartido y verificación reproducible.

No copies todo el repositorio ascendente en el proyecto de ejecución para usar esta habilidad. El iso-kit, tube y lathe ascendentes son sistemas de generación SVG; la geometría Three.js/Blender, la prueba de profundidad y la interacción de esta habilidad son implementaciones independientes.

Aceptación y entrega

Ejecuta según la funcionalidad real y conserva resultados verificables:

1. Geometría: verifica parámetros/ID/unidades/números finitos; los agujeros clave, espesores de pared, ejes, contactos y holguras tienen una verificación específica. Las comprobaciones de datos no pueden sustituir a las comprobaciones de imagen.
2. Estado: verifica el ensamblaje, el semi-despiece, el despiece completo y el reinicio; las lecturas en tiempo de ejecución son coherentes con la fase geométrica, y la pausa no causa saltos. La detección de colisiones solo se prueba para pares de piezas que no deberían estar en contacto; no marques como error el contacto de ensamblaje normal.
3. Imagen: en el tamaño de visualización real, verifica la primera pantalla predeterminada, la vista principal y las vistas trasera/lateral; verifica la proporción del cuerpo principal, la oclusión, las intersecciones de malla, las piezas flotantes, las diferencias de material, las sombras y la legibilidad del texto. Prueba en una pantalla estrecha para la web; vuelve a abrir el archivo .blend en Blender para verificar objetos, drivers y estado de fotogramas. Si hay una obra original, añade una comparación de la vista general y un primer plano funcional en la misma posición de cámara; si hay transparencia, humo o llamas, verifica su oclusión delante/detrás y el proceso de parada. Después de pasar la geometría y el estado puro, aún se debe compilar el shader y observar la imagen.
4. Relectura de entrega: vuelve a abrir el punto de entrada o archivo que recibirá el usuario, y en el visor objetivo, registra PASS / FAIL / NOT_RUN para cada uno de los cuatro tipos de requisitos. Si hay exportación, verifica por separado el proyecto nativo, los archivos exportados y el soporte final; si hay animación, reproduce completamente el flujo que experimentará el usuario, verifica la acción, el texto y las lecturas; el muestreo de fotogramas no sustituye a la verificación continua. Verifica la consola o el registro de Blender; solo informa del rendimiento después de medir.

Actualmente, la plantilla Three.js es generada por prepare_web.py, que crea un manifiesto hash de archivos y build-info.js. Usa verify_preview.mjs --expect-build <id del manifiesto> para vincular la captura de pantalla a la versión real, la página, la cámara, el estado y el viewport leído; las imágenes aún deben ser revisadas manualmente. Cuando no se pueda leer la versión o el viewport correspondiente, no se deben usar capturas de pantalla antiguas como nuevos resultados. Después de cambios en instancias en lote, sincroniza la matriz y el número de caras y contornos; conserva la semántica del material fuente; no se puede crear detalle engrosando todas las varillas finas.

Entrega el punto de entrada, la fuente editable, los recursos necesarios y algunas capturas de pantalla clave. Informa sobre los hechos de la fuente, las partes originales/adaptadas, las verificaciones realizadas y los elementos no verificados. Cuando el usuario quiera una réplica, haz coincidir con la referencia real; no sustituyas con el ejemplo de la bomba adjunta.

Cuando haya exportación, múltiples versiones o requisitos de entrega claros, lee Herramientas de evidencia y entrega: haz coincidir los requisitos con la relectura final, vincula el código fuente y el hash de la captura de pantalla para evitar registros obsoletos; inicia la vista previa local en un puerto exclusivo y conserva la versión con instantáneas independientes verificadas. Las herramientas solo pueden verificar la asociación de evidencia y la integridad de los archivos; no pueden evaluar automáticamente el grado de restauración visual.

Al iterar sobre la habilidad en sí, según el cambio, selecciona temas independientes y entradas reales de evals/evals.json; estas son instrucciones de evaluación pendientes de ejecutar, no registros aprobados. Los ejemplos de desarrollo, las regresiones históricas y las evaluaciones de temas nuevos se registran por separado; evita sacar conclusiones de generalización basadas únicamente en el ajuste repetido del mismo caso.