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 - 0x464152434941525A5E5E

Strony: [1]
1
DirectX / Odp: LOD mesha oparty na różnych IB
« dnia: Styczeń 26, 2013, 16:09:20 »
W sumie ciekawa koncepcja, czyli rozumiem, że teraz podczas Draw() proporcjonalnie(kwadratowo) zmniejszam ilość prymitywów + przemnażam to razy LOD w VS

Ok dzięki za pomoc

2
DirectX / Odp: LOD mesha oparty na różnych IB
« dnia: Styczeń 26, 2013, 12:11:43 »
Przede wszystkim zrobienie nowego VB nie będzie bardzo szkodziło. W przypadku tekstur każdy LOD (mipmapa) ma kompletnie własną kopię danych zredukowaną do 1/4 i wszystkie poziomy w sumie zajmują mniej niż 1/3 oryginalnej tekstury (hint: suma szeregu geometrycznego).
W sumie racja.

Za to używając starego VB nie będziesz mógł zoptymalizować VB i IB jako pary. W efekcie cache będzie zaciągał wiele niepotrzebnych danych (sąsiednie wierzchołki w tej samej linii cache). Czy to będzie miało znaczenie? Ciężko powiedzieć.
Aha, ale co masz na myśli poprzez optymalizację VB +IB "w parę" - mówisz o jakimś połączeniu/związaniu ich w DX3D(o czym nie wiem)? Bo ja do tej pory po prostu wołałem setIndexBuffer/setVertexBuffers dla każdego mesha i już...


Właściwie pisząc mesha, to konkretnie chodziło mi o grid siatki terenu (aczkolwiek byłem generalnie ciekaw jak to będzie odnosiło się ogólnie), (np. LOD0: 128x128, LOD1: 64x64, itd.), więc będzie to dokładnie tak jak z LOD tekstury - chcę wygenerować te kilka poziomów LOD, każda siatka jest w coordynatach x,y:(-1,1), tyle, że z 2x mniejszymi rozdzielczościami, wysokości będę samplował z heightmapy dostarczonej do VS jako tekstura, tak to się chyba teraz robi ( teren z heightmapy na GPU?) + transfomracja grida w określone miejsce świata. Na morphing połączenia różnych LOD też mam pomysł.

3
DirectX / LOD mesha oparty na różnych IB
« dnia: Styczeń 25, 2013, 22:18:30 »
Witam,

Zastanawia mnie pewna kwestia związana z wydajnością renderingu mesha z różnym poziomem LOD z zastosowaniem kilku wersji index bufferów.

Otóż załóżmy, że mam sytuację, mam 1 spory vertex buffer z wszystkimi wierzchołkami.
Do tego powiedzmy, że generuję kilka wersji index bufferów (dla tego VB) - ale każdy dla różnego poziomu LOD mesha, tak że każdy kolejny IB poziom będzie używał znacznie mniej wierzchołków.

Najczęściej będą renderowane najniższe poziomy LOD (IB z najmniejszą ilością prymitywów), a więc pytanie, czy i jak duży będzie spadek wydajności z tego tytułu, że dla małego(najniższych LOD) index buffera, będzie ustawiany ten duży VB, w którym de facto większość wierzchołków nie będzie używanych (90%)?
Czy jednak opłaca się dla każdej wersji IB robić oddzielną wersję VB, w której będą tylko te wierzchołki, z których w pełni korzysta?
Innymi słowy, czy wielkość VB(poziom jego wykorzystania) będzie miał wpływ na szybkość?

Mam nadzieję, że przedstawiłem wszystko zrozumiale, jakby co pisać.

4
Tworzenie silników / Odp: Silnik graficzny-podstawy
« dnia: Styczeń 04, 2013, 19:07:53 »
O silniku 3d czy renderze (zwał jak zwał) trzeba by myśleć tak: to twór, który ma maksymalnie uprościć rendering grafiki, dzięki któremu żeby cokolwiek narysować - nie musisz ręcznie wołać 20 różnych metod/funkcji API graficznego, żeby ustawić cały potok i inne rzeczy na GPU, a wywołać 1 czy 2 proste metody silnika, który tym wszystkim się będzie zajmował automatycznie...

