czym się rożni normal od bump?

[ciacho191]

Witam drogich panów i panie mam takie otóż pytanie : czym się różnią normal texture od bumpa?

[heaven]

normal to tekstura kolorowa i gladka a bump to tekstura czarno biala wsadzona w kanal BUMP dajaca uwypuklenia, nierownosci itp.

 

chyba tak :P hehe

[GRiPi]

normal mapa, jak nazwa wskazuje, wyznacza normalna powierzchni, czyli linie prostopadla do powierzchni. dzieki temu ze operuje w 3 wymiarach(po jednym dla kazdej skladowej kloloru), mozna przy jej uzyciu uzyskac dokladny shading obiektu ktory ma udawac. bump mapa dziala tylko w jednym wymiarze(gora-dol wzgledem powierzchni obiektu) i nadaje sie raczej do nadawania drobnych fraktur.

[Orangegraphics]

praktycznie to normal daje mocniejsze efekty. może także być real time generowany. ale technicznie to nie wiem.

[mathix]

GRiPi dość dobrze to wyjaśnił. Ogólnie bump mapping to taki szczególny przypadek normal mappingu, gdzie normalmapa powstaje na podstawie mapy wypukłości. Zresztą tutaj masz to ładnie wyjaśnione:

http://en.wikipedia.org/wiki/Bump_mapping

http://en.wikipedia.org/wiki/Normal_mapping

[SYmek]

Hmm, wydaje mi się, że różnica między normal mapami a bump mapami jest trochę inna i niekoniecznie ma związek z przekształceniami powierzchni w jednej osi lub trzech osiach.

(Choć przyznam szczerze, że ponieważ używa się je głównie w grach, nie mam wielkiego doświadczenia z normal mapami, mogę więc coś mieszać ;) )

 

Technicznie rzecz biorąc obie służą do tego samego:

podają funkcjom odbicia (reflectence model), które definiują kolory powierzchni "błędne" informacje w celu imitacji mikro wypukłości. W jaki sposób?

 

Do obliczenia koloru powierzchni w najprostszym przypadku potrzebujesz:

 

P - położenia punktu na powierzchni

I - wektora od tegoż punktu do kamery

L - wektora od tegoż punktu do światła

N - normalną punktu

 

W przypadku bumb-mapy udajemy, że punkt nie znajduje się w punkcie P, tylko w punkcie przesuniętym wzdłuż jego N o wartość podaną w mapie (dajmy na to "lum"):

 

fakeP = P + (N*lum)

 

potem musimy jeszcze raz obliczyć jego normalną, która może się zmienić (szczególnie dla okolicznych punktów.

 

nN = computenormal(N)

 

Nie następuje prawdziwe przesunięcie, to dzieje się w przypadku displacemant shader, ale kiedy takie N podamy funkcji obliczającej kolor, np. najprostszemu lambertowi:

 

lambert = cos(nN, L)

 

...to dostajemy kolor nie dla P zdefiniowanego przez geometrię, ale jakby przesuniętego. Tak jakbyśmy pytali: jaki byłby kolor P, gdyby go przesunąć o tyle a tyle wzdłuż jego normalnej?

 

Jak łatwo się domyślić z powyższego normal mapa jest czymś szalenie podobnym. Zamiast hipotetycznie przesuwać punkt, obliczać dla niego nową normalną i podawać to do funkcji odbicia (takiej jak diffuse, phong, blinn, cook-torrance etc), dostarczamy jej "udawne" normalne, a funkcje te, podobnie jak w przypadku bump mapy obliczą "niewłaściwe" światło.

 

Dlaczego więc wymyślono normal-mapy, skoro bump działa podobnie? Nie znam zapewne wszystkich przyczyn, ale jedną z nich jest dokładność. Bardzo nieoczywistym punktem w tej opowieści jest ponowne obliczanie normalnych dla zmodyfikowanego P.

 

Liczy się je za pomocą cross produktu (wektor prostopadły do płaszczyzny dwóch wektorów), dwóch bardzo nieoczywistych wartości: pochodnych z S i T powierzchni (s i t to takie UV implicite zawarte w każdym prymitywie). Otóż obliczanie tej wartości nigdy nie będzie dokładniejsze od wartości normal map z Zbrusha, ponieważ obliczane jest w przestrzeni ekranowej i zależy od wielu parametrów, takich jak rozdzielczość ekranu, sampling, AA, sposób rasteryzacji powierzchni etc. Dlatego właśnie najgorzej wyglądającą częścią obrazka "zbumpowanego" są krawędzie między przesuniętymi punktami a tymi, które zostały na miejscu. Wyglądają bardzo niedokładnie, prawda?

 

Ponieważ normal mapa definiuje kierunek zwrócenia powierzchni, oczywiście musi być kolorowa... ;)

 

No i zdaje się, że normal mapy z Zbrusha są w tangent space a nie camera space. A skoro tak, to robi się to jeszcze trochę bardziej skomplikowane ;)

 

pozdr.,

skk.

[Hynol]

Dokładnie tak. Normal mapa i height mapa (bo nie bump mapa - to jest zależne od sposobu użycia) w istocie są tożsame. Normal mapa działa szybciej chociażby z tego powodu że piksle są jednoznaczne (określają normalną powierzchni) a w height mapie trzeba znać wszystkie piksele na około aby wiedzieć jak ułoży się w tym miejscu normalna a więc trzeba dodatkowych obliczeń. Każdą height mapę można przeliczyć na normal mapę i odwrotnie.

[mathix]

http://www.spinquad.com/forums/showthread.php?t=4478

