xiaotao-02/wireframe-3d

Que fait wireframe-3d ?

Créez une œuvre 3D observable, démontable et explicable à partir d'un objet physique ou d'un processus de production. Selon les objectifs de l'utilisateur, répartissez les priorités de réalisation : la vulgarisation structurelle privilégie l'explication du mécanisme ; la modélisation de référence privilégie la reproduction de l'apparence visible, puis ajoute la structure, le mouvement et l'interface demandés par l'utilisateur.

L'objectif est validé selon deux critères : structure/interaction utilisable et correspondance de l'apparence de référence/expression visuelle. Le premier ne remplace pas le second ; les résultats d'anciens cas ne prouvent pas automatiquement la qualité d'un nouveau sujet.

Lorsque l'utilisateur fournit une image et demande une modélisation, une reproduction, ou un retour « cela ne ressemble pas / n'est pas utilisable », lisez Modélisation de référence et première livraison avant de choisir la méthode de construction, d'appliquer un modèle ou de générer le corps principal. Confirmez d'abord les contours, les surfaces, les ouvertures et les matériaux qui déterminent la reconnaissance ; n'automatisez pas le passage à un style de vulgarisation simplifié en invoquant cette compétence. Effectuez le rendu, la vérification des plans et les retouches nécessaires de manière proactive lors d'une même demande utilisateur, sans attendre que l'utilisateur agisse comme premier inspecteur visuel.

Lors de l'exécution de cette branche, lisez Outils de modélisation de référence : fixez la référence à l'aide d'enregistrements de sources, utilisez les outils de surfaces subdivisées / ouvertures réelles / surfaces courbes selon les besoins, puis générez un modèle gris avec verrouillage de la caméra et une table de correspondance des matériaux. La réussite de la vérification par l'outil ne remplace pas l'inspection visuelle.

Lorsque des carrosseries continues (véhicules, etc.) sont signalées comme trop simplifiées, lisez Réparation itérative des surfaces continues : reconstruisez d'abord les formes contrôlables indépendamment et les limites partagées, diagnostiquez la qualité du maillage après le trou de coupe, puis réparez les cavités des phares et la peinture continue ; conservez le code source et la vue fixe correspondants à chaque itération.

Lorsque le produit de référence nécessite des couches de matériaux, des composants attachés ou de nombreux détails répétés, lisez Intégration pratique et réception de la modélisation de produits : les matériaux doivent prendre effet sur le maillage livré, les jonctions géométriques doivent être configurées pour une vérification réelle, et le regroupement statique ne doit pas compromettre la sémantique, le mouvement et les objets de mesure. Sauvegardez d'abord la ligne de base avant l'amélioration, puis conservez les retouches réelles dans la même tâche de référence ; les cas déjà utilisés pour l'optimisation sont des validations de développement, ne les rebaptisez pas comme des tests aveugles indépendants.

Lors de la réalisation d'explications structurelles ou de mouvement, lisez Méthode de réalisation issue d'Anatomy : déterminez « opération → changement de composant → résultat observable », et concentrez la précision sur les interfaces fonctionnelles, les guidages, les terminaisons et les espaces négatifs. Sa méthode de réalisation et l'implémentation Three.js de cette compétence sont tracées séparément ; ne copiez pas directement le système d'ordre SVG amont.

Choisir la voie de livraison

• Si l'utilisateur spécifie un moteur, suivez-le. Si non spécifié et qu'une page web interactive est souhaitée : par défaut Three.js, lisez Voie Three.js.
• Le moteur de livraison web et la méthode de création géométrique sont choisis séparément. Pour les surfaces complexes continues, vérifiez d'abord si la construction peut exprimer les formes clés ; si nécessaire, créez un maillage modifiable dans Blender (disponible), puis importez-le dans la page web. Lorsque l'utilisateur demande une modélisation purement procédurale, respectez cette contrainte et choisissez une méthode capable d'exprimer les surfaces et ouvertures locales ; n'augmentez pas simplement le nombre d'échantillons de l'extrusion simple.
• Pour un projet modifiable, un rendu hors ligne ou des animations de caméra : utilisez Blender, lisez Voie Blender.
• Pour les deux livraisons : partagez les identifiants des composants, la géométrie et la signification des états, validez séparément des deux côtés ; une seule exécution ne signifie pas que l'autre moteur est validé.
• Pour la modélisation de produits courants sans nécessité d'explication structurelle, vous pouvez utiliser le threejs-modeling-studio installé ; cette compétence ne l'exige pas.
• Lorsque le sujet change ou que le modèle ne ressemble pas à la référence, lisez Sujets et méthodes de construction. Pour l'architecture, traitez d'abord les plans/coupes/élévations, les volumes/percées et les relations de site ; pour la mécanique, traitez d'abord les contours/axes/cavités ; pour l'usine, traitez d'abord les postes de travail et la logistique ; choisissez la branche en fonction de la tâche réelle.

