Różnica między renderowaniem w oprogramowaniu do animacji OpenGL i 3D

16

Dzięki OpenGL i tym podobnym mogę renderować niesamowite rzeczy w czasie rzeczywistym w 60 FPS. Jeśli jednak spróbuję nagrać wideo z tej samej sceny, powiedzmy Maya, lub 3ds Max, renderowanie byłoby dużo DUŻO dłuższe, mimo że ma tę samą rozdzielczość i liczbę klatek na sekundę.

Dlaczego te dwa typy renderowania wymagają różnych okresów czasu dla tego samego rezultatu?

Uwaga: Tak, zdaję sobie sprawę, że oprogramowanie do animacji 3D może wytwarzać obrazy o lepszej jakości niż w czasie rzeczywistym. Ale w przypadku tego pytania mam na myśli scenę o jednakowej złożoności.

J.Doe
źródło
1
Krótka odpowiedź jest taka, że ​​OpenGL ma skróty.
user253751,

Odpowiedzi:

9

Główną różnicą byłoby to, że z OpenGL powiedzmy, że w grze wideo masz proces zwany rasteryzacją, który w zasadzie zajmuje się określeniem, którą część sceny widzisz.

Musi być szybki, abyśmy mogli doświadczyć go w czasie rzeczywistym.

Dlatego algorytm wykonuje kilka prostych kroków.

  • sprawdź, czy jakaś część sceny jest moim zdaniem

    Custing Frustum

  • sprawdź, czy coś jest przed nim, co może wymagać późniejszego renderowania za pomocą bufora głębokości

    Bufor głębokości

  • uporządkuj znalezione obiekty

  • narysuj je , wyświetlając je na ekranie
  • cieniuj je w oparciu o tekstury / shadery / światła / ...

Z drugiej strony oprogramowanie do renderowania (Blender / Max / Maya / ...) najprawdopodobniej używa pewnego rodzaju raytracingu

Wymaga to dużo więcej matematyki, aby osiągnąć wyższy stopień realizmu. Zasadniczo działa w ten sam sposób:

  • stwórz przed nim kamerę i płaszczyznę obrazu
  • strzelaj jednym promieniem (lub wieloma próbkami) przez każdy piksel
  • sprawdź, czy promień uderza coś w scenie
  • najbliższe trafienie to takie, które zostanie ostatecznie narysowane w pikselu (np. bufor głębokości)
  • obliczyć światło dla danego punktu Obliczanie światła

Przestałem tutaj wymieniać, ponieważ od tego momentu startuje raytracing.

Zamiast sprawdzać tylko, czy punkt został trafiony, większość raytracer zaczyna teraz obliczać:

  • ilość światła przenikającego przez powierzchnię
  • ile światła odbija
  • rzucaj nowe promienie z punktu życia na scenę, aż może trafić w źródło światła

Istnieje mnóstwo technik o różnym stopniu realizmu, które można wykorzystać do obliczenia światła określonego punktu na scenie.

TL; DR Istotą jest to, że raytracer próbuje przede wszystkim być fizycznie dokładny, jeśli chodzi o oświetlenie, i dlatego ma dużo więcej obliczeń na piksel (czasami strzelać tysiące promieni), a z drugiej strony gry uzyskują prędkość rysowanie większych fragmentów ekranu za pomocą prostszych obliczeń światła i wielu sztuczek cieniujących, które pozwalają mu wyglądać realistycznie.

xoryouyou
źródło
7

Porównujesz jabłka do pomarańczy

Gra przypomina port widokowy w aplikacji do modelowania. Możesz użyć rzutni do renderowania i uzyskasz te same prędkości 60 klatek na sekundę.

Nie ma powodu, dla którego nie można uzyskać grafiki w czasie rzeczywistym, która byłaby bardzo dobra z oprogramowania do modelowania, takiego jak Maya lub 3DS Max. Wyniki, które są na równi z wieloma grami. Mają shadery rzutni, tak jak gry. Istnieje również opcja renderowania rzutni, która dzieli klatki na dysk tak szybko, jak to pozwala (zrobiłem rendery Full HD przy 30 fps od Maya). Wszystko, co musisz zrobić, to przestać korzystać z dostarczonego oprogramowania raytracers.

Istnieją jednak pewne różnice. Główną różnicą jest to, że jako użytkownik nie optymalizujesz rzeczy tak bardzo, jak robią to twórcy gier (optymalizacja wykorzystuje wszystkie sztuczki opisane w książce). Po drugie, prymitywy animacji działają na procesorze, ponieważ potrzebujesz elastyczności. W grach można sobie pozwolić na optymalizacje. W sumie płacisz za to, że nie masz obok siebie zespołu programistów.

Wiele rzeczy mogło być wcześniej obliczonych, więc nie są one o wiele szybsze, tylko lepiej zorganizowane. Pieczenie twojego pośredniego oświetlenia będzie bić codziennie nieprzygotowane rezultaty.