http://wiki.blender.org/index.php/Manual/Bump_and_Normal_Maps

Chyba jednak chodzi o transformację w trzech wymiarach.

[SYmek]

http://www.spinquad.com/forums/showthread.php?t=4478

http://wiki.blender.org/index.php/Manual/Bump_and_Normal_Maps

Chyba jednak chodzi o transformację w trzech wymiarach.

 

Jak mówię, nie pracuję na tym, więc nie chcę się spierać, ale wydaje mi się, że powyższe wątki mówią po prostu o tym, że normal mapy lepiej wywiązują się z imitacji przesunięcia, bo lepiej definiują normalne powierzchni. Nie przesuwają jej jednak. Nadpisują N. Najwyraźniej bump mapy ( i przeliczanie N na nowo po ich aplikacji) radzą sobie z tym zagadnieniem gorzej niż myślałem ;)

 

Ale faktem jest, że z samej natury normalnych wynika, że łatwiej jest za ich pomocą definiować kształt powierzchni, niż za pomocą bumpa. Tu, zdaje się, masz rację.

[Shogun 3D]

No to ja jeszcze napiszę o co chodzi z displace. Rózni sie ona od normali i bumpów tym, że faktycznie deformuje siatkę poprzez zagęszczenie jej i mechaniczną deformację, dzięki czemu nie jest to już fake nierówności, tylko faktyczne nierówności.

[mathix]

SYmek: oczywiście, że nie przesuwają, bo to nie displacement :) Źle się trochę wyraziłem. Chodziło mi o to, że normal mapa, ma możliwość bezpośredniego wpływania na normalne, a bump mapa, tylko w określony sposób. Łatwo sobie wyobrazić perturbacje normalnych, których nie da się uzyskać za pomocą bumpa.

 

W związku z tym, każdy bump może zostać normal mapą, ale na odwrót niestety już nie. Przynajmniej nie bez utraty informacji.

[SYmek]

SYmek: oczywiście, że nie przesuwają, bo to nie displacement :) Źle się trochę wyraziłem. Chodziło mi o to, że normal mapa, ma możliwość bezpośredniego wpływania na normalne, a bump mapa, tylko w określony sposób. Łatwo sobie wyobrazić perturbacje normalnych, których nie da się uzyskać za pomocą bumpa.

 

W związku z tym, każdy bump może zostać normal mapą, ale na odwrót niestety już nie. Przynajmniej nie bez utraty informacji.

 

Masz absolutną rację ;).

 

No to ja jeszcze napiszę o co chodzi z displace. Rózni sie ona od normali i bumpów tym, że faktycznie deformuje siatkę poprzez zagęszczenie jej i mechaniczną deformację, dzięki czemu nie jest to już fake nierówności, tylko faktyczne nierówności.

 

Ale nam sie wiki rozmowa zrobiła :)

 

Shogun 3D, nie chciałbym Ci robić przykrości, ale nie masz racji, he he. To znaczy masz tylko w połowie. Displace oczywiście odkształca powierzchnię, ale czy to jest siatka, czy się ją zagęszcza itd, to już inna historia... Wymieniłeś tylko jeden ze sposobów, ten gorszy ;)

 

pozdr.,

skk.

[SWRSC]

a ja tylko powiem, ze w przypadku vRay lepiej stosowac normal mapę niż zwykłego bumpa. Normal daje nam wyraźniejszy bump i nie jest tak bardzo zjadany przez LC.

[piotrek]

ehh, SWRSC - wszystko posułeś - była piękna, teoretyczna dyskusja, a Ty od razu w vrayem wyskakujesz :p

[mathix]

SYmek: hehe ustaliliśmy wspólną wersję. A jak temat schodzi na displace, to wiesz może coś więcej dlaczego rendermanowski (i nie chodzi mi tu tylko o implementację PRMan) displace jest taki szybki?

[SYmek]

SYmek: hehe ustaliliśmy wspólną wersję. A jak temat schodzi na displace, to wiesz może coś więcej dlaczego rendermanowski (i nie chodzi mi tu tylko o implementację PRMan) displace jest taki szybki?

 

No właśnie dlatego, że się nie zajmuje siatką, poligonami, prymitywami etc. Jak wiesz, REYES zaczyna od stworzenia sobie reprezentacji geometrii widocznej w buckecie w mikro-poligonach. Kiedy ma już mikropoligony zapomina o geometrii, niczego nie zagęszcza, przesuwa, interpoluje, nic z tych rzeczy. Ma chmurę punktów w przestrzeni i pracuje tylko na nich - do czasu wywołania raytracingu przez shader oczywiście.

 

To tak, jakbyś oblepił rzeźbę piaskiem. Bez względu ma to, jak gęsta, skomplikowana itd rzeźba by nie była, sprowadza się do ziaren piasku, których ilość jest zależna od wielkości na ekranie (między innymi). Możesz nawet zapisać te mikropoligony na dysku i nigdy więcej nie sięgać po samą gemetrię, która posłużyła do jej powstania. Zostanie tylko forma odlana z punktów.

 

To ma swoje niebagatelne konsekwencje, wiele konsekwencji. Na przykład odpowiednio zapisana chmura punktów nie musi rezydować w pamięci w całości (brickmaps!), a dostęp do okolicznych punktów jest śmiesznie tani w porównaniu z innymi metodami (point clouds). No i przemieścić taki punkt (displace) jest także śmiesznie łatwo w porównaniu z gęstą siatką poligonów na których pracuja raytracery.

 

To tak z grubsza ;)

 

pozdr.,

skk.

[mathix]

Tak z grubsza wystarczy. Resztę sobie doczytam. Dzięki :)