Autor Wątek: Oświetlenie per pixel w teorii  (Przeczytany 5175 razy)

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 21, 2006, 16:57:47
czesc, zastanawiam sie nad oswietleniem per pixel. Chcialbym poradzic sie osob, ktore orientuja sie jak sie robi pewne rzeczy albo co jest optymalne.

Przy oswietleniu statycznym na lightmapkach doradza sie zazwyczaj pakowanie lightmapekw  jedna wieksza teksturke co owocuje potem w mniejszej ilosci wywolan zmiany tekstury. Czy tak warto robic przy oswietleniu per pixel ? Tam dynamicznie oblicza sie luminacje caly czas wiec i dynamicznie trzeba by bylo obliczac polozenie danej teksturki w tej wiekszej - co moze byc na mins co do pakowania mapek luminacji.

Wiadomo ze scena zazwyczaj sklada sie z trojkatow no ale czesto bywa ze trojkaty tworza prostokat i wowczas wyliczania dla kazdego z trojkatow tego prostokata luminacji to robienie 2 razy tego samego. Czy warto zatem (mowa o dosc skomplikowanych mapach nie takich z samych prostokatow) wyszukiwac par takich trojkatow i opowiednio realizowac obliczanie luminacji w czasie rzeczywistym ? Czy moze tez robi sie jeszcze inaczej ?

dzieki za wszelka pomoc

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 21, 2006, 17:09:06
Cytuj
Przy oswietleniu statycznym na lightmapkach doradza sie zazwyczaj pakowanie lightmapekw  jedna wieksza teksturke co owocuje potem w mniejszej ilosci wywolan zmiany tekstury.
Nie chodzi głównie o wywołania zmian tekstury, ale o to, że więcej trójkątów korzysta z tego samego zestawu tekstur, więc można je wpakować do jednego vertex buffera i renderować jako całość.

Cytuj
Czy tak warto robic przy oswietleniu per pixel ? Tam dynamicznie oblicza sie luminacje caly czas wiec i dynamicznie trzeba by bylo obliczac polozenie danej teksturki w tej wiekszej - co moze byc na mins co do pakowania mapek luminacji.
Nie wiem, co dokładnie robisz, ale wydaje mi się, że jest to coś dziwnego. :P W oświetleniu per-pixel są dwa główne podejścia:
- liczenie wszystkiego dynamicznie (np. używając tekstury 3D do zaniku oświetlenia, stencil shadow i normalmap)
- przeliczenie maski oświetlenia - podejście dokładnie takie, jak w lightmapach (światło nie może się poruszać względem obiektu), ale w masce są uwzględnione tylko cienie i zanik światła z odległością (nadal używa się tu normalmap i technik do cieni dynamicznych)

W pierwszym przypadku są używane tylko zwykłe tekstury (diffuse, normalmapa, glossmapa, itp.), więc nic nie trzeba dynamicznie obliczać na CPU. W drugim przypadku sytuacja jest podobna do tej przy używaniu lightmap. :)

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 21, 2006, 17:35:56
Krzysiek.K:
Cytuj
przeliczenie maski oświetlenia - podejście dokładnie takie, jak w lightmapach (światło nie może się poruszać względem obiektu), ale w masce są uwzględnione tylko cienie i zanik światła z odległością (nadal używa się tu normalmap i technik do cieni dynamicznych)

nie bardzo rozumiem, skoro mam na mapie cienie to dodatkowo jeszcze musze je liczyc dynamicznie ? no isprawa speculara - tutaj zawsze musze luminacje wyliczac dynamicznie

w pierwszym przypadku jaki wymieniles trzeba wg mnie dynamicznie liczyc wlasnie rozklad oswietlenia

Drugie podejscie juz probowalem zrealizowac ale jedynie dla swiatla dot3diffuse wiec nic dynamicznie faktycznie liczyc nie musialem ale jesli chcialbym uwzglednic specular to juz trzeba dynamicznie wyznaczyc zanik luminacji.

