Optimisation du rendu temps réel du jumeau numérique du pont roulant

Architecture du Jumeau Numérique, modèle de données AAS, étalonnage par simulation — cet article aborde le problème le plus concret : comment faire fonctionner le Jumeau Numérique de manière fluide sur un PC industriel.

La scène 3D du Jumeau Numérique du pont roulant ne s'exécute pas sur une station de travail haut de gamme, mais sur un PC industriel d'atelier (i5-8500, GPU intégré, 4 Go de mémoire vidéo partagée). Avec cette configuration, le rendu fluide d'un modèle de pont roulant de 200 000 triangles, ainsi que l'environnement du bâtiment d'usine, est impossible sans optimisation. Mesures réalisées : 12 fps avant optimisation, 58 fps après — cet écart de 46 fps est précisément l'objet de cet article.

Réduction du maillage : de 500 000 à 50 000 faces

Le modèle 3D du pont roulant dans le Jumeau Numérique provient généralement d'un modèle CAO exporté depuis la nomenclature de conception ou un fichier STEP, comptant souvent entre 500 000 et 1 million de triangles. Cette précision est acceptable pour la simulation structurelle, mais elle constitue une catastrophe pour le rendu dans un navigateur Web. La réduction du maillage est la première étape indispensable.

1.1 Stratégie de réduction polygonale

Le principe fondamental de la réduction polygonale est la « priorité au plan » : les grandes surfaces planes du modèle (âme de la poutre principale, plaque de couverture, côtés de la tête de pont) sont fusionnées à l'aide d'une détection planaire, tout en préservant les arêtes du contour. En revanche, le taux de réduction est abaissé pour les surfaces courbes et les cordons de soudure afin d'éviter toute déformation. Flux de travail recommandé : utilisez d'abord la décimation planaire pour réduire au minimum le nombre de polygones des zones planes, puis appliquez la décimation par effondrement pour une optimisation secondaire des zones restantes, en visant un total de moins de 50 000 polygones.

1.2 Outils recommandés

• Modificateur Decimate de Blender : gratuit, prend en charge la décimation planaire et la décimation par effondrement, avec un contrôle précis du taux de réduction.
• Simplygon : outil industriel de réduction automatique, génère automatiquement des chaînes LOD. Son coût est élevé, mais les résultats sont excellents.
• MeshLab : open source, adapté au traitement par lots.

1.3 Limites à ne pas dépasser

Un nombre de polygones plus faible n'est pas toujours synonyme de meilleure qualité. Une réduction excessive déforme le contour du modèle, ce qui est immédiatement perceptible. La règle empirique est la suivante : après réduction, la différence visuelle entre le modèle statique et le modèle d'origine doit être imperceptible à l'œil nu. Concrètement, superposez le modèle original et le modèle réduit, activez la transparence pour comparer, et considérez que le résultat est acceptable si l'écart de contour est inférieur à 1 pixel.

Chargement progressif par niveaux de détail (LOD)

Le LOD (Level of Detail) est la technique d'optimisation 3D la plus éprouvée : on voit les détails de près, et le contour de loin. Dans un contexte de Jumeau Numérique, l'opérateur ne scrute généralement pas les détails des cordons de soudure d'un pont roulant spécifique ; la plupart du temps, il observe l'état de fonctionnement de plusieurs ponts roulants dans une vue d'ensemble.

2.1 Conception des niveaux de détail

Les niveaux de détail sont répartis en 4 catégories selon la distance de visualisation : LOD0 (haute précision, 0~50 m), LOD1 (précision moyenne, 50~200 m), LOD2 (aperçu grossier, 200~500 m), LOD3 (vue lointaine, 500 m et plus). Le nombre de polygones et la résolution des textures pour chaque niveau sont conçus comme suit :

2.2 Stratégie de transition

Si le changement de LOD est effectué en coupe franche (basculement brutal du modèle au seuil), un effet de « saut » visuel se produit. Il est recommandé d'utiliser le composant LOD de three.js avec une transition en fondu, ou de définir le seuil de basculement comme une plage d'animation (par exemple, un mélange progressif de transparence entre 48 et 52 m). Par ailleurs, la détection du changement de LOD ne doit pas être effectuée à chaque frame ; une vérification toutes les 200 ms suffit, ce qui économise le CPU.

III. Compression des textures

Les textures constituent la principale source d'occupation de la mémoire vidéo. Un ensemble complet de matériaux PBR (baseColor + roughness + metallic + normal + AO) en 2048×2048 non compressé consomme environ 200 Mo de mémoire vidéo pour un seul pont roulant. L'affichage simultané de 5 ponts roulants provoque directement un dépassement de la mémoire vidéo.

Solution recommandée :

• ASTC 6×6 : format de compression de texture développé par ARM, taux de compression d'environ 4:1, perte de qualité acceptable. Bien pris en charge par WebGL2.
• KTX2 + Basis Universal : compression de texture multiplateforme, décompression directement par le GPU sans intervention du CPU, loader prêt à l'emploi dans Three.js.
• Réduction de la résolution des textures : baseColor en 1024×1024 suffit, roughness/metallic en 512×512, normal en 1024×1024, AO en 256×256.