Dlaczego raytracery działają wolniej?

Nie są *, jeden po prostu wykonuje więcej pracy na ray tracerze, ponieważ jest to łatwe. Cecha po funkcji nie są znacznie wolniejsze w cyklach obliczeniowych. Na przykład nie ma potrzeby, aby promień promieniowy rzucał promienie wtórne (odbicia życia w tym przypadku promień promieniowy wytrąci geometrię, a nawet jej nie załaduje, w rzeczywistości promień mentalny właśnie to robi). Zwykle robi się to, ponieważ jest to trywialne i jest to wyraźna zaleta ray tracerów. Możesz nawet skonfigurować je tak, aby działały na procesorze w niektórych przypadkach. Są po prostu zoptymalizowane pod kątem różnych rzeczy:

  1. Emisja danych na dysk, nie tylko ramki, ale wszystkie dane. Coś, co natychmiast przerwałoby większość gier.

  2. Praca na ogólnym sprzęcie. Procesor graficzny jest znacznie szybszy w przypadku niektórych rzeczy po zoptymalizowaniu go pod kątem GPU. Ale to nie działa dla wszystkich obciążeń, w rzeczywistości procesor Intel jest szybszy w obliczeniach ogólnie niż GPU. Procesor graficzny jest po prostu masywnie równoległy, co nie jest procesorem. Architektura wygrywa, jeśli możesz pozostać w GPU i zminimalizować transfer i zoptymalizować pod kątem architektury GPU.

Płacisz więc za elastyczność i łatwość użytkowania. Ale tak źle przyznam, że zarówno Maya, jak i Max cierpią z powodu skrajnej starości. Aby mogli być szybsi.

TL; DR Różnica polega głównie na optymalizacji (przeczytanie wielu sztuczek) i dostępnych zasobach zewnętrznych.

PS: Istnieje błędne przekonanie, że dzieje się tak, ponieważ jest to bardziej poprawne fizycznie. Z pewnością może być, ale ray tracer nie jest z natury bardziej poprawny fizycznie niż przeciętna gra lub inne obliczenia. W rzeczywistości wiele gier używa naprawdę dobrych modeli, podczas gdy całkiem wielu modelarzy tego nie robi.

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

joojaa
źródło
2
Przepraszam, ale to po prostu źle. OpenGL i DirectX używają aproksymacji, które są z natury szybsze niż precyzyjne śledzenie promieni. Cały sens akcelerowanej grafiki 3D polega na algorytmach, które równoważą realizm i szybkość, wystarczająco dobrze
prezentując się
2
@IMil OpenGL może być używany do raytracingu. Jest szybszy, ponieważ jest zoptymalizowany dla danego sprzętu. Ale Maya NIE musi promieniować śladem. Maya i Max mogą korzystać z openGL i directX tak samo jak twoja gra. Rzutnia Mayas (i 3ds) jest opengl lub directX (twój wybór). Fakt, że procesor działa wolniej w przypadku niektórych równoległych obciążeń przetwarzania, to inna sprawa. Tak więc odpowiedź stoi. Standardowe ustawienia mayi nie są bardziej realistyczne niż standardowa linia skanowania.
joojaa,
5

Podgląd w czasie rzeczywistym

Pracując po stronie VFX w branży, jeśli mówisz o podglądach rzutni w czasie rzeczywistym, a nie renderowaniu produkcyjnym, to Maya i 3DS Max zazwyczaj również używają OpenGL (lub ewentualnie DirectX - prawie tak samo).

Jedną z głównych różnic koncepcyjnych między oprogramowaniem animacji VFX a grami jest poziom założeń, jakie mogą poczynić. Na przykład w oprogramowaniu VFX często zdarza się, że artysta ładuje pojedynczą, bezszwową siatkę znaków obejmującą setki tysięcy do milionów wielokątów. Gry najczęściej optymalizują się w przypadku dużej sceny składającej się z mnóstwa prostych, zoptymalizowanych siatek (każda z tysięcy trójkątów).

Renderowanie produkcji i śledzenie ścieżek

Oprogramowanie VFX kładzie również nacisk nie na podgląd w czasie rzeczywistym, ale na renderowanie produkcyjne, w którym promienie świetlne są symulowane pojedynczo. Podgląd w czasie rzeczywistym często jest po prostu „podglądem” wyników produkcji o wyższej jakości.

Gry wykonują ostatnio piękną robotę, zbliżając wiele z tych efektów, takich jak głębia ostrości w czasie rzeczywistym, miękkie cienie, rozproszone odbicia itp., Ale należą one do kategorii aproksymacji o dużej wytrzymałości (np. Rozmyte mapy kostek do rozproszenia odbicia zamiast faktycznie symulujących promienie świetlne).

Zawartość

