Comment les moteurs de jeu modernes obtiennent-ils un rendu en temps réel par rapport au rendu «lent» de Blender?

Gamedev et Blender sont nouveaux pour moi, et il y a quelque chose que je ne peux pas ébranler:

Dans Blender, un seul rendu (même à l'aide du rendu plus avancé de Cycles) peut prendre jusqu'à 45 secondes sur ma machine. Mais évidemment, dans un jeu, vous pouvez avoir des graphismes époustouflants et le rendu se fait donc de manière continue, plusieurs fois par seconde en temps réel.

Je me demande donc aussi quelle est la différence entre les rendus "lents" de Blender et la manière dont les moteurs de jeu obtiennent un rendu en temps réel (ou presque).

rendering blender

— smeeb
source

Le rendu en temps réel est un sujet très important en lui-même. De nombreux livres y sont écrits (y compris le "rendu en temps réel"). Et les moteurs de jeu tels que Cycles fonctionnent de manière totalement différente de celles des moteurs de rendu 3D - vous ne pouvez pas vraiment les comparer

— UnholySheep

@UnholySheep Bien sûr, vous pouvez les comparer. Sinon, comment quelqu'un pourrait-il expliquer la différence, répondre à la question?

— user985366

@ 10 Réponses Mais cette question ne serait pas d'actualité sur ce site.

— GiantCowFilms

@ 10 Réponses: Bien que le PO mentionne Blender, la question se résume essentiellement à la question de savoir pourquoi les moteurs de jeu en temps réel semblent rendre les scènes 3D plus rapidement que les moteurs de rendu 3D approximativement photoréalistes (tels que Blender, mais aussi de nombreux autres). Notez que c’est aussi la question à laquelle répond la réponse acceptée. Dans cet esprit, je suis d’accord sur le fait que la question porte plus sur le développement de jeux , où les questions relatives à la technologie de développement de jeux en général peuvent être posées, plutôt que sur Blender , où les questions sont plus spécifiques à Blender en particulier.

— OU Mapper

Je suppose que le secret ici est que incroyable ne doit pas être précis. Il existe des approximations rapides pour les mathématiques utilisées dans le rendu 3D, comme InvSqrt

— Dmitry Grigoryev

Réponses:

115

Le rendu en temps réel, même le rendu en temps réel moderne, est une panoplie d’astuces, de raccourcis, de hacks et d’approximations.

Prenez des ombres par exemple.

Nous n'avons toujours pas de mécanisme complètement précis et robuste pour le rendu des ombres en temps réel à partir d'un nombre arbitraire de lumières et d'objets arbitrairement complexes. Nous avons plusieurs variantes de techniques de mappage des ombres, mais elles souffrent toutes des problèmes bien connus liés aux cartes d’ombres et même les "correctifs" de ces techniques ne sont en réalité qu’une collection de solutions de rechange et de compromis (en règle générale si vous voyez les termes "biais de profondeur" ou "décalage de polygone" dans n'importe quoi alors ce n'est pas une technique robuste).

Le précalcul est un autre exemple de technique utilisée par les moteurs de rendu en temps réel. Si quelque chose (par exemple, l'éclairage) est trop lent à calculer en temps réel (et cela dépend du système d'éclairage que vous utilisez), nous pouvons le pré-calculer et le stocker, puis utiliser les données pré-calculées en temps réel. temps pour une amélioration des performances, souvent au détriment des effets dynamiques. C’est un compromis direct entre mémoire et calcul: la mémoire est souvent bon marché et abondante, alors que ce n’est pas souvent le cas de calcul, nous brûlons donc de la mémoire supplémentaire en échange d’une économie de calcul.

Les outils de rendu et de modélisation hors ligne, en revanche, ont tendance à être davantage axés sur l'exactitude et la qualité. De plus, comme ils travaillent avec une géométrie changeante de manière dynamique (telle qu'un modèle au moment de sa construction), ils doivent souvent recalculer les choses, alors qu'un moteur de rendu en temps réel travaillerait avec une version finale ne comportant pas cette exigence.

— Maximus Minimus
source

Un autre point à mentionner est que la quantité de calcul utilisée pour générer toutes les données qu’un jeu aura besoin de rendre rapidement aux vues d’une zone peut être d’un ordre de grandeur supérieur à la quantité de calcul nécessaire pour rendre une vue. Si le rendu des vues d’une zone prend une seconde sans calcul préalable, mais que certaines données précalculées peuvent réduire ce temps à 1/100 seconde, il peut être utile de passer 20 minutes sur les précalculs si les vues sont nécessaires on veut juste un film de 24 secondes en dix secondes, il aurait été beaucoup plus rapide de passer quatre minutes ...

— Supercat

... générer les 240 vues requises à raison d'une par seconde.

