🍺 [MAJ] Auberge médiévale : Low-Poly, Texture Caching et le nouveau super-nœud
Une scène d'auberge médiévale/fantasy pour crash-tester plusieurs briques techniques d'un coup : peinture UV sur low-poly, upscale IA via chaiNNer, le nouveau Texture Caching de Blender, l'instancing de collections et un éclairage volumétrique bien piégeux.
Nouvelle scène de PAO, et cette fois-ci ce n’est pas un seul truc à tester mais carrément une pile de six. Le thème : une auberge médiévale/fantasy, avec ses poutres, ses bougies et son ambiance tavernes-de-jeu-de-rôle. Le prétexte visuel est sympa, mais l’objectif réel était clairement technique.
Voici le menu du jour.
🧱 Low-Poly + peinture UV, retour aux sources
Toute la scène est en low-poly. Pas de sculpt ou de détail géométrique brut : tout repose sur le bon vieux modificateur de Subdivision. Le vrai exercice ici, c’était de retravailler la peinture de texture directement sur ces maillages légers, avec des UV proprement dépliés pour que la subdivision ne vienne pas tout casser au niveau des jointures et des angles. L’idée était simplement de voir si c’était possible, car la subdivision subdivise aussi les UVs, ce qui peut occasionner pas mal de problèmes visuels qu’il faut anticiper.
🖼️ Upscale x2 via chaiNNer
Considérant la quantité d’objets, la définition des textures n’était pas très grande afin de rentrer dans 16 Go de VRAM. Mais pour ce test (et surtout à cause du point suivant), j’ai lâché la bride sur la résolution. Je suis passé par chaiNNer pour un upscale IA x2.
Le résultat est propre sur ce type de textures : contrairement à l’upscale vidéo (galère absolue, voir mon article sur le Charger ‘69), l’IA s’en sort beaucoup mieux sur une texture statique, fixe, sans mouvement à reconstruire. Les détails de peinture restent cohérents, pas de bavure ni d’artefact flagrant.
💾 Le vrai morceau : le Texture Caching de Blender
Voilà le point le plus intéressant de cet article. Avec la densité d’objets de cette scène, la variété d’assets (mobilier, vaisselle, décorations, structure…) et les textures fraîchement upscalées, la VRAM a forcément explosé direct. Ça ne rentrait pas sur 16 Go, pas même sur 24 Go.
C’est là qu’intervient la toute dernière fonctionnalité de Blender : le Texture Caching.
Le principe est simple sur le papier : au lieu de charger la totalité de chaque texture en pleine résolution dans la VRAM (même les zones de l’image qui ne sont jamais visibles à l’écran), Blender convertit désormais les textures en .tx, un format tuilé et mipmapé (à la OpenImageIO). Concrètement :
- Le découpage en tuiles (tiles) : chaque texture est débitée en petits blocs indépendants au lieu d’être une seule grosse image monolithique.
- Les niveaux de LOD (mipmaps) : chaque texture existe en plusieurs résolutions empilées (comme une pyramide), de la pleine définition jusqu’à des versions minuscules.
- Le streaming à la demande : le moteur ne charge en VRAM que les tuiles et le niveau de LOD réellement nécessaires selon la distance caméra, l’angle et la taille à l’écran. Un pot en arrière-plan flou n’a aucune raison de bouffer sa texture en 4K native.
Résultat : la scène qui ne passait pas sur 24 Go tourne désormais avec environ 8 Go de VRAM. C’est une bascule complète de philosophie, dans le même esprit que ce qui se fait dans les jeux vidéo avec le .DDS, mais appliqué et adapté à la PAO. Ça change clairement la donne pour ce genre de scène chargée en assets uniques.
🎛️ Le super-nœud de compositing, version quasi-finale
J’utilise et je fais évoluer depuis un moment mon “super-nœud” de compositing maison sous Blender. Il a encore pas mal grandi depuis la dernière fois que j’en ai parlé, et je le sens sérieusement approcher de sa version finale. Cette scène m’a servi de nouveau terrain de test grandeur nature pour vérifier sa robustesse sur un rendu complexe (volumétrie, multiples sources de lumière, matériaux variés).
Je referai probablement un article dédié à ce nœud une fois qu’il sera scellé.
🪑 Instancing de collections
Avec autant de mobilier et de petits objets répétés (chaises, chopes, tonneaux, bougies…), c’était l’occasion parfaite de pousser l’instancing de collections. Au lieu de dupliquer bêtement la géométrie, chaque groupe d’objets est instancié depuis une collection source unique, ce qui garde la scène légère en mémoire tout en permettant des variations rapides (position, rotation, échelle) sans exploser le nombre de vrais meshes.
🕯️ L’éclairage : le pire scénario possible pour un path-tracer
Dernier test, et pas des moindres : l’éclairage. J’ai volontairement cumulé tout ce qui fait souffrir un moteur en path-tracing :
- Une scène sombre, avec très peu de lumière ambiante.
- Une multitude de petites sources ponctuelles (les bougies), chacune générant son propre bruit à nettoyer.
- De la volumétrie partout pour donner cette ambiance poussiéreuse/enfumée de taverne.
Le combo lumière faible + multi-sources + volumes est probablement l’un des pires cas de figure pour un path-tracer : chaque rayon a statistiquement moins de chances de croiser une source de lumière, ce qui fait exploser le bruit et le temps de convergence. Il a fallu pas mal de samples, beaucoup d’ajustements, et un peu de triche pour arriver à un résultat propre sans perdre l’ambiance tamisée voulue.
📸 Galerie des rendus
Beaucoup de cases cochées d’un coup sur cette scène, mais c’était clairement le but : la faire suffisamment dense et complexe pour mettre tout mon pipeline actuel sous pression en même temps. Le Texture Caching à lui seul justifie l’article, ça ouvre clairement la porte à des scènes bien plus chargées sans avoir à sacrifier la VRAM.
🔄 Mise à jour — 03/07/2026
Petite passe de polish sur la taverne ! J’ai entièrement remplacé les anciens rendus de la galerie par de nouvelles versions bien plus propres. Au menu des réjouissances :
- Agencement & Meshes : Revue globale de la composition pour corriger quelques coquilles. J’en ai profité pour retoucher pas mal de maillages afin d’apporter un peu plus de variations visuelles sur les détails.
- Shaders & Matériaux : Divers ajustements sur les textures et correction de petites erreurs qui traînaient dans mes nœuds de shaders.
- Lighting & Compositing : L’éclairage a été retouché par-ci par-là pour mieux guider l’œil. Côté post-prod, j’ai enfin branché la version finale de mon arbre de compositing.
- Le cas AgX : Passage sur le View Transform AgX. J’ai tenté de dompter et de corriger cette fameuse teinte saumon/rose hyper caractéristique (et franchement pas très heureuse) que cette colorimétrie applique sur les zones de fortes sur-expositions chaudes (les bougies, le feu, etc.).
🧠 Petit point sur le Texture Cache (toujours en bêta)
Dans la version actuelle, Blender m’indique une consommation d’environ 8 à 9 Go de VRAM pour le Texture Cache. Pourtant, dans les faits, toute la VRAM se retrouve utilisée quand même.
Reste à savoir s’il s’agit d’un comportement normal — type mécanisme de pré-allocation globale ou cache agressif — ou d’un empilement graduel des LODs des textures jusqu’à saturation complète de la mémoire. On décryptera tout ça plus au calme lors de la sortie de la version 5.2 !