Taką nakładkę na API graficzne już można by nazwać renderem/silnikem.
Poza tym render może, zajmować się jeszcze innymi zadaniami, które mają związek z renderingiem grafiki:
- frustum culling (pewnie najważniejsza optymalizacja w renderingu 3d)
- może jakiś LoD meshy (czyli znowu optymalizacje)
- grafem sceny (czyli definiujesz sobie przekształcenia jednych obiektów względem drugich)
- i inne...

5
C++ / Odp: Wyciek pamieci :)
« dnia: Grudzień 20, 2012, 15:25:09 »
To są jakieś standardowe alokacje stdlib, pewnie jakiś globalnych obiektów, albo hu wie czego...

zamiast wołać CrtDumpMemoryLeaks() zanim destruktory to zwolnią, ustaw flagę, która rzuca dump przy kończeniu procesu, bo wtedy będą już zwolnione

powinno pomóc

6
DirectX / Odp: Implementacja muliline EditBoxa na bazie CDXUTEditBox
« dnia: Grudzień 20, 2012, 15:17:36 »
na początek zamiast wstawiania '\n' spróbuj "\r'\n"

7
Windows / Odp: co na deactivate?
« dnia: Grudzień 17, 2012, 18:34:32 »
Chyba najprościej wziąć przykład z MessageBox'a. Bo niby jak on działa? otóż odpala sobie wewnętrznego message loopa, co daje efekt złudzenia, że wykonanie programu się na MessageBoxie zatrzymało, tym czasem nasz app cały czas przetwarza sobie eventy :>, co prawda tylko idące do okienka message boxa

Tym sposobem można napisać sobie pauzę ala message box, która "stopuje wykonanie kodu" w naszym przypadku kodu ramki.

Dodatkowo skoro to gra, najpewniej mierzony jest czas, z tego powodu trzeba też zmierzyć "czas trwania pauzy", żeby odjąć ją od czasu ramki

// taki pseudo kod, pauzy ala mesage box
// oczywiście wszystko w dużym uproszczeniu :>

time make_pause()
{
  begin_time = get_time(); // czas początku pauzy
 
  MSG msg;
  while(GetMessage(...))
  {
    if(WM_UNPAUSE) break; // trzeba sobie zrobić jakiś event unpausujący, najlepiej jakiś WM_COMMAND
    .. translate + dispatch
  }
 
  end_time = get_time(); // czas końca pauzy
  return end_time - begin; // no i czas pauzy na zewnątrz
}


// pause contoling
void pause()
{
  PostThreadMessage(niezapausowany thread, WM_PAUSE, 0, 0);
}

void unpause()
{
  PostThreadMessage(zapausowany thread, WM_UNPAUSE, 0, 0);
}



// przykład użycia, czyli message loop w grze
time pause_time = 0; // ewentualny czas pausy, który trzeba uwzględniać w ramce
for(;;)
{
  if(PeekMessage(...))
  {
    if(msg.message == WM_QUIT) break;
   
    if(msg.message == WM_PAUSE) pause_time += make_pause(); // pauzujemy
   
    translate + dispatch
  }
  else
  {
     onFrame(pause_time); // przekazujemy pause time do ramki, oczywiście prawie zawsze tu będzie 0 :>
     pause_time = 0;
  }
}

I jeszcze jedna rzecz, trzeba obsłużyć możliwość wystąpienia WM_QUIT poczas pauzy, czyli gdy trafi do loopa pauzy, w tym wypadku może jednak w make_pauze lepeij zwracać czy czasem nie wystąpił WM_QUIT i w takim przypadku kończyć także main loopa, a pause time zwracać/zwiększać przez parametr



"Dopóki GetMessage nie dostanie eventa o wyciągnięciu okna na wierzch, to leci nieskończona pętla while."
?!?! bardzo wątpię, aby leciała jakaś pętla

co prawda nie znam kodu GeMessage, ale gdybym jak pisał GetMessage w przypadku gdy w kolejce nie ma już eventów (lub od razu nie ma, czyli już po pierwszym sprawdzeniu), oddał bym kontekst wykonania następnemu wątkowi/procesowi, na pewno w systemie są inne wątki, które chcą coś wykonywać, a jakiekolwiek oczekiwanie bezsensownymi pętlami i sprawdzanie "w kółko czy jest jakiś message" byłoby OGROMNYM MARNOTRAWIENIEM ZASOBÓW SPRZĘTOWYCH

