Guide au filtrage des bitmaps et au bake des textures dans V-Ray SDK

Au 7 octobre 2026, la documentation de Chaos sur V-Ray SDK répertorie les paramètres disponibles pour filtrer les textures bitmap et baker des textures avec BakeView. Ce guide s’adresse aux artistes techniques et aux développeurs qui utilisent les fonctionnalités du SDK plutôt que les menus d’une interface. La documentation ne précise pas à quelle version du logiciel V-Ray ces fonctionnalités s’appliquent ; il ne faut donc pas présumer d’une compatibilité avec une version particulière. L’objectif est de comprendre le rôle des paramètres afin de configurer plus judicieusement les workflows de texture et de bake.

1. Choisir le type de filtrage du bitmap

BitmapBuffer sert à fournir au plug-in de texture TexBitmap les données bitmap d’un fichier. Le choix du filtre se fait avec le paramètre filter_type. La documentation indique les options sous forme de valeurs numériques ; il est donc important de vérifier à quelle méthode correspond chaque valeur lors de l’intégration au SDK.

1. Commencez par choisir le filtre adapté à l’usage de la texture, puis vérifiez que la valeur de filter_type correspond à la méthode retenue. Par exemple, 1 correspond au filtrage mip-map, tandis que 5 correspond au filtrage mip-map net. Ce ne sont pas les mêmes réglages.

2. Si vous ne souhaitez aucun filtrage, envisagez la valeur 0 ; si vous avez besoin du comportement au plus proche voisin, envisagez -1. La documentation décrit ces options, mais ne recommande pas de valeur idéale unique pour toutes les scènes ou tous les types de textures.

3. N’utilisez pas la valeur 4 dans une nouvelle configuration. La documentation du SDK indique que cette option est obsolète.

4. filter_blur figure également parmi les propriétés de BitmapBuffer, mais l’extrait de documentation fourni ne précise ni le comportement de ce paramètre ni une valeur recommandée. Vérifiez la documentation de l’application utilisée au lieu de présumer d’une valeur de flou fixe.

L’effet du filtrage sur l’image ne se limite pas au choix de cette valeur numérique. Le transfert des couleurs et les informations sur l’espace colorimétrique peuvent également influer sur le traitement du bitmap. Ne considérez donc pas les paramètres de filtre indépendamment de la gestion des couleurs.

2. Régler ensemble la fonction de transfert et l’espace colorimétrique

Dans BitmapBuffer, transfer_function indique la fonction de transfert de la texture : 0 signifie linear, 1 gamma corrected, 2 sRGB et 3 auto. La documentation signale également un point important : si transfer_function n’est pas défini, le filtrage de la texture risque de ne pas fonctionner correctement. Ce paramètre doit donc être pris en compte lors du choix du filtre.

1. Déterminez la fonction de transfert adaptée à la source de la texture et définissez transfer_function en conséquence. La documentation répertorie clairement les options et leurs valeurs numériques, mais ne propose pas de règle générale indiquant quelle valeur utiliser selon le type de fichier.

2. Considérez rgb_color_space comme l’espace colorimétrique RGB linéaire de la texture. La valeur par défaut indiquée est raw, ce qui signifie qu’aucune conversion n’est effectuée.

3. Parmi les noms d’espaces colorimétriques intégrés figurent lin_srgb et acescg. La documentation décrit lin_srgb comme l’espace RGB linéaire pour sRGB. Si une variable d’environnement OCIO est définie ou si le paramètre ocio_config_file de SettingsUnitsInfo est renseigné, d’autres noms d’espaces colorimétriques présents dans la configuration OCIO correspondante peuvent également être utilisés.

4. Tenez compte de l’ordre des conversions : selon la documentation, la conversion de l’espace colorimétrique a lieu après l’application de la fonction de transfert. Des paramètres incompatibles peuvent donc compromettre le résultat attendu du traitement des couleurs.

Ces précisions sont particulièrement importantes dans les workflows reposant sur le SDK, où des textures provenant de différentes sources sont utilisées dans une même scène. La documentation ne recommande toutefois aucune valeur d’espace colorimétrique ou de fonction de transfert pour une scène donnée. Le choix doit être vérifié en fonction de la nature de la texture source et de la configuration OCIO utilisée dans le projet.

