Shadery macierze

category

Uncategorized

author

admin

W Blenderze zrobiłem sobie najprostszą płaszczyznę z pomalowanymi wierzchołkami. Po zaimportowaniu do Unity i usunięciu rotacji wygląda to tak:

Aby się dobrać do koloru musimy w strukturze przekazywanej do funkcji operującej na wierzchołkach dodać:

No i naturalnie w strukturze przekazywanej do fragment shadera:

Potem w vertex shaderze po prostu przekazujemy go dalej do fragment shadera, a we fragment shaderze podajemy ten kolor jako wyjście i tyle 🙂

Dobra. Ale my nie o tym. W tym artykule będzie mowa o co chodzi z tymi macierzami.

Pozycje wierzchołków z wierzchołków modelu 3D należy przemnożyć przez 3 macierze M V P aby uzyskać wyświetlony poprawnie model 3D.
Można to np. zrobić tak jak w podstawowym shaderze:

A co się stanie jeśli zamienimy powyższą linijkę tą, czyli bez mnożenia macierzy:

Teraz cały obraz w edytorze pokrywa nasz obiekt. Dopasował się idealnie i to nie zależnie od tego jak obrócimy kamerę. Dlaczego tak się stało?
WYDAJE mi się (z naciskiem na wydaje), że dzieje się tak ponieważ widok kamery jest we współrzędnych jednorodnych gdzie x i y zawierają się w przedziale [-1,1] i wszystko byłoby spoko, gdyby nie to, że żółty wierzchołek jest w blenderze w pozycji (1,1) a na powyższym obrazku jest w lewym dolnym rogu. Czyżby tam było (1,1)??? Albo to jest wszystko jakoś śmiesznie rotowane.

Dodałem do shadera “Cull Off” żeby było 2 stronnie. Odwrócenie normalnych

A co się wydarzy jeśli niektóre wierzchołki w Blenderze będą większe niż 1 a inne np. o.4?


Wygląda na to, że pokazywane jest na scenie i tak tylko to co jest w kwadracie z przedziałami -1,1. Ale jakoś obrócone…
Ponoć kamera ma patrzeć na -z… ale nie wiem…

Zróbmy jeszcze jeden test. Kolor równy położeniu. R i G będą x i y. Gdzieś koło środka powinny się robić czarne, bo w środku jest (0,0), a w prawym górnym rogu powinno być czarne, bo kolory są ujemne. No obaczmy… No i oczywiście NIE, jednak działa to inaczej… Jakby w pikselach to było jednak? Wartości są przemnożone przez 0,003 i dlatego jest gradient, tak to wszystko jest żółte, czyli ma wartości większe od 1, ba idące w tysiące. Nie mam pojęcia jak to działa… Natomiast wygląda na to, że składowa ‘z’ jest zawsze równa 0.

Dodam parametry tego shadera do przesuwnia po ekranie. Ciekawe czy zadziała…

Owszem działa. Przesunięcie wymnożonego wszystkiego, zgodnie z przewidywaniem, rusza już narysowany na ekranie. Przesunięcie przed narysowaniem przesuwa po globalnej osi x.
A  ciekawe co będzie jak ruszę po namalowaniu w osi z? powoduje to przesunięcie na osi z którego nie widać, bo to jest jakby forward/backward. Ale w miarę cofania się i ujemnego z, obiekt w końcu znika (nie jestem pewien czy już dla z=-0,01 znika)

Dobra opis tych macierzy:

M – model to world
Ta macierze zamienia współrzędne modelu na współrzędne w świecie czyli skaluje, przemieszcza i rotuje. Czyli możemy mieć 2 takie same modele z blendera w różnych miejscach skalach itd.
Ta macierz odpowiada wartościom z inspektora!

V – world to view
Ta macierz przesuwa wszystko tak, aby kamera była w pkt (0,0,0) i wskazywała -z. Tak więc to nie kamera się rusza, tylko cały świat naokoło.

P – view to projection
Projection matrix “ściska” nasz świat do 2 wymiarowej przestrzeni i te trójkąty są rysowane na ekranie. Można tym poruszać w osi x i y i wtedy rusza się to co jest na kamerze

wygląda ona różnie w zależności od tego czy jest to kamera ortographic czy perspecive

(Żródło: http://www.codinglabs.net/article_world_view_projection_matrix.aspx)

Ale to faktyczni dobrze działa, i pokazuje to samo (dla kamery perspetywicznej)

 

 

Test macierzy M. Kolor od skali:

fragment shader:

 

TAK!!! Wygląda na to, że faktycznie transformacje z inspektora są w tej macierzy i one odpowiadają za przesunięcie modelu!

Test 2, ciekawe czy zadziała to z położeniem!
TAAAK!!!111!!cos(0)!!

A jak wygląda nasz shader?

Zatem najpierw są rzędy a potem kolumny. Bo jak wiemy, za położenie odpowiada ostatnia trzecia kolumna.

 

No to teraz podobny teścik macierzy “V”:

 

Wygląda na to, że też to działa:

Co ciekawe, kolor obiektu zależy od tego z której kamery patrzymy. Kamera w edytorze, ma inne położenie niż game object kamery stąd różnica w kolorze.

Ciekawe, dla jakiego ustawienia kamery dostaniemy macierz jednostkową.

Sprawdźmy jak jest:


Tu jest jeszcze o tych rotacjach:

Matrix Playground Shader

Dla kamery w pkt(0,0,0) i rotacji (0,0,0) kolor jest żółty, czyli gdzieś coś się obraca. Zrobiłem shader z 9 parametrami które zerują poszczególne składowe.
Zobaczmy na które parametry zmienią kolor i tam nie będzie 1 tylko coś innego. Na podstawie tego, uda się być może ustalić z którą macierzą rotacji mamy do czynienia.
Chociaż to może nie zadziałać,  bo jeśli to będzie jakiś kąt dla którego cos lub sin wynosi zero to mi ten parametr nic nie da. Ale spróbujmy…
Nie zgadza mi się to. Wygląda na to, że w trzecim wierszu mam same zera. Ale to nie jest możliwe dla jakiejkolwiek rotacji…

Ok, ale może w zły sposób próbuję się dobrać do wartości shadera? Niby błędów nie wywala, ale spórubjemy tak:

No i oczywiście wyniki są inne. Wygląda na to, że na [2][2] mamy -1. Ale żeby dla [0][0] = 1, dla [1][1] =1 i dla [2][2] = -1 to takiego kąta ja nie widzę. Tutaj nic mi się nie zgadza. Owszem rotowanie kamery zmienia kolory, czyli faktycznie wartości macierzy “V” odpowiadają w jakiś sposób temu co jest w inspektorze. Ale jak? To pozostaje zagadką 🙂

Może być tak, że macierz V składa się z zupełnie czego innego niż TRS i może dlatego nic się nie zgadza. I tak chyba właśnie jest. Projection Matrix też wygląda zupełnie inaczej.

 

Leave a comment