DX 9 vs. DX 11

Jedino sto ne kuzim je ovaj tvoj post... sasvim si me nepotrebno prozvao...

Mozda nisam tehnicki strucnjak, ali lazan marketing je lazan marketing, za mene, nevazno iz kojeg razloga. Navoditi da dx11 stoji iza ''boljih refleksija'' i ostale gluposti nas ''smrtnike'' koji nemamo vase cijenjeno znanje navodi na pomisao da bi to moglo biti tako. Dakle, to je lazan marketing. Moj post koji je ispravio LevaOpaki se ne temelji na mom znanju (sto sam u istom i istaknuo) vec na podacima koje sam pokupio okolo, dakle kako sam ja dosao do krivih podataka? Lijepo upakiranim marketingom?

Molim te nemoj me krivo shvatiti. Samo moje misljenje. Po meni nebi nista manji ucinak bio da se u razgovoru sa developerom AvP-a reklo da snaga novih kartica omogucava kvalitetniji render i da to nema veze da dx-om... Dakle, sto ja tu nisam shvatio...?

Ali nije samo AvP u pitanju, gotovo svaki gaming sajt koji opisuje dx11 features navodi slicne gluposti... Pa zasto ne mogu reci onda da to nema veze sa dx-om?

Molim te, ne prozivaj i ne vrijedaj nego pojasni jer ne razumijem. Ne svida mi se tvoj stav uopce, kada nekome nije nesto jasno, ja se potrudim objasniti tako da on to shvati...

By the way nisam spavao vec poprilican broj sati pa sam malo nervozan nemoj ovo shvatiti kao napad...ili povod za raspravu... naprosto ulozio sam odredenu kolicinu vremena da saznam sto vise o doticnoj temi i jedino sto sam saznao je hrpa gluposti... valjda razumijes moju frustraciju... i na kraju u zelji da pomognem, ispadnem troll koji siri dezinformacije, a to mi nije bila namjera...

Nije "lažni marketing", jer, kao što Leva reče, svodi se na to da će biti razlike. Ono što sam ja htio reći, a Leva je objasnio, je ukratko i graf koji dobijaš snagom hardvera. DX11 prednosti bit će sve očitije i očitije porastom snage hardvera i implementacijom rješenja s manjim gledanjem na kompatibilnost s DX9.

e,da,meni je bio fascinantan taj unigine demo

a iam jedno pitanje

cisto tehnicko

da li postavke hadrware-a sa ukljucenom teselizacijom od jednostavnog poligona sa texturom cini komplexan lijep poligon kakav treba biti (stepenice,uzad,crijepovi) pa onda teselizacija promatra texturu i na osnovu algoritma i prepoznavanja sjena (stepenice) odnosno boje (shiljci zmaja) stvara dodatne poligone ili ti morash bash jednostavnijem poligonu (stepenicama) josh reci neke parametre hardware-u sa ukljucenom teselizacijom (kako bi dobio od kose plohe stepenice)?

hmm kako da to probam pojasniti. nije to bas tako jednostavno uljucis tezelaciju pa ona radi. ne postoji tako nesto. tezelacija se sada radi potpuno programabilno na sljedeci nacin.

za to postoje nova dva shadera koji se zovu hull i domain shader. znaci SM 5.0 u DX 11 ima sada 5 vrsta shadera. vertex, geometry, hull, domain i pixel shader. svaki od njih se programira

u HLSL jeziku koji je slican C++ i koji se onda prevodi u ASM za graficke kartice. u dx 8 su se shaderi pisali direkno u asebleru, u dx 9 se moglo birati hlsl ili asm a u dx10 i 11 se mogu pisati samo u hlsl. ali i dalje moze vodjeti asm output pa optimizirati nesto ako kompajler izbacuje previse instrukcija za nesto.

znaci napises program koji kaze na koji nacin se sjece poligon i sto ces s njime raditi. to moze biti na puno nacina

i tezelacija tj. sjeckanje poligona se moze raditi na razlicite paterne. trazi malo po netu pa ces vidjeti koliko ima razlicitih algoritama za tezeliranje geometrije. znaci kad odaberes nacin na koji ces rezati

geometriju odredis kontrolne tocke u hull shaderu i prosljedis ih u domain shader.
recimo, uoci metodu djeljenja poligona ovdje:

i ovdje:

programer sam kroz shader odreduje kako ce se djeliti poligoni i na koliko puta. pa recimo mozes prosljediti poziciju kamere u shader, izracunat udaljenost do vertexa i onda ovisno o udaljenosti smanjiti