Wracając do tego tematu, założenia treści między oprogramowaniem VFX a grą są bardzo różne. Oprogramowanie VFX koncentruje się przede wszystkim na tworzeniu wszelkiego rodzaju treści (przynajmniej jest to ideał, chociaż w praktyce często nie ma go blisko). Gry koncentrują się na treściach z dużo cięższymi założeniami (wszystkie modele powinny być w zakresie tysięcy trójkątów, normalne mapy powinny być stosowane do fałszywych szczegółów, nie powinniśmy mieć 13 miliardów cząstek, postacie nie są animowane przez mięśnie platformy i mapy napięć itp.).

Ze względu na te założenia silniki gier często łatwiej stosują techniki przyspieszania, takie jak ubijanie fragmentów, które umożliwiają utrzymanie wysokiej, interaktywnej liczby klatek na sekundę. Mogą zakładać, że niektóre treści będą statyczne, z góry upieczone. Oprogramowanie VFX nie może łatwo przyjąć takich założeń, biorąc pod uwagę znacznie większy stopień elastyczności w tworzeniu treści.

Gry Zrób to lepiej

To może być trochę kontrowersyjny pogląd, ale przemysł gier jest znacznie bardziej dochodowym przemysłem niż oprogramowanie VFX. Ich budżety na jedną grę mogą sięgać setek milionów dolarów i mogą sobie pozwolić na wydawanie silników nowej generacji co kilka lat. Ich wysiłki badawczo-rozwojowe są niesamowite, a setki tytułów gier są wydawane przez cały czas.

Z drugiej strony oprogramowanie VFX i CAD nie jest tak lukratywne. Badacze pracujący w środowisku akademickim często zlecają prace badawczo-rozwojowe, a wiele firm często wdraża techniki opublikowane wiele lat wcześniej, jakby to było coś nowego. Oprogramowanie VFX, nawet pochodzące od firm tak dużych jak AutoDesk, często nie jest tak „najnowocześniejsze” jak najnowsze silniki do gier AAA.

Mają też znacznie dłuższą spuściznę. Na przykład Maya to 17-letni produkt. Został bardzo odnowiony, ale jego podstawowa architektura jest nadal taka sama. Może to być analogiczne do próby pobrania Quake 2 i aktualizowania go aż do 2015 roku. Wysiłki mogą być świetne, ale prawdopodobnie nie będą pasować do Unreal Engine 4.

TL; DR

Tak czy inaczej, to trochę z tej strony tematu. Nie mogłem się zorientować, czy mówisz o podglądach w czasie rzeczywistym w rzutniach, czy renderowaniu produkcyjnym, więc starałem się opisać trochę obu.

Dragon Energy
źródło
To także kwestia czasu. Nawet jeśli potrafisz renderować przy powiedzmy 60 klatkach na sekundę i uzyskiwać akceptowalne wyniki, rzadko można je zoptymalizować. Powiedzmy, że zajmuje to 3 minuty na klatkę, a ty masz 200 klatek do renderowania. Możesz uzyskać 60 klatek na sekundę, wynajmując program do cieniowania i optymalizując, ale zajmuje to co najmniej jeden dzień lub dwa. Ale 200 klatek w 3 minuty zajmuje tylko 10 godzin, więc oszczędzasz ten koszt. W praktyce taniej jest kupić więcej sprzętu i nie martwić się o to zbytnio. Gry po prostu nie mogą przyjąć tego podejścia.
joojaa,
@joojaa Jest to jednak trochę bardziej złożone. Samo wykonanie naprawdę dobrych shaderów czasu rzeczywistego dla Mayi może zająć co najmniej rok, a nawet nawet od doświadczonego programisty shaderów (z mniejszymi zyskami), ponieważ elastyczność systemu węzłowego jest ukierunkowana na renderowanie produkcji. Aby przełożyć te węzły cieniujące ogólnego przeznaczenia na system cieniowania w czasie rzeczywistym, który przechwytuje zakres efektów działania UE 4, potrzeba odwrotnej inżynierii i nowego rodzaju techniki generowania kodu GLSL / HLSL (jak system metaprogramowania). , np.
Dragon Energy
Silnik modułu cieniującego @joojaa UE 4 jest bezpośrednio ukierunkowany na mocno przybliżony sposób myślenia PBR (bardzo niewielki podzbiór modułu cieniującego PBR Disneya). Zaprojektowali nawet swój system materiałowy do szybkiego celu w czasie rzeczywistym, zamiast zaczynać od czegoś takiego jak system materiałowy Mayi, który wcale nie jest (przeznaczony do raytracingu). Nawet jeśli najjaśniejsze z UE 4 działało na VP 2.0, musieliby pracować dzień i noc przez możliwie lata, aby osiągnąć te same wyniki w stosunku do projektu nieprzeznaczonego do tego rodzaju rzeczy.
Dragon Energy
ale to jednorazowy koszt, nawet jeśli masz ten potok w aplikacji VFX, każda scena może wymagać dodatkowej optymalizacji. Nie ma powodu, dla którego użytkownik Maya nie mógłby renderować w UDK, na przykład dla tej samej platformy deweloperskiej modułu cieniującego.
joojaa,