Intégrer un moteur 3D VTK dans une application .NET

Vous développez une application de gestion en C# / .NET et vous avez besoin d'afficher de la 3D scientifique — pièces mécaniques, maillages, résultats de simulation ? Voici comment marier la puissance de VTK (C++) avec le confort de .NET.

Pourquoi VTK (et OpenCascade) ?

VTK (Visualization Toolkit, par Kitware) est une bibliothèque C++ de référence pour la visualisation 3D et le traitement de données scientifiques : rendu de maillages, iso-surfaces, coupes, champs scalaires/vectoriels, nuages de points… Pour la partie géométrie CAO (import STEP/IGES, opérations booléennes, maillage), OpenCascade (OCCT) vient naturellement en complément.

Le hic : ce sont des moteurs C++, alors que votre application est en C#. Tout l'enjeu est de construire un pont fiable entre les deux mondes.

Le pont entre C++ et .NET

Trois approches, selon vos besoins et votre maîtrise :

• Bindings existants : Kitware propose Activiz (wrapper .NET commercial de VTK) ; il existe aussi des wrappers communautaires. Rapide à mettre en œuvre, mais on dépend de la couverture et de la version proposées.
• Wrapper maison en C++/CLI : on écrit une couche pont exposant, en .NET, exactement les fonctions VTK/OCCT dont on a besoin. Plus de travail, mais un contrôle total sur l'API, les performances et le périmètre embarqué.
• Interop P/Invoke : possible pour une surface d'API réduite, mais vite fastidieux dès que l'on manipule des objets complexes.

En pratique, un wrapper C++/CLI ciblé est le meilleur compromis pour un produit industriel : on n'expose que le nécessaire, proprement — et on peut le réutiliser d'un projet à l'autre.

OPALE3D_CSHARP : le pont, déjà fait

C'est exactement la démarche que nous avons suivie chez JB-Opale : ce pont VTK ↔ .NET est packagé dans OPALE3D_CSHARP, un NuGet prêt à l'emploi. Vous ajoutez le package à votre projet C# et vous manipulez la 3D directement en .NET — sans écrire vous-même la couche d'interop C++, ni gérer l'alignement des versions et des DLL natives.

Le package ne se limite pas au rendu : OpenCascade y est également exploité pour lire les formats CAO (STEP, IGES, BREP) et réaliser des opérations booléennes sur la géométrie. D'autres fonctionnalités peuvent être ajoutées sur demande.

Concrètement, cela fait gagner les semaines les plus risquées d'un projet 3D : la « plomberie » bas niveau est traitée, vous vous concentrez sur votre métier (affichage, mesures, post-traitement). Découvrir OPALE3D_CSHARP →

Où afficher la 3D ?

Le rendu VTK se fait dans une fenêtre native. Selon votre pile UI :

• WinForms : intégration directe via un contrôle d'hébergement de la render window VTK.
• WPF : hébergement du contrôle natif (interop HwndHost) dans l'arbre visuel WPF.
• .NET MAUI / multiplateforme : plus délicat ; on passe généralement par un handler natif dédié à la surface de rendu.

Performances & pièges

• Marshaling : évitez les allers-retours C#↔C++ dans les boucles chaudes. On transfère les gros tableaux (points, cellules) en bloc, pas élément par élément.
• Threading : le rendu VTK doit rester sur le thread UI ; déportez les calculs lourds sur d'autres threads et ne touchez au pipeline de rendu que depuis l'UI.
• Mémoire : les objets VTK/OCCT sont natifs. Une libération rigoureuse (Dispose / using côté wrapper) évite les fuites qui, en 3D, se voient vite.
• Versions & déploiement : alignez les versions VTK/OCCT, la plateforme (x64) et embarquez les DLL natives requises. C'est une source fréquente de « ça marche sur mon poste ».

Cas d'usage typiques

Cette architecture alimente des applications concrètes : visualiseurs CAO (import STEP/IGES, mesure, coupe), post-traitement de simulation (thermique, RDM, écoulements), ou encore contrôle qualité par comparaison de maillages. Le tout intégré à un logiciel de gestion existant, sans repartir de zéro.