Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - bartekm

Strony: 1 2 3 4 [5] 6 7 8 9 ... 15
61
OpenGL / Odp: Deferred Shading kilka świateł
« dnia: Styczeń 08, 2012, 19:11:36 »
Nie za bardzo. W przypadku światła punktowego rysujesz sferę 3D, zamiast fullscreen quada. Ta sfera musi mieć takie same parametry (położenie i promień) jak światło. Kiedy będziesz liczył światło punktowe w Fragment shaderze, oprócz położeń wierzchołków potrzebujesz jeszcze współrzędnych TexCoordów, które liczy się tak jak w tutorialu, który ci podałem w linku:
input.ScreenPosition.xy /= input.ScreenPosition.w;   // input.ScreenPosition -
vec2 texCoord = 0.5f * (vec2(input.ScreenPosition.x,-input.ScreenPosition.y) + 1);
Czyli będzie coś takiego:
// Przebieg światła

LightRenderTarget->start(); //Rozpoczyna render do textury FBO.
   UstawShaderDlaSwiatlaKierunkowego();
   
   pętla po wszystkich światłach kierunkowych
   {
        PrzeslijInformacjeOSwietleDoShadera();
        DrawFullscreenQuad();
   }

   UstawShaderDlaSwiatlaPunktowego();
   
   pętla po wszystkich światłach punktowych
   {
        PrzeslijInformacjeOSwietleDoShadera();
        DrawSphere(SpherePositon = LightPosition, SphereRadius = LightRadius);
   }
LightRenderTarget->stop(); //Kończy render do textury FBO.
Analogicznie dla światła typu spot, tylko rysujesz stożek zamiast sfery

62
DirectX / Odp: [dx11] Problem z plikiem .fx
« dnia: Styczeń 07, 2012, 17:32:48 »
Zobacz co ci pokazuje Debugger, ale na moje oko tutaj masz źle:
cbuffer MatrixBuffer
{
        matrix worldMatrix : register(b0);
        matrix viewMatrix : register(b1);
        matrix projectionMatrix : register(b2);
};
 
cbuffer LightBuffer
{
        float4 diffuse;
        float3 lightDirection;
        float padding;
};
Powinno być raczej:
cbuffer MatrixBuffer : register(b0)
{
        matrix worldMatrix;
        matrix viewMatrix;
        matrix projectionMatrix;
};
 
cbuffer LightBuffer : register(b1)
{
        float4 diffuse;
        float3 lightDirection;
        float padding;
};
A przy podpinaniu CB:
bufferNumber = 0;
deviceContext->PSSetConstantBuffers(bufferNumber, 1, &m_lightBuffer);
powinno bufferNumber = 1. Poza tym tak jak wcześniej ci doradzali, lepiej olać Effect i pisać w czystych shaderach.

63
OpenGL / Odp: Deferred Shading kilka świateł
« dnia: Styczeń 07, 2012, 17:05:31 »
Kanał alpha raczej nie ma znaczenia, chyba że chcesz tam przekazać jakąś informację, którą wykorzystasz w efektach post-process. Ale ja nie spotkałem się, żeby wykorzystywać ten kanał do czegokolwiek. Skoro deferred już ci działa to super, teraz spróbuj napisać to samo dla świateł punktowych i kierunkowych. Robi się to tak samo, tylko zamiast full screen quada rysuje się sferę dla światła punktowego i stożek dla światła typu spot. Zobacz np. tutaj: http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/point-lights/.

64
OpenGL / Odp: Deferred Shading kilka świateł
« dnia: Styczeń 07, 2012, 16:15:13 »
Jeśli rysujesz światło kierunkowe to niepotrzebna ci pozycja. Poza tym źle rysujesz te światła. Pseudokod:
//Przebieg geometrii

m_multipleRenderTarget->start(); //Rozpoczyna render do textury FBO.
pętla po wszystkich obiektach
m_multipleRenderTarget->stop(); //Kończy render do textury FBO.

UstawBlendingAddytywny();