dlatego przykładowo w tym momencie w twoim systemie w 99,9% utworzonych wątków właśnie trwa wykonanie GetMessage, które wygląda tak, że gdy system daje czas wykonania takiemu wątkowi, ogranicza się to do tego, że właśnie sprawdzi czy coś jest w kolejce, a że w 99,9% nie ma nic, to odda sterowanie następnemu wątkowi, bo PO CO MARNOWAĆ CYKLE NA BEZCZYNNY WĄTEK?
dzięki czemu, gdy system wreszcie przydzieli czas wątkowi, który faktycznie coś wykonuje, stanie się to MOŻLIWE JAK NAJSZYBCIEJ

Tak mi się przynajmniej wydaje :>

8
DirectX / Deferred rendering - materiały
« dnia: Listopad 28, 2012, 20:46:22 »
Witam,
ostatnio zrobiłem deferred rendering według tego tutoriala:http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/ tylko że w DX11

I właśnie doszedłem do trudnego tematu... multiple materials :>
Z tego co czytałem to najpopularniejszym rozwiązaniem problemu jest wygenerowanie tekstury będącej zbiorem materiałów.
Jeśli chcę, żeby materiał to było coś takiego:
struct Material {
  float3 diffuse;
  // itd reszta komponentów
};
czyli materiał jednolity dla całego mesha, wtedy robię teksturkę o wymiarach ilość_komponentów_w_mat x ilość_materiałów i wypełniam ją materiałami
W ten sposób mam teksturę, w której w każdej linii mam 1 materiał, w shaderze pobierając piksel pobieram nic innego jak pojedynczy komponent materiału, na tej zasadzie to ma działać?
Czy można jednak zrobić to prościej?


Mam jeszcze 2 pytania z zupełnie innej bajki.
1. Czy zasoby DX11 typu IMMUTABLE (vertex/index buffery i textury) będą działać szybciej, niż DEFAULT, oraz czy jeśli tworząc zasób DX11 typu IMMUTABLE w CPU RAMie nie będzie jego kopii, bo dla DEFAULT pewnie istnieje w CPU jak i GPU RAMie.

2. Jeszcze znalazłem sprzeczne informacje na temat normal mappingu, a konkretnie jeśli mam wygenerowaną normal mapę w przestrzeni świata, czy mogę wykonywać obrót i translację, mesha do którego się odnosi. Przecież to zwykłe normalne, tak samo jak normalne wierzchołków, translacja nie wpłynie na nie wcale, a obrót jeśli przemnoży się je przez macierz obrotu, to powinny być nadal poprawne normalne tylko... obrócone, czyż nie?
W jednym miejscu czytam, że jakiekolwiek transformacje są zabronione w drugim, że tylko skalowanie jest ble.

9
Windows / Odp: Przeplatanie blitow i GDI (nie dziala - miga)
« dnia: Listopad 19, 2012, 15:35:55 »
Co się tyczy akceleracji sprzętowej - tutaj gość ma takie samo pytanie:
http://stackoverflow.com/questions/9347532/are-the-gdi-functions-bitblt-and-stretchblt-hardware-accelerated-in-win32

tylko czy StretchDIBits będzie wspomagane przez WDDM1.1? (bo StretchBits jest) wydaje mi się, że nie, gdyż używasz tu danych bitmapy w zwykłym buforze dla CPU, który przekazujesz pointerem do funkcji, więc twoja bitmapa nie istnieje w GPU memory, więc trudno tu o wspomaganie sprzętowe, co innego gdy pracujesz z bitmapą w HDC, to wtedy może mieć swoją reprezentację w GPU, więc da się i zrobić wspomaganie sprzętowe, o którym mowa.

GDIplus nie ma akceleracji sprzętowej w żadnym wypadku.

10
Windows / Odp: Przeplatanie blitow i GDI (nie dziala - miga)
« dnia: Listopad 19, 2012, 10:42:42 »
Nawet jeśli sam rozwiązałeś problem warto napisać rozwiązanie ludziom którzy trafią tu szukajką w przyszłości.

