SW Rendering v JavaScriptu

[nou]

MODERATOR: Vytrzeno z kontextu http://www.ceske-hry.cz/forum/viewtopic.php?t=3651

1Pupik1989 clovece preco ty nepouzivas WebGL? co som pochopil tak si vlastne pises vlastny rasterzier od piky. viem je to zaujimava robota ale realne to nevidim ze by to bolo pouzitelne. jedine ze pridu moznost spustat viacvlaknovy JS kod.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[1Pupik1989]

nou: WebGL nemá takovou podporu v prohlížečích. S 2D contextem mám šanci, že s excanvasem to rozjedou v rámci možností i lidi s Internet Explorerem. Sice pro ně už mám hotové jiné prostředí (jentak na oko) z pohledu boha, ale 3D by bylo hezčí. Samozřejmě počítám s tím, že to budou nějaké super low-poly modely, ale i tak by to bylo fajn.

[OndraSej]

1Pupik1989> a zkousel jsi merit, kolik polygonu zvladnes zobrazit v primerene velkem okne? Abys pak nezjistil, ze jsi nekde u 100 polygonu na frame...
_________________
http://trionteam.net

[1Pupik1989]

OndraSej: cca. 1000 trojúhelníků při rozlišení 1280x1024 běží u mě na 40 - 50 fps. Pokud domyslím to Octree, tak by se ještě fps mohli navýšit. Jako první jsem chtěl Z-buffer, ale to by se asi nejspíš zaseklo úplně. Nebo nemám představu jak bych to udělal s ohledem na nároky. Hodně toho udělá Backface Culling.



To první byl můj úplně počáteční pokus. Byl špatný, takže jsem ho smazal.

[Hunter]

[Ladis]

To FPS hodně klesne, až bude překreslovat každý pixel viewportu, nejlépe víckrát (překrývající se polygony). WebGL mi přijde jako lepší nápad, přestože v IE nebude podporován nikdy (třeba někdo udělá nějakej ActiveX).
_________________
Award-winning game developer

[OndraSej]

1Pupik1989> octree te moc nezachrani - umozni ti orezat polygony, co nejsou videt, ale porad budes mit na obrazovce max 1000 polygonu, coz je dost malo na zobrazeni cehokoliv detailnejsiho. Ber to tak, ze pokud postava ma 200 polygonu (coz je priblizne odpovida prvnimu Quakovi), tak muzes mit na obrazovce soucasne 5 postav a uz ti nic nezbyde na prostredi.

Napsat si softwarovy 3d engine v javascriptu rozhodne je frajerina a klidne v tom pokracuj, ale na neco jineho nez demo (ve smyslu demoscena) to nebude a mas lepsi pouzit to webGL a spolehat na to, ze nez hru dokoncis, tak uz ho bude podporovat i IE (v te dobe treba IE13).
_________________
http://trionteam.net

[1Pupik1989]

Hunter: Tohle je softwarové, nemůžeš chtít nemožné v nemožném. "u mě" znamená Phenom II X4 955 BE, 8Gb DDR3 1333 (@1466Mhz) a Radeon HD 6850.

Ladis: Překreslovat každý pixel nemám proč, proto jsem Z-Buffer vzdal, i když ani ten by nemusel být po pixelech.

OndraSej: Octree nepomůže tolik, ale pomůže přeci jen. Když ho dám místo momentálního třídění podle osy Z, tak je jednak rychlejší a druhak ušetřím spoustu trojúhelníků už v cyklu.

Vymyslet to opravdu není sranda. Jen 14 dní jsem ladil objekt pro matice 4x4, aby běžely nějak rozumně. Nechci se chvástat, ale momentálně je to jedna z nejrychlejších matematických knihoven, leč mi to je prd platné a pořád je to pomalé. 40fps to má při neustálém překreslování 1000 trojúhelníků, ty se ale tak často překreslovat v reálu nebudou. Navíc to pouštím ve smyčce opožděné o 1ms, takže nakonec i tam by se to mohlo zrychlit. Zkusím requestAnimationFrame co ukáže. Nicméně to celé vytvářet je celkem sranda.

[Hunter]

[1Pupik1989]

Hunter: No RPG ala Skyrim to určitě být nemůže. Nejspíš to asi skončí tak, že s tím 2D to nechám jen opravdu na nějaké demo postav, objektů atd. Jen takovou prezentaci. Pokud ovšem nevymyslím způsob jak z toho vytáhnout víc, což asi už nejde. Kolikrát mám nutkání s tím seknout a napsat to v pořádném jazyce. Jenže když si představím tu celou cestu třeba s C#, jako když jsem začínal s javascriptem, tak to potěš koště. Znovu 7 let už bych asi nechtěl trpět.

[Vilem Otte]

#Pupik1989 - Nebudu se vyjadřovat k tématu, u sebe jsem ho zařadil do balíku "Yet another flamewar". Nicméně na něco zareaguji:

Hráčům je úplně jedno na čem hra běží a v čem byla napsaná. Psát softwarový rasterizér v Managovaném jazyku je nepoužitelné (rychlost), psát jej v javascript je mimo demoscény absolutně k ničemu. Pokud to napíšeš v nativním Céčku, využiješ alespoň SSE2 (který má dnes dle Steam stats 99.9% mašin), a více-jádrové procesory, dostaneš se u nejmodernějších (Ivy Bridge arch.) někam k výkonu několik let staré generace GPU - tipl bych tak GeForce 8800. S tím, že budeš používat hodně optimální algoritmy jako paralelní halfspace triangle rasterizaci, a ideálně data ukládat v AoS místo SoA. Takový rasterizér je použitelný pro hry (zvládne statisíce trianglů vč. shadingu i na klasických low-end Core i3).
Druhou možností je napsat rasterizér v CUDA/OpenCL, kde to má větší smysl, nicméně stále budeš pomalejší než D3D/OpenGL ... nicméně už to bude více použitelné.

