Jump to content

HP vs LP+displace


Shogun 3D
 Share

Recommended Posts

Nie wiem, czy aby na pewno tutaj to wrzucać, ale... zrobiłem eksperyment mający na celu sprawdzenie różnicy tempa renderingu pomiędzy modelem lowpoly (kulka 2256 poly) z mapą displace oraz pierwowzorem tejże mapy displace, czyli kulką highpoly (144 384 poly) podrasowaną na łapu - capu w mudboxie.

Efekt mnie co najmniej zszkował, jako że spodziewałem się, iż displace przyspieszy render. Otóż nie!

Oto wyniki, z czasem podanym w pasku. Ilość poly podana w pasku renderu kulki LP wyraża ilośc poligonów powstałych na użytek displace'a.

 

Render LP + displace 1024:

 

dispbp4.jpg

 

Render HP:

 

hpve4.jpg

Link to comment
Share on other sites

dobrze wiedzieć

dziwny fenomen. pewnie to dlatego że musi dodatkowo obliczać przesuwanie ścianek na skutek displejsa.

 

a czy ustawienia świateł są te same? bo dolna kulka wygląda jakby jaśniej, ma też mniej kontrastu.

Link to comment
Share on other sites

tu chodzi o predkosc działania w wiuporcie + deformacje np. biped i zmiana postury a nie o predosc renderu :)

 

Sprobuj zrigowac model 1mln poly, model 10 k poly ;) roznica jest.

Displace w vraju 1.4xx cos był bardzo szybki, pozniej zauwazyłem spory spadek jego predosci, te wszystkie przeliczenia na poczatku, no ale w zamian jakosc generowanego dispa jest jednak wieksza :)

Link to comment
Share on other sites

Aniu, światła są takie same.

Klicuś, masz rację. :)

Leru zaproponował mi zrobienie animacji tej kulki z dowolną deformacją. Nałożyłem kulce Twista 180st i puściłem render. Potem powtórzę to dla kulki LP.

W obu przypadkach tylko 24 klatki.

Leru twierdzi, że ostateczny czas wypadnie lepiej dla displace, choć ja nie widzę różnicy pomiedzy stillem, a multiplikacją stilli składających się na animkę.

Ale jak już eksperymentować, to kompleksowo. :)

EDIT: Aniu, wydaje mi się, że różnica kontrastu polega na jakims błędzie lub deformmacji odbijania światła przy generowaniu displace'a. Oba materiały to standardowy szary V-ray material, przy czym jeden ma oczywiście dodatkowo mapę displace.

Link to comment
Share on other sites

Shogun bo to jest swego rodzaju oczywiste, obiekt 3d z duza iloscia poly (jak masz duzo ramu) zostanie raz wrzucony w ram i renderowany dlatego jest to szybsze :)

 

Wszystkie silniki renderujace (oprocz brazila/scanlajna) ma displejs liczony podczas renderu a nie przed nim dzieki czemu nie zapycha tak ramu.

 

 

Shogun mozesz wrzucic te swoje przykładowe obiekty ? zorobił bym kilka testów :)

Link to comment
Share on other sites

macie tutaj linka do tej kulki od Shogun + mapy :)

 

http://www.mm.pl/~aktimel/K_map.rar

 

Pecet Twoj kulka, nie jest miarodajna ;)

 

patrz na ta kulke z finala ... 1 mln poly po displejsie :

test1.jpg

test1.jpg

 

widzisz roznice w detalu ?

 

testy musimy robic na jednym modelu :*

 

render modelu hi :

 

test4.jpg

 

 

render dispa :

 

test6.jpg

test7.jpg

 

 

skanlajt całe 14 sekund a efekt znosny :

 

test8.jpg

Link to comment
Share on other sites

tak :) nie chodzi o to zeby było szybciej :) narazie zrobmy testy zobaczmy ktore rendery maja porownywalne czasy kosztem jakosci :)

 

powiem Ci tak zriguj siatke hp szybciej niz ja zriguje siatke low ;) zawsze jest niestety cos za cos :)

 

