Arrêtez de reconstruire la roue: Comment faire évoluer votre pipeline CAO vers 3D

De nombreuses équipes d'ingénieurs ont frappé le même mur. Les fichiers CAO s'accumulent. Les critiques ralentissent. Les gens qui ont besoin de voir un modèle ne peuvent pas l’ouvrir, et ceux qui peuvent l’ouvrir n’ont pas le temps de le convertir pour tous les autres.

Ce guide s'adresse à tous ceux qui possèdent ce problème: Ingénieurs 3D, concepteurs, développeurs, et le personnel informatique qui les soutient. Il décompose ce qu'exige un pipeline CAO-Temps Réel 3D évolutif, pourquoi les scripts ad hoc et les conversions ponctuelles cessent de fonctionner à grande échelle, avec des exemples d'entreprises qui ont résolu le problème en production.

C'est un cadre de travail que vous pouvez utiliser pour évaluer votre propre pipeline, quels que soient les outils que vous choisissez.

A qui s'adresse ce guide

Ingénieur 3D, concepteur, ou développeur: il s'agit d'une décomposition technique de ce qu'un pipeline doit faire.

Directeur informatique ou directeur de l’ingénierie des données : cela couvre les questions de gouvernance, de coûts et d’échelle qui vous importent.

Les deux groupes ont un objectif commun: sortir les données 3D complexes des silos pour les mettre entre les mains des personnes qui en ont besoin, de manière fiable et répétée.

Chapitre 1: L'écart de réalité - pourquoi les données CAO restent bloquées dans des silos

Voir, c'est croire. Lorsqu'une équipe peut réellement voir ce qu'elle construit, en trois dimensions et en temps réel, elle prend de meilleures décisions. Il attrape les défauts de conception plus tôt. Il met les produits sur le marché plus rapidement.

La plupart des organisations ne fonctionnent pas ainsi. Designers et ingénieurs construisent les produits de demain dans des outils de CAO spécialisés. Tous les autres membres de l'équipe, des spécialistes du marketing de produits aux directeurs d'usine, examinent les dessins plats et les diapositives statiques. Unity appelle cela déconnecter le fossé réalité: la personne qui comprend le mieux le modèle est souvent la seule personne qui peut l'ouvrir.

Trois goulets d'étranglement spécifiques créent le fossé de la réalité:

• Outillage. Les moteurs CAO, PLM et temps réel parlent rarement la même langue. Chaque transfert entre eux risque de perdre des données ou une reconstruction manuelle.
• Temps. Convertir et optimiser un seul assemblage complexe à la main peut prendre des jours. Multipliez cela par des centaines d'assemblages et des dizaines de gammes de produits, et le retard peut être important.
• Expertise. Les personnes qui savent déplacer des données entre ces outils sont souvent une poignée de spécialistes. Quand ils sont occupés, ou quand ils partent, le pipeline bloque avec eux.

Aucun de ces problèmes n'est nouveau. Ce qui a changé, c’est le coût de les ignorer. Les produits sont plus complexes. Les cycles de révision sont plus répartis, souvent entre les fuseaux horaires et les disciplines. Et on s'attend, de plus en plus, à ce qu'un modèle 3D se mette à jour aussi vite que le fichier source dont il est issu.

Un pipeline conçu pour combler le fossé de la réalité ne convertit pas un fichier une seule fois. Il doit fonctionner pour chaque itération, quel que soit le volume que l'organisation produit de nouveaux assemblages, sans avoir besoin d'un spécialiste pour le surveiller. C’est la différence entre une conversion ponctuelle et un pipeline évolutif, et c’est le sujet du reste de ce guide.

Chapitre 2: Que signifie évolutif pour un pipeline 3D

Il est facile d'appeler n'importe quel flux de travail CAO en 3D un pipeline. Il est plus difficile d’en faire un qui balance. La différence se résume à cinq étapes, qui doivent chacune fonctionner sans qu'une personne le refait à la main à chaque fois.

1. Ingérer. Le pipeline doit accepter n’importe quel format utilisé par l’équipe de conception, qu’il s’agisse d’un outil de CAO mécanique, d’un package BIM, d’un scan de nuage de points ou d’un maillage exporté depuis un autre moteur.

2. Convertis. Les données CAO, paramétriques, et les données 3D temps réel, polygonales, ne sont pas la même chose, et aucune quantité de nettoyage manuel ne change cela à grande échelle. (Le chapitre 3 explique pourquoi.) Le pipeline doit faire cette traduction automatiquement.

