HP vs LP+displace

[Shogun 3D]

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:

 

 

Render HP:

 

[Ania]

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.

[KLICEK]

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 :)

[Shogun 3D]

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.

[pecet]

ja to już dawno wiedziałem ;)

[Shogun 3D]

To czemu siedziałeś cicho?

[pecet]

myślałem że to oczywiste, że tak musi być i tyle :)

[KLICEK]

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 :)

[Shogun 3D]

Ok, czyli odkryłem Amerykę w konserwie... Ale skoro chociaz Ania na tej wiedzy skorzystała, to nie był to czas zmarnowany. :)

[pecet]

a tak to wygląda w mental rayu:

displace 360 faces 27s

hi poly ~40k faces 17s

[KLICEK]

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 :

 

widzisz roznice w detalu ?

 

testy musimy robic na jednym modelu :*

 

render modelu hi :

 

 

 

render dispa :

 

 

 

skanlajt całe 14 sekund a efekt znosny :

 

[pecet]

ale i tak widać, na displace wolniej :p

[KLICEK]

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 :

 

 

 

Mental render obiektu Hi :

 

[pecet]

o rigowaniu słyszałem tylko z opowiadań :p

Twoje rendery też nie są miarodajne bo na drugim kulka jest mniejsza! ;)

[KLICEK]

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)

 

 

 

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

 

[vv3k70r]

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...

[KLICEK]

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 :)

[Shogun 3D]

No, Klicuś... bomba opracowanie. ;D

[piotrek]

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

 

HiPoly (25s):

LowPoly + disp (18s):

 

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ł.

[pecet]

co to prman? i co on daje? bo widze ze u Ciebie szybciej poszło z dispalcem...

[KLICEK]

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

[piotrek]

PRman (Pixar Photorealictic Renderman) to po prostu silnik renderujący, jak mental, vray czy inne.

Cały rendering trwał tyle czasu, nie było żadnego przeliczania wcześniej.

W końcu nie bez powodu liczą nim epoki lodowcowe czy Carsy...

[masater]

jak znajdę chwilkę mogę jeszcze z innych rendermanów rendery powsadzać, m in. pixie, aqsis czy 3Delight

[Shogun 3D]

Tyle, ze Renderman pomyka na Mayce...

[piotrek]

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ć :/

[andy_a]

Mantra radzi sobie „przyzwoicie” ;)

Hi-poly (jakość normal) 30s

Hi-poly (jakość fast) 25s

 

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

Disp (jakość normal) 23s

Disp (jakość fast) 17s

 

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

[piotrek]

Dzięki za teścik.

Tak robiłem, ale mi jakieś dziwne babole wychodziły.

To teraz już wiemy, czemu w Hollywood nie używa się vraya :)

[andy_a]

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.

[KLICEK]

ł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

[piotrek]

AMD Athlon XP 1600+ (~1400MHz) + 256 DDR RAM xD

 

Tak jak pisałem - mental z 4 minuty to trawił i nie dał rady, ale chyba coś miałem namieszane i pamięć zapchaną, bo w sumie nie możliwe, że sobie nie poradził z jedną kulką.

[Cruzh3r]

Ź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

...;)

[KLICEK]

Crush3r to juz zostało powiedziane ;)