skanlajn ma chyba porownywalne efekty czasu renderu dispa do czasu renderu modelu hi

 

Mental disp :

 

test9.jpg

 

 

Mental render obiektu Hi :

 

test10.jpg

Link to comment
Share on other sites

jest mniejsza bo musiałem właczyć midle-centered poniewaz disp nie jest 32bit sorry :)

 

ok dorzucam render z brazila :

 

Render : obiektu hi (13 sekund)

test11.jpg

 

 

 

render : obiektu low : (low ... ) (17 sekund czas renderu bucketowego)

 

test12.jpg

Link to comment
Share on other sites

jakby sie do tego nie brac to model LP z displacem, neizaleznie jak sie dlugo rysuje pozwala trzymac go wiecej w viewporcie niz HP... zreszta po to wymyslono cale te subdividy... zeby bylo mniej poly w oknie... a zeby wiecej bylo widac... trzeba po prostu znalezc zloty srodek do potrzeb...

 

ze wzgledu na sposob probkowania renderow mapy textur zawsze wyjda ostrzej niz probkowanie polygonow... ot taki problem usredniania swiatla na trojkatach :) oczywiscie zakladam zarowno ostre mapy, jak i ostre trojkaty, bo jak ktos da zblurowana mape to ma to co narysowal...

Link to comment
Share on other sites

ok wiec chciałbym podsumowac to co zauwazyłem testując te wszystkie 4 rendery :)

 

Wiec na poczatku trzeba je rozbić na 2 grupy renderów :

 

1grupa ) final,mental,Vray - rendery, ktore przeliczaja mape disp podczas bucketowania nie przeliczaja obiektu wczesniej nie obciazajac ramu.

 

2grupa) scanlajn, brazil - rendery ktore przeliczaja dispa przed renderem zapychac ram (u mnie do okolo 1 giga)

 

Specjalnie w brazilu ustawilem efekt zageszczenia siatki co 1xpiel zeby wyszło jak najwiecej poly ... jak widac ze screena przeliczanie przed renderowe trawalo około 1:40 min ... przy czym wytworzył on bryłe o wielkosci prawie 4,5 mln poly i wszystko wrzucił w ram - czas bucketowego renderu (to co mogłem zobaczyc) trwał około 17 sekund ;)

Na podobnej zasadzie działa skanlajn tylko chyba troszkę szybciej przeliczył bryłe, ale to pewnie z tego wzgledu ze bryła koncowa miała cos około 1mln poly.

 

natomiast Final + mental + vray - mape disp przeliczaja podczas renderu odrazu włacza sie bucket render i w tym czasie generowana jest bryła. Trwa to dłuzej ale zauwazyłem ze spozycie ramu przy tej technice stoi na około 200 mb ...

 

Moim zdaniem najlepszym renderem pod dispa jest mental jest zdecydowanie najszybszy... i najłatwiej jest w nim ustawić dispa , poniewaz tak naprawde zmieniłem 2 rzeczy :

 

Maksymalna wysokosc jaka moze osiagnac disp (dziwna sprawa, bo gdy ten parametr jest niski disp dochodzac do tej wysokosci sie spłaszcza ;))

Oraz parametr odpowiadajacy za dodwanie polygonow na detalu do 1 pixela.

 

I to by było tyle, bardzo poczuczajace doswiadczenie :)

Link to comment
Share on other sites

Tutaj jeszcza taka szybka próbka przy użyciu PRMan'a:

 

HiPoly (25s):

hifibnalkt6.jpg

LowPoly + disp (18s):

lowdispnf8.jpg

 

Próbowałem to samo zrobić na mentalu, by zobaczyć jak się mój komp spisze (256MB RAM) ale po czterech minutach renderingu w połowie nagle skończył.

Link to comment
Share on other sites

chyba chodzi mu o pixar renderman ale moge sie mylic ;)

 

pecet pamietaj ze na predosc renderu dispa sklada sie kilka rzeczy :

 

- wysokosc dispa

- zageszczenie podczas renderu itp

 