3. Définir le périmètre du bake avec BakeView

La documentation décrit BakeView comme le plug-in qui remplace RenderView lors du bake de textures. La cible de l’opération est indiquée avec bake_node, et les objets ciblés par un bake par projection avec target_nodes. La génération des UV peut être associée via bake_uvwgen ; les champs u_min, v_min, u_max et v_max définissent les limites de la plage UV à baker.

1. Déterminez les objets à baker et les cibles de projection. Pour activer le bake par projection, projection_baking vaut 0 pour un bake normal et 1 pour un bake par projection.

2. Associez le générateur d’UV à BakeView. Pour placer plusieurs objets dans une seule image, vous pouvez utiliser mapped_bake_nodes et les générateurs d’UV correspondant à chaque objet. Il est également possible d’attribuer le même générateur d’UV à tous les nœuds via bake_uvwgen.

3. Si vous définissez les régions de bake individuellement, gardez à l’esprit que mapped_x0, mapped_y0, mapped_x1 et mapped_y1 indiquent la région de sortie de chaque objet. La propriété mapped_bake_nodes_auto permet un placement automatique des régions ; selon la documentation, elle bake les nœuds dans une seule image sans définir de régions.

4. Contrôlez le comportement des rayons. max_depth permet d’ignorer la géométrie située au-delà de cette distance le long du rayon ; si la valeur est 0, aucune géométrie n’est exclue pour cette raison. ray_offset définit le décalage du point de départ du rayon le long de la normale. La documentation ne recommande pas de valeur idéale générale pour ces champs.

5. Choisissez le type de normale et la direction du bake en fonction du besoin. Lorsque normal vaut 0, une smooth normal est utilisée ; lorsqu’il vaut 1, c’est une geometry normal. Pour from_camera, 0 correspond aux rayons réfléchis le long de la normale de surface et aux effets d’ombrage similaires ; 1 correspond à un bake avec des rayons émis depuis la caméra. Définissez clairement la méthode de bake souhaitée avant de modifier ces options.

Erreurs fréquentes

L’erreur la plus importante consiste à choisir un filtre sans définir transfer_function : la documentation du SDK précise que le filtrage risque alors de ne pas fonctionner correctement. Une autre erreur consiste à mal interpréter la valeur numérique de filter_type ou à choisir l’option 4, indiquée comme obsolète.

Pour le bake, n’oubliez pas qu’une valeur de max_depth différente de zéro peut affecter la géométrie éloignée. De plus, lorsque vous utilisez mapped_bake_nodes, veillez à assurer la cohérence entre les générateurs d’UV associés à chaque objet et la logique des régions de sortie. La documentation fournit les paramètres du SDK, mais ne donne ni chemin de menu pour 3ds Max ou une autre application, ni numéro de version, ni réglage de qualité prêt à l’emploi.

Conséquences pour les workflows d’architecture et de visualisation

Ces paramètres sont utiles aux équipes qui automatisent le chargement de textures et le bake via V-Ray SDK. Les artistes techniques qui développent des outils de visualisation architecturale peuvent définir explicitement l’espace colorimétrique et les informations de transfert des bitmaps, ainsi que gérer au niveau du code le périmètre du bake et les régions UV des ressources de scène. Pour les équipes d’architecture et d’aménagement intérieur, l’intérêt tient moins à l’ajout direct d’une nouvelle fonctionnalité visuelle qu’à la possibilité de mieux contrôler la préparation des ressources.

Ces sources ne précisent ni les exigences matérielles, ni les conditions de licence, ni les versions précises de V-Ray concernées. Avant d’intégrer ces fonctionnalités à une chaîne de production, il convient donc de vérifier la compatibilité de la version du SDK utilisée, les conditions de licence et la configuration de gestion des couleurs du projet. Les fonctionnalités répertoriées dans la documentation ne doivent pas être considérées comme une garantie d’amélioration automatique de la qualité ou de la vitesse.