Différence entre le rendu dans OpenGL et le logiciel d'animation 3D

16

Avec OpenGL et autres, je peux rendre des choses assez étonnantes en 60 FPS "en temps réel". Cependant, si j'essaie de faire une vidéo de cette même scène dans disons Maya, ou 3ds Max, cela prendrait BEAUCOUP BEAUCOUP plus de temps pour qu'elle soit rendue même si c'est la même résolution et le même FPS.

Pourquoi ces deux types de rendu prennent-ils des périodes de temps différentes pour le même résultat?

Remarque: Oui, je me rends compte que le logiciel d'animation 3D peut produire des images très supérieures à ce qui pourrait être fait en temps réel. Mais pour cette question, je me réfère à une scène d'égale complexité.

J.Doe
la source
1
La réponse courte est qu'OpenGL prend des raccourcis.
user253751

Réponses:

9

La principale différence serait qu'avec OpenGL dans disons un jeu vidéo, vous aurez un processus appelé rastérisation qui se charge essentiellement de déterminer quelle partie de la scène que vous voyez.

Il doit être rapide pour que nous puissions le vivre en temps réel.

Par conséquent, l'algorithme effectue quelques étapes simples.

  • vérifier si une certaine partie de la scène est à mon avis tronc

    Frustum Culling

  • vérifier si quelque chose est en face de lui qui doit être rendu plus tard en utilisant un tampon de profondeur

    Tampon de profondeur

  • commander les objets que nous avons trouvé à dessiner

  • les dessiner en les projetant sur l'écran
  • les ombrer en fonction des textures / shaders / lumières / ...

D'un autre côté, un logiciel de rendu (Blender / Max / Maya / ...) utilise très probablement une sorte de raytracing

Cela implique beaucoup plus de mathématiques pour atteindre un degré de réalisme plus élevé. Cela fonctionne essentiellement de la même manière:

  • créer une caméra et un plan d'image en face
  • tirer un rayon (ou plusieurs rayons d'échantillon) à travers chaque pixel
  • vérifier si le rayon frappe quelque chose dans la scène
  • la frappe la plus proche est celle qui doit être dessinée dans le pixel (comme le tampon de profondeur)
  • calculer la lumière pour le point donné Calcul de la lumière

....

Je vais arrêter de lister ici car c'est le point où le raytracing décolle.

Au lieu de seulement vérifier si un point est atteint, la plupart des raytracer commencent maintenant à calculer:

  • la quantité de lumière qu'une surface pénètre
  • la quantité de lumière réfléchie
  • projetez de nouveaux rayons depuis le point de frappe dans la scène jusqu'à ce qu'il puisse toucher une source de lumière

Il existe une tonne de techniques avec différents degrés de réalisme qui peuvent être utilisées pour calculer la lumière d'un certain point de la scène.

TL; DR L'essentiel serait qu'un raytracer essaie principalement d'être physiquement précis en ce qui concerne l'éclairage et a donc beaucoup plus de calculs à faire par pixel (parfois des milliers de rayons) et, d'autre part, les jeux obtiennent leur vitesse par dessiner de plus gros morceaux de l'écran avec des calculs de lumière plus simples et de nombreuses astuces de shader qui lui donnent un aspect réaliste.

xoryouyou
la source
7

Vous comparez des pommes à des oranges

Le jeu est comme le port d'affichage de votre application de modélisation. Vous pouvez utiliser la fenêtre d'affichage pour le rendu et vous obtiendrez les mêmes vitesses de 60 images par seconde.

Il n'y a aucune raison pour laquelle vous ne pouvez pas obtenir de graphiques en temps réel qui sont très bons avec des logiciels de modélisation comme Maya ou 3DS Max. Des résultats comparables à de nombreux jeux. Ils ont des shaders de fenêtre comme les jeux. Il existe également une option de rendu de la fenêtre d'affichage qui segmente les images sur le disque aussi rapidement qu'il le permet (j'ai effectué des rendus Full HD à 30 ips de Maya). Tout ce que vous avez à faire est de cesser d'utiliser les raytracers logiciels fournis.