ale rzeczywiscie czasy renderu sa imponujace :) ale tylko pod warunkiem ze disp był liczony podczas renderu (bucketowego) - niechce mi sie szukac takiej notki na necie hehe

Link to comment
Share on other sites

PRMan jako taki jest rendererem standalone.

Jedyne, czego potrzeba to exportera sceny do formatu RIB. Chociaż nie ma co ukrywać, że Maya jest w uprzywilejowanej pozycji, bo jest MTOR (plugin od Maya), który umożliwia pracę z PRMan'em w samej Mayce, nie trzeba się paprać z RIBami w notatniku i w commandline :)

 

klik

klik

 

 

Chciałem jeszcze sprawdzić jak sobie z takim dispem radzi inny renderer "produkcyjny" - Mantra, ale nie bardzo umiem ustawić :/

Link to comment
Share on other sites

Mantra radzi sobie „przyzwoicie” ;)

Hi-poly (jakość normal) 30s

hinormal30zl9.jpg

Hi-poly (jakość fast) 25s

hifast25lx5.jpg

 

Do Displace’a musiałem zwiększyć znacznie długość, żeby porządnie wyglądało.

Disp (jakość normal) 23s

disnormal23mp3.jpg

Disp (jakość fast) 17s

disfast17hu2.jpg

 

P.S Żeby w hudym dispa wyrenderowaćz mapy w SHOP’ie należy stworzyć VEX Displace Map i dodać w Object->Shading->Shop Displacement ten shader

 

Edit:

Sprzęt:

p4 1.8

ram - 1 GB

Link to comment
Share on other sites

Mi w viewportcie też się czarne kwadraty pojawiały ale jak renderowałem przez ROP’a to było git :) Swoją drogą to nie wiem, czy już ślepy jestem czy co ale nie widzę zbytniej różnicy między jakością normal a fast – skoro nie widać różnicy… :D Może ujawnia się ona przy innych bajerkach.

Link to comment
Share on other sites

ło chlopaki super testy :) tak trzymac :)

 

no skoro Prman tak ładnie sobie radzi to jestem pod wrazeniem :)

 

Piotrek na jakim sprzecie to liczyłes ? bo wspominales ze masz 256 mb ram, wiec wydaje mi sie ze na lepszym sprzecie czas by był bardziej imponujacy, ale moge sie pewnie mylic

 

Moje testy były robione na nastepujacym sprzecie :

p4 2.8

ram - 2 giga

Link to comment
Share on other sites

Źle rozumiecie chyba działanie displacementu, on niema prawa działać szybciej od zwykłego hi poly geometry. Po prostu renderer subdividuje(według ustawień) mesha 300 faces do 30tyś faces. I jeżeli dacice wersje hipoly też 30tyś faces to będzie równy czas renderingu.

 

Każdemu displacementowi można dać różną dokładność.

W vray'u jest resolution, w maxowym subdivision zaznaczamy iterations. Daje to różne wyniki + optymalizacja jeden mesh po displacemencie będzie miał (100tyś poly, drugi 200tyś)

 

Problem wasz wygląda tak że, jeżeli displacement robi się wolniej niż hipoly, to znaczy że displacement tak subdividował mesha lowpoly że ma więcej poly niż highpoly [paradoksalnie].

 

Niema różnicy między lowpoly z subdivision displacementem(a innego chyba niema, są tylko różne sposoby subdivision faców. (bardziej zoptymalizowane bądź mniej)) Lowpoly z displacementem to dla renderera zwykłe highpoly, tylko potrzebuje na początku się obliczyć dodatkowo(podzielić się kilkunastokrotnie, i zmienić pozycje wertexów).

 

Zawsze jeżeli coś jest precomputed to łatwiej tego używać. Np. Gi w vray'u.

Lightmapy w grach, normalmapy zamiast czarnobiałych bump map. Dzięki nim mniej obicążamy aplikacje.[Przy animacji ruchu, do każdej klatki renderer od nowa musi obloczać mesha po displacemencie.

 

I tak powiem

...;)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy