Názory k článku Tvoříme trojrozměrné scény v jazyce VRML 2

No montujes zobrazovani do ukladani.
Neprimo jsem naznacil ze v souboru muzu mit treba jen rutinu ktera vyuziva nejaky format, ktera neco vygeneruje a pouzije k tomu dataset z toho sameho souboru, v hudbe tomu odpovida modulovy format znamy jako *.mod *.it, editory k nim se jmenuji treba protracker a impulsetracker. V grafice tez existuji takove formaty, napriklad formaty ruznych L-Systemu, nakonec i *.3ds je semi-proceduralni.

Ja nic nemontuju. Ja mluvil o principech ktere zustavaji. Trojuhelnikova hranicni reprezentace budiz jednim prikladem.

Apropo, ve VRML se musi ukladat jen trojuhelniky ci co?

Dekuji za nabidku, jsem radeji kdyz do diskuze muze zasahnout vice nazoru, radeji zde.

Podle toho co jsem se DOCETL Surfely jenom obchazi potize ktere vnikaji pri tom kdyz je potreba zobrazit grafiku ponekud etericke povahy, napriklad chuml casticoveho systemu (kour, bahno etc. nebo velmi clenity povrch), ze by surfely vedly k prekonani n-gonove reprezentace rict nejde, spis jde o doplnek a vylepseni casticovych systemu (samozrejme neni problem pouzit i na pevne teleso-casticovy system je v urcitem casovem bode tez vlastne pevny), proste mapuji na mista jednotlivych castic misto jednoho bodu nejake plosky s x parametry, barva, normala, velikost, textura... stejne tak dobre tam jde namapovat metaball (ktery se zkonverti na polygony) nebo rovnou polygon, na ten se i Surfely vlastne zkonverti tak jako tak (zde je ta masivni paralelyzace ? - vyuzitim dnesnich GPU srze konvezi na polygony ?), pochybuju ze kvuli renderovani orientovanych fleku nekdo bude prekopavat GPUcka.

Aha, no celou svoji disertacku do diskuse teda davat nebudu, ma to pres 400 stran.

Surfely jsou (velmi zjednodusene receno) pouzivany v pripade, ze je povrch telesa opravdu tak slozity, ze ho nema smysl reprezentovat polygonove. Proc? protoze v realu jsou mnohdy ty polygony mensi nez velikost pixelu na obrazovce, tak proc vlastne mit slozite GPU, ktere stejne v tomto pripade nedela nic jineho nez praci na subpixelove urovni. Surfel je naproti tomu renderovan jako elipticka stopa, pro jejiz rasterizaci byl odvozen velmi jednoduchy algoritmus zalozeny pouze na scitani. Transformace surfelu? -> vyhledavaci tabulka (zadnou extra presnost pro malou eliptickou stopu nepotrebujeme), tj. zadne nasobicky, nic sloziteho.

Surfel si s sebou nese svoji polohu (samozrejme), orientaci i barvu. Tj. neco jako texturovaci pamet i texturovaci jednotka je vlastne odstranena - ostatne jde pouze o nahrazku skutecnych vlastnosti povrchu. Je to docela malo dat, hlavne kdyz se to porovna s trojuhelnikem.

Co je vsak hlavni vyhoda - takove renderovani je vlastne lokalni, proto se cely framebuffer muze rozdelit na casti (ja jsem je nazval dlazdice, tiles) a pro kazdou dlazdici mit samostatny renderovaci "strojek". Vstupni data jdou pres trosku slozitejsi fronty a radic rozdeleny do jednotlivych renderovacich strojku, ktere si na zaklade souradnic vyberou spravnou dlazdici a do te renderuji. Tady je ta paralelizace, klasicka GPU to moc zvladat nemuzou, protoze by musely trojuhelniky rozdelit na mensi kousky, jenze to rozdeleni je mozne az po transformacich. nehlede na to, ze se GPU "hadaji" jak o texturovaci pamet, tak i o framebuffer. Samozrejme se dneska experimentuje se stripovanim, ale (nejenom podle me) se to zastavi na max. ctyrech GPU, protoze potom se podle Amdahlova zakona zacne projevovat "krize" pri komunikaci.