broj djeljenja. i kao sto si mozda vidio na prvom videu, kocka se nigdje ne ispupci nakon djeljenja. znaci ako si isprogramirao djeljenje nitko ne odreduje dal ce se vertexi ili tocke uopce pomicati.

to opet odreduje programer i moze s tim tockama raditi sto zelis. mos' ih animirati po sinusu i dobit ces valove, moze se prosljediti heightmapu i pogurati vertexe ovisno o boji teksture.

to se onda zove real displacement mapping. height mapa ti je crno bijela tekstura gdje npr. crna boja moze predstavljati najvecu udubinu, a bijela predstavlja ispupcenje. znaci programer onda na osnovu te teksture

i normale u vertexu, pomakne taj vertex za neki faktor koji ce odredivati jacinu ispupcenja. normala je naravno okomica na povrisnu i po jednom vertexu se sprema jedna normala uglavnom i onda ovisno o toj normali (vektor smjera) se vertex pomice. znaci ovisno o tome kako su ti normale usmjere uspucenje ce se dogadati pa moze postici efekt stuba na kosoj povrisini ili siljke na zmaju. naravno height mapa mora biti isto odgovarajuca. heightmapu ne vidis u demou ona se u pozadini prosljeduje u shader. googlaj neku heightmapu pa ces vidjeti kako izgleda tekstura i da ima logike za odredivanje visina. naravno kad znas sto mozes napraviti hardwareski i koja su ti ogranicenja onda je samo dobra volja i masta programera da smisli lude stvari. ljudi su radili i tezelaciju cak recimo sa compute shaderom koji je dio DX 11 a vrti se na DX 10 hardwareu. tako da recimo da je izvedivo i na dx10 :)

http://www.3dkingdoms.com/CW3D/Doc/displacement-maps.jpg 
evo ovdje na ovoj slici mozes vidjeti diffuse (color mapa), height mapa i normal mapa u tanget space-u. naravno teksture se uglavnom drze kao odvojene, ne kombiniraju se tako u jednu sliku. ti samo vidis finalnu boju pixela za koji je sudjelovalo hrpa tekstura, diffuse, normal mapa, height mapa, mozda neke albedo, razne material mape kao specular mapa, shadow mape za sjene. nisi ni svjestan, ali se vjerojatno za taj svaki pixel cita i po 10 tekstura od kojih i neke teksture i nekoliko desetaka puta po pixelu. takoder da bi tezelacija ok proradila ne mozes uzeti bilo koji model. tokom modeliranja moras paziti na odredene stvari kao uv mapa i organizacija mesha da bi tezelacija prosla kako treba. znaci nije samo tako odlucit preci na tezelaciju moraju se i artisti educirati malo.

ovo je najjednostavnije sto sam mogao pojasniti nadam se da pomaze. :) ako te to zanima vise morat ces puno toga procitati na netu krenuvsi od toga kako uopce graficke rendaju geometriju

da vidis kako se tu tezelacija uklapa. pogledaj kako radi moderni graficki pipeline i kroz koje stageve prolazi. ali ne postoji nesto sto ti mozes ukljuciti pa to radi kao npr. tezelacija. directx je low level api i sve moras rucno raditi. vjeruj mi, napatio bi se da iscrtas obicni staticni crveni trokut na crnoj pozadini izbacis na ekran i napisao bi barem 250 linija codea i 20 linija shadera. e sada zamisli sto treba napisati da dobijes obicni model na ekranu s obicnom teksturom  i nekim osvjetljenjem. :) radit igre je teze nego ikad prije.
evo demo di ima tonu fizike (gpu simulirana) i nesto tezelacije:

thnx :)

tako sam si nekako i mislio (na haj levelu :D )

a ti si stvarno to jako lijepo i jako opshirno objasnio

super je to shto se to moze koristiti za koje kakve druge stvari,koje su manje komplexnije od broja milijuna poligona,a opet mosh bilo kakve informacije na taj nacin obradjivat

kewl :)

He he, evo lagao sam, ispadne jos vise :)