LightRenderTarget->start(); //Rozpoczyna render do textury FBO.
   UstawShaderDlaSwiatlaKierunkowego();
   
   pętla po wszystkich światłach kierunkowych
   {
        PrzeslijInformacjeOSwietleDoShadera();
        DrawFullscreenQuad();
   }
LightRenderTarget->stop(); //Kończy render do textury FBO.
A właściwości każdego światła (kierunek, kolor, intensywność itp) przekazujesz przez uniformy.

65
OpenGL / Odp: Deferred Shading kilka świateł
« dnia: Styczeń 07, 2012, 15:38:26 »
Deferred składa się z dwóch etapów: etap geometrii w którym wypełniasz G-Buffor potrzebnymi informacjami takimi jak: albedo, normalne, specular itp. i etap światła w którym kolorujesz scenę światłami korzystając z poprzednio wygenerowanego G-Bufora. W tym tutorialu jest podany tylko jak zrobić etap geometrii, który powinien wyglądać tak (punkt 2):
m_multipleRenderTarget->start(); //Rozpoczyna render do textury FBO.
pętla po wszystkich obiektach
m_multipleRenderTarget->stop(); //Kończy render do textury FBO.
Potem w podpunkcie 3 masz napisane, że żeby oświetlić scenę musisz narysować fullscreen quada z odpowiednim vertex i fragment shaderem do osobnego render targetu nazywanego zazwyczaj Light Accumulation Buffer (etap światła). Wszystkie świała rysujesz do tego render targetu, a w tutku jest tylko jedno światło kierunkowe. Gdybyś chciał dodać drugie światło kierunkowe rysujesz drugiego fullscreen quada itd. Pamiętaj o ustawienia blendingu addytywnego, w tutorialu chyba o nim nie wspomnieli.

66
Szkółka / Odp: [Algorytmy] Podzielność współczynników dwumianowych
« dnia: Styczeń 06, 2012, 22:55:58 »
Na przykład niech (n k) = (6 3) = 20, m = 8. Czynniki pierwsze m = {2, 2, 2}. Wszystkie czynniki dzielą się bez reszty: 20/2 = 10, 20/2 = 10, 20/2 = 10, a liczba "m" się nie dzieli, bo (6 3)/8 = 20/8 = 2,5.

67
DirectX / Odp: DirectX9 10 i 11 jak to z tym jest
« dnia: Styczeń 05, 2012, 11:53:40 »
DX11 jednak trochę różni się od DX10. Przede wszystkim w 11 nie ma tych wszystkich wspomagaczy typu obsługa fontów, meshy czy funkcji matematycznych, pozostał jedynie sam renderer. Niektóre funkcje są też w innym miejscu niż w przypadku DX10. Ale prawda jest taka, że bardzo wiele rzeczy jest podobnych (różnią się jedynie nazewnictwem funkcji i zmiennych - ID3D11 zamiast ID3D10).

68
DirectX / Odp: Deferred shading
« dnia: Grudzień 25, 2011, 13:37:56 »
Cytuj
Ogranicza liczbę do zakresu [0, 1], powinno być bez saturate, myślałem żeby distance() sprowadzić do tego zakresu i mnożyć przez kolor.
To nie distance ma być z zakresu [0, 1] tylko attenuation. Distance musi być z zakresu [0, R]. Gdybyś napisał tak:
Att = saturate(1.0f - distance()/R)byłoby ok.
Cytuj
Ale dobra wracając do problemu, teraz patrzę na ten kod shadera i to wygląda sensownie. Zrobiłem sobie model kuli w maxie wyeksportowałem do .x, ten o to model rysuję zamiast światła i trochę się zdziwiłem bo zamiast niebieskiej kuli zobaczyłem czarną kulę, jej kolor się nie zmienia nie reaguje na parametry koloru, wcześniej rysowałem kule tworzoną przez D3DXCreateSphere...
Trudno powiedzieć co może być źle nie pokazując kodu. Najlepiej pokaż cały PS odpowiadający za światło punktowe.