A co do tego co uwazasz za dziwne :) to chodzi mi o cos takiego: mam sobie mape, z trojkatow i wykorzystuje (zakladam) pierwsze podejscie , licze wszystko dynamicznie (glownie chodzi o luminacje) , musze luminacje przechowywac w teksturze, i jesli dwa trojkaty tworza prostokat to moge liczyc raz dla calego prostokata (wowczas nalezaloby przeszukac geometrie i wylapac takie przypadki wczesniej) albo liczyc luminacje dla kazdego trojkacika tylko ze powtorze pewna czesc obliczen. Drugie pytanie tez mnie trapi: Skoro mapki moga sie zmieniac szczegolnie speculara -za kazdym poruszeniem kamery- to czy warto meczyc sie i grupowac je zeby potem uzyc vertex array/buffer ? No i w koncu mozna jeszcze bardziej sytuacje uogolnic -nie  zalozmy ze jest swiatlo ruchome wiec nie wiadomo do konca na ktora sciane ile pada swiatle i ile takich map luminacji moze byc wiec tym bardziej robi sie skomplikowana sprawa z pakowaniem ich.
« Ostatnia zmiana: Styczeń 21, 2006, 18:21:38 wysłana przez skalniak »

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 21, 2006, 19:05:00
Ja tam się nie znam, ale wydaje mi się, że można traktować elementy geometrii mapy jako wielokąty (oczywiście zawsze płaskie, wypukłe, proste, leżące na jednej płaszczyźnie, ale mogące posiadać dowolną liczbę wierzchołków), a nie tylko same trójkąty.

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 21, 2006, 20:20:24
Regedit: tez uwazam ze mozna i ze to naprawde poprawi wydajnosc . Watpie jednak w wydajnosc przy pakowaniu mapek dla wielu trojkatow nie bedacych na jednej plaszczyznie,  bo sprawa wg mnie wyglada tak:
+ fakt ze bede mugl uzyc vertex array
- zeby tak dynamicznie zmieniac fragmenty tekstury trzeba duzo obliczen dodatkowych zwiazanych z tym gdzie w wiekszej teksturze znajduje sie konkretna mapka odpowiadajaca jakiemus tam trokatowi

chcialbym poznac rozne zdania i argumenty.

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 21, 2006, 22:46:47
Cytuj
nie bardzo rozumiem, skoro mam na mapie cienie to dodatkowo jeszcze musze je liczyc dynamicznie ?
Masz na mapie cienie, ale tylko statyczne. Nadal musisz uwzględnić cień poruszających się obiektów.

Cytuj
no isprawa speculara - tutaj zawsze musze luminacje wyliczac dynamicznie
Przy specularze dynamicznie wyznaczasz tylko odbicie ( N dot H ). Takie rzeczy, jak cienie i zanik światła wraz z odległością możesz nadal trzymać na statycznej teksturze nawet dla speculara. :)

Cytuj
Drugie podejscie juz probowalem zrealizowac ale jedynie dla swiatla dot3diffuse wiec nic dynamicznie faktycznie liczyc nie musialem ale jesli chcialbym uwzglednic specular to juz trzeba dynamicznie wyznaczyc zanik luminacji.
Jak już napisałem, nie trzeba.
- na teksturze masz przeliczony zanik światła i cienie (podobnie jak w lightmapach, tyle że nie uwzględniasz kierunku światła i normalnej oświatlanej powierzchni)
- vertex shader wyznacza wektory L i H
- pixel shader pobiera normalną z normalmapy, normalizuje L i H oraz wyznacza: ((L dot N)*diffuse + (H dot N)^exp*specular)*maska


Do normalizacji można wykorzystać cubemap'y, a resztę operacji da się zrobić w kilku przebiegach nawet bez wykorzystania pixel shaderów.


Cytuj
licze wszystko dynamicznie (glownie chodzi o luminacje) , musze luminacje przechowywac w teksturze,
Błąd. Na teksturze przechowujesz maskę światła, czyli część równania, która się nie zmienia. Zmienianie czegokolwiek na teksturze podczas renderowania jest zwykle bardzo złym pomysłem.

Cytuj
Skoro mapki moga sie zmieniac szczegolnie speculara -za kazdym poruszeniem kamery- to czy warto meczyc sie i grupowac je zeby potem uzyc vertex array/buffer ?
Renderer powinien być napisany tak, żeby nie musiał nic zmieniać na teksturze. Są od tego wyjątki, gdzie renderowanie do tekstury jest częścią zastosowanej metody (np. shadow volume), ale w Twoim przypadku da się to zrobić lepiej bez zmieniania czegokolwiek na teksturach.