Il existe cependant quelques différences. La principale différence est que vous, en tant qu'utilisateur, n'optimisez pas les choses autant que les développeurs de jeux (l'optimisation utilise toutes les astuces du livre). Deuxièmement, vos primitives d'animation fonctionnent sur le processeur car vous avez besoin de flexibilité. Dans les jeux, on peut se permettre de faire des optimisations. Dans l'ensemble, vous payez pour ne pas avoir une équipe de programmation à côté de vous.

Beaucoup de choses peuvent en fait avoir été précalculées, donc elles ne sont pas tellement plus rapides mais mieux organisées. La cuisson de votre éclairage indirect battra tous les jours des résultats non cuits.

Pourquoi les raytracers sont-ils plus lents?

Ils ne le sont pas *, on a juste tendance à faire plus de travail sur un traceur de rayons parce que c'est facile. Fonction par fonctionnalité, ils ne sont pas beaucoup plus lents dans les cycles de calcul. Par exemple, il n'y a pas besoin d'un traceur de rayons pour projeter des rayons secondaires (les réflexions de la vie dans ce cas, le traceur de rayons éliminera la géométrie, ou ne la chargera même pas, en fait mental ray fait exactement cela). C'est juste généralement fait parce que c'est trivial de le faire et c'est l'avantage clair des traceurs de rayons. Vous pouvez même les configurer pour qu'ils s'exécutent sur le CPU dans certains cas. Ils sont juste optimisés pour différentes choses:

  1. Émettre des données sur le disque, pas seulement des images, mais toutes les données. Quelque chose qui briserait instantanément la vitesse de la plupart des jeux.

  2. Travailler sur du matériel général. Le GPU est beaucoup plus rapide pour certaines choses une fois que vous l'avez optimisé pour le GPU. Mais cela ne fonctionne pas pour toutes les charges, en fait un processeur Intel est plus rapide en informatique que le GPU. Le GPU est simplement massivement parallèle, contrairement au CPU. L'architecture gagne si vous pouvez rester dans le GPU et minimiser le transfert et optimiser pour l'architecture GPU.

Vous payez donc pour la flexibilité et la facilité d'utilisation. Mais oui, admettons mal que Maya et Max souffrent d'une vieillesse extrême. Ils pourraient donc être plus rapides.

TL; DR La différence réside principalement dans l'optimisation (lire beaucoup d'astuces) et les ressources externes disponibles.

PS: Il y a une idée fausse selon laquelle c'est plus physiquement correct. Cela peut certainement l'être, mais le ray tracer n'est pas intrinsèquement plus physiquement correct que votre jeu moyen ou tout autre calcul. En fait, de nombreux jeux utilisent de très bons modèles, contrairement à de nombreux modélisateurs.

* Voir http://www.graphics.cornell.edu/~bjw/mca.pdf

joojaa
la source
2
Désolé, mais c'est tout à fait faux. OpenGL et DirectX utilisent des approximations qui sont intrinsèquement plus rapides qu'un lancer de rayons précis. L'intérêt des graphiques 3D accélérés est d'avoir des algorithmes qui équilibrent le réalisme et la vitesse, qui
semblent
2
@IMil OpenGL peut être utilisé pour le lancer de rayons. C'est plus rapide car il est optimisé pour le matériel en question. Mais Maya n'a PAS à lancer de rayons. Maya et Max peuvent utiliser openGL et directX autant que votre jeu. La fenêtre de visualisation Mayas (et 3ds) est opengl ou directX (votre choix). Le fait que votre processeur soit plus lent dans certaines charges de traitement parallèles est une autre chose. La réponse est donc valable. Les paramètres standard de maya ne sont pas plus réalistes qu'une ligne de balayage standard.
joojaa
5

Aperçu en temps réel

Travaillant du côté VFX de l'industrie, si vous parlez de prévisualisations de fenêtres en temps réel et non de rendu de production, Maya et 3DS Max utilisent généralement également OpenGL (ou peut-être DirectX - à peu près la même chose).

L'une des principales différences conceptuelles entre les logiciels d'animation VFX et les jeux est le niveau d'hypothèses qu'ils peuvent faire. Par exemple, dans le logiciel VFX, il n'est pas rare que l'artiste charge un maillage de caractères unique et transparent qui s'étend sur des centaines de milliers à des millions de polygones. Les jeux ont tendance à être optimisés pour une grande scène composée d'une cargaison de maillages simples et optimisés (des milliers de triangles chacun).

Rendu de production et traçage de chemin

Le logiciel VFX met également l'accent non pas sur l'aperçu en temps réel mais sur le rendu de production où les rayons lumineux sont réellement simulés un à la fois. L'aperçu en temps réel n'est souvent que cela, un "aperçu" du résultat de production de meilleure qualité.

Les jeux font un beau travail d'approximation de beaucoup de ces effets récemment comme la profondeur de champ en temps réel, les ombres douces, les réflexions diffuses, etc., mais ils sont dans la catégorie d'approximation robuste (ex: cartes de cube floues pour diffus réflexions au lieu de simuler réellement des rayons lumineux).

Contenu