69
DirectX / Odp: Deferred shading
« dnia: Grudzień 25, 2011, 12:07:57 »
Na tej kuli powinien łagodnie rozejść się niebieski kolor, w moim wypadku jest on jednolity, ale się rysuje więc błędu trzeba szukać w shaderze
A pomnożyłeś końcowy wynik przez "attenuation"?
pierwsza rzecz która mnie trochę dziwi to po co odejmować od texcoodra wartość halfpxel ?
(...) Po co to ?
Chodzi zapewne o to, że texele w stosunku do pikseli są przesunięte o odległość pół pixela.
http://msdn.microsoft.com/en-us/library/bb219690(VS.85).aspx. Ta linijka koryguje ten offset, żeby na każdy teksel quada przypadał dokładnie każdy pixel. To jest problem, który występuje w DX9, ale w DX10 został już usunięty.
Normal ma długość równą 1 po co dodawać do niego 1.0f i dzielić go na połowę ?
Chodzi o to, że GBufor do którego zapisujesz normalne ma format unsigned (tak przynajmniej zakładam), czyli nie można zapisać do niego ujemnych wartości. Normalne jak wiesz mają współrzędne w zakresie od [-1, 1] i gdybyś je tak zapisał do GBufora to stracił byś informacje o znaku. Dlatego transformuje je się do postaci [0, 1], a potem przy odczycie (np. liczeniu światła) "rozpakowuje" je się z powrotem do przedziału [-1, 1].
Trzeba teraz obliczyć rozproszenie światła wraz z jego odległością, w tutorialu odpowiada za to linijka:
float attenuation = saturate(1.0f - length(lightVector)/lightRadius);
Nie rozumiem jak długość wektora dzielony przez promień światła ma się do współczynnika rozproszenia światła.
Attenuation to nic innego jak funkcja zanikania światła zależnie od odległości. length(LightVector) to nic innego jak odległość centrum światła od pozycji wierzchołka, czyli powyższa funkcja to liniowa zależność w postaci A(r) = 1 - r/R. W środku światło świeci najmocniej więc A(r) = 1. Dla brzegu i poza nim A(R) = 0. Tak naprawdę to tylko model, bo ta funkcja może przybierać różne postacie np. A(r) = 1/(a0 + a1*r + a2*r^2) albo bardziej zgodne z fizyką A(r) = exp(-a*r). Ja u siebie stosuje A(r) = (1 - r/R)^1.3.
Myślałem żeby liczyć z:
saturate(distance(pos, lightpos));
Funkcja distance u ciebie to jest to samo co length(lightVector). Poza tym twój wzór jest bezsensu (zobacz co robi funkcja saturate).
No ale widoczniej lepiej to obliczyć z tej pierwszej "funkcji", tylko teraz przeanalizujmy dlaczego, "funkcja" ta przyjmuje lightVector i promień światła, lightVector....
Promień światła jako parametr jest potrzebny, żeby zapewnić, że dla jakiegoś r>R światło zniknie. W deferredzie światło punktowe, jeśli jest rysowane przy pomocy sfery, musi mieć zapewnione, że dla jakiejś odległości (np. którą z góry zakładamy przy pomocy promienia światła R) będzie równe 0. Dlatego funkcja attenutation musi być w takiej postaci, żeby A(0) = 1, A(R) = 0.

70
DirectX / Odp: Deferred shading
« dnia: Grudzień 22, 2011, 10:37:31 »
Może nie ustawiłeś blendingu addytywnego (BlendOp = Add)?

71
Szkółka / Odp: [Algorytmy] Podzielność współczynników dwumianowych
« dnia: Grudzień 20, 2011, 19:10:31 »
Wydaje mi się, że ten rozkład na czynniki pierwsze może być złym testem. Na przykład niech "m" ma cztery czynniki pierwsze p1, p2, p3, p4. Wtedy (n k)/m = (n k)/(p1*p2*p3*p4). Niech faktycznie wszystkie czynniki dzielą się bez reszty i niech (n k)/p1 = C1. Wtedy otrzymasz (n k)/m = C1/(p2*p3*p4). Czyli (n k)/m dzieli się bez reszty jeśli C1 dzieli się bez reszty z p2, p3 lub p4 (lub matematycznie (n k) mod m = 0 <=> C1 mod p2 = 0 v C1 mod p3 = 0 v C1 mod p4 = 0). A tego nie wiesz i nie jesteś w stanie tego określić z testu dla wszystkich czynników. Mam nadzieje, że nie zamotałem. Najlepiej popytaj kogoś na forum o matematyce, tam siedzą mózgi zdolne do rozwiązywania takich zadań, gdy już będziesz chciał zakodzić to przyjdź tutaj:)