3. Optimisation. Un import CAO brut est généralement trop lourd pour être exécuté en temps réel. Le pipeline doit optimiser les fichiers (par exemple: simplifier la géométrie, générer des niveaux de détails pertinents) sans qu'une personne ouvre chaque fichier.

4. Centraliser et gouverner. Une fois qu'un modèle est converti, quelqu'un doit être capable de le trouver, de savoir quelle version est actuelle et de contrôler qui peut le voir ou le changer.

5. Distribuer. L'actif fini doit atteindre n'importe quelle application ou périphérique sur lequel l'utilisateur final se trouve, et il doit se mettre à jour lorsque le fichier source change.

Un workflow qui gère bien l’une de ces étapes mais pas les autres n’est pas un pipeline. C’est un goulot d’étranglement avec moins d’étapes. Le chapitre suivant examine ce qui se passe techniquement à chacune de ces étapes, et le chapitre 5 transforme cette liste en une liste de vérification que vous pouvez utiliser pour évaluer n'importe quel pipeline, y compris le vôtre.

Chapitre 3: Anatomie d'un pipeline 3D CAO-temps réel

Commencez par une question : pourquoi un moteur 3D ne peut-il pas ouvrir directement un fichier CAO ?

La réponse est la géométrie. Les outils de CAO décrivent des formes avec des surfaces paramétriques exactes, parfois appelées BRep ou NURBS. Cette précision est exactement ce dont un ingénieur mécanique a besoin pour concevoir une pièce au micron près. Mais les moteurs 3D ne restituent pas les surfaces paramétriques. Ils donnent des maillages: des collections de triangles plats qui se rapprochent d'une forme assez proche pour regarder juste à la vitesse. Transformer l'un en l'autre n'est pas facultatif. Optimiser des données complexes pour une utilisation dans un moteur 3D est le premier travail que tout pipeline CAO vers 3D doit faire.

Cette étape doit préserver plus que la forme brute. Un pipeline utile conserve :

• Hiérarchie, donc un assemblage de mille parties reste organisé en mille parties.
• Matériaux et couleurs, donc le modèle ressemble toujours à ce qu’il est censé être.
• Métadonnées, afin que les équipes en aval puissent rechercher, filtrer et produire des rapports sur le modèle.

La couverture du format compte ici. Unity Asset Transformer prend en charge plus de 70 formats CAO, BIM, maillage et nuage de points, notamment les fichiers AutoCAD, CATIA, STEP, IFC, Revit et glTF, car les équipes d'ingénierie utilisent rarement un seul outil. Si un pipeline ne gère que les formats que votre équipe de CAO utilise aujourd'hui, il prendra du retard si une autre équipe, un autre fournisseur ou une autre acquisition apporte quelque chose de différent.

Une fois la géométrie convertie, elle doit généralement être plus légère avant d’être prête pour une utilisation en temps réel. Les techniques d'optimisation typiques comprennent:

• Décimation, qui réduit le nombre de triangles.
• Retopologie, qui reconstruit un maillage simplifié à partir d'un maillage complexe.
• Génération de niveau de détail (LOD), de sorte que les objets distants restituent à une fidélité inférieure automatiquement.

Enfin, le pipeline doit déplacer l’actif fini quelque part d’utile, que ce soit dans une visionneuse Web, téléchargé dans un projet de moteur 3D ou poussé vers un casque XR. Si le fichier CAO source change, un pipeline vraiment évolutif réexécute automatiquement toute cette séquence et informe les personnes utilisant le modèle qu'une nouvelle version est prête.

Chaque étape de ce chapitre peut être faite manuellement, et pour un seul modèle, c'est souvent le cas. Le problème, c'est la répétition à l'échelle, ce que recouvre exactement le chapitre 4.

Chapitre 4 : Construire vs. Acheter - Pourquoi des pipelines assez bons cassent à grande échelle

La plupart des pipelines CAO vers 3D ne commencent pas comme des pipelines. Ils commencent comme un scénario. Un ingénieur avait besoin d'un modèle converti pour une présentation, a écrit une exportation ponctuelle, et ça a marché. Six mois plus tard, ce script est lancé chaque semaine, personne ne se souvient de tous ses cas de bord, et il se casse quand un nouvel outil de CAO entre dans le mix.

C’est la question de la construction contre l’achat à laquelle tout décideur technique est finalement confronté, et il vaut la peine d’être honnête sur ce que coûte réellement la construction à grande échelle :

