Grafika, jej wydajność i optymalizacja 18881 12

O temacie

Autor Adanos

Zaczęty 23.01.2011 roku

Wyświetleń 18881

Odpowiedzi 12

Adanos

Adanos

Administrator
Szara eminencja
posty5204
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja
Grafika, jej wydajność i optymalizacja
[/b]

Na naszym forum dość często można usłyszeć, że jakiś model trójwymiarowy posiada zbyt dużą liczbę trójkątów, zmarnowano wiele trójkątów etc. Ale jak naprawdę z tym jest? Czy tylko liczba wierzchołków ma znaczenie i jak bardzo wpływa na płynność w grach komputerowych? Zadając sobie te pytania, postanowiłem bliżej przyjrzeć się temu zagadnieniu.

Na początek może odpowiedzmy na pytanie: dlaczego trójkąty? Otóż operowanie obiektami, które składają się z trójkątów, jest dużo łatwiejsze niż w przypadku jakichkolwiek innych wielokątów. Do obsługi funkcji ustawiania geometrii i trójkątów akceleratory wykorzystują tylko jedną macierz, co przyśpiesza pracę. Powtarzające się operacje mogą zostać zapisane w pamięci karty graficznej i wywoływane cyklicznie bez tracenia czasu na liczenie nowej macierzy (zob. [1]).

Teraz odpowiedzmy na kolejne pytanie: jakie ma znaczenie liczba trójkątów w obiekcie 3d? Nie ma znaczenia... (zob. [2]). Jak to?! Czyli nie należy zadbać o to, aby model 3d nie posiadał niepotrzebnych wierzchołków? Nie trzeba w ogóle optymalizować? Przyjrzyjmy się może najpierw temu, co napisano w dokumentacji silnika Unity3d 3: „Modern graphics cards are really good at pushing a lot of polygons, but they have quite a bit of overhead for every batch that you submit to the graphics card. So if you have a 100-triangle object it is going to be just as expensive to render as a 1500-triangle object. The "sweet spot" for optimal rendering performance is somewhere around 1500-4000 triangles per mesh.” ([3]),
tłumaczenie*:
„Nowoczesne karty graficzne dobrze znoszą dużą liczbę wielokątów, ale mają całkiem sporo na głowie - każdy proces wysyłany poprzez ciebie do karty graficznej. Tak więc, jeśli masz obiekt złożony ze 100 trójkątów, to będzie tak samo kosztowny do renderowania, jak obiekt złożony z 1500 trójkątów. Korzystnym rozwiązaniem optymalnej wydajności renderowania będzie przyjęcie 1500-4000 trójkątów na siatkę.”
Mając to na uwadze, już wiemy, jak bardzo powinien być złożony nasz model, aby zadbać o dobrą wydajność. A co jeśli chcemy mieć bardzo szczegółowy model? Najpierw powinniśmy odpowiedzieć na kilka pytań:
  • Jak najbliżej obiektu jest w stanie znaleźć się kamera w trakcie regularnej gry?
  • Z jak najdalszej odległości kamera będzie w stanie uchwycić obiekt w trakcie regularnej gry?
  • W jakim zasięgu kamery dany obiekt będzie najczęściej przebywał w trakcie regularnej gry?
  • Czy obiekt będzie regularnie widziany z różnych kątów czy tylko z jednego?
  • Jaka jest spodziewana gęstość występowania obiektu z uwzględnieniem planu otaczającego obiekt? Czy to obiekt miejski, wiejski, dżungla czy równina?
  • Jak dowolny jest obiekt? Czy jest on tworzony w określone miejsce na określoną mapę czy będzie używany dowolnie i często?
  • Czy obiekt będzie często występował na mapie?
  • Jakie są możliwości silnika gry w generowaniu grafiki?

Po odpowiedzeniu sobie na te pytanie, możemy przystąpić do modelowania, dobierając do tego odpowiednie techniki.

Dlaczego należy sobie odpowiedzieć na te pytania?

Przede wszystkim trzeba się dowiedzieć, co i jak jest renderowane podczas gry. Po pierwsze renderowane jest tylko to, co znajduje się w polu widzenia kamery, i nic więcej. Po drugie nie jest renderowany cały obiekt, tylko ta część obiektu, którą widać. Po trzecie nie jest renderowany obiekt, który jest zasłonięty i niewidoczny przez inny obiekt.
Kolejnymi rzeczami jakie trzeba uwzględnić to użycie m.in. teselacji. Teselacja polega na dzieleniu wielokątów na trójkąty. Więcej: „Aby skrócić czas potrzebny na przekazanie do akceleratora danych o trójkątach, stosuje się metodę wachlarza trójkątów (triangle fan). Dzięki temu maleje liczba danych potrzebnych do opisania świata. Ponieważ na początku podaje się trzy wierzchołki (P1, P2, P3) tworzące trójkąt T1, a następnie już tylko po jednym wierzchołku, który z dwoma poprzednimi tworzy nowy trójkąt (w naszym wypadku punkt P4 z P2 i P3 tworzy trójkąt T2). Jak łatwo zauważyć, każdy kolejny trójkąt jest podawany w tym samym kierunku, co stanowi dodatkowy atut metody eliminacji ukrytych powierzchni (face culling), która polega na renderowaniu tylko jednej strony trójkąta. Ponieważ zwykle karta interpretuje każdy podawany trójkąt jako dwa - tylny i przedni, jeżeli zbudujemy postać składającą się z 500 trójkątów, to bez stosowania metody eliminacji ukrytych powierzchni obiekt taki w rzeczywistości składa się z 1000 trójkątów.” (zob. [1]).
Skąd komputer wie, które obiekty są  bardziej widoczne, a które mniej? W grach komputerowych często stosuje się algorytm BSP. BSP (ang. Binary Space Partitioning – binarne dzielenie przestrzeni) jest algorytmem obliczania widoczności na podstawie sortowania obiektów 3D w drzewo binarne. BSP jest algorytmem dość szybkim i jest wykorzystywany w grach komputerowych (np. Gothic, UDK). Jest wykorzystywany głównie przy podziale zamkniętych obszarów, przy otwartych przestrzeniach lepiej sprawdza się drzewo ósemkowe (ang. octree).

Jakie techniki wpływają korzystnie na wydajność?
Następujące techniki wpływają korzystnie na wydajność:
  • technika LOD,
  • dzielenie tekstur,
  • biblioteki siatek (ang. mesh libraries),
  • maskowanie alfy - odnosi się do specjalnego stosowania alfy (ang. alpha blending) gdzie wszystkie piksele są renderowane jako w pełni przezroczyste bądź nie (100% lub 0%) bez przejściowych wartości.
Następujące techniki wpływają niekorzystnie na wydajność:
  • sortowanie alfy,
  • używanie zbyt wielu materiałów na obiekcie.

Zwiększenie liczby trójkątów niesie ze sobą koszt wydajności, ale zastosowane rozsądnie i
w połączeniu z LOD, koszt ten jest pomijalny w porównaniu z kosztem sortowania alfy.

Wiem, że zaprezentowany tu materiał jest trochę po łebkach, ale mam nadzieję, że może się to komuś przydać. Podsumowując, optymalizacja modeli 3d ma sens, jeśli można znacząco zmniejszyć liczbę trójkątów. Dla siatek zawierających mniej niż 500 trójkątów, optymalizacja się po prostu nie opłaca.

*mam nadzieję, że bez większych błędów...

Literatura
1. http://www.pcworld.pl/artykuly/druk/35120_5_1/Tworzenie.swiata.html
2. http://unity3d.com/support/documentation/Manual/OptimizeForIntegratedCards.html
3. http://unity3d.com/support/documentation/Manual/Optimizing%20Graphics%20Performance.html
4. http://www.trainz.pl/_forum/viewtopic.php?t=1619, patrz post zaczynający się od „Ta strona dostarcza podstawy informacji do rozważań nad wydajnością przy tworzeniu nowych modeli.”
5. http://rostok.3e.pl/download/Michal_Rostocki_praca_magisterska_%28BSP_i_PVS%29.pdf
6. http://pl.wikipedia.org/wiki/Binary_Space_Partitioning
7. http://pl.wikipedia.org/wiki/Drzewo_%C3%B3semkowe

Żadna Głupia Spółgłoska

Żadna Głupia Spółgłoska

Użytkownicy
Mniejszość Żydowska na HMS Stuleja
posty2557
Propsy3534
ProfesjaGracz
  • Użytkownicy
  • Mniejszość Żydowska na HMS Stuleja
Czyli co, jakiś tam kubeczek może mieć 500 trójkątów, bo jak będzie miał mniej, to komputer i tak będzie miał tyle pracy, co przy modelu mającym 500? A co z łączeniem wielu modeli w jeden obiekt w programie 3D, a więc tworzenie zestawów modeli, zamiast wrzucania każdego oddzielnie do sceny?
 
Często odkrywa się, jak naprawdę piękną jest rzeczywiście piękna kobieta dopiero po długim z nią obcowaniu. Reguła ta stosuje się również do Niagary, majestatycznych gór i meczetów, szczególnie do meczetów.
Mark Twain

Adanos

Adanos

Administrator
Szara eminencja
posty5204
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja

Adanos
Administrator

Grafika, jej wydajność i optymalizacja
#2 2011-01-23, 22:34(Ostatnia zmiana: 2011-01-23, 22:42)
Cytuj
A co z łączeniem wielu modeli w jeden obiekt w programie 3D, a więc tworzenie zestawów modeli, zamiast wrzucania każdego oddzielnie do sceny?
Jak połączysz obiekty, to w sumie mają więcej trójkątów. Jeśli po tym mają zbyt dużą liczbę trójkątów, to zawsze można uprościć ;)
Cytuj
Zwiększenie liczby trójkątów niesie ze sobą koszt wydajności, ale zastosowane rozsądnie i
w połączeniu z LOD, koszt ten jest pomijalny w porównaniu z kosztem sortowania alfy.

Cytuj
Czyli co, jakiś tam kubeczek może mieć 500 trójkątów, bo jak będzie miał mniej, to komputer i tak będzie miał tyle pracy, co przy modelu mającym 500?
Ok, może to trochę niedokładnie, ale chodzi głównie oto, że różnica czasu renderowania jest praktycznie nie zauważalna.

Nie chcę nikogo odciągać od modelowania low-poly, chciałem zwrócić również uwagę na inne czynniki, które mają znaczenie na wydajność.

Tom

Tom

Użytkownicy
posty270
Propsy39
  • Użytkownicy
Chciałbym nadmienic ze BSP jest uzywany tylko wtedy kiedy gra wykorzystuje LOD. Nie kazda gra go zawiera. Najczesciej mozna go spotkac w grach RPG w pełni 3D. BSP dezaktywuje sie kiedy we wspomnianym widoku znajduje sie obiekt zawierający alpha co najmniej 1% bo to wtedy narzuca na karte więcej zadan.
 
GTX 8800 512mb/bit, 250GB SATA, 2560Ram, Pentium D Dual Core 2,8 GhZ, Samsung Sync 17', Fortron 400W, Microstar

sauron
  • Gość

sauron
Gość

Grafika, jej wydajność i optymalizacja
#4 2011-01-24, 01:54(Ostatnia zmiana: 2011-01-24, 02:50)
dorzucam się, ku przestrodze wszystkich mądrych którym się wydaje że wiedzą wszystko. dziękujcie techlandowi.

Introduction
Zanim model trafi do gry, przechodzi długą drogę przygotowawczą, poczynając od bogatego w szczegóły modelu wysokopoligonowego, przez model niskopoligonowy do zestawień różnych tekstur oraz dodatkowych elementów niezbędnych do poprawnego funkcjonowania w grze opartej na Chrome Engine 4.

Hi Polycount Geometry
Jeżeli model ma posiadać unikalne cechy, pozwalające od razu rozpoznać w nim porządny obiekt warto pokusić się o wykonanie najpierw modelu wysoko poligonowego, który będzie zawierać wszelkie niezbędne detale. Będzie on niezbędny do wykonania tekstury map normalnych (opisanych dalej), dając nieporównywalnie lepszy efekt niż ręczne ich rysowanie.

Już na etapie modelu wysokopoligonowego należy mieć na uwadze jak będzie wyglądał docelowy model, który znajdzie się w grze, gdyż od tego zależeć będzie sposób wykonania detali. Może się okazać iż docelowy model będzie miał elementy powtarzalne lub zapętlające się i należy je odpowiednio wymodelować już w pierwszaj fazie.


Low Polycount Geometry
Wykonanie modelu niskopoligonowego to sztuka kompromisu. Nie jest to jedynie uproszczenie modelu wysokopoligonowego, ale głęboka modyfikacja oraz podejmowanie decyzji często zmieniających wygląd pierwotny obiektu, tak by przy najmniejszej ilości trójkątów uzyskać jak najwierniej odwzorowany kształt oryginału. Nie można też zapomnieć o tym iż musi nadal wyglądać przekonywająco i tak balansować by uzyskać efekt optymalny. Proces ten, można podzielić na kilka części.


Distance Detailed Work
Podstawowym założeniem jest, że model nie powinien mieć zbędnych, niewidocznych dla gracza detali włączonych w geometrie. Większość obiektów jakie znajdują się w grze powinna prezentować się najlepiej z odległości około 3-5 metrów. Wszelkie detale, które zanikają, wydają się płaskie lub zlewają się z bryłą modelu należy uznać za zbędne i pozostawić je mapie normalnych (o czym dalej).

Fakt, iż gracz będzie w stanie podejść bliżej do obiektu i zobaczyć go z mniejszej niż 3m odległości nie powinno stanowić większego problemu, gdyż większą rolę odgrywają wtedy tekstury oraz dodatkowy detal zależny od materiału obiektu. To właśnie kompromis między wydajnością, a szczegółowością otoczenia.