Se slovem "nejrychlejší" matematická knihovna opatrně. Klidně uploadni její zdroják a můžeme udělat benchmark s ostatními známými knihovnami (glm, glsl-sse2, eigen, vectormath, a další), nicméně pochybuji že tyto knihovny trumfneš, dělá na nich více lidí celá léta, s léty zkušeností v této oblasti.

Zajímalo by mě, jak chceš řešit např. prolínající se polygony bez z-bufferu?

Octree (ani jeho efektivnější varianta KD-tree), ani jakákoliv jiná hierarchie scény (BVH, BIH, QBVH, LBVH, etc. etc.) ti nepomůže s rychlostí u rasterizéru o více než pár procent (pokud nemáš prasáckou scénu), vysoké zvýšení výkonu dávají u ray tracingu.

Celkově vzato k rychlosti které dostahuješ, je příliš nízká. Podívej se na scény zde - http://graphics.cs.williams.edu/data/meshes.xml ... až dokážeš že ti alespoň Sibenik nebo Dabovicova Sponza běží stabilně při 50 - 60 fps na tvé mašině doma s texturováním a alespoň lambertem a phongem, pak to bude teoreticky použitelné, do té doby nikoliv. Např. nám se momentálně daří dosahovat při ray tracingu kolem 100 MRays/s Conference hall (282k trianglů) na fermi kartách (gtx 580). Což ti dá pro primary rays kolem 48 fps na 1920x1080 rozlišení. Pro hry je to však stále příliš málo.

EDIT: Malý note, napsat rasterizér v C, který je použitelný se dá cca za týden lehké práce (cca 3 - 4 hodiny denně) bez jakýchkoliv dependencies - tedy když máš znalosti matematiky kolem, a zkušenosti v daném jazyce.

EDIT2: Překlep, záměna AoS za SoA.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[OndraSej]

1Pupik1989> Asi jsem to spatne napsal - schvalne si to zkus v profileru, ale muj odhad je, ze te nebrzdi ani tak detekce neviditelnych polygonu nebo jejich razeni, ale jen jejich vykreslovani na obrazovku. Coz znamena, ze i kdyz budes mit perfektni orezavani neviditelnych polygonu, tak viditelnych polygonu nemuzes mit vic jak 1000 soucasne (a to porad je strasne malo).

Ale jak psal Dlaha, pokud jsi zvladnul napsat zakladni SW renderer v JavaScriptu, uz mas nejspis dost zkusenosti, aby pro tebe prechod na jiny jazyk nebyl nejak zasadni problem.
_________________
http://trionteam.net

[Vilem Otte]

Přidávám zde benchmark naší knihovny scMath (je obdobná glsl-sse2, nicméně podporuje navíc quaterniony, aos-soa transformace, a lze zapnout it sse4 mód přes makro - avšak to nebylo použité) psané v C/C++ - zde je pár výsledků na notebooku s Core i3:
http://pastebin.com/emPcx1mG

Knihovna je v C++, nicméně to je pro hráče unrelated (je NEZAJÍMÁ v čem daný výrobek je, pouze jak rychle funguje a jaké má výsledky).

Kód který jsem použil používá stejnou sérii operací jako ty - inverze matice, násobení matice, sečtení vektorů a násobení vektor krát matice. Zpracoval jsem to dávkově z náhodně generovaných vektorů a matic (velikost dávky byla 10000000 matic a 10000000 vektorů).

Pro fetching jednotlivých matic a vektorů z paměti na 1 vlákně dostávám cca 8771929 takových operací za sekundu - v porovnání s tvým javascript kódem (566047 takových operací za sekundu - note. ten používá jeden vector a matici - což není zrovna ideální pro benchmarking, ale budiž) je to 15.49x rychlejší. Nicméně jen blázen by dnes nedělal věci multicore a s řádným fetchingem s paměti. Ideální warp size pro mě bylo 128 nebo 256 matic a vektorů, implementováno na persistentních vláknech, kdy jsem je spustil 4 (což je logické, jelikož Core i3 je dvoujádro s hyperthreadingem). Výsledek byl 26525198 (pro warp=128) a 26738310 (pro warp=256) - což je 46.86x, potažmo 47.23x rychlejší.
Jinými slovy jen lepším přístupem do paměti a použitím obou fyzických jader naplno jsem svůj kód zrychlil cca 3.048x - to ti javascript nikdy neumožní. V praxi to znamená, že na stejné mašině tím dokážu kreslit 3x tolik trianglů co v původní verzi.

Note. je možné, že pro použití více vláken tam budou o nějaký zlomek procenta lepší/horší výsledky, což je dáno vlastností implementace pomocí persistentních vláken).

Testovací systém je Windows 7, aplikace byla 32-bit. Kompilátor MSVC2010 (nicméně knihovna je psaná v SSE2 intrinsics, takže moc optimalizací na ní MSVC provést stejně nemůže).

Nechci tě zde od ničeho odrazovat, ale chci ti tímto říci, že psát pro engine software rasterizér v javascriptu je nesmysl.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[gindar]

[1Pupik1989]

gindar: Mám trochu jinak, ale principálně to je verze se setTimeout.