Co się tyczy double-bufferingu:
opcja 1: ustawić WS_EX_COMPOSITED dla okna, będzie to double buffering implementowany przez system
opcja 2: jeśli opcja 1 z jakiegoś powodu nie działa (lub ma działać pod win2k-) trzeba sobie samemu napisać double buffering, robisz tak: tworzysz oddzielną bitmapę (o wymaiarach okna czy updejtowanego fragmentu jeśli zawsze będzie stały), wołasz funkcje rysujące dla DC pamięciowego tej bitmapy, czyli rysujesz do double buffora innymi słowy i na koniec dopiero robisz pojedyncze BitBlt z twojego double buffora do DC okna, chodzi generalnie o to aby nie wołać wielokrotnie funkcji rysujących na DC okna.

Mówiłeś jeszcze o skalowaniu. Problemem ze skalowaniem w GDI jest brak dobrych algorytmów skalujących.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145089(v=vs.85).aspx
Masz raptem 3 algorytmy z czego 2 do kolorowych bitamp. COLORONCOLOR domyślny daje najzwyczajniej bardzo słaby efekt graficzny.

Jeśli potrzebujesz lepszego skalowania opłaca się podłączyć GDIplus, tam wybór jest znacznie lepszy:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms534141(v=vs.85).aspx

11
Windows / Odp: Owerlapped z klientem 300x300 ? - jak
« dnia: Listopad 08, 2012, 18:51:06 »
Jak nie działa jak działa normalnie...

Moja funkcja inicjująca okno o wymiarach klienta:
HWND InitWin32Window(int width, int height)
{
  const wchar_t* const ILU_SystemName = L"ILU_EngineSystem_Win32Class"; // win32 window's class name
  const uint32 stl = WS_OVERLAPPEDWINDOW; //WS_DLGFRAME | WS_SYSMENU | WS_CAPTION | WS_MINIMIZEBOX; // win32 window basic style
  const uint32 exstl = 0; // win32 window extended style

  HWND hwnd;
  HINSTANCE hInst = GetModuleHandleW(NULL); // get this *.exe image pointer
 

  // win32 class type
  WNDCLASSEXW wcl = { sizeof(wcl), 0, onWin32ProcessEvent, 0, 0, hInst, LoadIcon(NULL, IDI_APPLICATION), LoadCursor(NULL, IDC_ARROW),
                      (HBRUSH)GetStockObject(BLACK_BRUSH), NULL, ILU_SystemName, NULL };
  RegisterClassExW(&wcl); // try register win32 wnd class
 
 
  // calclate real size
  RECT rc = { 0, 0, width, height };
  if(AdjustWindowRectEx(&rc, stl, FALSE, exstl) == FALSE) return NULL;


  // create win32 window
  hwnd = CreateWindowExW(exstl, ILU_SystemName, L"ILU Engine v0.2", stl, CW_USEDEFAULT, CW_USEDEFAULT,
                         rc.right - rc.left, rc.bottom - rc.top, NULL, NULL, hInst, NULL);
  if(hwnd == NULL) return NULL;
  ShowWindow(hwnd, SW_SHOWDEFAULT);

  return hwnd;
}

... odświeżyłem stary wątek, ale nie mogłem patrzeć na "nie działa", komuś googlującemu na pewno się przyda.

12
DirectX / Odp: D3D11 - błędne działający depth / z test
« dnia: Listopad 08, 2012, 17:03:38 »
Tak... kombinowałem z tymi ustawieniami...
Próbowałem, różnych formatów, początkowo miałem jakiś inny, z  DXGI_FORMAT_D24_UNORM_S8_UINT, także próbowałem, format nie wpływa na problem, co najwyżej createBuffer kończy się FAILem.
Ustawień D3D11_DEPTH_STENCIL_DESC także próbowałem przeróżnych. StencilEnable także nie wpływa w żaden sposób na problem.

Jak np dam funkcję D3D11_COMPARISON_ALWAYS, wtedy odwrotnie ten obracający się dookoła jest zawsze przed, co prawidłowo wynika z działania tej funkcji, bo ten obracający się dookoła rysowany jest jako drugi.

