| mgsfan |
Arról nem is szólván, hogy dx9-ben vannak játékok amik mérföldekkel jobban nnéznek ki, mint ez a játék dx10-ben. |
| Netere |
Kamu!
Ezek csak marketing képek! Dx9 alatt is simán lehet ilyen grafikát csinálni, csak lehet hogy dx10-el könyebben programozható. |
| TerekG |
Csak az a baj, hogy az adaptív tesszeláció már kissé komplex dolog, annak hiányában meg százcsillió poligon lesz a terep. Persze meg lehet csinálni, csak lehet hogy egy GPU-nak túl összetett. PS3 SPE-k, szevasztok ;)
A talaj úgy egyébként többnyire borzasztó nehéz feladat minden 3D megközelítésnél, legyen bár offline render vagy realtime... igen, itt adaptív tesszalálnákak.. :P
egyébként nem életveszélyes, eddig is voltak ilyesmi cuccok, csak eddig a cpu végezte a gpu helyett..
a dx10es kártyákban meg elvileg lesz egy "geometry shader" vagy valami hasonló modul, és az hivatott csinálni... |
| LY |
Csak az a baj, hogy az adaptív tesszeláció már kissé komplex dolog, annak hiányában meg százcsillió poligon lesz a terep. Persze meg lehet csinálni, csak lehet hogy egy GPU-nak túl összetett. PS3 SPE-k, szevasztok ;)
A talaj úgy egyébként többnyire borzasztó nehéz feladat minden 3D megközelítésnél, legyen bár offline render vagy realtime... |
| TerekG |
Szted hány poligonból kéne állnia a talajnak ahhoz, hogy érdemben lehessen benne random lábnyomokat displace-elni?
:P alapesetben kegyetlenül sok... :P
cserébe pont itt jön be a dx10 és a vertex shader 4.0 verrtexgenerálás+displacement kombója, és az alap gyengébb poligonfelbontásba belegenerál annyi plusz poligont csak oda, hogy elég legyen...
ha egy idő után eltűnnek, meg messziről sem látszanak, akkor még a gépigényt sem dobja meg annyira... |
| LY |
Szted hány poligonból kéne állnia a talajnak ahhoz, hogy érdemben lehessen benne random lábnyomokat displace-elni?
:P |
| TerekG |
egyébként furálom a hozzáállásodat, mert nem úgy nézel ki a hsz-eid alapján mint aki nem ért hozzá, a DX10-es techpaperekben pedig le van írva feketén fehéren, hogy igenis a DX10-zel már könnyen implementálható a normális disp. mapping (azt hiszem a példában a dinamikus talajmintázat volt a példa, hogy pl. havas tájon megmaradnak a lábnyomok, amiket a hóesés szépen lassan befed).
persze, nem mondom, a parallax mapping és a normal mapping is életképes marad mellette. De minél inkább kezdenek majd bejönni a dformálható, interaktív felületek, annál nagyobb létjogosultsága lesz ennek a technikának, addigra pedig a HWek is fejlődnek annyit, hogy nagyobb mennyiségben használhasság egy jelenetben.
Na ámen :)
kulcsszó: "könnyen implementálható". :)
azt nem vitatom, hogy a dx10 ad rá plusz eszközöket, ellenben a displacement mapping már akkor is egy létező technika, a realtime megjelenítésben is.
attól a technika létjogosultságában teljesen igazad van, a lábnyomos példa nagyon zsír... :P |
| scumbag |
Gondolom az M$ nem kis penzt tol a fejlesztok zsebe, hogy reklamozzak a DX10et es ezzel kozvetve hatulrol azt masszirozzak a jatekosok fejebe, hogy vegyel Vistat, mert CSAK azon van DX10, mert biza DX9 alatt csak ilyen cuuunya kepet kapsz und noch dazu a szomszed Pistike is kirohog a homokozoban emiatt. |
| MelWin |
Sajna én nem értek ennyire a különböző shaderekhez és mappingokhoz, azt viszont furcsállom, hogy dx9-ben nincsenek árnyékok, valamint minimumra van véve a látótávolság :) |
| orbano |
a displacement mappingot ugyanúgy meg tudja csinálni a dx9 is shaderből. sőt, ezt igazából már a vertex shader 1.0 is tudta. Ebben annyira nem vagyok biztos (VS1 texturabol nem nagyon tud olvasni...)
igen, ez igaz, gyorsan utánanéztem... ez már vs3 feature. ami mellesleg még mindig csak dx9c... :) |
| orbano |
Hardver neked nem fog displacementet kirakni normal mapping helyett, az is biztos... Akkor mi fog, szoftver? :))) Olvass picit utána a dolgoknak... egy fő feature-je a DX10-nek a rt disp. mapping. Ez pedig annak köszönhető, hogy a geometry shaderek is hozzáférnek a textúrákhoz. Nem értem mi a gond azzal, hogy kiolvasok egy lebegőpontos értéket egy textúrából, majd a regiszterben lévő vertex megfelelő koordinátáihoz hozzáadom az értéket egy konstanssal felszorozva. A röptében készített vertexek (a'la truform) sem egy nagy feladat ezekkel a shaderekkel, tehát igazából a megnövekedett poligonszám-igény sem gond, mivel a teljes számítás on-chip történik (ráadásul a trasnzformációs résztől eltekinthetsz).
Szóval összességében: 1 textúraolvasás, 1 összeadás, egy szorzás és egy kis interpoláció szorozva N-nel (N kb 1..10 közötti szám) vertexenként. Ezt összehasonlítva egy komplexebb pixel shaderrel, ahol több textúraolvasás is szokott lenni, egy bonyolultabb megvilágítási modell is belekerül néhány vektor szorzásába, a multipass effektekről nem is beszélve, nem látom akadályát, hogy displacement mappingoljon nekem egy hardver :)
Normal mapping helyett meg valószínűleg nem is fog, mivel akkor azt már voxeles grafikának hívják, de nem is kell egy fragmentre eső összes raszterpozícióra egy vertexet interpolálni, jóval kevesebb is elég. a displacement mappingot ugyanúgy meg tudja csinálni a dx9 is shaderből. sőt, ezt igazából már a vertex shader 1.0 is tudta.
egyébként nem csak ennyiből áll a displacement mapping, mert ha egyszerűen csak eltolja a vertexet, újra kellene számolni a vertex normálokat, enélkül gázos lesz az árnyékolás, ellenben valóban nem sokkal bonyolultabb a dolog... :)
a normal mapping "utódja" a inkább a parallax mapping lesz, még egy jó darabig nem lesz olyan erős vas, hogy elbírjon annyi vertexet, amivel a szem számára megfelelő részletességet elő tudod állítani mindenféle mapping nélkül...
a vertexkészítés valóban szép feature a vs3.0-ban, de a képeken nem emiatt látszik a nagy eltérés... :)
egyébként furálom a hozzáállásodat, mert nem úgy nézel ki a hsz-eid alapján mint aki nem ért hozzá, a DX10-es techpaperekben pedig le van írva feketén fehéren, hogy igenis a DX10-zel már könnyen implementálható a normális disp. mapping (azt hiszem a példában a dinamikus talajmintázat volt a példa, hogy pl. havas tájon megmaradnak a lábnyomok, amiket a hóesés szépen lassan befed).
persze, nem mondom, a parallax mapping és a normal mapping is életképes marad mellette. De minél inkább kezdenek majd bejönni a dformálható, interaktív felületek, annál nagyobb létjogosultsága lesz ennek a technikának, addigra pedig a HWek is fejlődnek annyit, hogy nagyobb mennyiségben használhasság egy jelenetben.
Na ámen :) |
| TerekG |
a displacement mappingot ugyanúgy meg tudja csinálni a dx9 is shaderből. sőt, ezt igazából már a vertex shader 1.0 is tudta. Ebben annyira nem vagyok biztos (VS1 texturabol nem nagyon tud olvasni...)
|
| Psion |
Szerintem jól látható ezen a két képen, h. pár efektet kikapcsoltak DX9 alatt:
A szomorű szerintem csak az, h simán el tudom képzelni DX9 alatt tényleg így fog kinéznii! Pusztán azért, h. vegyünk DX10-es kártyákat...
Vagy csak a pesszimizmus verte le nállam a biztosítékot??! :D |
| Lord_Soth |
Nahát ez a különbség nem egy nagy durranás. Nem olyan, mint amilyet valami Flight Simulatornál ígérgetett az MS (persze concept renderrel alátámasztva). |
| Dulakh |
A detail-kulonbseget sem ertem teljesen (miert van tobb bokor a DX10-es kepeken? Ez nem a DX9/DX10 feature-einek a kulonbseget mutatja, hanem max. a teljesitmeny-kulonbseget... Ott a pont, ényleg ezek inkább marketing képek mint összehasonlító képek. |
| TnS |
MSDN-ből:
Games for Windows Showcase Features
S.1 Exploit Direct3D 10
The game implements a Direct3D 10 rendering pipeline that provides a compelling new experience over existing graphics APIs. If the game also implements Direct3D 9, a side-by-side comparison must demonstrate a perceptible improvement in content quality, visual techniques, performance, scene complexity, and/or other area of graphics fidelity. Csodálatos megvalósítás! |
| Remage |
a displacement mappingot ugyanúgy meg tudja csinálni a dx9 is shaderből. sőt, ezt igazából már a vertex shader 1.0 is tudta. Ebben annyira nem vagyok biztos (VS1 texturabol nem nagyon tud olvasni...)
A kepek tenyleg kisse nevetsegesek, par feature-t ki kellett kapcsolni DX9-en, hogy csunyabb legyen... :D
Ami itt a DX10-es kepeken van, az parallax mapping (vagy virtual displacement mapping, masneven), amit PS valosit meg, es ugyanugy mukodhetne DX9-en is. A detail-kulonbseget sem ertem teljesen (miert van tobb bokor a DX10-es kepeken? Ez nem a DX9/DX10 feature-einek a kulonbseget mutatja, hanem max. a teljesitmeny-kulonbseget...
Az also kozepso kep az teljesen kesz :D
A fak/hajo/epuletek suru kodben vannak, de a vizen tukrozodo fenysugar valahogy nem megy at ezen a kodon, igy ott szep tiszta marad a kep... :DD
Fizikailag nem teljesen korrekt, finoman szolva...
Marketing. |
| ladik |
Ú mekkora a különbség, rohanok is a boltba venni egy 8800-at... :Đ |
| LY |
Bogaram, displacementet évek óta használok napi szinten, lécci ne oktass ki ebből.
Amit a mai hardver ki bír izzadni, az meg édeskevés, lehet vele hullámzó tengerhez alapot csinálni és annyi. Garantáltan nem fogja kiváltani a bump/normal mappinget (ahogy te azt valamivel lejjebb írtad egy másik usert kioktatva), nem véletlen, hogy a fejlesztők 99%-a nem is erőlködik vele.
Arcod láthatóan szép nagy, de azért óvatosabban kéne tolni, beleakadhat itt a HW-n ebbe-abba... |
| mucius |
de amúgy mmorpg-nek elég pofás ez a conan :D |
| TerekG |
Hardver neked nem fog displacementet kirakni normal mapping helyett, az is biztos... Akkor mi fog, szoftver? :))) Olvass picit utána a dolgoknak... egy fő feature-je a DX10-nek a rt disp. mapping. Ez pedig annak köszönhető, hogy a geometry shaderek is hozzáférnek a textúrákhoz. Nem értem mi a gond azzal, hogy kiolvasok egy lebegőpontos értéket egy textúrából, majd a regiszterben lévő vertex megfelelő koordinátáihoz hozzáadom az értéket egy konstanssal felszorozva. A röptében készített vertexek (a'la truform) sem egy nagy feladat ezekkel a shaderekkel, tehát igazából a megnövekedett poligonszám-igény sem gond, mivel a teljes számítás on-chip történik (ráadásul a trasnzformációs résztől eltekinthetsz).
Szóval összességében: 1 textúraolvasás, 1 összeadás, egy szorzás és egy kis interpoláció szorozva N-nel (N kb 1..10 közötti szám) vertexenként. Ezt összehasonlítva egy komplexebb pixel shaderrel, ahol több textúraolvasás is szokott lenni, egy bonyolultabb megvilágítási modell is belekerül néhány vektor szorzásába, a multipass effektekről nem is beszélve, nem látom akadályát, hogy displacement mappingoljon nekem egy hardver :)
Normal mapping helyett meg valószínűleg nem is fog, mivel akkor azt már voxeles grafikának hívják, de nem is kell egy fragmentre eső összes raszterpozícióra egy vertexet interpolálni, jóval kevesebb is elég.
egyébként nem csak ennyiből áll a displacement mapping, mert ha egyszerűen csak eltolja a vertexet, újra kellene számolni a vertex normálokat, enélkül gázos lesz az árnyékolás, ellenben valóban nem sokkal bonyolultabb a dolog... :)
a normal mapping "utódja" a inkább a parallax mapping lesz, még egy jó darabig nem lesz olyan erős vas, hogy elbírjon annyi vertexet, amivel a szem számára megfelelő részletességet elő tudod állítani mindenféle mapping nélkül...
a vertexkészítés valóban szép feature a vs3.0-ban, de a képeken nem emiatt látszik a nagy eltérés... :) |
| haquitor |
Egyetértek Orbanoval!
Itt a lényeg "...de nem is kell egy fragmentre eső összes raszterpozícióra egy vertexet interpolálni"
A pöttyös túrórudi vertexének interpolálása a lényeg!!! :))
/leborul |
| vilma |
ennyi
van aki ilyen pikkpakk megoldja
az a sok okos meg csak agyal rajta |
| Luftwaffe |
Hehe... parasztvakitas rulez. |
| orbano |
Hardver neked nem fog displacementet kirakni normal mapping helyett, az is biztos... Akkor mi fog, szoftver? :))) Olvass picit utána a dolgoknak... egy fő feature-je a DX10-nek a rt disp. mapping. Ez pedig annak köszönhető, hogy a geometry shaderek is hozzáférnek a textúrákhoz. Nem értem mi a gond azzal, hogy kiolvasok egy lebegőpontos értéket egy textúrából, majd a regiszterben lévő vertex megfelelő koordinátáihoz hozzáadom az értéket egy konstanssal felszorozva. A röptében készített vertexek (a'la truform) sem egy nagy feladat ezekkel a shaderekkel, tehát igazából a megnövekedett poligonszám-igény sem gond, mivel a teljes számítás on-chip történik (ráadásul a trasnzformációs résztől eltekinthetsz).
Szóval összességében: 1 textúraolvasás, 1 összeadás, egy szorzás és egy kis interpoláció szorozva N-nel (N kb 1..10 közötti szám) vertexenként. Ezt összehasonlítva egy komplexebb pixel shaderrel, ahol több textúraolvasás is szokott lenni, egy bonyolultabb megvilágítási modell is belekerül néhány vektor szorzásába, a multipass effektekről nem is beszélve, nem látom akadályát, hogy displacement mappingoljon nekem egy hardver :)
Normal mapping helyett meg valószínűleg nem is fog, mivel akkor azt már voxeles grafikának hívják, de nem is kell egy fragmentre eső összes raszterpozícióra egy vertexet interpolálni, jóval kevesebb is elég. |
|
|
