Automatiser le rendu avec V-Ray App SDK : charger une scène et exporter l’image

Le V-Ray Application SDK (App SDK) permet aux applications tierces de lancer et de contrôler le moteur V-Ray. La documentation de Chaos consacrée à App SDK explique comment convertir en mémoire une scène en plug-ins V-Ray ou la charger depuis un fichier .vrscene, lancer le rendu et récupérer le résultat sous forme d’image. Ce guide présente le flux de travail de base du SDK aux équipes qui développent l’intégration du rendu à des outils d’architecture et de visualisation. Comme la documentation ne précise aucune version de V-Ray ou d’App SDK, les étapes décrites s’appliquent à l’interface App SDK documentée.

1. Préparer l’environnement d’exécution du SDK

Le composant principal d’App SDK est la classe VRayRenderer. Elle regroupe des opérations comme le chargement d’une scène, le lancement du rendu et l’accès à l’image. Avant de commencer, l’application doit pouvoir accéder à l’emplacement des fichiers de bibliothèque.

1. Définissez la variable d’environnement VRAY_SDK pour indiquer l’emplacement du SDK. Si vous utilisez le binding Python, le dossier python du SDK doit se trouver dans les chemins de recherche des modules Python ; la documentation donne PYTHONPATH en exemple à cet effet.

2. La documentation présente le script setenv.bat pour Windows et la commande source setenv.sh pour Linux et macOS. Ces scripts définissent les deux variables d’environnement.

3. Lorsque VRAY_SDK est défini, le binding recherche le binaire VRaySDKLibrary et ses dépendances dans VRAY_SDK/bin. Si l’arborescence du produit ne comporte pas de dossier /bin, il est possible d’utiliser la variable VRAY_APPSDK_BIN ; les binaires sont alors recherchés dans le dossier indiqué.

4. Si les variables d’environnement ne sont pas disponibles dans votre installation, le chemin de recherche des bibliothèques peut être défini à l’exécution. La documentation donne en exemple vray.setSDKLibraryPath(bin_folder) pour Python et le constructeur VRayInit pour C++.

Cette préparation est particulièrement importante pour une intégration intégrée à un autre logiciel ou exécutée de manière autonome : avant le lancement du rendu, le binding du SDK doit pouvoir trouver les bibliothèques V-Ray et leurs dépendances. Pour connaître les détails des méthodes d’initialisation, consultez également la documentation du binding correspondant au langage utilisé.

2. Charger une scène et lancer le rendu

Le flux de travail de base consiste à créer un objet VRayRenderer, à préparer une scène ou à la charger depuis un fichier, à lancer le rendu, à récupérer l’image, puis à libérer les ressources. La scène peut être construite en mémoire en réglant les paramètres des plug-ins V-Ray, ou chargée depuis un fichier .vrscene. L’exemple Python ci-dessous montre comment charger un fichier et obtenir une sortie PNG :

import vray
with vray.VRayRenderer() as renderer:
    renderer.load('./intro.vrscene')
    renderer.start()
    renderer.waitForRenderEnd(6000)
    image = renderer.getImage()
    image.save('intro.png')

start() s’exécute de manière asynchrone : le moteur V-Ray poursuit le rendu dans un thread distinct, sans monopoliser entièrement le flux d’exécution de l’application principale. getImage() permet de récupérer l’image à l’instant présent, non seulement une fois le traitement terminé, mais aussi pendant le rendu. L’application peut ainsi afficher une image intermédiaire ou l’enregistrer dans un fichier à l’aide de l’un des formats de compression pris en charge. La documentation utilise waitForRenderEnd() pour attendre la fin du rendu ; l’unité du paramètre indiqué dans les exemples n’est pas expliquée dans la source. Il ne faut donc pas lui attribuer d’unité de temps.

Lorsque l’application a terminé son travail, le renderer doit être fermé et la mémoire allouée libérée. L’exemple Python avec gestionnaire de contexte s’occupe du cycle de vie du renderer ; avec les bindings d’autres langages, utilisez la méthode de fermeture correspondante dans l’API concernée.

3. Choisir le mode pour l’aperçu ou le rendu final