72
Szkółka / Odp: [Algorytmy] Podzielność współczynników dwumianowych
« dnia: Grudzień 17, 2011, 19:03:56 »
Najpierw myślałem, żeby po prostu policzyć (n po k), podzielić przez m i sprawdzić resztę, ale kiedy zobaczyłem w jakim przedziale to jest sprawdzane (10^9) to wymiękłem. Ja bym to zrobił tak. Wiesz jak sprawdzić warunek dla liczby pierwszej p (z tw. Lucasa). Rozłóż liczbę "m" na czynniki pierwsze p1, p2, p3, ..., pn i sprawdzaj dla każdego czynnika czy dzieli się przez reszty. Jeśli (n po k) dzieli się bez reszty dla wszystkich czynników pierwszych liczby "m" to (n po k) przez "m" dzieli się bez reszty (przynajmniej tak mi się wydaje).

73
Szkółka / Odp: C++ operacje na dużych liczbach.
« dnia: Grudzień 02, 2011, 00:36:26 »
Duże liczby tzn. większe niż 2^64 zapisuje się w postaci kodu BCD (binary coded-decimal). Polega to na tym, że do zapisu jednej cyfry 0,1, ... lub 9 stosuje się 4-bitową postać binarną (w przypadku tzw packed BCD czyli wersji spakowanej) lub 8 bit w zwykłej. Czyli np. masz liczbę dziesiętną 25. W zapisie BCD ta liczba ma postać 0010 0101, bo 2 ma postać 0010 i 5 ma postać 0101, stąd (DEC)25 = BCD(0010 0101). Warto pamiętać też, że zapis BCD to nie jest zapis binarny liczby, bo wtedy wyglądała by tak BIN(0001 1001). Dodawanie, odejmowanie, mnożenie itp takich liczb przebiega trochę inaczej. Poszukaj na googlach jest dużo materiału o tym nawet w języku polskim. Takie liczby jak sam zauważyłeś przechowuje się w tablicach. Jako, że najmniejszy możliwy typ liczby całkowitej char ma 8-bit, to w jednej komórce można maksymalnie przechować 8bit/4bit = 2 liczby, dzięki temu oszczędza się na pamięci. Zapis BCD pozwala ci na operowanie na tak wielkich liczbach, jakie jest w stanie pomieścić twoja pamięć RAM.

74
Szkółka / Odp: OpenGL 2.x vs 3.x
« dnia: Listopad 30, 2011, 22:21:36 »
Jeśli chcesz, żeby działało u każdego musiałbyś pisać pewnie pod wersję OGL 1.5. Z czasem procent użytkowników z kartą OpenGL 3.x będzię rósł, a OpenGL 2.x będzie malał, więc bardziej przyszłościowo będzie uczyć się nowszej wersji. Jeśli twoim kryterium jest żeby twoja gra dotarła do jak największej liczby odbiorców to bierz się za wersję 2.x. Tylko czy dla kilku - kilkunastu procent odbiorców warto pozbawiać się tych wszystkich ulepszeń, które daje OGL w wersji 3.x.

75
Szkółka / Odp: OpenGL 2.x vs 3.x
« dnia: Listopad 30, 2011, 21:39:17 »
Zgodnie ze statystykami Steama, sprzęt OpenGL 3.x Ready posiada około 80% użytkowników, więc możesz spokojnie uczyć się wersji 3.2/3.3, jeżeli twoja karta taką obsługuje.

Strony: 1 2 3 4 [5] 6 7 8 9 ... 15