• Brittleness. Les scripts roulés à la main sont généralement écrits en fonction des fichiers CAO que l'auteur avait sous la main. Une nouvelle géométrie, de nouveaux formats ou des structures hiérarchiques inhabituelles ont tendance à les briser de manière difficile à déboguer après coup.
• Risque de personne clé. La connaissance du fonctionnement du pipeline vit souvent dans la tête d’une ou deux personnes. Lorsqu’ils ne sont pas disponibles, le pipeline s’arrête.
• Coût de maintenance caché. Chaque nouvelle version CAO, chaque nouveau format de fichier et chaque nouvelle cible en aval (par exemple: web, casque XR, mobile) est une autre chose que le script doit être mis à jour pour être supporté. C’est du temps d’ingénierie qui n’apparaît pas comme un élément de ligne avant d’être en retard.
• Aucune source de vérité. Sans gestion centralisée des actifs, différentes équipes se retrouvent avec des copies différentes et légèrement déphasées du même modèle.

Rien de tout cela ne signifie que construire le vôtre est toujours faux. Pour un cas d'utilisation étroit et stable, un script peut être exactement la bonne quantité d'ingénierie. Le risque apparaît spécifiquement lorsque le volume augmente: plus de gammes de produits, plus de formats, plus d'équipes ayant besoin d'accès, des changements de conception plus fréquents.

À ce moment-là, le véritable concurrent d'un pipeline construit à cet effet est la tentation de continuer à rapiécer ce qui existe déjà plutôt que de prendre du recul et de se demander si l'architecture sous-jacente peut réellement évoluer. Les critères d’évaluation du chapitre suivant sont conçus pour aider à faire cet appel objectivement, que vous évaluiez un fournisseur, un système maison ou un mélange des deux.

Chapitre 5: Une liste de contrôle d'évaluation pour les décideurs techniques

Quel que soit le pipeline que vous évaluez, qu’il soit construit à l’interne ou acheté à un fournisseur, les mêmes questions s’appliquent. Utilisez cette liste de contrôle pour comparer les options sur un pied d'égalité.

Couverture format

• Combien de formats CAO, BIM, maillage et nuage de points prend-il en charge nativement ?
• Préserve-t-il la hiérarchie, les matériaux, les métadonnées et l'animation à l'importation, ou simplement la géométrie brute ?

Profondeur d'automatisation

• Peut-il traiter par lots des centaines de fichiers sans qu'une personne n'ouvre chacun d'eux ?
• Expose-t-il une API ou un SDK pour que votre équipe puisse la scripter et l'étendre, plutôt que de se limiter à un ensemble fixe d'étapes manuelles ?
• Peut-il détecter et réexécuter automatiquement lorsqu'un fichier source change ?

Gouvernance et contrôle d'accès

• Prend-il en charge le contrôle d'accès basé sur les rôles, de sorte que les contributeurs, les réviseurs et les téléspectateurs voient et ne font que ce qu'ils devraient faire ?
• Peut-il imposer une version unique de la vérité entre les équipes, plutôt que de laisser les copies en double s'éloigner ?

Flexibilité de déploiement

• Peut-il fonctionner dans un cloud multi-locataire standard et séparément, peut-il être déployé dans un cloud privé virtuel ou un environnement sur site pour les équipes qui ont besoin de conserver des données dans leur propre infrastructure ?
• S'intègre-t-il aux systèmes de gestion des identités et des accès que votre équipe informatique utilise déjà ?

Intégration avec les outils existants

• Fonctionne-t-il avec les outils de conception que vos équipes utilisent déjà, pas seulement les packages CAO, mais des outils comme Blender, Maya ou Photoshop pour le contenu non CAO ?
• S'intègre-t-il dans votre workflow de contrôle de version existant, ou nécessite-t-il de l'abandonner ?

Coût total de possession

• Est-ce que la tarification par siège, par utilisation ou un forfait de plateforme, et comment cela évolue-t-il à mesure que votre équipe et votre bibliothèque d'actifs se développent ?
• Quel est le coût réel de l’ingénierie de l’entretien du pipeline une fois qu’il est en service, et pas seulement le coût de sa mise debout?

Aucun outil ne marquera parfaitement sur chaque ligne. Le but de cette check-list n’est pas de trouver une réponse parfaite. Il s’agit de s’assurer que les lacunes que vous acceptez sont des lacunes que vous avez choisies, et non des lacunes que vous avez découvertes alors que le pipeline était déjà porteur pour l’entreprise.

Chapitre 6 : La preuve du terrain

Les cadres sont utiles, mais ils sont plus faciles à faire confiance aux preuves. Voici comment trois organisations, dans trois secteurs d’activité différents, ont abordé le même problème sous-jacent.

Autoliv