Après optimisation, l'occupation mémoire des textures d'un seul pont roulant passe de 200 Mo à 45 Mo.

IV. Élimination des objets occultés (Occlusion Culling)

Dans une scène de Jumeau Numérique, au moins la moitié des objets sont invisibles depuis le point de vue actuel — le mur derrière, la Colonne de l'autre côté, le Chariot masqué par la Poutre Principale. Soumettre tous les objets au GPU pour rendu est un pur gaspillage.

Three.js n'intègre pas l'Occlusion Culling nativement ; il faut l'implémenter soi-même ou utiliser une bibliothèque tierce :

• Portails : diviser le Bâtiment d'usine en plusieurs zones/pièces ; les objets d'une zone ne sont rendus que lorsque cette zone est visible. Adapté aux scènes où la structure du bâtiment est Fixation.
• Requêtes d'occlusion matérielles : utiliser EXT_disjoint_timer_query ou l'Occlusion Query de WebGL2 pour Détection de la visibilité des objets. Précision élevée mais avec un délai d'une frame, adapté aux grands objets statiques.
• Frustum Culling : activé par défaut dans Three.js, ne rend que les objets dans le frustum de la caméra. C'est la base, mais insuffisant — les objets dans le frustum peuvent toujours être masqués par d'autres objets.

En pratique, la solution des portails est recommandée. Diviser le Bâtiment d'usine en plusieurs zones le long de la direction de la Portée ; chaque pont roulant n'appartient qu'à sa zone actuelle plus les zones adjacentes. Si l'opérateur se trouve dans la zone A, les ponts roulants des zones B et C ne sont pas rendus, seules leurs données d'état sont mises à jour sous forme de texte.

V. Optimisation du transfert de données

Le rendu ne concerne pas uniquement le front-end — la manière dont les données sont transmises du back-end au front-end, leur volume et leur vitesse influencent directement l'expérience utilisateur.

5.1 Mise à jour incrémentale

Les données d'état du pont roulant sont actualisées toutes les 100 ms, mais 95 % des points de données restent identiques à la frame précédente (par exemple, la Charge nominale et la Portée, ces Paramètres Techniques ne changent jamais). Une transmission complète est un gaspillage de bande passante et de temps de parsing CPU.

Solution : le back-end ne transmet que les attributs modifiés. Chaque envoi utilise un bitmap pour indiquer quels attributs ont changé ; le front-end ne met à jour que l'état des objets 3D correspondant aux attributs modifiés. En pratique, la bande passante passe de 50 Ko/s par pont roulant à 8 Ko/s.

5.2 Compression des données

• JSON + gzip : taux de compression d'environ 6:1
• JSON + Brotli (support natif Chrome/Firefox) : taux de compression d'environ 8:1, décompression légèrement plus lente que gzip mais acceptable
• Protocol Buffers (recommandé) : encodage binaire, volume 5 fois inférieur au JSON, vitesse de parsing 10 fois supérieure. Bibliothèque protobuf.js disponible, intégration sans douleur avec Three.js.

5.3 WebSocket vs SSE

• WebSocket : duplex intégral, latence minimale, adapté au flux de données en temps réel.
• SSE (Server-Sent Events) : transmission unidirectionnelle, support natif du navigateur, mécanisme de reconnexion intégré.
• Recommandation : WebSocket + reconnexion automatique (intervalle de heartbeat 15 s), avec repli sur SSE si le réseau sur site est instable.

VI. Optimisation du thread de rendu

L'optimisation du thread de rendu consiste essentiellement à extraire le traitement des données du thread principal :

Recommandations de configuration matérielle

Quelle configuration PC industriel pour un jumeau numérique de pont roulant ?

La configuration standard des PC industriels dans la plupart des usines se situe entre le niveau « entrée de gamme » et « standard ». Après mise en œuvre complète du plan d'optimisation ci-dessus, la fréquence d'images moyenne pour piloter 5 ponts roulants avec un i5-8500 et son GPU intégré est passée de 12 à 58 fps. Si le site ne compte que 1 à 2 ponts roulants, une configuration d'entrée de gamme est tout à fait suffisante.

Optimisation du rendu côté périphérie : les points clés

L'optimisation du rendu côté périphérie n'a rien de mystique. Tout repose sur trois principes : réduire les données transmises, simplifier les modèles 3D et tirer pleinement parti du GPU. En réduisant la bande passante de transmission de 50 Ko/s à 8 Ko/s par pont roulant, le nombre de polygones de 500 000 à 50 000 et l'utilisation mémoire de 1,8 Go à 480 Mo, il est tout à fait possible d'atteindre 60 fps pour le jumeau numérique sur un PC industriel.

Cette série d'articles sur le jumeau numérique s'achève ici pour le moment. Les quatre articles ont couvert l'architecture, le modèle de données, l'étalonnage de la simulation et l'optimisation du rendu, soit les quatre maillons technologiques essentiels à la mise en œuvre d'un jumeau numérique de pont roulant. De nouveaux articles viendront compléter cette série dès que de nouvelles avancées techniques seront disponibles.

Questions fréquentes sur le jumeau numérique de pont roulant