Problem leży w funkcji testującej. Wydaje mi się że głębokość jest mapowana odwrotnie, czyli to co powinno być przykryte jest pokazane, gdyby nie było usuwało prymitywów tyłem, pewnie widziałbym zawsze te prymitywy przykryte. W mnie wartość 0 określa znear, a najwyższa zfar, bufor czyszczę 1.0f, czyli odległością najdalszą, aczkolwiek funkcja testujący widzi to chyba odwrotnie.

EDIT:
zgadza się jak dałem D3D11_FILL_NULL, widzę wtedy te "wewnętrzne" prymitywy. zamiast te które je przykryły, a całość jest o tyle dziwna, że ta reguła obowiązuje tylko w przypadku pojedynczego drawIndexed, gdy gdy rysuję drugiego tygrysa (drugi drawIndexed) ten zawsze jest z tyłu, obojętnie czy z w rzeczywistości powinien być przed czy za

EDIT:
nadal nie uzyskałem odpowiedzi na to w którym miejscu obliczana jest wartość z-depth, czy jest tak jak ja mówiłem, czyli podczas mnożenia przez macierz projekcji? bo to chyba tutaj jest problem, wartość z-depth jest błędna


EDIT: jest 23:59 przysiadłem jeszcze raz otworzyłem projekt i znalazłem...
void ILU_CALL Render::setViewportArea(float x, float y, float width, float height)
{
  D3D11_VIEWPORT viewport;
  viewport.TopLeftX = x;
  viewport.TopLeftY = y;
  viewport.Width = width;
  viewport.Height = height;
  viewport.MinDepth = 0.0f;
  viewport.MaxDepth = 0.0f; // <- !!!! <... wiązanka niecenzuralnych słów ...>

  d3d11.dev_con->RSSetViewports(1, &viewport);
}
i pół dnia w plecy

13
DirectX / D3D11 - błędne działający depth / z test
« dnia: Listopad 08, 2012, 16:11:51 »
Witam
Problem, tak jak w tytule - polega na tym, że test z buffera nie działa poprawnie. Załączam: www.pgd.boo.pl/Projects.rar, żeby samemu zobaczyć (wymagane dx11 + vs/ps_4_0).

Wszystko ustawiłem, jak w dokumentacji przykazano, ale nie jest dobrze. Jeden mesh obraca się dookoła drugiego, mesh środkowy jest renderowany jako pierwszy, obracający się jako drugi i jak widać ten środkowy/pierwszy jest zawsze przed drugim, czyli objaw jest taki, że raz zapisany piksel do zbuffera już nie jest później modyfikowany (w przypadku kilku drawów), nawet gdy facey są przed - cóż funkcja testująca nie działa jak trzeba. Już pomijam fakt, że na poziomie jednego mesha prymitywy są źle przysłaniane, co dobrze widać, gdy tygrys jest zwrócony ogonem, bo ogon chowa się w tułowiu.


Zaraz dam garść kodu, jeszcze moje pytanie odnośnie z-buffera. Otóż definiując macierz projekcji określam znear i zfar, które przecież potem definiują ten zakres przestrzeni, która będzie wyznaczała wartości w zbufferze (znear jako 0.0f, zfar jako 1.0f), ale... ale na poziomie d3d11 ta przestrzeń nie jest definiowana, bo przecież macierze istnieją jedynie na poziomie shadera, równie dobrze mogło by ich nie być... a więc d3d11 nie jest w stanie policzyć wartości do zbuffera, w takim wypadku domyśliłem się, że wartość ta musi być liczona właśnie w momencie projekcji punktu 3d do 2d w shaderze. To tej pory wiedziałem, że projekcja przekształca koordynat float3(x,y,z) do float2(x,y) w d3d11 mapowane do (-1,1) (w d3d9 były to koordynaty rozdzielczości, tak?). Ale przecież poza float2(x,y) w przekształconym wierzchołku musi być informacja o głębi, gdyż tylko i wyłącznie tu może być policzona. W każdym tutorialu na wyjście pozycji vertex shadera definiuje się float4, więc domyślam się, że float4-z zawiera głębokość, czego wcześniej nie byłem świadomy, która trafia do z-testu, a potem przekazywana jest do pixel shadera, jako, że zwyczajnie pozycję przepisuję. Dobrze rozumuję, czy tkwię w błędzie?
We wszystkich źródłach, które do tej pory czytałem (no może nie było tego za dużo :>) zawsze było jedynie powiedziane, że w wyniku transformacji przez macierz projekcji, punkt jest rzutowany z 3d do 2d, a nigdy nie wspomina się o zapisie głębokości w tym miejscu, ale w sumie człowiek do pewnych rzeczy musi dojść sam...