Moras znati da je DX 10 i DX 11 totalno izbacio fiksni pipeline i nema toga vise
da ces ista rendati na ekran bez shadera. Obicni poligon ako zelis iscrtati moras pisati
minimalni vertex i pixel shader. U DX uopce nema neceg kao sto je model kojeg mozes ucitati i rendati na ekranu. To ne postoji. Ima u primjerima di je napisan code za tako nesto (par desetaka tisuca linija) no to je i dalje code kojeg tak i tak neces koristiti za ozbiljan projekt.
DX se svodi na vertex i index buffere koje programer sam mora filati informacijama.
Nema cak ni tranformacija da kao nekad u DX 9 (i nize) velis ovo je World matrica ovo View a ovo Projection pa mi rendaj tu geometriju na ekran. Ili da velis upali svjetlo, upali maglu. To vise nista ne postoji. To sve sada ide kroz shader i programer sam mora izmnoziti matrice poslat ih u shader kao konstante i izmnozit ih sa vertexima. To je posao koji moras obaviti ako zelis neku transformaciju. Onda u pixel shaderu samplaj teksture, racunaj osvjetljenje sa drugim prosljedenim konstantama, racunaj maglu shadeing itd itd.

Evo da bi rendao obicni trokut zute boje na plavoj pozadini u DX11 ti je potrebno 357 C++ linija codea i 34 HLSL shader linija codea.

Da bi rendao obicni sareni Quad/Pravokutnik bez teksture (boja je spremljena u vertex color) koji se rotira na plavoj pozadini potrebno ti je 454 linije C++ codea i 54 linije HLSL shader linija codea.

Onda da bi rendao obicnu teksturiranu kocku bez osvjetljenja, potrebno je 497 linija C++ codea i 80 linija HLSL shader codea.

Neki model na ekranu s teksturom bez osvjetljenja neces proci bez par tisuca linija codea nikako. A di je to od kompleksnog osvjetljenja, animacije itd.

Zar nebi trebali postojati neki defaultni shaderi u toolkitu? Zadnje što sam dirao je DX7 i 8 pa sam malo van priče, ali zar cijela priča oko DX-a nije kretala u suprotnom smjeru? Uostaom, množenje matrica mi se ne čini baš tolikim poslom.

Šteta što toliko toga treba nakucati. Valjda su zato izbacili XNA kao wrapper inače im za jednostavnije stvari OpenGL itekako konkurira.

Ne postoje i nema potrebe da postoje, jer je to podrucije postalo toliko opsezno da nema smisla tako nesto raditi. To se naravno i krsi sa gpu programabilnom paradigmom. Htjeli smo programabilni gpu i sad ga imamo. Toliko je razlicith nacina kako ces nesto izvesti i koje ces rendering metode koristiti da bi totalno bilo bezveze da oni ista naprave u naprijed. Gubitak vremena bi bio za njih i to MS zna. Mislim da u ovom trenutku nema shadera ni u jednoj igri da je isti. Svako ima isprogramirane svoje i prilagovada ih tome kako zeli da igra izgleda i naravno u skladu sa mogucnostima programera da razumiju problematiku toga sto zele postici. Sad je postalo problem razumijeti i znati nesto rijesiti i ukomponirati u ostatak enginea, a ne vise dal je moguce nesto izvesti. Naravno sve i dalje mora uci u okvire snage od platforme koja se cilja, ali to su sada primarni problemi. Npr. vec se pada na prvom testu da li ce recimo engine koristiti deferred rendering path ili klasicni forward rendering path. Mozda neki mix kao crysis engine 1 tj CryEngine 2. Koja je razlika se lako moze naci na netu pa ce se vidjeti da npr. u deferred pathu shaderi lighting prebacuju kao postprocessing pass a ne vise u trenutak kad se model renda. Totalno drugacija metoda. Dal' ce engine recimo koristiti Z prepass rendering ili ce sve rendati is prve a presortirati front to back. itd itd.

Ljudi cak taj standardni kit ne bi koristili jer bi igre bile ruzne i totalno iste. Zato smo i pobjegli od DX 7. Tamo su prakticki DX 7 igre izgledale totalno identicno. Razlike su bile mizerne i finte su bile samo u tome kako se netko sjetio abjuzati odredeni fixni feature. Ili su se izvodile razliciti efekti i finte sa multi texture-ingom i nekim bolesnim teksturama. Ali to je bilo toliko jadno i ograniceno da se moglo vidjeti sto je tko koristio cim se pogledalo na ekran. Razlika u generaciji igara na DX 7 je samo bila u tome sto je graficka bila jaca pa su se koristile vece teksture ili vise poligona na modelima. Evo ista je sada stvar sa Nintendo DS. Gpu u tom DS-u je koma i slab. API je nesto na razini DX 7. Ono, ukljuci toon shader i iskljuci ga, LOL. Nes' ti mogucnosti. Svaka igra koja ukljuci toon shader ce izgledati ama bas identicno. Jedina razlika ce biti u modelu i teksturi. Ono ukljuci svjetlo i per-vertex specular. Vidis shot i vidis koje su stvari ukljucene od 10 mogucnosti. Nemos' se ni nadati da ce neka igra izgledati bolje ako se izda 3 godine nakon izlaska konzole. Uzmes need 4 speed 1 i 2 i identicno izgleda. Samo nove staze. Cemu uopce kupovina nove igre. Cak ni auto nema vise poligona jer hardware tak i tak ne moze progutati vise, a bome ni vece teksture.