Detal, którego nie widać z 3-5 metrów nie powinnien istnieć w geometrii modelu.
Krawędzie znajdujące się blisko siebie, które zlewają się z większej odległości należy uprościć do wspólnej płaszczyzny.


View of Model
Kolejną zasadą określającą dokładność wykonania modelu, nawet już na poziomie hi-poly, jest to jak dany obiekt będzie widziany najczęściej oraz jakie jego elementy powinny najbardziej przyciągać uwagę, jakie powinny być wyeksponowane, a które całkiem pominięte. Już na poziomie modelowania wysoko poligonowego powinno się ustalić jak model będzie prezentowany w środowisku gry i które elementy oryginału można pominąć, gdyż nie będą widoczne.

Ta zasada ma główne zastosowanie do modeli broni, które mają ustalony kont i kierunek obserwacji, ale niektóre obiekty wypełniające otoczenie też można starać się upraszczać i ujednolicać w zależności od możliwości interakcji z nimi lub dystansu na jaki będziemy mogli podchodzić.

Elementy modelu, które są niewidoczne lub zlewają się z bryłą obiektu powinny być wykonane na mapie normalnych.
Parts of model which are invisible or blend into object's body should be prepared as a normal map.


FPP Quality
Nieco inaczej przedstawia się sytuacja z elementami gry, które widziane są z bliska, w perspektywie FPP, tuż “przed nosem” gracza. Do tej kategorii zaliczaja się wszelkiego rodzaju broń i inne modele przeznaczone bazowo do “trzymania w rękach”. Tego typu modele rządzą się innymi prawami, choć zasada “niewidocznych elementów” także ich dotyczy.

W tym wypadku geometria może, a nawet powinna być dokładniejsza. Najczęściej ważnym jest by obłe kształty miały wystarczającą ilość podziałów, tak by krzywizna nie była zbyt “kwadratowa”. Dotyczy to głownie elementów które są równoległe do płaszczyzny ekranu, gdyż to właśnie one są najbardziej widoczne. Pozostałe, prostopadłe, nie wymagają zwiększonej dokładności, gdyż w życie wchodzi zasada widoczności modelu i wiele poligonów zasłania się nawzajem i rzadko jest widoczna.

Często elementy, które z odległości 3-5 metrów pozostawione były by jedynie na mapie normalnych, w modelu FPP wymagają dodatkowej geometrii, lecz także i tu trzeba być ostrożnym i nie przesadzać z dokładnością. Jeżeli element nie odstaje zbytnio poza główny model i nie przekracza jego granic widoczności, także możemy pozostawić go mapie normalnych.

Broń trzymana zawsze w prawej ręce jest dodatkowo modelem wyjątkowym, gdyż pozwala na prawie całkowite odbicie lustrzane geometrii. Prawa strona jest praktycznie nie widoczna, a momenty gdy jednak pojawi sie na ekranie bywają krótkie, przy czym perspektywa mocno skraca widoczny obszar. Gdy jednak chcemy być wierni oryginałowi możemy charakterystyczne elementy dodać na osobnych poligonach. Robiąc to wszystko należy jednak pamiętać o następnej zasadzie, związanej z detalami.

Geometria znajdująca sie w skrócie perspektywicznym powinna być uproszczona.
Kształty ułożone równolegle do ekranu muszą być wykonane dokładniej.


Detail Expectation
Tworząc dowolny model budujemy bogatą bibliotekę materiałów na zadany temat i gromadzimy wiedzę, która często przekracza granice postrzegania przeciętnego gracza. Tworząc model staramy się odwzorować rzeczywistość, często nie zdając sobie sprawy, że zwykły człowiek, nie znający się na temacie, nawet nie zwróciłby uwagi na detale, które my uważamy za oczywiste. Taka sytuacja jest częstym powodem rozterek gdy dochodzi do optymalizacji modelu, gdy musimy pozbyć się nadmiaru poligonów, a wymodelowane z pieczołowitością detale powinny pójść na pierwszy ogień. Nikt nie zauważy braku kilku śrub, lub tego braku jakiegoś przełącznika. Nie spodziewa się też, że pewna krzywizna powinna być mniej lub bardziej obła, bo po prostu nie ma o tym pojęcia.

Praktycznie podczas tworzenia modelu hi-poly należy podjąć decyzję, które detale zostaną pominięte, które zmodyfikowane tak, by pasowały do całości obiektu, a które zostaną przeniesione na dodatkowy element mesha. Oszczędności na detalach to także przewidywanie jaka forma najlepiej sprawdzi się w modelu low-poly, jednocześnie bez strat na ostatecznym wyglądzie modelu. Upraszczanie i ujednolicanie poziomu detali jakie zostaną odzwierciedlone na modelu ma też wpływ na sposób mapowania i oszczędności na wielkości tekstur.