Cytuj
No i w koncu mozna jeszcze bardziej sytuacje uogolnic -nie  zalozmy ze jest swiatlo ruchome wiec nie wiadomo do konca na ktora sciane ile pada swiatle i ile takich map luminacji moze byc wiec tym bardziej robi sie skomplikowana sprawa z pakowaniem ich.
Przy światłach ruchomych nie stosuje się zwykle masek/lightmap wogóle. Do wyznaczania zaniku światła stosuje się tekstury 3D (niestety GeForce 2 tego nie obsługuje), albo odpowiednie połączenie tekstury 2D i 1D. Do wyznaczania cieni stosuje się techniki dynamiczne (nawet, jeżeli geometria sama z siebie się nie porusza, to porusza się ona teraz względem światła). Pozatym, jak zwykle, stosuje się normalmapy do wyznaczania rozpraszania się światła odbijanego od powierzchni (diffuse+specular).

Cytuj
- zeby tak dynamicznie zmieniac fragmenty tekstury trzeba duzo obliczen dodatkowych zwiazanych z tym gdzie w wiekszej teksturze znajduje sie konkretna mapka odpowiadajaca jakiemus tam trokatowi
Jak już pisałem, dynamiczne zmienianie fragmentów tekstury wydaje mi się kiepskim pomysłem.

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 21, 2006, 23:16:05
Cytat: Krzysiek K.
Przy specularze dynamicznie wyznaczasz tylko odbicie ( N dot H ). Takie rzeczy, jak cienie i zanik światła wraz z odległością możesz nadal trzymać na statycznej teksturze nawet dla speculara. :)

Skoro nie musze liczyc dla statycznych swiatel map zawierajacych interpolacje
N dot3 H to co mam w tej statycznej teksturce dla speculara ? ( bo ja myslalem ze musze ja liczyc dynamicznie). Napisales ze mam zanik swiatla ale  zgodny z N dot3 H  -nie wiem za bardzo bo chyba nie czuje idei

Cytat: Krzysiek K.
- pixel shader pobiera normalną z normalmapy, normalizuje L i H oraz wyznacza: ((L dot N)*diffuse + (H dot N)^exp*specular)*maska
Tutaj tez mam pytanie :) zbuzyles moje wyobrazenie o specularze :P . Dla jakiego punktu zatem licze H dot3 N jesli nie licze tego dla roznych punktow sciany?

Cytat: Krzysiek K.
Przy światłach ruchomych nie stosuje się zwykle masek/lightmap wogóle. Do wyznaczania zaniku światła stosuje się tekstury 3D (niestety GeForce 2 tego nie obsługuje)

Ale obsluguje cube mape.


Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 22, 2006, 01:25:06
Cytuj
co mam w tej statycznej teksturce dla speculara ?
Trochę fizyki. Promień światła leci od źródła światła do kamery i przeszkodzić mu mogą następujące rzeczy:
1. Jakiś obiekt po drodze (powstaje cień).
2. To, że oświetlany obiekt jest daleko (zanik światła wraz z odległością).
3. To, że promień słabo odbija się w kierunku kamery (diffuse i specular).

Pierwsze dwa elementy są niezależne od położenia kamery i tego, co właściwie dzieje się ze światłem po dotarciu do oświetlanej powierzchni (diffuse/specular), więc intensywność światła w danym punkcie można zapisać na teksturze.

Cytuj
Dla jakiego punktu zatem licze H dot3 N jesli nie licze tego dla roznych punktow sciany?
Liczysz to dla różnych punktów sciany. Dlatego napisałem, że tą operację robi pixel shader.

