Új hozzászólás Aktív témák

• #35857 Abu85 HÁZIGAZDA Jack@l #35856

  Új Válasz 2018-06-15 14:19:20 #35857

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz Jack@l #35856 üzenetére

  A mai játékokban azért a motion blur faék egyszerűen van megoldva. Az adott pixel végeredménye mindig a környező pixel valamilyen módon számolt súlyozott középértékéből van származtatva. A gyorsulást szimplán skálázhatod a képkockasebességből. A temporális screen space megoldások marhára nem elterjedtek ám. Persze kétségtelenül lehetségesek, csak egyrészt a számítási idő és a memóriaigény tekintetében relatíve költségesek, másrészt az eredményük nem sokkal jobb, így például nem adnak választ azokra a problémákra, hogy mi van azokkal az objektumokkal, amelyek már pont nincsenek rajta a képen. Szóval az egész egy baromi nagy screen space trükközés jelenleg. Úgy tudom egyedül a Nitrous működik másképp, az valóban temporális, ráadásul objektumszintű motion blurt használ, de ott eleve a leképező marhára más a texel shading miatt, tehát egy csomó mai motorra jellemző limitációval nem kell küzdenie. Ha kész egy objektum árnyalása egy viewportból, akkor azt annyiszor használhatod fel, ahányszor akarod, csak extra rajzolási parancs az ára, nem kell másodjára, harmadjára, vagy sokadjára árnyalni, mint az árnyalást és leképezést nem függetlenül elvégző motorok esetében.

  Nem kapsz több fps-t a tripla puffereléssel, vagy csak egy nagyon picit. Egyszerűen arról van szó, hogy a késleltetés növelése és a memóriaigény emelése árán biztosíthatod a jobb szinkronizációt tripla pufferelés mellett. De attól, hogy három képkockapuffered van, még a GPU erőforrásai nem nőnek meg, vagyis az éppen számolt képkocka mellett elkezdi számolni az következőt is a GPU, azaz valamekkora mértékben megtörténik a képkockák párhuzamos számítása. De ne úgy képzeld ezt el, hogy egyszerre elkezd két képkockát számolni, és egyszerre el is készülnek azok, hanem amikor az n képkocka számítása a vége felé jár, akkor már elkezdődik az n+1 képkocka számítása, a parancsok parancspufferekből történő behívásával. Ez az oka annak, hogy minél jobban növeled a képkockapufferek számát, annál inkább nő a késleltetés is.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Új hozzászólás Aktív témák