Nerikam, ze klasicka metoda HW renderingu je spatna, to urcite ne, ale pro mnoho oblasti uz se narazi na teoreticke limity. Ostatne staci si precist prispevky ze SigGraphu z poslednich let, tam se tomu venuji vetsi odbornici nez jsem ja (a SigGraph zdaleka neni nejaka akademicka konference).

Nj. jenže takový Surfelový konglomerát (aka paměť) musí být výsledkem jiné reprezentace jinak s ním neuděláte animované věci typu běžící voják, morfované věci typu vlnící se list atd., pořát je to jen (další) specialita, nic co by nahradilo stávající aparát kolem polygonů. Možná tak akorát časem přibude na konci pipeline další jednotka(ky)...

S tou úsporností to je pravda jen relativně, při popisu extrémně členitých věcí vyjde méně dat ale ne už pro popis věcí typu placatý schod, navíc dnes si můžu balit několik úrovní textur dle přiblížení a přídávat detailnost až do třeba nanometrů, to se Surfelama neudělám leda přidávat miliardy surfel dynamicky podle algoritmu "hmoty a její dynamiky" - něco co by plýtvalo výkonem víc se jen těžko výmýšlí (nebo jich mít miliardy na metr už předem).
Surfel je jenom maňásek za kterým musí kvůli animaci objetů a dynamickýmu prostředí stát vnitřně příšerně složitý "herec" který s ním hýbá výpočetně o to náročnější o co bude na scéně víc Surfelů než bude polygonů dneška, reatime dynamická grafika založená na Surfelech bude vyžadovat extrémně větší výkon přítomný na pozadí než co potřebuje grafika dnes a jak s tímhle chcete kreslit akcelerovanou grafiku různých CADů ?.

Obaval jsem se, ze to bude slozite na vysvetleni. Ted uz musim jit domu (mozna vic odpovim vecer), ale zamyslete se nad tim, proc se vlastne pouzivaji polygony? Je to snad prave ta entita, ktera se pouziva v CADech nebo ktera je na hry idealni? Pouze jako koncovy produkt! Ja je (jak uz jsem psal) neodsuzuji, ale to, ze se dnes na skoro vsechno pouzivaji polygony, zdaleka nic nerika o tom, ze je to idealni metoda. S polygony si dovolim rict taky animovaneho vojaka neudelate, chce to dalsi mnohdy hodne slozite struktury nad tim. Ale my se bavili o renderingu ne?

No však, a pokud budete chtít rendering provádět kde ty Surfely vemete ? o těch hodně složitých struktorách v pozadí mluvím, tady někdo nechce něco vidět.

Vyborne, konecne mam cas k pripojeni na net :-)

Je to v podstate jednoduche a Vy sam jste vlastne na nektere veci narazil, takze se mi to bude jednoduseji vykreslovat.

1) renderovaci strojky pro surfely jsou velmi jednoduche a masivne paralelni. Trosku jsem to naznacil tema dlazdicema ale hlavni figl spociva v tom, ze surfel je prostorove docela omezeny, takze zabira malou plosku, tudiz ho zpracovavaji maximalne ctyri strojky (kdyz nahodou padne do ctyr sousednich dlazdic). Pravdepodobnost tohoto jevu je pomerne mala, pocitejme tak 1,3 strojku na surfel. Je dulezite spravne nastavit velikost dlazdic, vsechno je to o koherenci dat i o tom, v jakem poradi do renderovace pristupuji. To je reseno nekolika frontami, ktere vlastne koherenci zvysuji - nemuze byt ani moc velka (vsechno by slo do jednoho strojku), ani moc mala (porad by se vyprazdnovaly fronty). Neni to jedina mozna cesta (tuto jsem zvolil ve sve praci), muzete se mrknout na "konkurenci" (spis kolegy): http://portal.acm.org/citation.cfm?id=1276490&coll=ACM&dl=ACM&CFID=30010714&CFTOKEN=67311369 http://citeseer.ist.psu.edu/568423.html