Różnorodność detali, a raczej decyzje o ich likwidacji, mają związek z późniejszym lustrzanym modelowaniem i mapowaniem, gdyż lewa i prawa strona obiektu będą wyglądać tak samo, chyba że zostaną stworzone elementy na dodatkowej geometrii. Jest to jednak zabieg pozwalający znacznie zwiększyć jakość ostatecznego wyglądu modelu, dzięki oszczędności przestrzeni na teksturze, a także gdy efekt końcowy będzie dostatecznie zadowalający, zmniejszyć jej rozmiar.


Mapping
Nawet najlepiej wykonany model hi-poly oraz zoptymalizowany low-poly mogą stracić na wartości gdy zostaną źle lub nieefektownie zamapowane na teksturze. Podobnie jak modelowanie, mapowanie UV podlega kilu zasadom, które wymagają przemyślenia ważności elementów, kompromisów jakościowych oraz planowania przestrzeni tekstury.


Mirror Mapping
Mapowanie lustrzane oznacza, iż obie strony lustrzanie odbitego elementu geometrii obiekty wymapowane sa w tym samym miejscu, mimo iż normalne wyświetlane mogą być odwronie na odbitej stronie, eksport do ChromeEngine? 4 skoryguje ustawienie tangentów tak, by lustrzane normalne wyświetlane były poprawnie.

Gdy model low-poly jest wykonany lustrzanie by ograniczyć ilość faców oraz detali, zrozumiałym jest iż mapowanie tych elementów także pozostanie lustrzane. Należy jednak pamiętać, iż mapowanie lustrzane wymaga dokładnego wykonywania tekstur, tak by linia odbicia nie była widoczna i nie tworzyły się charakterystyczne lustrzane wzory. Często warto, głownie w modelach broni, pozwolić by linia cięcia nie przebiegała idealnie przez środek, tylko w miejscu logicznego odcięcia utworzonego przez krawędź geometrii.

Prowadzenie linii obicia przez środek zawsze pozwala na zyskanie ilości miejsca na teksturze, przez co uzyskuje się lepszą jakość obrazu
Jeżeli faktura lub geometria obiektu pozwala na zamaskowanie linii odbicia, należy to wykorzystać

Linia odbicia lustrzanego mapowania nie zawsze musi przebiegać idealnie przez środek modelu. Czasem warto poświęcić nieco tekstury i najbardziej widoczne ściany pozostawić nieodbite, dzięki czemu zyskają na jakości


Level of Importance
Tak samo jak w przypadku modeli low-poly, mapowanie wymaga decyzji, które elementy obiektu są bardziej widoczne i ważniejsze, przez co wymagają lepszej jakości tekstury, czyli większej ilości miejsca.

Najlepiej jest przyjąć trójstopniową gradację ważności (wielkości) mapowanego elementu na teksturze, gdzie najpierw układa się elemety priorytetowe, tak by wykorzystać jak najlepiej rozmiar tektury, potem dodaje się elementy uzupełniające, a na końcu w pozostałą przestrzeń upycha się to co pozostanie.


1. Elementy priorytetowe
elementy broni i obiektów trzymanych przez Gracza blisko znajdujące się najbliżej ekranu
elementy przewidziane są do oglądania z bliska na obiektach otoczenia
fragmenty na których przewidziana jest szczegółowa, pełna detali tekstura

2. Elementy uzupełniające
fragmenty modelu widoczne w skrócie perspektywicznym
elementy widoczne, ale zasłonięte przez ruchome części modelu lub inny obiekt
fragmenty o monotonnej, niezróżnicowanej fakturze

3. Elementy mało widoczne
wszelkie elementy broni i obiektów trzymanych przez Gracza znajdujące poniżej krawędzi ekranu
fragmenty modelu widziane tylko w skrajnych sytuacjach (spody lub ściany wypełniające)
elementy całkowicie zasłonięte, widziane tylko z innej perspektywy niż podstawowa przewidziana (tylne ściany broni)

Należy pozostawić minimalną przestrzeń między mapowanymi elementami, lecz na tyle dużą by istniał margines pozwalający na tworzenie mipmap

By ułatwić pracę grafikowi rysującemu tekstury, elementy powinny być ułożone tak by ich orientacja była zbliżona do rzeczywistej w modelu
Elementy znajdujące się blisko siebie w modelu warto grupować także na teksturze