De la référence à la structure

Lors de la création d'une nouvelle œuvre ou d'une révision complète, écrivez d'abord une phrase principale que le spectateur devrait comprendre, et à partir des exigences de l'utilisateur, organisez « doit apparaître / doit être conservé / interdit d'apparaître / format de livraison ». Enregistrez la taille réelle de visualisation et l'état par défaut ; si des exigences existent déjà, continuez à les utiliser, ne posez pas de questions répétées pour remplir un formulaire. Suivez Comparaison visuelle et révision pour la réalisation, et vous pouvez réutiliser Enregistrement de contrôle de réalisation et de livraison ; pour les petites modifications, ne mettez à jour que les éléments concernés.

1. Déterminez à partir des questions de l'utilisateur les besoins réels en matière de reproduction d'apparence, d'explication structurelle et de démonstration de mouvement. Pour la modélisation de référence, verrouillez d'abord la forme et les caractéristiques visibles clés ; pour les problèmes de mécanismes, déterminez ensuite quels composants internes doivent être visibles. Les mécanismes internes, animations de conditions de fonctionnement et panneaux de contrôle non demandés ne deviennent pas automatiquement des priorités de la première itération.
2. Établissez une courte table des composants : id / rôle / assemblage parent / paramètres / objets connectés / mouvement / source. Pour les problèmes de mécanismes, déterminez d'abord l'appartenance, les connexions et le chemin causal, puis choisissez l'expression par coupe, déploiement ou ligne d'attache ; la vérification de la source des principes du mécanisme et la possibilité d'exécuter l'animation sont enregistrées séparément. Séparez les composants réels, les auxiliaires visuels et les particules indicatives. Pour l'usine, listez séparément les postes de travail, les chemins de matières, les transferts entre niveaux et les conditions de processus.
3. Utilisez en priorité les plans/maquettes réelles lorsqu'ils sont disponibles ; en l'absence de dimensions, déclarez l'échelle indicative et maintenez la cohérence des paramètres internes. Ne présentez pas des exemples originaux comme des projets source, des résultats de reproduction ou des modèles publics de l'œuvre de référence.
4. Commencez par le volume, le contour, les connexions et les cavités internes ; ajoutez ensuite les détails fonctionnels. Les trous doivent être des ouvertures réelles, les tuyaux ont une épaisseur de paroi, les supports montrent la relation de portance. N'utilisez pas une série de boîtes avec des étiquettes pour remplacer la structure mécanique centrale.
5. Le budget de modélisation est déterminé en fonction des objectifs réels, du degré de visibilité et de la capacité de reconnaissance ; n'appliquez pas un nombre fixe de composants ou un temps de travail fixe. Pour les surfaces complexes, utilisez des surfaces subdivisées appropriées, des maillages de subdivision, des lissages par sections, des révolutions, des balayages ou des actifs fiables ; validez d'abord les parties représentatives, puis étendez à l'ensemble. Les contributions des sources d'actifs et de la modélisation procédurale sont expliquées séparément.
6. Lorsque l'utilisateur demande de reproduire une œuvre existante, établissez d'abord une table « caractéristiques de référence → fichier source/fonction → implémentation → capture d'écran/preuve d'état », verrouillez les caméras comparables. La vue d'ensemble et les gros plans doivent tous deux être satisfaisants ; la quantité d'enregistrements sources ne remplace pas la similarité de forme. Voir Fidélité de la reproduction et vérification de l'animation pour les étapes détaillées.
7. Alignez d'abord les contours principaux, les espaces négatifs et les connexions sur le modèle gris, puis ajoutez la structure, les matériaux et l'éclairage ; en cas de données source insuffisantes, enregistrez les hypothèses. Suivez Comparaison visuelle et révision pour enregistrer séparément les correspondances, les différences et les non-vérifiés ; si des problèmes de forme clés sont découverts, continuez à corriger le modèle.