Cytuj
Ale obsluguje cube mape.
Cubemapy są mało przydatne, jeżeli chodzi o tworzenie map zaniku (co nie znaczy, że cubemapy są niepotrzebne).

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 22, 2006, 13:51:40
Cytat: Krzysiek K.
Trochę fizyki. Promień światła leci od źródła światła do kamery i przeszkodzić mu mogą następujące rzeczy:
1. Jakiś obiekt po drodze (powstaje cień).
2. To, że oświetlany obiekt jest daleko (zanik światła wraz z odległością).
3. To, że promień słabo odbija się w kierunku kamery (diffuse i specular).
Kumam i czec juz zrealizowalem. Co do tego watku to pojawil sie kolejny problem a mianowicie z tym specularem w ktorym cos nie tak rozumiem chyba.

Cytat: Krzysiek K.
Liczysz to dla różnych punktów sciany. Dlatego napisałem, że tą operację robi pixel shader.
Wlasnie chcialbym to zrobic bez pixel shader na poczatek.
Wydaje mi sie ze mamy roznice w notacji.
czy niejest tak ze ta maska ze wzoru:
  ((L dot N)*diffuse + (H dot N)^exp*specular)*maska 
to jest gloss map ?

W tej chwili zrealizowane mam
(L dot N)*diffuse w tym podejsciu z mapkami, ale specular tez ma zanik swiatla (punkt2) wiec musze trzymac ten zanik czyli rozklad N dot H per pixel w teksturce.
(wiem ze bez pixel shader obliczenie tego bedzie dlugotrwale ale moze zmniejsze rozmiary tej teksturki..cos kosztem czegos)

Cytuj
Ale obsluguje cube mape.
Cubemapy są mało przydatne, jeżeli chodzi o tworzenie map zaniku (co nie znaczy, że cubemapy są niepotrzebne).
Cytuj

Wiec jak w takim razie jak nie przy pomocy cube map zrobic zanik na GF 2 Mx ? :) To chyba jedyne rozwiazanie

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 22, 2006, 14:27:09
Cytuj
Wlasnie chcialbym to zrobic bez pixel shader na poczatek.
Bez pixel shader albo zabawy z mieszaniem tekstur i kilkoma przebiegami się nie da.

Cytuj
Wydaje mi sie ze mamy roznice w notacji.
czy niejest tak ze ta maska ze wzoru:
  ((L dot N)*diffuse + (H dot N)^exp*specular)*maska
to jest gloss map ?
Gloss map u mnie jest nazwany "specular". Maska to coś w stylu lightmapy dla pojedynczego źródła światła - zapisane są tam cienie i zanik światła z odległością (i nic więcej).

Cytuj
(L dot N)*diffuse w tym podejsciu z mapkami, ale specular tez ma zanik swiatla (punkt2) wiec musze trzymac ten zanik czyli rozklad N dot H per pixel w teksturce.
(N dot H) to nie jest zanik światła. Zanik światła to 1/distance^2 (ew. podobna funkcja zmniejszająca się wraz z odległością).
(N dot H) możesz wyznaczyć per-pixel używając normalmapy dla N i cubemapy dla H.

Cytuj
Wiec jak w takim razie jak nie przy pomocy cube map zrobic zanik na GF 2 Mx ?
Dla świateł statycznych możesz po prostu trzymać zanik razem z cieniami w maskach. Dla świateł dynamicznych można złożyć dwie tekstury następująco:
Przyjmujemy funkcję zaniku: attn = 1-dist^2

attn = 1-dist^2 = 1-sqrt(x^2+y^2+z^2)^2 = 1-x^2-y^2-z^2 = (1-x^2-y^2) - (z^2)
W ten sposób z funkcji f(x,y,z), którą zapisuje się na teksturze 3D zrobiliśmy dwie funkcje f(x,y) i g(z), które można zapisać na teksturach 2D i 1D i złożyć już podczas renderowania.

Offline skalniak

  • Użytkownik
    • Home page

# Styczeń 22, 2006, 14:55:30
Cytat: Krzysiek K.
Bez pixel shader albo zabawy z mieszaniem tekstur i kilkoma przebiegami się nie da.

Chce to wykonac na register combiners najpier a w przyszlosci mam zamiar sprobowac na pixel shader.

Cytat: Krzysiek K.
Gloss map u mnie jest nazwany "specular". Maska to coś w stylu lightmapy dla pojedynczego źródła światła - zapisane są tam cienie i zanik światła z odległością (i nic więcej).
rozumiem, tylko wydawalo mi sie ze ta maska jest potrzebna jedynie do diffuse a Ty mnozysz N dot H jeszcze przez rozklad luminacji  -  czemu tak ?.