Same Elements Maping
Często się zdarza, iż obiekt posiada kilka elementów wyglądających podobnie, znajdujących się w różnych miejscach modelu. Należ takie właśnie elementy uwspólniać, jeżeli tylko geometria modelu na to pozwala. Dobrze zaplanowana tekstura i mapowanie elementów o podobnym wyglądzie, to kolejny krok w zaoszczędzeniu przestrzeni tekstury, pozwalający zwiększyć jej ostateczną jakość. Czasami warto zagęścić siatkę geometrii modelu tak, by znaleźć elementy, które będą podobne i da się je zmapować w tym samym miejscu tekstury.

Przykładem może być bardzo długa lufa karabinu, która zamapowana na całej długości będzie proporcionalnie dość wąska, tak by zmieścić się na szerokość. Jeżeli jednak podzielić ją na dwie części, tekstura lufy zyska na jakości. Łatwo zauważyć, że zwiększy się też przestrzeń zajmowana przez ową lufę, która ostatecznie widziana w skrócie perspektywicznym jest tylko kawałkiem rury. Dla tego oba kawałki obiektu warto zmapować w tym samym miejscu, gdyż są bardzo podobne do siebie, a skrót perspektywiczny zamaskuje ewentualne niedoskonałości

Elementy podobne powinny być mapowane w tym samym miejscu, by dzięki uwspólnianiu zaoszczędzić miejsce na teksturze


Proportions
Ze względu na techniczne ograniczenia, docelowa tekstura, a co za tym idzie mapowanie, powinny trzymać proporcje 1:1 lub w skrajnych przypadkach 1:2 (2:1). Tekstury o proporcjach 1:4 (4:1) sprawiają trudności podczas tworzenia mipmap i nie powinno się ich używać.


Projections
Na koniec, gdy mamy gotowy obiekt wysoko i niskopoligonowy z gotowym mapowaniem, pozostaje przygotować wyjściowe tekstury:

normal map (normals) - podstawowa tekstura normalnych odwzorowująca detale
lightning (ambient occlusion) - mapa cieni własnych, rzucanych przez symulowane światło ogólne (sky), będzie stanowić dopełnienie mapy normalnych poprzez wmnożenie do tekstury koloru
height map - na niektórych obiektach warto użyć dodatkowo, poza mapą normalnych, by uzyskać głębię Virtual Displacement Mapping

Podczas wykonywania projekcji należy usunąć na mapowaniu pokrywające się elementy, tak by tylko jeden znajdował się w przestrzeni tekstury, inaczej projekcja będzie błędna


Projection Overscale
Bardzo często mapy normalnych oraz ewentualnie mapy wysokości, mogą nie dawać pożądanego efektu finalnego podczas wyświetlania na obiekcie w środowisku ChromeEngine? 4 i sprawiać wrażenie płaskich i niewidocznych. Powodem tego jest intepretaja skali detali obiektu podczas ich renderowania. Gdy nie ma możliwości przeskalowania normalnych w trakcie renderowania, a skalowanie ich poprzez materiał powoduje utratę jakości należy przeskalować detale.

W tym celu trzeba ręcznie przeskalować, nawet kilkakrotnie, wszystkie interesujące nas detale, które mają zostać uwydatnione na mapie normalnych. Dodatkowo warto ustawić ściany prostopadłe w stosunku do płaszczyzny projekcji nieco pod kontem, tak by promień projekcji mógł na nie trafić. Warto też zaakcentować zewnętrzne krawędzie tych ścian fazując je (chamfer) delikatnie.

Nie wszystkie detale warto poddawać temu zabiegowi, który najlepiej sprawdza się na elementach dużych gdyż przeskalowane elementy mogą zacząć tracić swój pierwotny charakter
 

inż. Avallach

inż. Avallach

Administrator
posty7662
Propsy5238
NagrodyV
ProfesjaProgramista
  • Administrator
Czyli co, jakiś tam kubeczek może mieć 500 trójkątów, bo jak będzie miał mniej, to komputer i tak będzie miał tyle pracy, co przy modelu mającym 500? A co z łączeniem wielu modeli w jeden obiekt w programie 3D, a więc tworzenie zestawów modeli, zamiast wrzucania każdego oddzielnie do sceny?
Tak właśnie zrozumiałem część przesłania odpowiedniego dokumentu z dokumentacji Unity - że jeśli mamy kilka, położonych stosunkowo blisko siebie niezbyt rozbudowanych obiektów, to najlepiej je połączyć i nawet użyć wspólnego materiału.

Chociaż to ich tłumaczenie że upraszczanie poniżej 1000 tris nic nie daje wydaje się trochę dziwne, przy wielu obiektach po prostu nie można zastosować trwałego łączenia.

