Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Hergot, o víkendu mi proběhlo hlavou, že při deinterlacingu videa jde relativně levně dopočítat mezisnímky, při „zpomalování“ videa se to taky běžně dělá, a říkal si, proč se to vlastně nepoužívá při renderingu grafiky, že by to za ty občasné nežádoucí artefakty stálo... To šlo rychle :D. Akorát mi přijde škoda omezovat to jen na VR.
Presne tak, preco to nepouzivat aj mimo VR headsetov? Viac ludi by urcite ocenilo, ze si slusne zahraju aj pri 20fps, kedze z toho razom bude 40 fps. To by ale musela byt podpora v ovladacoch a preco by vyrobca cipov navysoval naklady na vyvoj, aby si znizil zisk (stacili by lacnejsie karty), ze.
Porad je to siditko. Ve scene s rapidnimi zmenami (treba strelba z kulometu nebo zavodni hry) muzou byt artefakty dost vyrazne.
Kazdopadne copak jen GTX 960. Diky tomuhle by mohlo 3D byt (na nizke detaily) pouzitelne i na RX480.
Vidíš, vidíš. Kdybys ze závisti nad naší recenzí HD 7970 neztrácel čas diskusemi na DIITu a nechával si místo toho své geniální myšlenky včas patentovat, mohl ti dneska Oculus odvádět licenční poplatky ;-)
Tohle je taková pitomost, že si spíš říkám, jestli není problém právě v tom, že už si to někdo někdy patentoval.
Je to pěkný až na tu deformaci. Spíš si říkám, proč to nedělá grafika. Ta by mohla mít předchystaná data na tu ruku, vygenerovat obraz při převídání dalšího framu a mezisnímky vyplnit posunem a přeplácnout to popředím. Takhle totiž bude neustále docházet k deformacím obrazu a nemyslím, že to bude dvakrát košer.
Co kdyby grafika kreslila jen ty pixely, co se změnily a ne vždy celý frame ? Kolik by se ušetřilo GPU času ?
Pokud někdo vyvine algoritmus, který dokáže vyhodnotit rozdíly mezi dvěma obrazy, z nichž jeden neexistuje (nebyl vykreslen), pak o něj jistě budou mít grafické firmy eminentní zájem :-)
Bylo by to sofistikované :) řešení založené na predikci, která by byla mnohaúrovňová a zahrnovala by světla, z toho odvozené stíny, pohyb kamery, pohyb objektů atd. Částečně hw implementace, částečně sw, kde by bylo možné číst kód typu animovaná realtime sekvence dopředu. Když může mít predikční jednotku cpu, proč by ne gpu. Nějaký supervizor, který by předpokládal vývoj scény dřív, než se pracně nakreslí. No a kdyby mu to nevyšlo, tak by se predikce zahodila a začalo by se od znova. Stačila by, dejme tomu, 70% úspěšnost k radikálnímu skoku ve výkonu.
CPU predikuje na úrovni základních skokových instrukcí, predikce na úrovni stínů, kamery/objektů apod. je nereálná :)
Navíc v normálních scénách se 99% pixelů v každým framu liší + vykreslení pixelů, u kterých už víš barvu nežere (skoro) nic.
Hm, taková blbost, ale napadlo mě, jestli je nutný aby se 99% pixelů v každým frame lišilo? :o)
Není, ale pohyb objektů, dynamický světla / stíny / odlesky, HDR efekty, případně simulace denní doby, pohybu mraků nebo třeba pohyb kamery ti tvoje plány většinou nějak narušej :)
Vykreslovat jen změny šlo (a bylo nutný, aby se to rozumně hýbalo) dřív, když ještě neexistovaly 3D akcelerátory a kdy počet překreslených pixelů měl vliv na výkon, protože se kreslilo jen kopírováním pixelů a dělal to obvykle procesor.
Dneska se (kromě raytracingu) obraz nepočítá po pixelech, ale nejdřív se musí spočítat transformace bodů v 3D prostoru a až pak se to převádí na pixely.
A dnešní karty jsou schopné pixely vykreslovat obraz ve fullHD klidně v desítkách až možná už stovkách tisíc fps, pokud by šlo jen o kopírování pixelů z textury bez aplikování nějakých složitějších efektů).
Právěže není nutné, aby se všechny pixely v každým frame lišily. Ikdybys měl pravdu s těmi světly a dolesky a ... tak lidské oko se rádo nechá ošálit. Z toho přeci vychází videokodeky.
To je ale naprosto nesrovnatelná situace. Zatímco v případě videa se pozorovatel vůči scéně nehýbe, pozadí scény může být konstantní a pohybují se jen objekty ve scéně, ve 3D se pozorovatel naopak hýbe (chodí, běhá, skáče, ukračuje), takže se hýbe vše včetně pozadí i objektů. Nelze čekat, že algoritmus vypracovaný pro zcela konkrétní podmínky bude fungovat v naprosto odlišných podmínkách.
Problém asi nebude v těch pixelech, ale ve výpočtu toho, jak mají ty konkrétní pixely vypadat, řekl bych... :o)
k těm OS bych řekl že to popletli v Oculusu, minimum bude historický W7 a doporučený 8.
Minimum je W8 (a vubec bych se nedivil, kdyby W8.1) a doporuceny pro plnou podporu je W10. Pisou to i v tom odkazu v clanku, nechapu z ceho autor cerpal. "Windows 8 or later is required for ASW, but the latest version of Windows 10 provides the best support."
W7 samozrejme nic, s tim uz nikdo nepocita a nic pro to nevychazi, W7 SP1 uz skoncila podpora bezmala pred dvuma rokama.
1. Chce to číst a pokud možno s porozuměním. „Windows 8 or later is required for ASW“. Jenže ve článku / v tabulce řeším doporučené „požadavky pro Oculus VR“ nikoli doporučené požadavky pro ASW. Takže v prvním odstavci mícháš dvě různé záležitosti.
2. Doporučené požadavky pro Oculus VR pocházejí od Oculu, jak uvádím ve článku:
http://diit.cz/sites/default/files/oculus_recommended_specs.png
Tolik k „W7 samozrejme nic“.
Ale stejne.. O vikendu jsem byl v Imaxu na Dr. Strange (vrele doporucuji, melo to spad a bylo to vtipne, proste ta spravna limonada) a tak jsem si rikal, ze jeste hoooodne vody ubehne, nez budou bryle, ktere by dokazaly zobrazit tak velkou plochu s tak jemnym rozlisenim.
Zajímavé, možná by to mohli implementovat i do monitoru, něco podobného už umí gsync/freesync monitory s LFC - ony jen ten snímek zdvojují (ztrojují) ale nedopočítávají.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.