Lors du portage d'un HTML d'usine, lisez Portage du code d'affichage source et récupération des équipements : restaurez les coques robotSvg/toolSvg et les directions de section par poste de travail, vérifiez le décalage temporel externe de draw() et le contrôle de charge. Validez d'abord un poste de travail représentatif, puis étendez selon des ID stables ; assets/lib/source-frame.js fournit l'orientation des segments de bras rectangulaires. Les états et équipements spécifiques aux cas ne doivent pas être considérés comme des générateurs automatiques pour n'importe quel sujet.

Relations à maintenir impérativement

Pour les nouveaux sujets nécessitant des interfaces de connexion, des glissières ou des canalisations, lisez Vérification des interfaces et des assemblages et utilisez assets/lib/assembly.js pour livrer ensemble les coordonnées d'interface, les normales, les diamètres, les relations et la vérification réelle du maillage. pass ne couvre que les règles configurées ; les éléments hors budget/non configurés doivent être clairement marqués. Testez le vérificateur avec des contre-exemples tels que des interfaces délibérément déconnectées ou des diamètres réels modifiés par erreur.

L'audit et l'aperçu doivent référencer la même racine, les mêmes composants sémantiques et leurs maillages réels ; les copies hors arbre, les boîtes de sélection et les enveloppes d'audit ne peuvent pas être utilisées pour les tests. Les sondes d'ouverture/de surface d'interface maintiennent une référence indépendante ; une modification délibérée d'un composant réel doit pouvoir être détectée. L'intégralité des détails d'affichage doit toujours être jugée par un gros plan.

• Un même paramètre source génère la géométrie, la position d'assemblage, l'animation et les lectures. rest + explode * offset est le modèle de base de l'éclaté ; la réinitialisation revient à la pose de repos sauvegardée, évitant les translations cumulées.
• Pour l'animation, listez d'abord les états et les conditions de transition, puis le rendu. Si elle est déclenchée après l'éclatement, attendez la convergence réelle de l'assemblage avant de jouer les conditions de fonctionnement ; la pause fige les ressorts, le bruit, les particules et les lectures ; si l'arrêt a une traînée, ne supprimez pas directement l'effet. Lorsque des ressorts décalés sont nécessaires, pilotez-les par l'état des composants indépendants, n'utilisez pas la valeur cible du curseur comme position réelle.
• Pour le web, réutilisez de préférence assets/lib/motion.js et scene-runtime.js, afin que l'UI, l'échantillonnage d'état et la vérification par capture d'écran passent par le même setPose ; pour les conditions de fonctionnement complexes, vous pouvez étendre des modules d'état purs. Lisez État partagé et validation rejouable, évitez de réécrire une horloge pour chaque cas ou de cumuler les déplacements dans des appels répétés.
• Placez les pivots sur les axes de rotation réels ou les interfaces d'assemblage ; les sous-composants se déplacent avec leur assemblage parent. Nommez les composants avant de créer les interactions ; ne devinez pas les objets en fonction de l'ordre de création.
• En cas de chevauchement lors du déploiement, de coupes noires, de faces arrière de fines pales ou de décalages d'action, lisez Réparation du déploiement et du mouvement : configurez les phases par module sémantique, vérifiez l'espacement réel du maillage et injectez des contre-exemples de chevauchement ; ne vérifiez pas seulement les boutons ou les pourcentages. La bibliothèque d'exécution applique le déploiement après setPose ; lors du portage d'ancien code, évitez les déplacements dupliqués.
• Les flux de processus suivent le chemin réel et l'état actuel. Les connexions rompues après l'éclatement ne continuent pas à afficher un flux logistique ou fluide « libre » ; les lignes de flux peuvent être masquées ou transformées en lignes pointillées explicites.
• La dissimulation de composants, la visualisation transparente, le plan de coupe et la coupe solide avec obturation sont des fonctions différentes, nommez-les en fonction de leur implémentation réelle. Si le plan de coupe n'a pas d'obturation, ne prétendez pas avoir effectué une coupe solide.
• Les phases indicatives et la vitesse de démonstration peuvent être affichées ; la vitesse de rotation réelle, la température, le débit, la cadence, la pression, etc., nécessitent une source ou un calcul. Le flux de particules n'est pas une CFD, la rotation d'un engrenage n'est pas une résolution dynamique.
• Les scènes d'usine sont organisées par étage/atelier/poste de travail, puis les états de processus sont mappés aux équipements et aux matériaux. Les descriptions de processus proviennent de la documentation, les groupes visuels sont des choix d'implémentation ; ne les confondez pas.
• Lors du portage d'usine, vérifiez le décalage externe de draw(), la fenêtre HOME et l'appartenance de la charge. La bibliothèque assets/lib/process-timing.js avec son horloge indépendante et son échantillonnage aux limites peut être réutilisée ; vérifiez une image avant, pendant et après chaque point de transition, n'utilisez pas un échantillonnage à intervalles réguliers pour sauter les limites.