Autoliv, le plus grand fournisseur mondial de sécurité automobile, devait présenter aux clients des produits de sécurité complexes de manière plus interactive que ne le permettaient les dessins statiques. En utilisant Unity Asset Transformer pour automatiser le transfert et l'optimisation des données CAO, Autoliv a réduit ce processus de quatre jours à six heures par produit. Ce n'est pas une victoire unique - c'est une différence récurrente sur chaque nouveau produit qu'Autoliv met sur le marché.

Groupe BMW

BMW Group a dû faire face à une version différente du même problème à une échelle beaucoup plus grande: Version Control problèmes, formats de fichiers incohérents, et friction de collaboration sur une vaste bibliothèque mondiale de ressources 3D. BMW a construit « 3D Mine », une plateforme de gestion d’actifs 3D optimisée par Unity Asset Manager, pour standardiser la façon dont les équipes de conception, d’ingénierie et de marketing de l’entreprise stockent, trouvent et collaborent sur le contenu 3D.

Les détails diffèrent, mais la forme de chaque histoire est la même : un pipeline évolutif a transformé un goulot d'étranglement technique en infrastructure de routine et répétable, et chaque organisation a mesuré la différence en heures gagnées, en équipes débloquées ou en parties prenantes incluses.

Chapitre 7 : Gouvernance et sécurité à l’échelle de l’entreprise

Un pipeline qui va vite mais qui fuit la propriété intellectuelle ne résout pas réellement le problème, il change simplement le risque que vous portez. Pour les acheteurs techniques, la gouvernance compte généralement autant que la rapidité.

Trois domaines ont tendance à compter le plus:

Un contrôle d'accès basé sur les rôles. Toutes les personnes qui touchent un actif 3D n'ont pas besoin du même niveau d'accès. Un système pratique distingue les administrateurs qui gèrent l'ensemble du projet, les contributeurs qui téléchargent et modifient, les consommateurs qui utilisent les actifs dans le travail en aval, et les spectateurs qui n'ont qu'à regarder. La bonne granularité, tant au niveau de l’organisation que du projet, empêche le mode d’échec commun où le « partage facile » devient « aucun contrôle d’accès réel ».

Contrôle du déploiement. Certaines organisations sont à l'aise pour stocker des actifs 3D dans un cloud sécurisé et multi-locataires. D'autres, en particulier dans les industries réglementées ou ayant une PI sensible, ont besoin de données pour rester dans l'infrastructure qu'ils contrôlent. Un pipeline conçu pour une utilisation en entreprise devrait offrir les deux options : un stockage sécurisé dans le cloud par défaut et une option de cloud privé virtuel ou sur site, déployée sur des infrastructures comme AWS ou Azure, pour les équipes qui en ont besoin.

Intégration identitaire. Le contrôle d'accès est seulement aussi fort que le système d'identité derrière lui. Les pipelines de niveau entreprise devraient s'intégrer aux systèmes de gestion des identités et des accès (IAM) que votre organisation exécute déjà, plutôt que de maintenir un ensemble distinct et parallèle de comptes d'utilisateurs et d'autorisations.

C’est le travail de base qui devient non négociable au moment où un pipeline traite à grande échelle les conceptions réelles des produits d’une entreprise.

Chapitre 8 : Une feuille de route pour votre propre pipeline

Les conseils d’entreprise d’Unity décrivent une façon d’assembler cette architecture : Asset Transformer pour gérer l'ingest et l'optimisation, Asset Manager pour centraliser et régir les actifs résultants, et Pipeline Automation pour orchestrer toute la séquence à grande échelle, le tout fonctionnant ensemble comme ce qu'Unity désigne comme son moteur de données 3D. C’est une architecture de référence, pas la seule. La liste de contrôle du chapitre 5 vous indiquera si elle, ou toute autre option, correspond réellement aux besoins de votre organisation.

Chapitre 9 : Que faire ensuite

Un pipeline CAO-to-real-time 3D évolutif ne se construit pas en un seul après-midi, mais la première étape est petite : exécutez votre processus actuel par rapport à la liste de contrôle du chapitre 5 et voyez où se trouvent les lacunes.

À partir de là, quelques étapes pratiques suivantes:

• Explorez la documentation technique pour Unity Asset Transformer et Unity Asset Manager pour voir comment les étapes du chapitre 3 s'articulent avec une implémentation spécifique.
• Lancez un essai gratuit d'Unity Industry pour tester le flux de travail par rapport à vos propres fichiers CAO.
• Adressez-vous à un représentant Unity si votre organisation doit planifier un déploiement sur plusieurs équipes ou un déploiement en cloud privé virtuel.

Quel que soit votre choix, l'objectif reste le même: combler l"écart de réalité entre les personnes qui construisent vos données 3D et toutes les autres personnes qui ont besoin de les voir.