2) surfely jsou datove velmi malo objemne, coz je velmi dulezity udaj pri prenosu dat na akcelerator. S vyuzitim hierarchickych scen (o tech za chvili) se cely surfel i s barvou v pohode vleze do 12 bytu.

3) sceny jsou typicky hierarchicky rozdeleny. Uz jste zminil mipmapy, se surfely je to to stejne - 3D body lze sdruzovat napriklad do hierarchickych obalovych kouli, prostorovych mrizek atd. I to je jeden z duvodu, proc se surfel vleze do onech 12 bytu (i mene). Diky tomu ziskavame zadarmo i LOD, protoze vzdy nadrazeny objekt se da vykreslit bez nutnosti prenaset vsechny podobjekty. Hierarchicke deleni - bud vychazi primo z dane problematiky (omezena telesa), nebo se provede mnohem rychleji, nez BSP apod.

4) diky deleni sceny se ve skutecnosti da velmi jednoduchym logickym testem ano-ne (pouze or a and) rict, ktere surfely skutecne nebudou vykresleny.

5) shrnuti (bez dukazu, je nutno hledat bud v me praci nebo u zahranicnich kolegu): rendering surfelu je velmi rychly jak softwarove (http://www-graphics.stanford.edu/software/qsplat/), tak i v hardwaru (staci pitomy Xilinx, ale muzete nase schema nechat predelat do zakaznickeho obvodu - patentovane to neni).

6) proc to vsechno pouzivat:

a- slozite objekty je celkem zbytecne prevadet na polygony, jednodussi je provest prevod na surfely (mrknete na zminovany QSplat, tam nejake modely maji)

b- polygony nejsou onou kyzenou strukturou, ktera by scenu nejak vyznamne popisovala (a surfely uz vubec ne). Prozatim jsou polygony chapany jako dostatecne jednoduche pro renderovani, ovsem zacina se narazet na barieru paralelizace, koherence dat, sloziteho texturovani apod.

c- na vyssi urovni zpracovani se pro uzivatele nic nemeni - muze mit scenu slozenou z implicitnich ploch, NURBSu, polygonu, popsanou nejakou proceduralni funkci (fraktalni objekty apod.), ovsem pro rendering je nutne vzdy provest prevod (nyni na polygony, mozny i na surfely). Pametova slozitost se urcuje tezce, protoze surfely si s sebou nesou i informace o barve, kdezto u polygonu se vetsinou pouzivaji textury. Zduraznuji, ze tento prevod se provadi VZDY - bud na polygony ci surfely, tomuto se neda efektivne vyhnout (maximalne nekdo muze do GPU nacpat tesselaci NURBS).

Je jasne, ze napriklad pro hry - ktere se vzdy psaly optimalizovane a s "dorazem" na hardware - se surfely prozatim neujmou, maximalne jako doplnek k hernim modelum (ty jsou vsak velmi jednoduche, nedaji se srovnavat s modely, ktere se jiz dnes realne zpracovavaji). Ovsem pro mnoho dalsich disciplin je to velmi zajimava technologie a pokud se ujme jako doplne GPU, tak se s nim velmi brzy setkame i ve hrach.

Nemluvim vubec o fyzikalnich simulacich, casticovych systemech atd. - tady surfely uz z principu jasne vedou, ale toto je opravdu velmi specificka oblast.

Konecne jste se zacali bavit konkeretne. Zajimave a pro me nezname tema. Pane Tisnovsky, budou teda dalsi dily nebo ne? Otazka je, zda to ma vyznam, protoze kdo chce, informaci o VRML najde dost, knizka je levna (navic jako stara uz muze byt ve sleve nebo v knihovne) a na hrani to slozite neni.

. A jak s tímhle chcete kreslit akcelerovanou grafiku různých CADů ?.