App SDK propose deux modes de rendu principaux. Interactive est conçu pour prévisualiser rapidement l’image et suivre la progression tout en testant le contenu ou les réglages de la scène. Production sert à obtenir l’image finale souhaitée une fois la scène soigneusement configurée ; la préparation de l’image complète peut prendre plus de temps.

La documentation indique que le mode par défaut de la classe VRayRenderer est Interactive (CPU). Pour le GPU, CUDA et OptiX sont proposés pour NVIDIA, tandis que Metal et MetalRT sont proposés pour Apple. Cela ne signifie pas que tous les types de rendu sont disponibles sur chaque ordinateur : il faut vérifier que la station de travail et l’installation du SDK prennent en charge le mode choisi.

Le mode peut être défini à l’aide de la propriété renderMode de l’objet VRayRenderer. Selon la documentation, il n’est pas nécessaire de recréer ou de recharger la scène pour changer de mode entre deux rendus. Il est donc possible de travailler en mode Interactive pendant la conception, puis de passer en Production à l’étape finale, dans un même flux d’intégration.

4. Intégrer le suivi de l’état et des erreurs

Pendant le rendu en arrière-plan, le SDK émet des événements. L’événement de changement d’état permet d’informer l’application des transitions, par exemple du démarrage ou de la fin du rendu, ou de son arrêt à la suite d’une erreur. L’état indiquant que l’image finale est prête est IDLE_DONE ; des images intermédiaires peuvent également être récupérées pendant le traitement.

L’événement de message de journal fournit le texte du message et son niveau. La documentation énumère les niveaux info, warning, error et debug. L’application peut transmettre ces messages à son propre système de diagnostic afin de rendre visibles les problèmes survenant lors du chargement de la scène et du rendu.

Les callbacks d’événement sont exécutés dans un thread distinct de celui du rendu. Cette conception vise à éviter qu’un callback lent n’affecte la durée du rendu ; toutefois, des callbacks utilisateur lents peuvent retarder l’exécution d’autres callbacks. De plus, après un appel asynchrone à start(), il ne faut modifier ni la scène ni le renderer tant que ce dernier n’a pas quitté l’état PREPARING ; la documentation précise que les modifications effectuées pendant cette phase seront rejetées.

Qu’est-ce que cela change dans un workflow d’architecture et d’archviz ?

App SDK est surtout pertinent pour intégrer V-Ray au workflow d’une autre application, plutôt que pour accéder à un réglage de menu particulier dans une interface de modélisation. Une équipe peut, par exemple, regrouper dans son propre outil de préparation de scènes le chargement d’un fichier .vrscene, le lancement du rendu, la récupération de l’image en cours et l’enregistrement du résultat. L’intérêt est de pouvoir contrôler le moteur de rendu depuis l’application et d’effectuer l’aperçu comme le rendu final avec le même renderer.

Les bureaux doivent d’abord vérifier le binding correspondant au langage utilisé, l’emplacement des bibliothèques V-Ray et la disponibilité du mode CPU/GPU sur la machine cible. Les sources ne précisent ni les conditions de licence, ni le prix, ni la compatibilité avec un logiciel hôte particulier, ni les exigences matérielles ; il ne faut donc rien présumer à ce sujet. Le suivi de l’état de la scène et des journaux aide à créer une intégration plus robuste que la simple mise à disposition d’un bouton de rendu.

Erreurs fréquentes

• Lancer le binding du SDK sans avoir défini VRAY_SDK ou, en cas d’utilisation de Python, le chemin du module. Si la bibliothèque ou le module Python est introuvable, vérifiez d’abord les variables d’environnement et les chemins des dossiers.

• Traiter l’appel start() comme une opération synchrone et supposer que le rendu est immédiatement terminé. L’appel s’exécute en arrière-plan ; l’application doit suivre l’état d’avancement jusqu’à la fin.

• Modifier la scène ou le renderer pendant la phase PREPARING. Utilisez l’événement de changement d’état pour reporter les modifications à une phase appropriée.

• Exécuter des opérations longues dans un callback. La documentation indique que cela peut retarder les autres callbacks ; traitez les tâches lourdes en dehors du gestionnaire d’événements.