— Supercat

@supercat et, à cause de cela, vos rendus sont quasiment exempts de hâte et vous obtenez un contrôle important sur le processus. Vous pouvez utiliser un moteur de jeu pour rendre ... si vous êtes prêt à sacrifier des fonctionnalités. Mais comme vous l'avez dit, cela n'en vaut pas la peine.

— Joojaa

Un exemple frappant de ce phénomène, dont je me souvienne, est le moteur Quake original (~ 1996), qui permettait d'obtenir des graphismes 3D en temps réel assez hallucinants sur des machines très limitées en combinant des techniques de calcul préalable extrêmement fastidieuses. Les arbres BSP et les effets de lumière pré-rendus ont été générés à l’avance; La conception d'un niveau pour ce moteur impliquait généralement des heures (généralement la nuit) à attendre que les outils de compilation de cartes se terminent. Le compromis consistait essentiellement à réduire les temps de rendu aux dépens du temps de création.

— Jason C

(Le moteur original de Doom [1993] avait des calculs préalables similaires. Marathon peut en avoir aussi, mais je ne me souviens pas, je me souviens d'avoir construit des niveaux de Marathon, mais je ne me souviens pas de ce qui était en jeu.)

— Jason C Le

109

La réponse actuelle a très bien expliqué les problèmes généraux en jeu, mais j’ai le sentiment qu’il manque un détail technique important: le moteur de rendu "Cycles" de Blender est un type de moteur différent de celui utilisé par la plupart des jeux.

Généralement, les jeux sont rendus en parcourant tous les polygones d’une scène et en les dessinant individuellement. Cela se fait en "projetant" les coordonnées du polygone à travers une caméra virtuelle afin de produire une image plate. La raison pour laquelle cette technique est utilisée pour les jeux est que le matériel moderne est conçu autour de cette technique et que cela peut être fait en temps réel avec des niveaux de détail relativement élevés. Ce qui est intéressant, c’est aussi la technique employée par le moteur de rendu précédent de Blender avant que la Blender Foundation ne lâche l’ancien moteur en faveur du moteur Cycles.

Les cycles, d’autre part, constituent ce que l’on appelle un moteur de lancer de rayons. Au lieu de regarder les polygones et de les restituer individuellement, il projette des rayons de lumière virtuels dans la scène (un pour chaque pixel de l'image finale), réfléchit ce faisceau lumineux sur plusieurs surfaces, puis utilise ces données pour déterminer la couleur du pixel. devrait être. Le lancer de rayons est une technique très coûteuse en calcul qui le rend peu pratique pour le rendu en temps réel, mais il est utilisé pour le rendu des images et des vidéos car il offre des niveaux de détail et de réalisme supplémentaires.

Veuillez noter que mes brèves descriptions de tracé de rayons et de rendu de polygone sont très détaillées pour des raisons de brièveté. Si vous souhaitez en savoir plus sur les techniques, je vous recommande de rechercher un tutoriel ou un livre en profondeur, car je suppose qu'il y a beaucoup de gens qui ont écrit de meilleures explications que je ne pourrais en citer.

Notez également que le rendu 3D fait l’objet de nombreuses techniques et que certains jeux utilisent des variantes du lancer de rayons à certaines fins.

— Pharap
source

+1 pour un très bon point; Je ne suis pas allé délibérément dans le trou du lapin du lancer de rayons par rapport au rastérisation, c'est donc un plaisir d'avoir cela comme complément.

— Maximus Minimus

Cette réponse va plus au cœur de la différence. Les moteurs de jeu effectuent le rastérisation (en avant ou en différé) tandis que les rendus en mode hors connexion (comme Blender, Renderman, etc.) effectuent le lancer de rayons. Deux approches complètement différentes pour dessiner une image.

— ssell le

@ LeComteduMerde-fou Comme gamedev est destiné aux développeurs de jeux, j’ai pensé qu’une explication technique supplémentaire serait avantageuse pour le lecteur plus enclin au technique.

— Pharap

@ssell C'est vrai, mais il ne s'agit pas uniquement de lancer de rayon - même sans rendu de rayon, même avec le rendu GPU, le rendu de Blender est généralement beaucoup plus détaillé et plus lent. Cela concerne principalement la correction: filtrage et résolution des textures améliorés, anti-aliasing, éclairage, mappage des ombres, précision Z, quads, surfaces bidirectionnelles, grand nombre de polygones, sortie haute résolution, mappage précis des reliefs , absence de cartes précalculées, morphing, cinématique précise ... C’est une longue liste de fonctionnalités que les moteurs de jeu n’ont pas ou qui ne font pas semblant.

— Luaan

@ Chii je me suis mal souvenu. Je pensais à ART VPS , c’était juste une accélération, pas en temps réel.

— Jason C