Dracon

Dracon

Użytkownicy
posty1068
Propsy904
Profesjabrak
  • Użytkownicy
Cytuj
Dla siatek zawierających mniej niż 500 trójkątów, optymalizacja się po prostu nie opłaca.
Może się nie znam, ale myślę, że jeśli na scenie będzie jakieś 200 obiektów, które mają po 500, zamiast po 100 trójkątów, to musi mieć to jakiś wpływ na szybkość renderowania. Niech mnie ktoś oświeci, jeśli nie mam teraz racji. ;)
 
,,Dobry, to człowiek, który nie ukrywa siedzącego w nim zwierzęcia. A taki co usiłuje udawać dobrego, jest wręcz niebezpieczny. Najgroźniejsi są ci, którzy sami głęboko wierzą, że są dobrzy. Odrażający, ohydny przestępca może zamordować jednego człowieka, dziesięciu, stu, ale nigdy nie zabija milionów. Miliony mordują ci, którzy mają się za samą dobroć.''

Wiktor Suworow, Akwarium

inż. Avallach

inż. Avallach

Administrator
posty7662
Propsy5238
NagrodyV
ProfesjaProgramista
  • Administrator
Cały czas chodzi o to że sam fakt przesłania kolejnego obiektu jest tak kosztowny, że pareset tris ma nie robić ponoć różnicy. Jednak nie jestem pewien czy to prawo ogólne czy specyfika tego konkretnego enginu (bo jakoś nadal widuje się gry gdzie modele są low-poly).

sauron
  • Gość
dołączyłbym do tego zalety dx10 bo od niego zaczęły się optymalizacje wyświetlania większych ilości obiektów na scenie (wręcz na demach i reklamówkach dx10 było o tym mówione, że można narąbać elementów bez utraty framerate), czyli to już się dzieje z poziomu engine/hardware... programiści mogą więcej na ten temat wiedzieć?
 

Adanos

Adanos

Administrator
Szara eminencja
posty5204
Propsy3870
ProfesjaProgramista
  • Administrator
  • Szara eminencja

Adanos
Administrator

Grafika, jej wydajność i optymalizacja
#9 2011-01-24, 13:17(Ostatnia zmiana: 2011-01-24, 18:57)
Cytuj
Może się nie znam, ale myślę, że jeśli na scenie będzie jakieś 200 obiektów, które mają po 500, zamiast po 100 trójkątów, to musi mieć to jakiś wpływ na szybkość renderowania. Niech mnie ktoś oświeci, jeśli nie mam teraz racji. ;)
Ale masz na myśli, że wszystkie są widoczne? Ok, zrobiłem mały teścik. Model samochodzik, no cóż, może nie będę mówił... Tak ma, ale zobacz wyniki...

Testy wykonane w Blenderze
             wierzchołki ściany czas renderowania
bez subsurfa    8738      8232  3-4 s (zajmuje całą przestrzeń ekranu)
                8738      8232    1 s (po przeskalowaniu, aby zajmował mniejszą powierzchnię ekranu), nazwijmy je S1
               17436     16464  2-3 s dla dwóch samochodzików S1
               20776     20858    3 s dla trzech samochodów (różna skala)
               61166     57956  2-3 s dla siedmiu pomniejszonych samochodzików, nazwijmy je S2
              113594    107623  3-4 s dla trzynastu samochodzików S2
z subsurfem
               60660     58309  4-5 s jeden samochodzik
              116448    112869  8-9 s dla 2 samochodzików
              228144    221989   17 s dla 4 samochodzików

              336599 412798 22s dla 1 samochodzika z subsurfem i subdividem

Cytuj
Cały czas chodzi o to że sam fakt przesłania kolejnego obiektu jest tak kosztowny, że pareset tris ma nie robić ponoć różnicy. Jednak nie jestem pewien czy to prawo ogólne czy specyfika tego konkretnego enginu (bo jakoś nadal widuje się gry gdzie modele są low-poly).
Raczej ogólne. Model low-poly, to raczej nie musi być obiekt o ilości 500 trójkątów. To nie ilość trójkątów decyduje o tym, a złożoność siatki modelu.

Cytuj
dołączyłbym do tego zalety dx10 bo od niego zaczęły się optymalizacje wyświetlania większych ilości obiektów na scenie (wręcz na demach i reklamówkach dx10 było o tym mówione, że można narąbać elementów bez utraty framerate), czyli to już się dzieje z poziomu engine/hardware... programiści mogą więcej na ten temat wiedzieć?
Każda operacja potrzebuje iluś tam cykli, aby się wykonać. Dajmy na to, że mamy CPU 2 GHz (tak wiem, że główne obliczenia przejmuje GPU), czyli możemy wykonać gdzieś 18 milionów miliardów cykli na sekundę. Pytanie brzmi: ilu cykli potrzeba na narysowanie trójkąta?