Visuel et interactivité

Lorsqu'il est demandé de conserver le style graphique de deux projets originaux, lisez Rendu d'illustration unifié et utilisez illustrationPalette() avec renderStyle:'anatomy-light'. Partagez le fond de type papier, l'éclairage normal contrôlé, les contours fins avec test de profondeur et les couleurs d'accentuation sémantiques ; comparez les captures d'écran finales avec la même position de caméra, ne remplacez pas la validation du style graphique par une égalité des valeurs de couleur ou une réussite du test.

Pour la vulgarisation structurelle sans style visuel spécifié, héritez des contours clairs, des matériaux sobres et des couleurs d'accentuation sémantiques d'Anatomy. Pour la reproduction de référence, le style est déterminé par la référence et les exigences de l'utilisateur : pour les produits réalistes, choisissez explicitement des matériaux éclairés appropriés et un point de départ renderStyle:'studio' ; utilisez anatomy-light uniquement lorsque l'expression par illustration est nécessaire. Changer de style ne peut pas réparer des surfaces erronées ; vous devez réellement inspecter les plans.

Pour la vulgarisation structurelle, le premier écran montre le sujet principal, la structure interne clé et le mouvement compréhensible ; pour la démonstration d'apparence, le premier écran montre principalement le corps de l'assemblage complet, n'utilisez pas une coque entièrement transparente pour montrer une structure interne non supportée par la référence. Fournissez une vue principale avec un espace suffisant ; les étiquettes sont positionnées en fonction des composants réels, filtrées par occlusion et espace d'écran, évitez des dizaines de lignes d'attache sur un seul écran.

Les pages web offrent généralement la rotation/zoom, l'éclatement/l'assemblage, la sélection de composants, la pause/réinitialisation ; pour l'usine, ajoutez le filtrage par étage et par processus selon les besoins. Les contrôles de formulaire natifs sont utilisables au clavier, respectent reduced-motion, et mettent en pause les calculs lorsque l'écran est hors champ ou que la page est masquée. N'ajoutez pas de tableaux de bord sans rapport avec l'explication pour faire du remplissage.

Le point de départ par défaut de la page web utilise une barre supérieure compacte, un panneau d'étiquettes, des contrôles de démonstration permanents et un mode focus ; les explications complexes se déploient selon les besoins. Lors de la création ou de l'optimisation d'une interface d'aperçu, lisez UI d'aperçu et réutilisez assets/web/preview-ui.css / preview-ui.js, tout en vérifiant les marges de sécurité du cadrage du modèle et l'opérabilité sur écran étroit. La mise en page peut être ajustée selon le style de l'utilisateur.

Point de départ exécutable

Pour les nouveaux sujets Three.js, utilisez de préférence le constructeur indépendant buildScene() et prepare_web.py --builder ; l'aperçu par défaut fonctionne avec les ID de composants fournis, sans plus besoin d'emprunter hub/rotor/cover de la pompe. Lisez Bibliothèque de composants et interface de sujet et appelez selon les besoins les éléments de assets/lib/ : révolutions creuses, tubes à diamètre variable, brides/dalles avec trous, ouvertures/cadres de fenêtres en mur de pierre, canaux à pente douce, et outils d'objectif/d'éclairage. Ce sont des composants bruts modifiables, pas un modélisateur automatique d'objets arbitraires.

