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.

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).

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.