Leírás

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Stuff

Anything related to game development.

Contact: darthasylum at gmail dot com

Nemlineáris cikkek

Mi ezeknek a célja?

Leginkább az, hogy magyarul is elérhető legyen programozási anyag, olvasmányos formában.

A cikkek kódja GitHub-ról is elérhető. (*)-al jelölöm azt a cikket ami nemrégiben frissült.

A színek a nehézséget próbálják jelezni, de az, hogy egy cikk piros nem azt jelenti, hogy csak a profiknak szól!

 

 

 

 

 

 

 

 

Hörcsög (Adobe Flash szükséges)

The Asylum

3D grafikával kapcsolatos bejegyzések és cikkek. A Quadron Virtual Particle nevű game engine fejlesztése.

Friss topikok

Címkék

HTML

A karbantartás fontossága

2013.11.24. 20:41 | darthasylum | Szólj hozzá!

A tapasztalatom az, hogy minél általánosabbra akarod megírni az engine-t, annál inkább tele lesz hackeléssel. A hétvégén néhány egyszerű hibát akartam kijavítani, de végül egy sokkal nagyobb varacskolás lett a vége.

Én persze a varacskolást inkább kerülöm, még akkor is ha cserébe 5 órán keresztül kódolok. A kódolás témája a unit cube clipping (UCC), azaz a közeli és távoli vágósíkok ráfittelése a modellre. Ez kis modelleknél is baromi fontos (zfight), shadow mappinggal viszont kötelező! Utóbbi szerencsére már megvolt csinálva, most viszont a jelentre is rá akartam illeszteni a kamerát.

Az első probléma az volt, hogy ha két projekciós mátrixot interpolálsz, az alapvetően hibás (és UCC-vel különösen látható). A megoldás az, hogy interpolálod a view mátrixot, ezzel elvégzed el az UCC-t mindkét kamerára, majd az így kapott projekciós mátrixokat interpolálod. Ezt tök jól kitaláltam, nagy öjömbódottá közepette el is kezdtem kódolni éééééééés...bazdmeg a kamera nem tudja ezt, nem tudja azt, ez kajak hülyén van kitalálva... Pech...reggel 10-kor felkeltem, 12-re kész volt a kamera rendbeszedés.

Második probléma a depth linearizálása. Máris mondom, hogy perspektív projekcióval nem lehet tisztán a mátrixban megoldani... legjobb esetben a vertex shaderbe kell egy d = pos.z / farPlane. Rosszabb esetben opos.z *= opos.w / farPlane. Ez pl. SSAO-hoz kell.

Harmadik probléma szintén a UCC de most shadow mappinggal. Példának említem a causticos demót (találtok képet). A near/far rá van fittelve a sárkányra. Egyrészt ez alapból rossz, hiszen a fotonok a parkettára csapódnak, de ettől most tekintsünk el. A probléma a shadow-al van. Feltételezem mindenki eljutott odáig, hogy a shadowmap címzési módja GL_BORDER, a színe pedig fehér. Ennek ellenére a shadowmap körül fekete részek jelennek meg.

float d = cpos.z / cpos.w;

Általában jó. Itt nem. Hiszen d simán a far plane mögé eshet, és akkor d <= sd nem teljesül, azaz árnyék keletkezik. A helyes megoldás:

float d = saturate(cpos.z / cpos.w);

Nem akarok belegondolni, hogy ez mit fog okozni bizonyos meg nem nevezett Intel kártyákon. Feltételezem azért az 1 == 1 még megy neki.

Negyedik gondolatként megemlíteném, hogy a shadowmapbe mindig depth-et írj! (én persze a tutoriálokban távolságot írtam, de hamarosan javítva lesz). Így elég R16F. Bár hallottam olyan kósza híreket, hogy a DX9 is tud depth textúrát, nem próbáltam ki.

ucfitting.jpg

Konklózióként azt mondanám, hogy akármilyen fasza a is a progid, ne gondold azt, hogy tökéletes. Folyamatosan reviewolni, szúrós szemmel nézni és gumikacsázni kell. Regressziós teszt még fontosabb (egy éves SMAA hibát is kijavítottam).

A bejegyzés trackback címe:

https://darthasylum.blog.hu/api/trackback/id/tr655654211

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.