--example river-pavilion / --example flanged-chamber sont des problèmes de validation d'outils architecturaux/mécaniques originaux ; ils ne remplacent pas l'objet de reproduction spécifié par l'utilisateur. Les scripts scripts/make_demo.py, prepare_web.py --scene et build_blender.py conservent la route de la liste de partage de la pompe centrifuge. Les nouveaux composants JS et l'aperçu générique ne supportent pas automatiquement Blender ; implémentez et validez séparément.

--example pneumatic-press fournit un exemple avec de nouvelles interfaces, des caractéristiques de maillage réelles, une course, un diagramme de connexion et un rendu d'illustration. La nouvelle vérification d'interface JS et le shader ne sont pas automatiquement migrés vers Blender ; ne présentez pas la validation web comme une validation double moteur.

--example contact-switch fournit une reconstruction 3D indépendante du mécanisme de bouton d'Anatomy : trous de guidage réels, ressort à pas variable, six terminaisons, distance nette du fil à la plaque de base, et lecture pilotée par l'écart réel des contacts. C'est un exemple de développement, ne le considérez pas comme un résultat de test aveugle pour tous les nouveaux sujets.

--example indexed-workcell est un exemple de développement de processus original, démontrant différents constructeurs d'équipements, des cycles indépendants et HOME, l'appartenance des matières et un cache dynamique multicolore. Réutilisez le mappage explicite des équipements et l'échantillonnage conditionnel de factory-process.js ; les équipements inconnus ne doivent pas être silencieusement dégradés en boîtes génériques. Exécutez verify_migration.py --three <cheminThree> --report <JSON> pour vérifier ces relations et les contre-exemples de couleur/projection, puis inspectez réellement la page.

• Conventions de données partagées : coordonnées, géométrie, état et limites de vérification.
• Carte des sources et des migrations : inspiration par fichier/fonction amont précis, parties réimplémentées, licence.
• Lorsque l'utilisateur spécifie un cas open source existant, lisez Migration 3D d'œuvres existantes : géométrie d'affichage et proxy d'audit, extraction d'état pur, instanciation et validation réelle dans le navigateur.
• scripts/validate_scene.py : vérifie les ID, les nombres finis, les faces dégénérées, les maillages fermés et le volume orienté positivement. Ne vérifie que les solides fermés applicables ; pour les surfaces ouvertes, ajustez les règles et expliquez.
• Après avoir modifié la vérification d'interface, exécutez scripts/verify_assembly.py --three <cheminThree installé> --report <JSON de sortie>, puis configurez les trous/surfaces d'interface/jeux réels et les contre-exemples erronés pour le nouveau sujet ; actuellement, seule la vérification Three.js est implémentée.
• Après avoir modifié un composant JS partagé, exécutez scripts/verify_components.py --three <cheminThree installé> --report <JSON de sortie>, vérifiez les trous, l'épaisseur de paroi, les différentes tailles et la zone de sécurité de l'objectif ; ouvrez ensuite les exemples concernés. La vérification numérique n'évalue pas l'esthétique.
• Après avoir modifié le déploiement ou le cadrage, exécutez scripts/verify_explosion.py --three <cheminThree installé> --report <JSON de sortie> ; pour un sujet réel, configurez explosionChecks et validez avec verify_scene.py ; sans configuration, ce n'est pas considéré comme réussi. Pour l'aperçu, utilisez serve_preview.py --root <répertoire de génération> --port <port de départ>, en liant uniquement les ports libres de la machine locale et en désactivant le cache de développement ; après la génération, recharger pour vérifier le résultat actuel.
• Pour un nouveau sujet, vous pouvez exécuter scripts/verify_scene.py --builder <subject.js> --three <cheminThree installé> --report <JSON de sortie> ; puis utilisez les outils de navigateur autorisés par l'environnement actuel pour manipuler et prendre des captures d'écran. Si l'automatisation du navigateur indépendante est autorisée, vous pouvez exécuter node scripts/verify_preview.mjs --url <URL d'aperçu local> --out <répertoire de preuves> pour enregistrer les captures d'écran, l'état et les erreurs, puis inspecter manuellement les plans. Pour l'utilisation, les limites des outils et le périmètre, voir État partagé et validation rejouable.