Cytat: Krzysiek K.
(N dot H) to nie jest zanik światła. Zanik światła to 1/distance^2 (ew. podobna funkcja zmniejszająca się wraz z odległością).
(N dot H) możesz wyznaczyć per-pixel używając normalmapy dla N i cubemapy dla H.

Racja, zle napisalem , na mysli mialem rozklad N dot H.

Cytat: Krzysiek K.
Dla świateł statycznych możesz po prostu trzymać zanik razem z cieniami w maskach.
Gdy mam swiatla statyczne to moge w maskach trzymac zanik (diffuse), ale
specular musialbym caly czas liczyc (czyli cube mapa).

Cytat: Krzysiek K.
attn = 1-dist^2 = 1-sqrt(x^2+y^2+z^2)^2 = 1-x^2-y^2-z^2 = (1-x^2-y^2) - (z^2)

W ten sposób z funkcji f(x,y,z), którą zapisuje się na teksturze 3D zrobiliśmy dwie funkcje f(x,y) i g(z), które można zapisać na teksturach 2D i 1D i złożyć już podczas renderowania.

 2 przebiegi wchodza w gre ?
« Ostatnia zmiana: Styczeń 22, 2006, 15:03:21 wysłana przez skalniak »

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 22, 2006, 15:35:46
Cytuj
Gdy mam swiatla statyczne to moge w maskach trzymac zanik (diffuse), ale
specular musialbym caly czas liczyc (czyli cube mapa).
Nie musiałbyś, jak to już pisałem powyżej ze dwa razy. Odezwij się do mnie na gg, to będzie mi na pewno łatwiej to wytłumaczyć, niż tu na forum. :)

Cytuj
2 przebiegi wchodza w gre ?
Tak, albo nawet więcej (Doom 3 na przykład wymagał czasem nawet 5 przebiegów do wyrenderowania jednego światła). :)

Offline Spider100

  • Użytkownik
    • Strona domowa

# Styczeń 22, 2006, 18:52:26
Witam !

No to czas napisać pierwszego posta :D   

skalniak: Na początek google ma dużo do zaoferowania

świetny artykuł znajdziesz tutaj:
http://www.ronfrazier.net/apparition/index.asp?appmain=research/advanced_per_pixel_lighting.html

Jeszcze proponuje przeanalizować ten kod (delphi, ale myślę że nie powinno sprawić problemów)
http://www.delphi3d.net/download/tangentbump.zip

Dodam jeszcze że dynamiczne oświetlenie z dot3 i specularem na gf2 to strata cennego czasu programisty. Zdecydowanie lepiej w pierwszym przebiegu renderować lightmapę w drugim mape zasięgu dla wszystkich świateł, a w trzecim diffuse daje to gorsze efekty, ale działa szybciej i przy trzech światłach można jeszcze jakoś grać :D

Krzysiek K. W jakie dni jesteś na gg? bo jeszcze nigdy nie trafiłem :D

Pozdrawiam!
Spider ^*^

Offline Krzysiek K.

  • Moderator
    • DevKK.net

# Styczeń 22, 2006, 20:20:55
Cytuj
Krzysiek K. W jakie dni jesteś na gg? bo jeszcze nigdy nie trafiłem
Codziennie po kilka(naście) godzin (na przykład w tej chwili, ale właśnie wychodzę). Musiałeś mocno kombinować, żeby mnie nie zastać. :)

Offline Spider100

  • Użytkownik
    • Strona domowa

# Styczeń 22, 2006, 21:24:35
Cytuj
Codziennie po kilka(naście) godzin (na przykład w tej chwili, ale właśnie wychodzę). Musiałeś mocno kombinować, żeby mnie nie zastać.

No to nie wiem co jest (może nie mam zasięgu, albo potrzebny 0 kierunkowy lol joke) bo celowałem o różnych porach kilka razy. Albo dostałem po prostu błędny numer. Jedno jest pewne ten co dostałem nie ma żadnych danych w katalogu i jest ciągle niewidoczny :)

Sorqa za offtopa :D