A! Jeszcze są CUDA Nvidii: http://www.frazpc.pl/aktualnosci/161741,NVIDIA-CUDA-zacznie-wreszcie-dzialac-cuda.html
Cytuj
Według NVIDIA zakodowanie filmu MPEG-2 w rozdzielczości 720p i o długości dwóch minut do formatu obsługiwanego przez iPoda, zajmuje najszybszym obecnie czterordzeniowym procesorom kilkanaście minut, podczas gdy GT200 jest w stanie to zadanie wykonać w ciągu niespełna 50 sekund!
https://www.youtube.com/watch?v=kHhkLyJLLYI

http://visualcompute.noumentalia.de/visualcompute.pdf
Kolega opowiadał mi, że ta technologia jest dość szybka. I to bardzo szybka. Przykładowo algorytm mnożenia macierzy jest kilkadziesiąt(kilkaset?) razy szybszy z wykorzystaniem CUDA, niż bez!

EDYCJA
Cytuj
Cały czas chodzi o to że sam fakt przesłania kolejnego obiektu jest tak kosztowny, że pareset tris ma nie robić ponoć różnicy. Jednak nie jestem pewien czy to prawo ogólne czy specyfika tego konkretnego enginu (bo jakoś nadal widuje się gry gdzie modele są low-poly).
http://forums.cgsociety.org/archive/index.php//t-911907.html
Cytuj
Poly Count:

For UDK / UTIII / Crytek / Unity or whatever other game engine not to have a fit when rendering the assets a few poly counts should be respected, these are:

1000 - 2000 for buildings with exteriors only.

1500 - 3000 for buildings with both interiors and exteriors.

3000 - 5000 for main chars, less for secondary chars.

1500 - 3500 for FPS weapons the char will be holding, less for weapons used by enemies.
[/s]

Zysk

Zysk

Użytkownicy
posty606
Propsy451
  • Użytkownicy
Cytuj
A! Jeszcze są CUDA Nvidii: http://www.frazpc.pl/aktualnosci/161741,NVIDIA-CUDA-zacznie-wreszcie-dzialac-cuda.html

https://www.youtube.com/watch?v=kHhkLyJLLYI

http://visualcompute.noumentalia.de/visualcompute.pdf
Kolega opowiadał mi, że ta technologia jest dość szybka. I to bardzo szybka. Przykładowo algorytm mnożenia macierzy jest kilkadziesiąt(kilkaset?) razy szybszy z wykorzystaniem CUDA, niż bez!
Tak, kilkadziesiąt, chyba że porównujesz ze strasznie starym procesorem. Dla niektórych zagadnień uzyskuje się tak dobre wyniki. Ale warto zwrócić uwagę, że karta graficzna działająca w tradycyjny sposób jest pewnie sporo ponad 100 razy szybsza w renderowaniu grafiki, niż procesor. W związku z tym, pewnie sporo czasu minie, zanim całość grafiki będzie renderowana przy użyciu tego typu technologii.
 


Żadna Głupia Spółgłoska

Żadna Głupia Spółgłoska

Użytkownicy
Mniejszość Żydowska na HMS Stuleja
posty2557
Propsy3534
ProfesjaGracz
  • Użytkownicy
  • Mniejszość Żydowska na HMS Stuleja
EDYCJA
Takie podawanie polycountów bez podania specyfiki gry, w tym trybu kamery, gatunku i szybkości rozgrywki jest bez sensu. Co innego budynek bez wnętrza który ma być jakimś ważnym ośrodkiem wokół którego kręcą się wydarzenia, co innego budynek w RTSie widziany z góry, co innego szeregowiec stojący wzdłuż ulicy i pełniący funkcję ogranicznika, co innego dom chociażby w ścigałce, który będziemy po prostu mijać jadąc 245 km/h. Do tego dochodzi także wielkość wahająca się w zakresie komórka-pałac. Tak więc podanie 1000-2000 trisów bez określenia co to za budynek nie ma w sumie sensu.

[mod=Adanos]Tak, masz rację, ta edycja była bezsensu.[/mod]
 
Często odkrywa się, jak naprawdę piękną jest rzeczywiście piękna kobieta dopiero po długim z nią obcowaniu. Reguła ta stosuje się również do Niagary, majestatycznych gór i meczetów, szczególnie do meczetów.
Mark Twain


0 użytkowników i 1 Gość przegląda ten wątek.
0 użytkowników
Do góry