Ne copiez pas l'intégralité du dépôt amont dans le projet d'exécution pour utiliser cette compétence. Les iso-kit, tube, lathe amont sont des systèmes de génération SVG ; la géométrie Three.js/Blender, le test de profondeur et l'interactivité de cette compétence sont des implémentations indépendantes.

Validation et livraison

Exécutez en fonction des fonctionnalités réelles et conservez des résultats révisables :

1. Géométrie : vérifiez les paramètres/ID/unités/nombres finis ; validez spécifiquement les trous clés, l'épaisseur de paroi, les axes, les contacts et les jeux. La vérification des données ne remplace pas la vérification des images.
2. État : vérifiez l'assemblage, le semi-éclaté, l'éclaté complet, la réinitialisation ; les lectures à l'exécution sont cohérentes avec la phase géométrique, pas de saut en pause. Les collisions ne sont testées que sur les paires de pièces qui ne doivent pas entrer en contact ; ne considérez pas tous les contacts d'assemblage normaux comme des erreurs.
3. Image : vérifiez le premier écran par défaut, la vue principale et les vues arrière/latérales à la taille de visualisation réelle, vérifiez la proportion du sujet, l'occlusion, la traversée de maillage, le flottement, les différences de matériaux, les ombres et la lisibilité du texte. Testez un écran étroit pour le web ; rouvrez le fichier .blend dans Blender pour vérifier les objets, les drivers et l'état des images. En présence d'une œuvre originale, ajoutez une comparaison avec la même position de caméra pour la vue d'ensemble et les gros plans fonctionnels ; en présence de transparence, de fumée ou de flammes, vérifiez l'occlusion avant/après et le processus d'arrêt. Après avoir passé la géométrie et l'état pur, vous devez toujours compiler le shader et observer l'image.
4. Relecture de la livraison : rouvrez le point d'entrée ou le fichier que l'utilisateur recevra, et dans le visualiseur cible, enregistrez élément par élément PASS / FAIL / NOT_RUN selon les quatre catégories d'exigences. En cas d'exportation, vérifiez séparément le projet natif, l'exportation et le support final ; en cas d'animation, lisez intégralement le processus que l'utilisateur vivra, vérifiez les actions, le texte et les lectures, un échantillonnage d'images ne remplace pas une inspection continue. Vérifiez la console ou le journal Blender ; ne rapportez les performances qu'après mesure.

Le modèle Three.js actuel est généré par prepare_web.py avec une liste de hachages de fichiers et build-info.js. Utilisez verify_preview.mjs --expect-build <ID de liste> pour lier les captures d'écran à la version réelle, à la page, à la caméra, à l'état et au viewport relu ; les images doivent encore être inspectées manuellement. Si la version ou le viewport correspondant ne peut pas être lu, n'utilisez pas d'anciennes captures d'écran comme nouveaux résultats. Après des changements par lots, synchronisez les matrices et le nombre de faces et de contours ; conservez la sémantique des matériaux source, ne créez pas de détails en épaississant toutes les tiges fines.

Livrez le point d'entrée, la source éditable, les ressources nécessaires et quelques captures d'écran clés. Rapportez les faits sur la source, les parties originales/adaptées, les validations effectuées et les éléments non vérifiés. Lorsque l'utilisateur demande une reproduction, correspond à la référence réelle, ne remplacez pas par l'exemple de pompe fourni.

En cas d'exportation, de versions multiples ou d'exigences de livraison explicites, lisez Outils de preuve et de livraison : faites correspondre les exigences avec la relecture finale, liez le code source et le hachage de la capture d'écran pour empêcher les enregistrements obsolètes ; lancez l'aperçu local sur un port exclusif et conservez la version avec des instantanés indépendants validés. Les outils ne peuvent vérifier que les associations de preuves et l'intégrité des fichiers, ils ne peuvent pas évaluer automatiquement le degré de restitution visuelle.

Pour itérer la compétence elle-même, sélectionnez des sujets indépendants et des entrées réelles dans evals/evals.json en fonction des changements ; ce sont des invites d'évaluation à exécuter, pas des enregistrements de réussite. Les exemples de développement, les régressions historiques et les évaluations de nouveaux sujets sont enregistrés séparément, évitez de tirer des conclusions généralisées en optimisant uniquement sur le même cas.