Résolvez l'erreur « Pyro Collisions Limit Exceeded » dans Cinema 4D
Comprendre les limites de simulation GPU de Pyro
Lorsque notre ferme de rendu traite des scènes Cinema 4D avec des simulations Pyro, nous rencontrons parfois l'erreur « Pyro collisions limit exceeded ». Ce n'est pas un crash aléatoire — c'est un signal direct que votre GPU (ou le GPU du nœud de rendu) a manqué de mémoire vidéo pendant la phase de simulation. Le solveur Pyro dans Cinema 4D est accéléré par GPU par défaut, ce qui signifie qu'il décharge le calcul sur le processeur graphique. Lorsque la grille de simulation dépasse la VRAM disponible, Cinema 4D ne peut pas terminer la résolution, et le travail échoue.
Contrairement au rendu, qui peut se distribuer facilement entre les cœurs du CPU, la simulation Pyro est étroitement couplée à un seul GPU. Une scène qui se rend bien sur votre station de travail peut échouer sur un nœud de ferme si ce nœud a une architecture GPU différente ou moins de VRAM. De même, les graphiques intégrés bas de gamme sur les ordinateurs portables échoueront immédiatement sur les simulations Pyro complexes.
Pourquoi la VRAM du GPU s'épuise
Les simulations Pyro stockent des grilles volumétriques dans la mémoire du GPU. Chaque voxel dans la grille consomme de la mémoire — plus de voxels signifient plus de VRAM. Les principaux facteurs qui vous poussent au-delà de la limite sont :
- Résolution de la grille : Doubler la résolution à chaque axe multiplie l'utilisation de la mémoire par 8. Une grille 100×100×100 utilise bien moins qu'une grille 200×200×200.
- Complexité de simulation : Plusieurs objets de collision, substeps élevés ou longues plages de frames composent toutes les demandes de mémoire.
- Autres charges GPU : Si votre moteur de rendu est également chargé dans la VRAM, le solveur Pyro a moins d'espace.
Sur nos nœuds de ferme avec des GPU de 24 Go de VRAM, nous voyons généralement Pyro échouer sur les simulations avec des résolutions de grille supérieures à 256³ lorsqu'elles sont entièrement détaillées. Sur les graphiques intégrés avec 2 Go de VRAM partagée, même les grilles 64³ peuvent déclencher l'erreur.
Basculer à CPU dans les paramètres de projet Cinema 4D
Le correctif le plus rapide est de désactiver l'accélération GPU pour le solveur Pyro. Ouvrez Cinema 4D et accédez à Édition > Paramètres de projet > Simulation > Scène, puis localisez la liste déroulante Appareil. Par défaut, elle est définie sur « GPU (CUDA) » ou « GPU (HIP) » selon votre matériel.
Changez Appareil en CPU. Cela force Cinema 4D à calculer la simulation Pyro sur vos cœurs de CPU à la place. La simulation CPU est plus lente — comptez sur 2–5× des temps de résolution plus longs en fonction de la complexité de la scène — mais elle ne plantera pas à cause d'une VRAM insuffisante car la RAM du CPU est beaucoup plus grande (généralement 16–64 Go sur les systèmes modernes).
L'inconvénient est clair : la simulation CPU bloque le rendu jusqu'à ce que la résolution soit terminée. Sur notre ferme, nous configurons Team Render pour utiliser la simulation CPU, bien que nous définissions des substeps de priorité inférieure ou des plages de frames plus courtes pour maintenir le délai d'exécution acceptable.
Stratégie d'optimisation : Réduire la résolution
Avant de basculer vers le CPU, réfléchissez à la question de savoir si vous pouvez réduire la résolution de la grille sans perdre la qualité de simulation. Une grille 128³ utilise 1/8 de la VRAM d'une grille 256³. Souvent, la différence visuelle est minimale, surtout à distance ou avec flou de mouvement dans le rendu final.
Dans l'onglet Simulation de votre objet Pyro :
- Notez la Résolution de grille actuelle (souvent définie sur 128 ou 256).
- Réduisez-la d'un cran : 256 → 128, ou 128 → 64.
- Rebake le cache localement pour prévisualiser la modification.
- Si le résultat semble acceptable, vous avez récupéré une marge de VRAM significative.
Pour les soumissions à la ferme, incluez cette résolution optimisée dans votre fichier de scène. Une simulation 64³ sur GPU est plus rapide et plus fiable qu'une simulation 256³ sur CPU, même si elle est légèrement moins détaillée.
Baking du cache de simulation
Une autre approche consiste à pré-bake la simulation Pyro sur votre machine locale (en utilisant le CPU si nécessaire) et à l'enregistrer en tant que cache disque. Une fois cachée, Cinema 4D n'a plus besoin de recalculer la simulation pendant le rendu — il lit simplement les frames à partir du disque.
Pour mettre en cache localement :
- Dans l'objet Pyro, activez Simulation > Utiliser le cache disque.
- Spécifiez un dossier de cache.
- Lisez la timeline dans Cinema 4D (ou utilisez Fichier > Exporter pour rendrer localement) pour déclencher le bake de cache.
- Une fois en cache, redémarrez Cinema 4D pour vider la mémoire GPU.
Lorsque vous soumettez à notre ferme de rendu, les fichiers de cache voyagent avec votre projet. Les nœuds de la ferme ignorent entièrement la phase de simulation et passent directement au rendu. Cela élimine la contrainte VRAM du côté de la ferme, bien qu'il ajoute du temps de pré-production de votre côté.
Fallback CPU pour la soumission à la ferme
Lors de la soumission à notre ferme de rendu cloud, vous avez la possibilité de demander explicitement la simulation basée sur le CPU dans les métadonnées du travail (ou via votre plugin de soumission). Notre ferme assignera le travail à un nœud CPU multi-cœurs au lieu d'un nœud GPU, avec la compréhension que la résolution prendra plus de temps mais ne échouera pas à cause des limites de mémoire du GPU.
Nous maintenons les versions actuelles de Cinema 4D et des pilotes GPU sur tous les nœuds, donc le changement de l'appareil dans vos paramètres de projet sera respecté par le système de soumission de la ferme. Changez simplement en CPU avant de soumettre, et la ferme honorera ce choix.
Pour les très grandes simulations (résolution de grille 512³ ou plus), le CPU est votre seule option. Prévoyez des temps de résolution de 30–60 minutes sur un nœud de ferme 16 cœurs. Si c'est un problème, envisagez de diviser la simulation en plusieurs simulations plus petites par frame, ou de réduire la taille globale de la grille.
Graphiques intégrés et ordinateurs portables
Si vous utilisez un ordinateur portable ou une station de travail avec seulement des graphiques intégrés (Intel UHD, AMD Radeon intégré, etc.), le solveur Pyro échouera ou se figera même sur les grilles modestes. Les graphiques intégrés partagent la RAM du système et ne allouent généralement que 1–2 Go pour les tâches GPU, bien en dessous de ce dont Pyro a besoin.
Solution : Désactivez l'accélération GPU dès le départ. Définissez Appareil sur CPU dans votre projet pour assurer un comportement cohérent entre votre station de travail et la ferme. Ne soumettez pas une scène configurée pour GPU si vous savez que vous travaillez avec des graphiques intégrés — la ferme héritera de ce paramètre et échouera probablement.
Surveillance de la mémoire GPU sur la ferme
Lorsque vous soumettez un travail à notre ferme, vous pouvez demander des journaux détaillés qui montrent l'utilisation de la VRAM du GPU pendant la phase Pyro. Si vous voyez la simulation s'approcher de la limite VRAM du GPU (par exemple, « 92 % de la mémoire GPU utilisée »), c'est un signe d'avertissement pour des résolutions plus élevées ou des plages de frames plus longues.
Ajustez la scène avant la prochaine soumission : réduisez la résolution de la grille, réduisez la complexité de simulation ou basculez vers le CPU. Itérer sur une plage d'échantillon plus petite (par exemple, frames 1–10 au lieu de 1–100) vous aide à déboguer les problèmes de VRAM plus rapidement sans attendre l'échec d'une soumission de frame complète.
Pratiques recommandées pour Pyro sur les fermes de rendu
- Pré-bake localement si possible. La mise en cache disque évite les contraintes de mémoire GPU du côté de la ferme.
- Testez d'abord les modifications de résolution sur votre station de travail. Une simulation basse résolution prend des secondes à prévisualiser ; les défaillances de ferme gaspillent les crédits et le temps.
- Spécifiez explicitement l'appareil dans les paramètres de projet. Ne comptez pas sur les valeurs par défaut ; le GPU sur les graphiques intégrés ou le CPU sur un nœud à VRAM élevée sont tous les deux des gaspillages.
- Documentez votre résolution de grille et vos substeps. Si un collègue reprend le projet, il saura pourquoi la simulation a été construite de cette façon.
- Surveillez les journaux de ferme pour les avertissements VRAM. Les ajustements proactifs battent les travaux échoués re-soumis.
FAQ
Puis-je utiliser la simulation GPU si j'ai 16 Go de VRAM GPU ?
Oui. Les GPU 16 Go (RTX 4070 Ti, RTX 6000 Ada ou plus récents) gèrent les grilles 256³ et les scènes modérément complexes sans atteindre la limite. Les grilles plus grandes (512³+) ou les simulations hautement détaillées peuvent toujours déborder. Surveillez les journaux de votre première soumission.
Pourquoi ma soumission à la ferme est-elle plus lente que ma machine locale ?
La ferme peut utiliser une architecture GPU ou une version de pilote différente, ou le travail peut être mis en attente derrière d'autres. La simulation CPU est également beaucoup plus lente que GPU. Vérifiez les journaux de travail pour confirmer quel appareil a été utilisé et demandez les nœuds GPU uniquement si vous avez besoin de résolutions GPU plus rapides.
Le cache baking sur CPU et l'envoi rendra-t-il le rendu de la ferme plus rapide ?
Oui. Une fois en cache, la ferme ignore la résolution CPU lente et passe directement au rendu. Vous échangez le temps de pré-production (1–2 heures de bake local) contre des délais d'exécution de ferme plus rapides par itération.
Que se passe-t-il si je définis l'appareil sur GPU sur la ferme, mais que le nœud a moins de VRAM que ma station de travail ?
Le travail échouera avec l'erreur Pyro collisions limit exceeded, tout comme sur votre machine. Testez toujours votre scène sur du matériel avec des spécifications similaires ou inférieures à vos nœuds de ferme.
Puis-je augmenter la VRAM en utilisant uniquement le GPU, pas le CPU, pendant la simulation ?
Non. La VRAM GPU est fixée par la carte graphique. Les seuls moyens de rester dans les limites sont de réduire la résolution de la grille, de bake le cache ou d'utiliser le CPU. Il n'y a pas de pooling de mémoire ou de débordement vers la RAM système.
La simulation CPU est-elle jamais plus rapide que GPU, même pour les petites grilles ?
Sur les très petites grilles (32³ ou 64³), les temps de résolution CPU et GPU sont comparables, parfois en faveur du CPU en raison du surcoût inférieur du kernel. Pour les grilles de production (128³+), le GPU est presque toujours plus rapide — s'il rentre dans la VRAM.