Aha i czego używacie do debugowania shaderów, PIX jest nie sprawny.

No i potrzebny kod:
// crete depth-buffer
  const DXGI_FORMAT depth_buffer_format = DXGI_FORMAT_D32_FLOAT;
  D3D11_TEXTURE2D_DESC tx_desc;
  tx_desc.Width = width;
  tx_desc.Height = height;
  tx_desc.MipLevels = 1;
  tx_desc.ArraySize = 1;
  tx_desc.Format = depth_buffer_format;
  tx_desc.SampleDesc.Count = 1;
  tx_desc.SampleDesc.Quality = 0;
  tx_desc.Usage = D3D11_USAGE_DEFAULT;
  tx_desc.BindFlags = D3D11_BIND_DEPTH_STENCIL;
  tx_desc.CPUAccessFlags = 0;
  tx_desc.MiscFlags = 0;
  hr = d3d11.dev->CreateTexture2D(&tx_desc, NULL, &buffer);
  if(FAILED(hr))
  {
    releaseD3D11Interfaces();
    return ILU_APIERROR;
  }
  D3D11_DEPTH_STENCIL_VIEW_DESC db_desc;
  db_desc.Format = depth_buffer_format;
  db_desc.ViewDimension = D3D11_DSV_DIMENSION_TEXTURE2D;
  db_desc.Flags = 0;
  db_desc.Texture2D.MipSlice = 0;
  hr = d3d11.dev->CreateDepthStencilView(buffer, &db_desc, &d3d11.depth_buffer);
  buffer->Release();
  if(FAILED(hr))
  {
    releaseD3D11Interfaces();
    return ILU_APIERROR;
  }
 
 
  // create depth stencil state
  D3D11_DEPTH_STENCIL_DESC depthStencilDesc;
  depthStencilDesc.DepthEnable = TRUE;
depthStencilDesc.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ALL;
depthStencilDesc.DepthFunc = D3D11_COMPARISON_LESS;

  depthStencilDesc.StencilEnable = TRUE;
depthStencilDesc.StencilReadMask = 0;
depthStencilDesc.StencilWriteMask = 0;

  // front facing
depthStencilDesc.FrontFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;
depthStencilDesc.FrontFace.StencilDepthFailOp = D3D11_STENCIL_OP_DECR;
depthStencilDesc.FrontFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;
depthStencilDesc.FrontFace.StencilFunc = D3D11_COMPARISON_ALWAYS;
 
  // back facing
depthStencilDesc.BackFace.StencilFailOp = D3D11_STENCIL_OP_KEEP;
depthStencilDesc.BackFace.StencilDepthFailOp = D3D11_STENCIL_OP_INCR;
depthStencilDesc.BackFace.StencilPassOp = D3D11_STENCIL_OP_KEEP;
depthStencilDesc.BackFace.StencilFunc = D3D11_COMPARISON_ALWAYS;

  hr = d3d11.dev->CreateDepthStencilState(&depthStencilDesc, &d3d11.depth_state);
if(FAILED(hr))
{
releaseD3D11Interfaces();
    return ILU_APIERROR;
}

 

  // crete rasterizer state
  D3D11_RASTERIZER_DESC rasterDesc;
  rasterDesc.FillMode = D3D11_FILL_SOLID;
rasterDesc.CullMode = D3D11_CULL_BACK;
  rasterDesc.FrontCounterClockwise = FALSE;
rasterDesc.DepthBias = 0;
rasterDesc.DepthBiasClamp = 0.0f;
  rasterDesc.SlopeScaledDepthBias = 0.0f;
rasterDesc.DepthClipEnable = TRUE;
  rasterDesc.ScissorEnable = FALSE;
  rasterDesc.MultisampleEnable = FALSE;
rasterDesc.AntialiasedLineEnable = FALSE;
hr= d3d11.dev->CreateRasterizerState(&rasterDesc, &d3d11.rasterizer);
if(FAILED(hr))
{
releaseD3D11Interfaces();
    return ILU_APIERROR;
}

//...