Kad tako nesto vidis onda je covjek sretan kad ima programabilni gpu. Ali eto, to su ostaci ostataka i sve ostale konzole su programabilne, barem ove velike. Nova generacija i malih ce takoder biti.

Onda covjek pocne cjeniti DX8 pa na dalje i OpenGL koji podrzava shadere. DX je inace puno naprediji u stvarima koje donosi gotove sa SDK od OpenGL-a. OpenGL je totalna koma i ruzno nazbukan novim stvarima. U OpenGL-u fixni pipeline radi jos uvijek, ali samo radi suporta starim aplikacijama. Ali ce biti totalno izbacen. U DX-u je u pozadini stari DX emuliran shaderima ali mu se vise ne moze programabilno pristupiti. OpenGL je ruzno nadozbukan sa mogucnostima kako dolaze, jer na njemu radi hrpa firmi i samo dodaje neke ARB ekstenzije. To je takav jedan cuspajz da je strava. Naravno i dalje ima neke stvari rijesene bolje od DX-a, barem devetke, ali po mogucnostima su prakticki podjednaki.

Uglavnom i OpenGL je low level api. Mozes kreirati vertex buffer, index buffer, ucitati razlicite teksture, setirati neke stateove i to je to. Nema cak ni klase koja bi se zvala mesh u koju mozes ucitati neki model. Cak ne dobijas primjere s kojima mozes raditi i nema hrpa utility funkcija koju recimo dobijes sa DX-om. Cak neke graficke formate za teksture ne mozes ucitati direkno bez specijalnih loadera. DX ima ogromnu biblioteku D3DX s kojom mozes cuda naspram GL-a. XNA wraper je odlican za C# ekipu i one koji ulaze u game dev. Tu se mogu napraviti odlicne stvari i nauciti nesto prije ulaska u pravu game industriju. XNA je vise zamisljen kao ulazna karta ljudima u taj svijet da ljudi odmah ne izgube volju. Tu svaka cast MS-u. Ali GL nema s cime uopce konkuritati DX osim sa time da radi na svim platformama. To je jedini razlog zasto je ziv, ali to je jako dobar razlog i nece nikad nestati :)

Ali to sto se mora puno toga nakucati uopce nije neki problem. Na netu ima toliko codea da glava zaboli. Svatko moze krenuti s necim tudim, uzet barem dio codea koji je open source ili primjer pa ga poceti preradivati, pa dodat svoje, pa jednom zamjeniti to svojom boljom klasom itd. To je zabavan proces i proces ucenja. Pa nije sada DICE za novi BF kad je radio DX 11 render radio mesh klasu iz pocetka. Nema sanse. Samo su u DX11 renderu umjesto DX 9 vertex i index buffera punili onaj DX 11 i sve 3.0 shadere su za pocetak prebacili na 5.0 target. I u roku od 3 mjeseca su recimo imali DX 11 render koji indenticno renda kao DX 9 path. E onda odatle krecu razlike i prilagodba da se bolje iskoriste mogucnosti. Najnoviji unreal engine ima unutra jos ostatke od prve verzije. Stvari se postepeno dograduju no kad jednom napravis bazu sve ostalo je onda lakse. Matematicki Core unreal enginea se vjerojatno mjenjao 10% od njegovog nastanka.

Da malim igracima je teze uci u game dev nego ikad prije, ali nije nemoguce. I to se nikad nece promjeniti. Uvijek se moze uspjeti, ali krenes sa manjim stvarima koje isto mogu donjeti velike pare. Pa kad jednom bude para krenes s vecim. Nema ni jednog razloga da svatko ne uspije i dogura do velikog team-a, samo to ce biti malo duzi proces nego recimo devedesetih. I takoder ne znaci da ces sjediti bez para usput. Cak i da programiranje igara nije puno opsirnije i dalje je problem orgomne kolicine contenta kojeg je potrebno napraviti za jednu vecu igru tako da tu mali teamovi nemaju sto raditi na tom polju. Ali to je samo jedan dio trzista i ima vremena da se do toga dode.

Ne

pa ako misliš iskoristit do kraja ram memoriju i proc, mislim da ćeš ipak kupit win 7.