Pour en revenir à ce sujet, les hypothèses de contenu entre un logiciel VFX et un jeu diffèrent énormément. L'objectif principal d'un logiciel VFX est de permettre la création de tout type de contenu possible (du moins c'est l'idéal, bien que dans la pratique, il soit souvent loin d'être proche). Les jeux se concentrent sur le contenu avec des hypothèses beaucoup plus lourdes (tous les modèles doivent être dans la gamme de milliers de triangles, les cartes normales doivent être appliquées aux faux détails, nous ne devrions pas avoir en fait 13 milliards de particules, les personnages ne sont pas réellement animés par des muscles gréements et cartes de tension, etc.).

En raison de ces hypothèses, les moteurs de jeux peuvent souvent appliquer plus facilement des techniques d'accélération comme l'abattage de troncs qui leur permettent de maintenir une fréquence d'images interactive élevée. Ils peuvent émettre l'hypothèse que certains contenus vont être statiques, préparés à l'avance. Le logiciel VFX ne peut pas facilement faire ce genre d'hypothèses étant donné le degré beaucoup plus élevé de flexibilité dans la création de contenu.

Les jeux font mieux

Cela pourrait être une sorte de point de vue controversé, mais l'industrie du jeu est une industrie beaucoup plus lucrative que les logiciels VFX. Leurs budgets pour un seul jeu peuvent atteindre des centaines de millions de dollars et ils peuvent se permettre de continuer à publier des moteurs de prochaine génération toutes les quelques années. Leurs efforts de R&D sont incroyables, et il y a des centaines et des centaines de titres de jeux qui sortent tout le temps.

Les logiciels VFX et CAD, en revanche, sont loin d'être aussi lucratifs. La R&D est souvent externalisée par des chercheurs travaillant dans des milieux académiques, avec une grande partie de l'industrie mettant souvent en œuvre des techniques publiées plusieurs années auparavant comme si c'était quelque chose de nouveau. Ainsi, les logiciels VFX, même provenant de sociétés aussi grandes que AutoDesk, ne sont souvent pas aussi "à la pointe de la technologie" que les derniers moteurs de jeu AAA.

Ils ont également tendance à avoir un héritage beaucoup plus long. Maya est un produit vieux de 17 ans, par exemple. Il a été beaucoup rénové, mais son architecture de base est toujours la même. Cela pourrait être analogue à essayer de prendre Quake 2 et de continuer à le mettre à jour et à le mettre à jour jusqu'en 2015. Les efforts peuvent être importants mais ne correspondront probablement pas à Unreal Engine 4.

TL; DR

Donc, de toute façon, c'est un petit aperçu de ce côté du sujet. Je ne pouvais pas savoir si vous parliez d'aperçus en temps réel dans les fenêtres ou de rendu de production, j'ai donc essayé de couvrir un peu les deux.

Dragon Energy
la source
C'est aussi une question de temps. Même si vous pouviez effectuer un rendu d'environ 60 images par seconde et obtenir des résultats acceptables, il se déploie rarement pour l'optimiser. Disons que cela prend 3 minutes par image et que vous avez 200 images à rendre. Vous pourriez être en mesure d'obtenir les 60 images par seconde en embauchant un rédacteur de shader et en optimisant, mais cela prend au moins un jour ou deux de votre temps. Mais 200 images à 3 minutes ne prennent que 10 heures, vous économisez donc ce coût. En pratique, c'est moins cher d'acheter plus de matériel et de ne pas trop s'en inquiéter. Les jeux ne peuvent tout simplement pas adopter cette approche.
joojaa
@joojaa Mais c'est aussi un peu plus complexe. Le fait de faire de très bons shaders en temps réel pour Maya peut prendre au moins un an, même d'un développeur de shaders expérimenté (avec des gains moindres), car la flexibilité du système nodal est ciblée sur le rendu de production. Il faudrait une mentalité d'ingénierie inverse et une sorte de nouveau type de technique de génération de code GLSL / HLSL (comme un système de méta-programmation) pour traduire ces nœuds de shader à usage général en un système d'ombrage en temps réel qui capture la gamme d'effets de UE 4 , par exemple
Dragon Energy
Le moteur de shader de @joojaa UE 4 est directement ciblé vers un état d'esprit PBR fortement approché (un très petit sous-ensemble du shader PBR de Disney). Ils ont même conçu leur système matériel dans un but rapide et en temps réel, au lieu de commencer avec quelque chose comme le système matériel de Maya qui n'est pas du tout (conçu pour le raytracing). Même si les plus brillants de l'UE 4 travaillaient sur VP 2.0, ils devraient travailler nuit et jour pendant des années, peut-être, pour obtenir les mêmes résultats par rapport à une conception non destinée à faire ce genre de choses.
Dragon Energy
mais c'est un coût unique, même si vous avez ce pipeline dans une application VFX, chaque scène pourrait avoir besoin de cette optimisation supplémentaire. Il n'y a aucune raison pour qu'un utilisateur maya ne puisse pas rendre dans UDK par exemple pour la même plate-forme de développement de shader.
joojaa
1
Continuons cette discussion dans le chat .
joojaa