// set used buffers and states
  d3d11.dev_con->OMSetRenderTargets(1, &d3d11.render_buffer, d3d11.depth_buffer);
  d3d11.dev_con->OMSetDepthStencilState(d3d11.depth_state, 1);
  d3d11.dev_con->RSSetState(d3d11.rasterizer);
  d3d11.dev_con->PSSetSamplers(0, 1, &d3d11.sampler);

// i czyszczenie

ILU_RESULT ILU_CALL Render::frameBegin(bool clear_depth, bool clear_target)
{
  // clear render target buffer
  if(clear_target) d3d11.dev_con->ClearRenderTargetView(d3d11.render_buffer, (float*)&d3d11.background_color);

  // clear depth buffer
  if(clear_depth) d3d11.dev_con->ClearDepthStencilView(d3d11.depth_buffer, D3D11_CLEAR_DEPTH, 1.0f, 0);


// aha no i transformacje
bool onFrameRender()
{
  // setup matrix
 
  DWORD time = timeGetTime();
  // calc angle position in deg based on time
  float rotateX = (time / 10) % 360;
  float rotateY = (time / 25) % 360;
  float rotateZ = (time / 50) % 360;
  // convert deg to rad
  rotateX *= (XM_PI / 180.0f);
  rotateY *= (XM_PI / 180.0f);
  rotateZ *= (XM_PI / 180.0f);

  const float fov = 70.0f * (XM_PI / 180.0f);
 
  XMFLOAT4
    eyePos(0.0f, 0.0f, 4.0f, 0.0f),
    viewPos(0.0f, 0.0f, 0.0f, 0.0f),
    upDir(0.0f, 1.0f, 0.0f, 0.0f);

  struct MatrixBufferData {
    XMFLOAT4X4 worldviewproj;
    XMFLOAT4X4 world;
    XMFLOAT4   eyePos;
    XMFLOAT3X3 normal;
  };
  MatrixBufferData* bufData = (MatrixBufferData*)matrixBuffer->updateData();
 
  // calc world transformation
  XMMATRIX _world = XMMatrixRotationY(rotateY);
  XMStoreFloat4x4(&bufData->world, _world);
 
  // calc view & proj transform
  XMMATRIX _view = XMMatrixLookAtLH(XMLoadFloat4(&eyePos), XMLoadFloat4(&viewPos), XMLoadFloat4(&upDir));
  XMMATRIX _proj = XMMatrixPerspectiveFovLH(fov, 4.0f / 3.0f, 0.5f, 25.0f);
  _proj = XMMatrixMultiply(XMMatrixMultiply(_world, _view), _proj); // world * view * proj
  XMStoreFloat4x4(&bufData->worldviewproj, _proj); // store result in GPU matrix buffer
 
  // set eye pos
  bufData->eyePos = eyePos;

  // calc normal vectors transformation
  XMVECTOR det;
  _world = XMMatrixInverse(&det, _world);
  _world = XMMatrixTranspose(_world);
  XMStoreFloat3x3(&bufData->normal, _world);


  if(ILU_FAILED(render->frameBegin())) return false;


  render->render(mesh, material, texture, vdesc, vsh, psh, (const DataBuffer**)&matrixBuffer, 1, NULL, 0);

  // update matrices again
  bufData = (MatrixBufferData*)matrixBuffer->updateData();
  _world = XMMatrixTranslation(2.0f, 0.0f, 0.0f);
  _world = XMMatrixMultiply(_world, XMMatrixRotationY(rotateZ));
  XMStoreFloat4x4(&bufData->world, _world);
  _proj = XMMatrixPerspectiveFovLH(fov, 4.0f / 3.0f, 0.001f, 25.0f);
  _proj = XMMatrixMultiply(XMMatrixMultiply(_world, _view), _proj); // world * view * proj
  XMStoreFloat4x4(&bufData->worldviewproj, _proj); // store result in GPU matrix buffer
 

  render->render(mesh, material, texture, vdesc, vsh, psh, (const DataBuffer**)&matrixBuffer, 1, NULL, 0);


  if(ILU_FAILED(render->frameEnd())) return false;

  if(ILU_FAILED(render->presentFrame())) return false;

  return true; // render next frame
}

Jakieś pomysły?

Strony: [1]