No, ještě mi tam neštymuje jedna věc – že je tam jen pár naprosto stejných objektů, které jsou tisíckrát naklonované (obdobně jako v úvodu ukázky) a ve výsledku to vypadá jako Minecraft ve vyšším rozlišení.
Ale jinak celkem dává smysl, že když se s meshem jde na úroveň polygonů o velikosti několika pixelů, přestává polygonová síť už tak nějak dávat smysl a voxely vypadají rozumněji.
Ale kdy to bude použitelné... S nostalgií vzpomínám na "vizionáře", kteří viděli demo na Cinema 2.0 s Ruby a těšili se, jak máme na Radeonech
za dva, tři roky ve hrách fotorealistickou grafiku
+1
+1
-1
Je komentář přínosný?
Adams Adams https://diit.cz/profil/adams
3. 8. 2011 - 00:53https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseNo, ještě mi tam neštymuje jedna věc – že je tam jen pár naprosto stejných objektů, které jsou tisíckrát naklonované (obdobně jako v úvodu ukázky) a ve výsledku to vypadá jako Minecraft ve vyšším rozlišení.
Ale jinak celkem dává smysl, že když se s meshem jde na úroveň polygonů o velikosti několika pixelů, přestává polygonová síť už tak nějak dávat smysl a voxely vypadají rozumněji.
Ale kdy to bude použitelné... S nostalgií vzpomínám na "vizionáře", kteří viděli demo na Cinema 2.0 s Ruby a těšili se, jak máme na Radeonech
za dva, tři roky ve hrách fotorealistickou grafiku
https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593206
+
Asi největší problém vidím ve fyzice, jakmile se něco takového má rozumně a realisticky rozhýbat (např. kopnu do země a vyletí hrstka štěrku) tak najednou je to se složitostí poněkud jinde :)
+1
-1
-1
Je komentář přínosný?
Bilbo https://diit.cz/profil/bilbo1
3. 8. 2011 - 02:09https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseAsi největší problém vidím ve fyzice, jakmile se něco takového má rozumně a realisticky rozhýbat (např. kopnu do země a vyletí hrstka štěrku) tak najednou je to se složitostí poněkud jinde :)https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593209
+
Tohle chce podporu v HW jinak se to nehne, i na polygony to bylo potřeba (různé pixel/vertex shadery) aby se to trochu hejbalo...
+1
0
-1
Je komentář přínosný?
mamlasos1 https://diit.cz/profil/mamlasos1
3. 8. 2011 - 09:24https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseTohle chce podporu v HW jinak se to nehne, i na polygony to bylo potřeba (různé pixel/vertex shadery) aby se to trochu hejbalo...https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593226
+
Proč by to mělo být složitější, než polygony? Co se tak dívám, tak se stejně skoro všude používají pro tyto účely sprosté sprity, ty se dají dodat do jakéhokoli enginu. U animací (třeba postav) taky nevidím proti polygonům principiální zesložitění, ale je fakt, že to je podstatná část enginu, kterou očividně ještě nemají.
+1
0
-1
Je komentář přínosný?
xvasek https://diit.cz/profil/xvasek
3. 8. 2011 - 10:01https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseProč by to mělo být složitější, než polygony? Co se tak dívám, tak se stejně skoro všude používají pro tyto účely sprosté sprity, ty se dají dodat do jakéhokoli enginu. U animací (třeba postav) taky nevidím proti polygonům principiální zesložitění, ale je fakt, že to je podstatná část enginu, kterou očividně ještě nemají.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593231
+
Animace je problém viz diskuze na zive.cz, odkaz níže.
+1
0
-1
Je komentář přínosný?
mamlasos1 https://diit.cz/profil/mamlasos1
3. 8. 2011 - 10:17https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseAnimace je problém viz diskuze na zive.cz, odkaz níže.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593233
+
ono to má své opodstatnění, vemte si kdyby opravdu udělali tak obrovský ostrov jak říkali a udělali by rozmanitý jako normální ostrov. Kolik by pak zabírala data tohoto ostrovu? Asi hoši dobře vědí proč to sestavují ze stejných kusů a stejnými stromy
+1
0
-1
Je komentář přínosný?
Roman Vietze https://diit.cz/profil/euromen
3. 8. 2011 - 08:07https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseono to má své opodstatnění, vemte si kdyby opravdu udělali tak obrovský ostrov jak říkali a udělali by rozmanitý jako normální ostrov. Kolik by pak zabírala data tohoto ostrovu? Asi hoši dobře vědí proč to sestavují ze stejných kusů a stejnými stromyhttps://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593216
+
Tak to bych chtěl vidět stejně rozmanitý ostrov udělaný v polygonech...to by byl ještě větší porod. Jenom vyrobit textury a namapovat je...opakování objektů je běžné i s polygonama tak nevím proč u nějakého dema je to najednou špatně.
+1
-1
-1
Je komentář přínosný?
mamlasos1 https://diit.cz/profil/mamlasos1
3. 8. 2011 - 16:11https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseTak to bych chtěl vidět stejně rozmanitý ostrov udělaný v polygonech...to by byl ještě větší porod. Jenom vyrobit textury a namapovat je...opakování objektů je běžné i s polygonama tak nevím proč u nějakého dema je to najednou špatně.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593279
+
I když budou hry od začátku přizpůsobeny masivní teselaci nikdy nebudou stejně kvalitní jako voxely a to z toho důvodu že se teselace aplikuje pouze na hotové polygony. Jako krásný příklad poslouží protnutí stromu se zemí.Kromě toho všichni víme kolik výkonu vzhledem k výsledku sežere.Bump-mapping je zde právě z toho důvodu že větší počet polygonu ve scéně rapidně snižuje výkon.Co se týče ovladačů, nástrojů i samotného API je zde samozřejmě velký problém s kompatibilitou.Ovšem největší problém této technologie spočívá v animacích a samotné fyzice.K uvedení do pohybu jediného objektu (postavy) je zapotřebí opravdu silné grafické karty. Nicméně jako příklad uvádím engin kterému zdá se pohyb byť jen v malém měřítku problém nedělá.http://www.atomontage.com/ .Ať už chceme nebo ne, voxely jsou budoucnosti počítačové grafiky a to z toho důvodu že jsou přirozenější, usnadňují práci vývojářům (jeden LOD model, realistická fyzika materiálů,atd..) a v neposlední řadě působí mnohem věrněji.
+1
0
-1
Je komentář přínosný?
Martin Šefl https://diit.cz/profil/orten
3. 8. 2011 - 02:37https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseI když budou hry od začátku přizpůsobeny masivní teselaci nikdy nebudou stejně kvalitní jako voxely a to z toho důvodu že se teselace aplikuje pouze na hotové polygony. Jako krásný příklad poslouží protnutí stromu se zemí.Kromě toho všichni víme kolik výkonu vzhledem k výsledku sežere.Bump-mapping je zde právě z toho důvodu že větší počet polygonu ve scéně rapidně snižuje výkon.Co se týče ovladačů, nástrojů i samotného API je zde samozřejmě velký problém s kompatibilitou.Ovšem největší problém této technologie spočívá v animacích a samotné fyzice.K uvedení do pohybu jediného objektu (postavy) je zapotřebí opravdu silné grafické karty. Nicméně jako příklad uvádím engin kterému zdá se pohyb byť jen v malém měřítku problém nedělá.http://www.atomontage.com/ .Ať už chceme nebo ne, voxely jsou budoucnosti počítačové grafiky a to z toho důvodu že jsou přirozenější, usnadňují práci vývojářům (jeden LOD model, realistická fyzika materiálů,atd..) a v neposlední řadě působí mnohem věrněji.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593210
+
Nejsem grafik, ale není jediný LOD model i při využití teselace?
+1
0
-1
Je komentář přínosný?
webwalker https://diit.cz/profil/webwalker
3. 8. 2011 - 08:54https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseNejsem grafik, ale není jediný LOD model i při využití teselace?https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593219
+
Nemyslím. Teselace není všmocná. je to už spíše to finální vyhlazení a zvýšení drobných detailů pro velmi krátké vzdálenosti, ale stejně budeš potřebovat více LOD modelů, aby jsi na desítky či stovky metrů nemusel vykreslovat tak velké množství polygonů (byť základní model s vypnutou teselací).
+1
0
-1
Je komentář přínosný?
Shal https://diit.cz/profil/shal
3. 8. 2011 - 11:30https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseNemyslím. Teselace není všmocná. je to už spíše to finální vyhlazení a zvýšení drobných detailů pro velmi krátké vzdálenosti, ale stejně budeš potřebovat více LOD modelů, aby jsi na desítky či stovky metrů nemusel vykreslovat tak velké množství polygonů (byť základní model s vypnutou teselací).https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593239
+
3. 8. 2011 - 11:39https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseAno je, ovšem zatím se tento způsob nepoužívá
https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593241
+
A ještě jeden odkaz (aneb domyslete firmu, která nemůže z bezpečnostních důvodů implemetovat webGL do svého prohlížeče a chybí tam, nápovědou je xbox):
K článku: Také bych jako Orten tuto technologii předem neschazoval. Navíc v době vícejader. Čas ukáže co bylo jen chvástání se. Co tam nepadlo je závislost na OS.
+1
0
-1
Je komentář přínosný?
gurulix https://diit.cz/profil/gurulix
3. 8. 2011 - 03:54https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseNa umrtvování se pracovalo před více než 13 lety. Ani spoluvytvoření nového API nezachránilo Silicon Graphics (OpenGL) o 11 let později od bankrotu.
Doporučuji přečíst:
http://en.wikipedia.org/wiki/Comparison_of_Direct3D_and_OpenGL
A ještě jeden odkaz (aneb domyslete firmu, která nemůže z bezpečnostních důvodů implemetovat webGL do svého prohlížeče a chybí tam, nápovědou je xbox):
http://en.wikipedia.org/wiki/Khronos_Group
K článku: Také bych jako Orten tuto technologii předem neschazoval. Navíc v době vícejader. Čas ukáže co bylo jen chvástání se. Co tam nepadlo je závislost na OS.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593212
+
Vcera som to objavil, myslim ze to vcera vyslo :)) treba to sledovat :)
+1
0
-1
Je komentář přínosný?
Exhumanizator https://diit.cz/profil/fero77ke
3. 8. 2011 - 08:02https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseVcera som to objavil, myslim ze to vcera vyslo :)) treba to sledovat :)https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593214
+
Ono to ma totiz daleko prozaictejsi duvod. Nelze zamenovat dva rozdilne fyzikalni popisy v nasem pripade nelze zamenovat popis zalozeny na mechanice za kinematicky model/teorii. Nelze infinitezimalni veliciny zamenit za molekuly (castice). Vektorove operatory (div grad rot nabla laplace ...) nelze pouzit na bodove objekty. Predpokladam, ze jejich casticovy model netvori vektorove pole.
+1
0
-1
Je komentář přínosný?
Lada1 https://diit.cz/profil/lada1
3. 8. 2011 - 08:56https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseOno to ma totiz daleko prozaictejsi duvod. Nelze zamenovat dva rozdilne fyzikalni popisy v nasem pripade nelze zamenovat popis zalozeny na mechanice za kinematicky model/teorii. Nelze infinitezimalni veliciny zamenit za molekuly (castice). Vektorove operatory (div grad rot nabla laplace ...) nelze pouzit na bodove objekty. Predpokladam, ze jejich casticovy model netvori vektorove pole.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593220
+
Voxelová grafika i jejich akcelerátory se používají. Například v lékařství, data z tomografů jsou prostorová, nikoliv povrchová.
U herních systémů je ta potíž, že se všechno postavilo na vykreslení jednoho trojúhelníku. To jde rychle. Jen těch trojúhelníků nemí být moc.
Toto se obcházelo (ano obcházelo), texturami, které dělaly dojem, že to není plocha. Na stínech a bočních pohledech to ale vidět jde. To se obcházelo ješte jinak.
Takže, celá ta věž stojí na chatrném základu (malém množství trojúhelníků) a nad tím se staví domeček z karet, který mnoho věcí neumožňuje (například raytracing).
Udělat z trojúhelníků dokonalou kouli nelze. Přitom koule je zrovna matematicky jeden z nejjednodušších útvarů. Takový PovRAY raytracer nestaví na trouhelnících, ale na matematickém popisu objeků. To, co z toho leze jsou přesné geometrické útvary, které jsou snadno animovat. Bohužel máme akcelerátory trojúhelníků, nemáme akcelerátory paprsků.
+1
-1
-1
Je komentář přínosný?
Heron https://diit.cz/profil/heron
3. 8. 2011 - 10:54https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseVoxelová grafika i jejich akcelerátory se používají. Například v lékařství, data z tomografů jsou prostorová, nikoliv povrchová.
U herních systémů je ta potíž, že se všechno postavilo na vykreslení jednoho trojúhelníku. To jde rychle. Jen těch trojúhelníků nemí být moc.
Toto se obcházelo (ano obcházelo), texturami, které dělaly dojem, že to není plocha. Na stínech a bočních pohledech to ale vidět jde. To se obcházelo ješte jinak.
Takže, celá ta věž stojí na chatrném základu (malém množství trojúhelníků) a nad tím se staví domeček z karet, který mnoho věcí neumožňuje (například raytracing).
Udělat z trojúhelníků dokonalou kouli nelze. Přitom koule je zrovna matematicky jeden z nejjednodušších útvarů. Takový PovRAY raytracer nestaví na trouhelnících, ale na matematickém popisu objeků. To, co z toho leze jsou přesné geometrické útvary, které jsou snadno animovat. Bohužel máme akcelerátory trojúhelníků, nemáme akcelerátory paprsků.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593235
+
nejde o nic noveho pod sluncem, Voxelovych engine je spousta,
tenhle se jen snazi o 'tezky' PR pres hype ...
osobne vim o minimalne jednom jinem ktery povazuji za podstatne vyspelejsi pro adaptaci ve hrach ...
+1
0
-1
Je komentář přínosný?
David Foltyn https://diit.cz/profil/dwarden
3. 8. 2011 - 10:56https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskusenejde o nic noveho pod sluncem, Voxelovych engine je spousta,
tenhle se jen snazi o 'tezky' PR pres hype ...
osobne vim o minimalne jednom jinem ktery povazuji za podstatne vyspelejsi pro adaptaci ve hrach ...https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593236
+
3. 8. 2011 - 11:40https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseMyslíš ten Atomontage, o kterém píše Orten?https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593242
+
a ano, Atomontage znam jiz nejakou dobu a rozhodne bych po nem sahnul driv v ramci voxelovych engine
+1
0
-1
Je komentář přínosný?
David Foltyn https://diit.cz/profil/dwarden
4. 8. 2011 - 03:26https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskusehttp://notch.tumblr.com/post/8386977075/its-a-scam
http://notch.tumblr.com/post/8423008802/but-notch-its-not-a-scam
a ano, Atomontage znam jiz nejakou dobu a rozhodne bych po nem sahnul driv v ramci voxelovych enginehttps://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593319
+
Pokud by se to dalo skloubit s klasickým polygonálním renderováním a využít například pro statické objekty, tak by to nemuselo být špatné. Pro fyzikální engine by se kolem toho hodil low-poly model (na kolize), jako se to dělá dneska.
Akorát vidím problém s nasvícením, určitě by se osvětlení (ať už globální nebo lokální) na tomhle objektu projevilo jinak, než na ostatních poly objektech takže by to vypadalo nesourodě.
Celkem by mě zajímaly algoritmy jakými to kreslí...jo a taky stroj na kterém to běželo (jestli je to normální PC nebo nějaká farma)
+1
0
-1
Je komentář přínosný?
Ondřej Petržilka https://diit.cz/profil/pixel-0
3. 8. 2011 - 11:39https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskusePokud by se to dalo skloubit s klasickým polygonálním renderováním a využít například pro statické objekty, tak by to nemuselo být špatné. Pro fyzikální engine by se kolem toho hodil low-poly model (na kolize), jako se to dělá dneska.
Akorát vidím problém s nasvícením, určitě by se osvětlení (ať už globální nebo lokální) na tomhle objektu projevilo jinak, než na ostatních poly objektech takže by to vypadalo nesourodě.
Celkem by mě zajímaly algoritmy jakými to kreslí...jo a taky stroj na kterém to běželo (jestli je to normální PC nebo nějaká farma)https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593240
+
Kolize jsou úplně v pohodě viz odkaz na živě výše...
+1
0
-1
Je komentář přínosný?
mamlasos1 https://diit.cz/profil/mamlasos1
3. 8. 2011 - 11:48https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseKolize jsou úplně v pohodě viz odkaz na živě výše...https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593245
+
Což o to, vykreslit by to šlo. Pokud by to byly skutečné pixely, tak po transformaci máš jejich x a y souradnice pro obraz. Ty nejbližší stačí vykreslit. U polygonu se postupuje stějně, body ohraničují trojuhelník. V tom problém nebude.
Mě by spíše zajímalo na čem dělají ty transformace. Těch bodů je tam skutečně hodně a i když se vykresluje jen pár px (1.5Mpx), tak je stejně nutné otransformovat pár miliard(?) bodů.
Asi to mají v nějakých skupinách, které podléhají transformaci jako celek a pak se podle viditelnosti dotransformují jednotlivé px.
V každém případě, mě to uchvátilo. Konečně se taky něco děje.
+1
0
-1
Je komentář přínosný?
Heron https://diit.cz/profil/heron
3. 8. 2011 - 15:54https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseCož o to, vykreslit by to šlo. Pokud by to byly skutečné pixely, tak po transformaci máš jejich x a y souradnice pro obraz. Ty nejbližší stačí vykreslit. U polygonu se postupuje stějně, body ohraničují trojuhelník. V tom problém nebude.
Mě by spíše zajímalo na čem dělají ty transformace. Těch bodů je tam skutečně hodně a i když se vykresluje jen pár px (1.5Mpx), tak je stejně nutné otransformovat pár miliard(?) bodů.
Asi to mají v nějakých skupinách, které podléhají transformaci jako celek a pak se podle viditelnosti dotransformují jednotlivé px.
V každém případě, mě to uchvátilo. Konečně se taky něco děje.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593277
+
Hezké, polygony to nenahradí, ale nevidím důvod, proč by to nemohlo existovat společně. Ne všechny hry musí být nutně "skutečně 3D". Leckteré výtvarné zpracování 3D grafiky naopak bude vypadat mnohem lépe ve Voxelech a fyziky netřeba. Záleží na žánru hry atd...
Už na osmibitech se používaly všelijaké triky, jak vylepšit dojem ze hry na slabém hardwaru. Přijde mi, že se to postupně vytratilo pod tlakem metody "umíme 3D grafiku, tak tím budeme dělat všechno". Přitom třeba spritové Age Of Empires II vypadaly mnohem lépe, než bezprostředně následující Age Of Mythology používající polygony. Podobně prastaré Theme Hospital od Bullfrogu působilo příjemněji než následovníci typu Hospital Tycoon ...
Tím chci říct, že není důležité jestli je nějaká technologie lepší, nebo superúžasná ..., mnohem důležitější je správná volba pro konkrétní účel. A teprve kombinace vzhledu, zvuku, hratelnosti a chytrého nápadu dělá dobrou hru. Jedno bez druhého nejde.
+1
+1
-1
Je komentář přínosný?
zx cygnus https://diit.cz/profil/cygnus
3. 8. 2011 - 11:48https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseHezké, polygony to nenahradí, ale nevidím důvod, proč by to nemohlo existovat společně. Ne všechny hry musí být nutně "skutečně 3D". Leckteré výtvarné zpracování 3D grafiky naopak bude vypadat mnohem lépe ve Voxelech a fyziky netřeba. Záleží na žánru hry atd...
Už na osmibitech se používaly všelijaké triky, jak vylepšit dojem ze hry na slabém hardwaru. Přijde mi, že se to postupně vytratilo pod tlakem metody "umíme 3D grafiku, tak tím budeme dělat všechno". Přitom třeba spritové Age Of Empires II vypadaly mnohem lépe, než bezprostředně následující Age Of Mythology používající polygony. Podobně prastaré Theme Hospital od Bullfrogu působilo příjemněji než následovníci typu Hospital Tycoon ...
Tím chci říct, že není důležité jestli je nějaká technologie lepší, nebo superúžasná ..., mnohem důležitější je správná volba pro konkrétní účel. A teprve kombinace vzhledu, zvuku, hratelnosti a chytrého nápadu dělá dobrou hru. Jedno bez druhého nejde.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593244
+
Neni to nic novýho. Reálny komerční použití, až na to bude HW. Tak za 20 let. Není problem, vytvořit jednu strukturu. Ale stovky nebo 1000 ce. To už zabere nějaký data. A další věc je fyzika. Tzn demo pekny, ale zatim nevyuzitelny.
+1
0
-1
Je komentář přínosný?
Samboush https://diit.cz/profil/samboush
3. 8. 2011 - 12:31https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseNeni to nic novýho. Reálny komerční použití, až na to bude HW. Tak za 20 let. Není problem, vytvořit jednu strukturu. Ale stovky nebo 1000 ce. To už zabere nějaký data. A další věc je fyzika. Tzn demo pekny, ale zatim nevyuzitelny.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593258
+
Tohle vypadá na obdobu raytracingu (jinak by to hafo "čehosi" nedokázali v rozumném čase zobrazit). A u toho je hlavně problém s pohybem (animací). Takže až budou umět animaci, pak ať ukazujou videa :D
+1
0
-1
Je komentář přínosný?
Ondar https://diit.cz/profil/ondar007
3. 8. 2011 - 12:42https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseTohle vypadá na obdobu raytracingu (jinak by to hafo "čehosi" nedokázali v rozumném čase zobrazit). A u toho je hlavně problém s pohybem (animací). Takže až budou umět animaci, pak ať ukazujou videa :Dhttps://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593259
+
Vypada to na obdobu raytracingu? Dovolim si drzou otazku > V cem ?!?!
A jelikoz by to mohla byt obdoba raytracingu - tak to najednou jsou schopni zobrazit v rozumnem case? No, to je taky odvazny odhad. :-D
+1
+1
-1
Je komentář přínosný?
Er Nestor https://diit.cz/profil/ernest
3. 8. 2011 - 19:41https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseVypada to na obdobu raytracingu? Dovolim si drzou otazku > V cem ?!?!
A jelikoz by to mohla byt obdoba raytracingu - tak to najednou jsou schopni zobrazit v rozumnem case? No, to je taky odvazny odhad. :-Dhttps://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593301
+
V rychlosti jsem procetl mnohe komentare a obcas musim souhlasit a obcas mam pocit, ze nektere hlavni myslenky zustaly nedotceny.
Zkraje bych se rad dostal k te fyzice a castecne i k animaci. Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna. Ac co vyvojar to ruzna implementace, fyzikalni model mnohdy neni to same co graficky model. Ackoliv se obcas vyvojari uchyli k generovani fyzikalniho modelu z "grafickych" modelu pri behu hry, casto se presto jedna o samostatne vymodelovane objekty urcene jen a jen pro fyziku - at uz je treba predgeneroval nejaky editor z "grafickych" dat. Vypocet fyziky pak ma dve casti a zde je zejmena relevantni "detekce kolize", kterou povazuji za narocnejsi. Shodou okolnosti se vsak velka cast teto detekce dela pomoci objemu (sem se slovo voxel nehodi). Nejidealnejsi je pak detekce pruniku dvou kouli/sphere. Takze teoreticky je problem s voxelovymi daty? NE. Pac se daji chapat jako model poskladany z objemu. V realu pak model pro detekci kolize obsahuje nekolik urovni/detailu objemu, tak aby se testovali pruniky jen "hrube" a teprve po zjisteni kolize se dopocital presnejsi bod kolize z "jemnejsich" dat -> coz ale porad nijak zvlast nehranici s tim co bylo v prezentaci ukazano.
Druha cast fyzikalnich simulaci pak abstrahuje na teziste - proste bod o nejake hmotnosti a par vektoru k tomu. Tam uz je nejaky tvar vlastne docela irelevantni.
Animace jsou trosku slozitejsi, aktualne se s oblibou model vybavi kostrou a jednotlivym vrcholum/vertexum se rekne, jak moc/jakou vahou se maji ridit posunem nejake kosti v kostre - to umoznuje ruzne natahovani a smrstovani a vubec nejakou pruznost "hmoty" kolem kostry. Ale proc by neslo toto rict taky "atomum" (voxelum jestli chcete). Ale souhlasim s tim, ze mnoho algoritmu jiz napsanych proste zatim pocita s polygony a problem je ciste v tom, ze da jedndoduse praci vsechno prepsat - verim, ze by to nemuselo byt v tomto pripade nejako brutalne slozite.
Kde vidim problemy? No jednoznacne mnozstvi dat! A jednoznacne vyber pixelu. Ono propocitat co ma byt videt a co ne, je docela zajimavy a slozity problem, na ktery se stale hledaji nove a nove postupy. Nedokazu si aktualne predstavit jak vybiraji z pohledu na miliardy atomu, co ma byt a co nema byt videt. Ostatne to je jedno z hlavnich tajemstvi jejich uspechu.
Trosku me pak zarazil komentar autora clanku, ze mohou mit predstavu jak to delat a jak ziskat pri softwarovem renderingu takove hodnoty FPS. Asi tusi neco vice nez ja po par letech studia a zajmu :-) zavidim!
A k osvetlovani a zastaralemu vzhledu. Kdyz nad tim premyslim, klasicke metody vyslovene tezily z toho, ze existuje nejaky "povrch" u ktereho lze docela snadno simulovat nejake svetelne vlastnosti - zakladajici se na ruznych vektorech/barvach. V dobe shaderu, se samozrejme osvetlovaci model muze zakladat na temer libovolnych datech a neobvyklych vypoctech - ackoliv vysledkem ne vzdy budou realisticke obrazy. Ale u voxelu? Namapovat vsechny potrebne udaje na takove mnozstvi castic vidim jako docela slozite. Varianta, kdy ma kazda castice vsechny udaje uz z modelu, ve me jen vyvolava pocit obrovskeho mnozstvi dat?! Takze je to jedna z klasickych otazek - sezrat hromadu pameti, nebo sezrat hromadu vykonu?
no, trosku sem se rozepsal, uz koncim, dekuji
+1
0
-1
Je komentář přínosný?
Er Nestor https://diit.cz/profil/ernest
3. 8. 2011 - 19:29https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseV rychlosti jsem procetl mnohe komentare a obcas musim souhlasit a obcas mam pocit, ze nektere hlavni myslenky zustaly nedotceny.
Zkraje bych se rad dostal k te fyzice a castecne i k animaci. Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna. Ac co vyvojar to ruzna implementace, fyzikalni model mnohdy neni to same co graficky model. Ackoliv se obcas vyvojari uchyli k generovani fyzikalniho modelu z "grafickych" modelu pri behu hry, casto se presto jedna o samostatne vymodelovane objekty urcene jen a jen pro fyziku - at uz je treba predgeneroval nejaky editor z "grafickych" dat. Vypocet fyziky pak ma dve casti a zde je zejmena relevantni "detekce kolize", kterou povazuji za narocnejsi. Shodou okolnosti se vsak velka cast teto detekce dela pomoci objemu (sem se slovo voxel nehodi). Nejidealnejsi je pak detekce pruniku dvou kouli/sphere. Takze teoreticky je problem s voxelovymi daty? NE. Pac se daji chapat jako model poskladany z objemu. V realu pak model pro detekci kolize obsahuje nekolik urovni/detailu objemu, tak aby se testovali pruniky jen "hrube" a teprve po zjisteni kolize se dopocital presnejsi bod kolize z "jemnejsich" dat -> coz ale porad nijak zvlast nehranici s tim co bylo v prezentaci ukazano.
Druha cast fyzikalnich simulaci pak abstrahuje na teziste - proste bod o nejake hmotnosti a par vektoru k tomu. Tam uz je nejaky tvar vlastne docela irelevantni.
Animace jsou trosku slozitejsi, aktualne se s oblibou model vybavi kostrou a jednotlivym vrcholum/vertexum se rekne, jak moc/jakou vahou se maji ridit posunem nejake kosti v kostre - to umoznuje ruzne natahovani a smrstovani a vubec nejakou pruznost "hmoty" kolem kostry. Ale proc by neslo toto rict taky "atomum" (voxelum jestli chcete). Ale souhlasim s tim, ze mnoho algoritmu jiz napsanych proste zatim pocita s polygony a problem je ciste v tom, ze da jedndoduse praci vsechno prepsat - verim, ze by to nemuselo byt v tomto pripade nejako brutalne slozite.
Kde vidim problemy? No jednoznacne mnozstvi dat! A jednoznacne vyber pixelu. Ono propocitat co ma byt videt a co ne, je docela zajimavy a slozity problem, na ktery se stale hledaji nove a nove postupy. Nedokazu si aktualne predstavit jak vybiraji z pohledu na miliardy atomu, co ma byt a co nema byt videt. Ostatne to je jedno z hlavnich tajemstvi jejich uspechu.
Trosku me pak zarazil komentar autora clanku, ze mohou mit predstavu jak to delat a jak ziskat pri softwarovem renderingu takove hodnoty FPS. Asi tusi neco vice nez ja po par letech studia a zajmu :-) zavidim!
A k osvetlovani a zastaralemu vzhledu. Kdyz nad tim premyslim, klasicke metody vyslovene tezily z toho, ze existuje nejaky "povrch" u ktereho lze docela snadno simulovat nejake svetelne vlastnosti - zakladajici se na ruznych vektorech/barvach. V dobe shaderu, se samozrejme osvetlovaci model muze zakladat na temer libovolnych datech a neobvyklych vypoctech - ackoliv vysledkem ne vzdy budou realisticke obrazy. Ale u voxelu? Namapovat vsechny potrebne udaje na takove mnozstvi castic vidim jako docela slozite. Varianta, kdy ma kazda castice vsechny udaje uz z modelu, ve me jen vyvolava pocit obrovskeho mnozstvi dat?! Takze je to jedna z klasickych otazek - sezrat hromadu pameti, nebo sezrat hromadu vykonu?
no, trosku sem se rozepsal, uz koncim, dekujihttps://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593300
+
V tomhle případě hodně paměti i hodně výkonu. Podle mne bude close future kombinovat rasterizační techniky s raytracingem.
+1
0
-1
Je komentář přínosný?
Samboush https://diit.cz/profil/samboush
3. 8. 2011 - 20:15https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseV tomhle případě hodně paměti i hodně výkonu. Podle mne bude close future kombinovat rasterizační techniky s raytracingem.https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593305
+
Tam je jedna strasne zasadni otazka, jak se dela vyber toho co bude videt... mam teoreticky tri moznosti, bud pro pixel vykreslim vsechny elementy a ponecham si barvu jen toho nejblizsiho (coz dela rasterizace), budu dopredu znat intervaly mezi prostorem a hmotou/voxely a tim i budu vedet kde je jejich rozhrani (velice stary, problematicky a teoreticky postup) - vyhoda je, ze se pohybuju v nejake pevne mrizce s pouzitim celych cisel (to se hodi vzdy), nebo budu z pozice kamery sledovat paprsek vychazejici z pomyslne kamery skrze body mrizky/rastru/bodu obrazovky a pak musim udelat onu slozitou detekci kolize, podobne jako jsem to zminoval u fyziky....
Pokud budeme tedy uvazovat treti moznost, raytracing, mam trosku problem s predstavou, ze pocitam potencialni prusecik primky s kazdym mnoha elementu, ktere autori pouzivaji. Ostatne vzpomente si na rovnici pro primku, hned na nas vyskoci desetina cisla/plovouci desetina carka. Tady se ale da vyuzit to, ze se pohybujem v diskretni mrizce, takze teoreticky, neni treba vykonavat slozite vypocty. Ma to ale svuj hacek, musi se otestovat kazdy bod na trase paprsku... takze cim dal objekt bude, tim dele ho budu hledat. Jestli se autori vydavaji touto cestou - o cemz trosku pochybuju - je jejich vyhoda zrejme postavena na hratkach se statistikou.
ale je to docela uvaha od boku... tak i tak bych byl opatrny s uzitim slov jako je "raytracing".
+1
-1
-1
Je komentář přínosný?
Er Nestor https://diit.cz/profil/ernest
3. 8. 2011 - 23:23https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseTam je jedna strasne zasadni otazka, jak se dela vyber toho co bude videt... mam teoreticky tri moznosti, bud pro pixel vykreslim vsechny elementy a ponecham si barvu jen toho nejblizsiho (coz dela rasterizace), budu dopredu znat intervaly mezi prostorem a hmotou/voxely a tim i budu vedet kde je jejich rozhrani (velice stary, problematicky a teoreticky postup) - vyhoda je, ze se pohybuju v nejake pevne mrizce s pouzitim celych cisel (to se hodi vzdy), nebo budu z pozice kamery sledovat paprsek vychazejici z pomyslne kamery skrze body mrizky/rastru/bodu obrazovky a pak musim udelat onu slozitou detekci kolize, podobne jako jsem to zminoval u fyziky....
Pokud budeme tedy uvazovat treti moznost, raytracing, mam trosku problem s predstavou, ze pocitam potencialni prusecik primky s kazdym mnoha elementu, ktere autori pouzivaji. Ostatne vzpomente si na rovnici pro primku, hned na nas vyskoci desetina cisla/plovouci desetina carka. Tady se ale da vyuzit to, ze se pohybujem v diskretni mrizce, takze teoreticky, neni treba vykonavat slozite vypocty. Ma to ale svuj hacek, musi se otestovat kazdy bod na trase paprsku... takze cim dal objekt bude, tim dele ho budu hledat. Jestli se autori vydavaji touto cestou - o cemz trosku pochybuju - je jejich vyhoda zrejme postavena na hratkach se statistikou.
ale je to docela uvaha od boku... tak i tak bych byl opatrny s uzitim slov jako je "raytracing".https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593314
+
Tohle u raytracingu není problém. Pokud mám rozumně ohraničené objekty (např kámen), tak nejprve otestuju bounding box (což je průsečík paprsku s krychlí, koulí nebo něčím podobně jednoduchým co obsahuje celý objekt) a až když paprsek do bounding boxu vletí, testuju jestli protne jednotlivé plochy kamene a tak.
Bounding boxy mohou být hierarchické (např. bounding box postavy, v něm je bounding box jednotlivých částí těla, např. ruka, ruka pak má bounding boxy jednotlivých prstů a až když se paprsek trefí i do bounding boxu prstu tak pak řeším jednotlivou plošku (např. který kus nehtu) a pro statické scény lze použít k-d-stromy a pak každý paprsek místo aby se testoval průsečík s miliardami objektů scény tak se otestuje třeba jen s tisícovkou různých bounding boxů, dokud se netrefí přesně do nějakého malého ohraničeného objektu.
Pokud dokážu objekty generovat (např. je ve scéně X stejných nebo podobných objektů) tak není problém v rozumném čase i s dnešním HW vyrenderovat raytracingem např. krajinu s miliardami stromů, kdy každý strom se skládá třeba z milionu polygonů nebo koulí, atomů nebo čehokoliv.
Problém ale nastává pokud se věci začnou hýbat (k-d-stromy fungujou jen na statické scény) a trochu problém pak může být i osvětlení (jakmile paprsek narazí na objekt, tak ještě musím spočítat jak je osvětlen, jenže nestačí jen poslat jeden paprsek do každého zdroje světla, jelikož je i nepřímé osvětlení, tak těch paprků je potřeba posílat celkem dost aby to vypadalo realisticky :) I tady to ale lze různě urychlit a zjednodušit různými aproximativními algoritmy, kdy lze ovětlení spočítat o dost rychleji s dostatečně dobrou přesností, že si nikdo nevšimne rozdílu.
Vzhledem k tomu že mají problém právě s osvělením bych to tipoval na raytracing.
+1
+1
-1
Je komentář přínosný?
Bilbo https://diit.cz/profil/bilbo1
4. 8. 2011 - 01:34https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseTohle u raytracingu není problém. Pokud mám rozumně ohraničené objekty (např kámen), tak nejprve otestuju bounding box (což je průsečík paprsku s krychlí, koulí nebo něčím podobně jednoduchým co obsahuje celý objekt) a až když paprsek do bounding boxu vletí, testuju jestli protne jednotlivé plochy kamene a tak.
Bounding boxy mohou být hierarchické (např. bounding box postavy, v něm je bounding box jednotlivých částí těla, např. ruka, ruka pak má bounding boxy jednotlivých prstů a až když se paprsek trefí i do bounding boxu prstu tak pak řeším jednotlivou plošku (např. který kus nehtu) a pro statické scény lze použít k-d-stromy a pak každý paprsek místo aby se testoval průsečík s miliardami objektů scény tak se otestuje třeba jen s tisícovkou různých bounding boxů, dokud se netrefí přesně do nějakého malého ohraničeného objektu.
Pokud dokážu objekty generovat (např. je ve scéně X stejných nebo podobných objektů) tak není problém v rozumném čase i s dnešním HW vyrenderovat raytracingem např. krajinu s miliardami stromů, kdy každý strom se skládá třeba z milionu polygonů nebo koulí, atomů nebo čehokoliv.
Problém ale nastává pokud se věci začnou hýbat (k-d-stromy fungujou jen na statické scény) a trochu problém pak může být i osvětlení (jakmile paprsek narazí na objekt, tak ještě musím spočítat jak je osvětlen, jenže nestačí jen poslat jeden paprsek do každého zdroje světla, jelikož je i nepřímé osvětlení, tak těch paprků je potřeba posílat celkem dost aby to vypadalo realisticky :) I tady to ale lze různě urychlit a zjednodušit různými aproximativními algoritmy, kdy lze ovětlení spočítat o dost rychleji s dostatečně dobrou přesností, že si nikdo nevšimne rozdílu.
Vzhledem k tomu že mají problém právě s osvělením bych to tipoval na raytracing.
https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593317
+
> Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna
To jo. S fyzikou v jejich modelu nevidím problém proto, že by neměly polygonu, ale proto, že tam mají tolik částic. Když mám najednou rozpohybovat několik miliard zrnek hlíny, které můžou všelijak navzájem kolidovat se sebou a s okolím, tak je jedno jestli jsou z polygonů nebo atomů, žádný současný CPU ani GPU to v reálném čase neutáhne :)
+1
+1
-1
Je komentář přínosný?
Bilbo https://diit.cz/profil/bilbo1
4. 8. 2011 - 01:47https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse> Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna
To jo. S fyzikou v jejich modelu nevidím problém proto, že by neměly polygonu, ale proto, že tam mají tolik částic. Když mám najednou rozpohybovat několik miliard zrnek hlíny, které můžou všelijak navzájem kolidovat se sebou a s okolím, tak je jedno jestli jsou z polygonů nebo atomů, žádný současný CPU ani GPU to v reálném čase neutáhne :)https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593318
+
Z vlastnich zkusenosti musim potvrdit, ze dokud se clovek opravdu vazneji nepokusi pouzivat nejake urychlujici struktury (programujicim doporucuju vyzkouset, je to dost zabavne) ... tak vykon trpi. Ostatne ty metody jsou natolik obecne, ze je jedno jestli mam deleni prostoru a hierarchii pouzitou pro raytrace ci rasterizaci.
A s tim osvetlenim - opet musim potvrdit - pokusit se o simulaci globalni iluminace je vykonovy zabijak (opet stoji za vyzkouseni). Clovek vyplaca stovky paprsku na jeden pixel aby pak zjistitl, ze vysledek je stejne zrnity a musi pouzit bud dalsi hromadu paprsku (nebo nejaky dobry svindl...samozrejme).
Ono cele je to vubec otazka, jak moc maji nastavena omezeni. Par tisic castic poletujicich ve vzduchu tu uz prezentoval kdekdo, ale tezko muzem cekat, ze budou simulovat sterkovou cestu v zavodni hre. Ostatne stejne jako s grafikou - existuje nejaka mez, kde jeste je zajimave/ma smysl pokouset se o detailni simulaci. - Pak se opet clovek dostava k tomu, co lze aproximovat (a to nejen u raytraceru).
A jeste jedna neznama, proc by jim to s nejakou konvencni metodou slo a konkurenci ne.
+1
0
-1
Je komentář přínosný?
Er Nestor https://diit.cz/profil/ernest
4. 8. 2011 - 09:42https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseZ vlastnich zkusenosti musim potvrdit, ze dokud se clovek opravdu vazneji nepokusi pouzivat nejake urychlujici struktury (programujicim doporucuju vyzkouset, je to dost zabavne) ... tak vykon trpi. Ostatne ty metody jsou natolik obecne, ze je jedno jestli mam deleni prostoru a hierarchii pouzitou pro raytrace ci rasterizaci.
A s tim osvetlenim - opet musim potvrdit - pokusit se o simulaci globalni iluminace je vykonovy zabijak (opet stoji za vyzkouseni). Clovek vyplaca stovky paprsku na jeden pixel aby pak zjistitl, ze vysledek je stejne zrnity a musi pouzit bud dalsi hromadu paprsku (nebo nejaky dobry svindl...samozrejme).
Ono cele je to vubec otazka, jak moc maji nastavena omezeni. Par tisic castic poletujicich ve vzduchu tu uz prezentoval kdekdo, ale tezko muzem cekat, ze budou simulovat sterkovou cestu v zavodni hre. Ostatne stejne jako s grafikou - existuje nejaka mez, kde jeste je zajimave/ma smysl pokouset se o detailni simulaci. - Pak se opet clovek dostava k tomu, co lze aproximovat (a to nejen u raytraceru).
A jeste jedna neznama, proc by jim to s nejakou konvencni metodou slo a konkurenci ne. https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593344
+
Viz video- co že celý ten rok co o nich nikdo nešlyšel dělali?? Před rokem udělali kámen do hry, a pak celý rok hledaly nějaký který se mu bude podobataby ho mohli dát na promo video :D
jinak tomuhle vůbec nerozumím, ale když se řešily ty stíny a pod, přece by to šlo zkombinovat s nějakou low-polygonovou mapou na které by už bylo jasné kde mají stíny padat, jak se má postava hýbat + tohle by bylo pozlátko na tom ne??
+1
0
-1
Je komentář přínosný?
NoDicz https://diit.cz/profil/nodicz
4. 8. 2011 - 00:00https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuseViz video- co že celý ten rok co o nich nikdo nešlyšel dělali?? Před rokem udělali kámen do hry, a pak celý rok hledaly nějaký který se mu bude podobataby ho mohli dát na promo video :D
jinak tomuhle vůbec nerozumím, ale když se řešily ty stíny a pod, přece by to šlo zkombinovat s nějakou low-polygonovou mapou na které by už bylo jasné kde mají stíny padat, jak se má postava hýbat + tohle by bylo pozlátko na tom ne??https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskuse#comment-593315
+
Diskuse k Euclideon: Revoluce ve 3D grafice?https://diit.cz/clanek/euclideon-revoluce-ve-3d-grafice/diskusehttps://diit.cz/sites/default/files/diit-logo.png
No, ještě mi tam neštymuje jedna věc – že je tam jen pár naprosto stejných objektů, které jsou tisíckrát naklonované (obdobně jako v úvodu ukázky) a ve výsledku to vypadá jako Minecraft ve vyšším rozlišení.
Ale jinak celkem dává smysl, že když se s meshem jde na úroveň polygonů o velikosti několika pixelů, přestává polygonová síť už tak nějak dávat smysl a voxely vypadají rozumněji.
Ale kdy to bude použitelné... S nostalgií vzpomínám na "vizionáře", kteří viděli demo na Cinema 2.0 s Ruby a těšili se, jak máme na Radeonech
za dva, tři roky ve hrách fotorealistickou grafiku
Asi největší problém vidím ve fyzice, jakmile se něco takového má rozumně a realisticky rozhýbat (např. kopnu do země a vyletí hrstka štěrku) tak najednou je to se složitostí poněkud jinde :)
Tohle chce podporu v HW jinak se to nehne, i na polygony to bylo potřeba (různé pixel/vertex shadery) aby se to trochu hejbalo...
Proč by to mělo být složitější, než polygony? Co se tak dívám, tak se stejně skoro všude používají pro tyto účely sprosté sprity, ty se dají dodat do jakéhokoli enginu. U animací (třeba postav) taky nevidím proti polygonům principiální zesložitění, ale je fakt, že to je podstatná část enginu, kterou očividně ještě nemají.
Animace je problém viz diskuze na zive.cz, odkaz níže.
ono to má své opodstatnění, vemte si kdyby opravdu udělali tak obrovský ostrov jak říkali a udělali by rozmanitý jako normální ostrov. Kolik by pak zabírala data tohoto ostrovu? Asi hoši dobře vědí proč to sestavují ze stejných kusů a stejnými stromy
Tak to bych chtěl vidět stejně rozmanitý ostrov udělaný v polygonech...to by byl ještě větší porod. Jenom vyrobit textury a namapovat je...opakování objektů je běžné i s polygonama tak nevím proč u nějakého dema je to najednou špatně.
I když budou hry od začátku přizpůsobeny masivní teselaci nikdy nebudou stejně kvalitní jako voxely a to z toho důvodu že se teselace aplikuje pouze na hotové polygony. Jako krásný příklad poslouží protnutí stromu se zemí.Kromě toho všichni víme kolik výkonu vzhledem k výsledku sežere.Bump-mapping je zde právě z toho důvodu že větší počet polygonu ve scéně rapidně snižuje výkon.Co se týče ovladačů, nástrojů i samotného API je zde samozřejmě velký problém s kompatibilitou.Ovšem největší problém této technologie spočívá v animacích a samotné fyzice.K uvedení do pohybu jediného objektu (postavy) je zapotřebí opravdu silné grafické karty. Nicméně jako příklad uvádím engin kterému zdá se pohyb byť jen v malém měřítku problém nedělá.http://www.atomontage.com/ .Ať už chceme nebo ne, voxely jsou budoucnosti počítačové grafiky a to z toho důvodu že jsou přirozenější, usnadňují práci vývojářům (jeden LOD model, realistická fyzika materiálů,atd..) a v neposlední řadě působí mnohem věrněji.
Nejsem grafik, ale není jediný LOD model i při využití teselace?
Nemyslím. Teselace není všmocná. je to už spíše to finální vyhlazení a zvýšení drobných detailů pro velmi krátké vzdálenosti, ale stejně budeš potřebovat více LOD modelů, aby jsi na desítky či stovky metrů nemusel vykreslovat tak velké množství polygonů (byť základní model s vypnutou teselací).
Ano je, ovšem zatím se tento způsob nepoužívá
Na umrtvování se pracovalo před více než 13 lety. Ani spoluvytvoření nového API nezachránilo Silicon Graphics (OpenGL) o 11 let později od bankrotu.
Doporučuji přečíst:
http://en.wikipedia.org/wiki/Comparison_of_Direct3D_and_OpenGL
A ještě jeden odkaz (aneb domyslete firmu, která nemůže z bezpečnostních důvodů implemetovat webGL do svého prohlížeče a chybí tam, nápovědou je xbox):
http://en.wikipedia.org/wiki/Khronos_Group
K článku: Také bych jako Orten tuto technologii předem neschazoval. Navíc v době vícejader. Čas ukáže co bylo jen chvástání se. Co tam nepadlo je závislost na OS.
Vcera som to objavil, myslim ze to vcera vyslo :)) treba to sledovat :)
Ono to ma totiz daleko prozaictejsi duvod. Nelze zamenovat dva rozdilne fyzikalni popisy v nasem pripade nelze zamenovat popis zalozeny na mechanice za kinematicky model/teorii. Nelze infinitezimalni veliciny zamenit za molekuly (castice). Vektorove operatory (div grad rot nabla laplace ...) nelze pouzit na bodove objekty. Predpokladam, ze jejich casticovy model netvori vektorove pole.
čeho litr ?
Rozsáhlejší diskuze k tématu zde:
http://www.zive.cz/titulni-strana/euclideon-vime-jak-100-000-zlepsit-poc...
Voxelová grafika i jejich akcelerátory se používají. Například v lékařství, data z tomografů jsou prostorová, nikoliv povrchová.
U herních systémů je ta potíž, že se všechno postavilo na vykreslení jednoho trojúhelníku. To jde rychle. Jen těch trojúhelníků nemí být moc.
Toto se obcházelo (ano obcházelo), texturami, které dělaly dojem, že to není plocha. Na stínech a bočních pohledech to ale vidět jde. To se obcházelo ješte jinak.
Takže, celá ta věž stojí na chatrném základu (malém množství trojúhelníků) a nad tím se staví domeček z karet, který mnoho věcí neumožňuje (například raytracing).
Udělat z trojúhelníků dokonalou kouli nelze. Přitom koule je zrovna matematicky jeden z nejjednodušších útvarů. Takový PovRAY raytracer nestaví na trouhelnících, ale na matematickém popisu objeků. To, co z toho leze jsou přesné geometrické útvary, které jsou snadno animovat. Bohužel máme akcelerátory trojúhelníků, nemáme akcelerátory paprsků.
nejde o nic noveho pod sluncem, Voxelovych engine je spousta,
tenhle se jen snazi o 'tezky' PR pres hype ...
osobne vim o minimalne jednom jinem ktery povazuji za podstatne vyspelejsi pro adaptaci ve hrach ...
Myslíš ten Atomontage, o kterém píše Orten?
http://notch.tumblr.com/post/8386977075/its-a-scam
http://notch.tumblr.com/post/8423008802/but-notch-its-not-a-scam
a ano, Atomontage znam jiz nejakou dobu a rozhodne bych po nem sahnul driv v ramci voxelovych engine
Pokud by se to dalo skloubit s klasickým polygonálním renderováním a využít například pro statické objekty, tak by to nemuselo být špatné. Pro fyzikální engine by se kolem toho hodil low-poly model (na kolize), jako se to dělá dneska.
Akorát vidím problém s nasvícením, určitě by se osvětlení (ať už globální nebo lokální) na tomhle objektu projevilo jinak, než na ostatních poly objektech takže by to vypadalo nesourodě.
Celkem by mě zajímaly algoritmy jakými to kreslí...jo a taky stroj na kterém to běželo (jestli je to normální PC nebo nějaká farma)
Kolize jsou úplně v pohodě viz odkaz na živě výše...
Což o to, vykreslit by to šlo. Pokud by to byly skutečné pixely, tak po transformaci máš jejich x a y souradnice pro obraz. Ty nejbližší stačí vykreslit. U polygonu se postupuje stějně, body ohraničují trojuhelník. V tom problém nebude.
Mě by spíše zajímalo na čem dělají ty transformace. Těch bodů je tam skutečně hodně a i když se vykresluje jen pár px (1.5Mpx), tak je stejně nutné otransformovat pár miliard(?) bodů.
Asi to mají v nějakých skupinách, které podléhají transformaci jako celek a pak se podle viditelnosti dotransformují jednotlivé px.
V každém případě, mě to uchvátilo. Konečně se taky něco děje.
Hezké, polygony to nenahradí, ale nevidím důvod, proč by to nemohlo existovat společně. Ne všechny hry musí být nutně "skutečně 3D". Leckteré výtvarné zpracování 3D grafiky naopak bude vypadat mnohem lépe ve Voxelech a fyziky netřeba. Záleží na žánru hry atd...
Už na osmibitech se používaly všelijaké triky, jak vylepšit dojem ze hry na slabém hardwaru. Přijde mi, že se to postupně vytratilo pod tlakem metody "umíme 3D grafiku, tak tím budeme dělat všechno". Přitom třeba spritové Age Of Empires II vypadaly mnohem lépe, než bezprostředně následující Age Of Mythology používající polygony. Podobně prastaré Theme Hospital od Bullfrogu působilo příjemněji než následovníci typu Hospital Tycoon ...
Tím chci říct, že není důležité jestli je nějaká technologie lepší, nebo superúžasná ..., mnohem důležitější je správná volba pro konkrétní účel. A teprve kombinace vzhledu, zvuku, hratelnosti a chytrého nápadu dělá dobrou hru. Jedno bez druhého nejde.
Neni to nic novýho. Reálny komerční použití, až na to bude HW. Tak za 20 let. Není problem, vytvořit jednu strukturu. Ale stovky nebo 1000 ce. To už zabere nějaký data. A další věc je fyzika. Tzn demo pekny, ale zatim nevyuzitelny.
Tohle vypadá na obdobu raytracingu (jinak by to hafo "čehosi" nedokázali v rozumném čase zobrazit). A u toho je hlavně problém s pohybem (animací). Takže až budou umět animaci, pak ať ukazujou videa :D
Vypada to na obdobu raytracingu? Dovolim si drzou otazku > V cem ?!?!
A jelikoz by to mohla byt obdoba raytracingu - tak to najednou jsou schopni zobrazit v rozumnem case? No, to je taky odvazny odhad. :-D
V rychlosti jsem procetl mnohe komentare a obcas musim souhlasit a obcas mam pocit, ze nektere hlavni myslenky zustaly nedotceny.
Zkraje bych se rad dostal k te fyzice a castecne i k animaci. Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna. Ac co vyvojar to ruzna implementace, fyzikalni model mnohdy neni to same co graficky model. Ackoliv se obcas vyvojari uchyli k generovani fyzikalniho modelu z "grafickych" modelu pri behu hry, casto se presto jedna o samostatne vymodelovane objekty urcene jen a jen pro fyziku - at uz je treba predgeneroval nejaky editor z "grafickych" dat. Vypocet fyziky pak ma dve casti a zde je zejmena relevantni "detekce kolize", kterou povazuji za narocnejsi. Shodou okolnosti se vsak velka cast teto detekce dela pomoci objemu (sem se slovo voxel nehodi). Nejidealnejsi je pak detekce pruniku dvou kouli/sphere. Takze teoreticky je problem s voxelovymi daty? NE. Pac se daji chapat jako model poskladany z objemu. V realu pak model pro detekci kolize obsahuje nekolik urovni/detailu objemu, tak aby se testovali pruniky jen "hrube" a teprve po zjisteni kolize se dopocital presnejsi bod kolize z "jemnejsich" dat -> coz ale porad nijak zvlast nehranici s tim co bylo v prezentaci ukazano.
Druha cast fyzikalnich simulaci pak abstrahuje na teziste - proste bod o nejake hmotnosti a par vektoru k tomu. Tam uz je nejaky tvar vlastne docela irelevantni.
Animace jsou trosku slozitejsi, aktualne se s oblibou model vybavi kostrou a jednotlivym vrcholum/vertexum se rekne, jak moc/jakou vahou se maji ridit posunem nejake kosti v kostre - to umoznuje ruzne natahovani a smrstovani a vubec nejakou pruznost "hmoty" kolem kostry. Ale proc by neslo toto rict taky "atomum" (voxelum jestli chcete). Ale souhlasim s tim, ze mnoho algoritmu jiz napsanych proste zatim pocita s polygony a problem je ciste v tom, ze da jedndoduse praci vsechno prepsat - verim, ze by to nemuselo byt v tomto pripade nejako brutalne slozite.
Kde vidim problemy? No jednoznacne mnozstvi dat! A jednoznacne vyber pixelu. Ono propocitat co ma byt videt a co ne, je docela zajimavy a slozity problem, na ktery se stale hledaji nove a nove postupy. Nedokazu si aktualne predstavit jak vybiraji z pohledu na miliardy atomu, co ma byt a co nema byt videt. Ostatne to je jedno z hlavnich tajemstvi jejich uspechu.
Trosku me pak zarazil komentar autora clanku, ze mohou mit predstavu jak to delat a jak ziskat pri softwarovem renderingu takove hodnoty FPS. Asi tusi neco vice nez ja po par letech studia a zajmu :-) zavidim!
A k osvetlovani a zastaralemu vzhledu. Kdyz nad tim premyslim, klasicke metody vyslovene tezily z toho, ze existuje nejaky "povrch" u ktereho lze docela snadno simulovat nejake svetelne vlastnosti - zakladajici se na ruznych vektorech/barvach. V dobe shaderu, se samozrejme osvetlovaci model muze zakladat na temer libovolnych datech a neobvyklych vypoctech - ackoliv vysledkem ne vzdy budou realisticke obrazy. Ale u voxelu? Namapovat vsechny potrebne udaje na takove mnozstvi castic vidim jako docela slozite. Varianta, kdy ma kazda castice vsechny udaje uz z modelu, ve me jen vyvolava pocit obrovskeho mnozstvi dat?! Takze je to jedna z klasickych otazek - sezrat hromadu pameti, nebo sezrat hromadu vykonu?
no, trosku sem se rozepsal, uz koncim, dekuji
V tomhle případě hodně paměti i hodně výkonu. Podle mne bude close future kombinovat rasterizační techniky s raytracingem.
Tam je jedna strasne zasadni otazka, jak se dela vyber toho co bude videt... mam teoreticky tri moznosti, bud pro pixel vykreslim vsechny elementy a ponecham si barvu jen toho nejblizsiho (coz dela rasterizace), budu dopredu znat intervaly mezi prostorem a hmotou/voxely a tim i budu vedet kde je jejich rozhrani (velice stary, problematicky a teoreticky postup) - vyhoda je, ze se pohybuju v nejake pevne mrizce s pouzitim celych cisel (to se hodi vzdy), nebo budu z pozice kamery sledovat paprsek vychazejici z pomyslne kamery skrze body mrizky/rastru/bodu obrazovky a pak musim udelat onu slozitou detekci kolize, podobne jako jsem to zminoval u fyziky....
Pokud budeme tedy uvazovat treti moznost, raytracing, mam trosku problem s predstavou, ze pocitam potencialni prusecik primky s kazdym mnoha elementu, ktere autori pouzivaji. Ostatne vzpomente si na rovnici pro primku, hned na nas vyskoci desetina cisla/plovouci desetina carka. Tady se ale da vyuzit to, ze se pohybujem v diskretni mrizce, takze teoreticky, neni treba vykonavat slozite vypocty. Ma to ale svuj hacek, musi se otestovat kazdy bod na trase paprsku... takze cim dal objekt bude, tim dele ho budu hledat. Jestli se autori vydavaji touto cestou - o cemz trosku pochybuju - je jejich vyhoda zrejme postavena na hratkach se statistikou.
ale je to docela uvaha od boku... tak i tak bych byl opatrny s uzitim slov jako je "raytracing".
Tohle u raytracingu není problém. Pokud mám rozumně ohraničené objekty (např kámen), tak nejprve otestuju bounding box (což je průsečík paprsku s krychlí, koulí nebo něčím podobně jednoduchým co obsahuje celý objekt) a až když paprsek do bounding boxu vletí, testuju jestli protne jednotlivé plochy kamene a tak.
Bounding boxy mohou být hierarchické (např. bounding box postavy, v něm je bounding box jednotlivých částí těla, např. ruka, ruka pak má bounding boxy jednotlivých prstů a až když se paprsek trefí i do bounding boxu prstu tak pak řeším jednotlivou plošku (např. který kus nehtu) a pro statické scény lze použít k-d-stromy a pak každý paprsek místo aby se testoval průsečík s miliardami objektů scény tak se otestuje třeba jen s tisícovkou různých bounding boxů, dokud se netrefí přesně do nějakého malého ohraničeného objektu.
Pokud dokážu objekty generovat (např. je ve scéně X stejných nebo podobných objektů) tak není problém v rozumném čase i s dnešním HW vyrenderovat raytracingem např. krajinu s miliardami stromů, kdy každý strom se skládá třeba z milionu polygonů nebo koulí, atomů nebo čehokoliv.
Problém ale nastává pokud se věci začnou hýbat (k-d-stromy fungujou jen na statické scény) a trochu problém pak může být i osvětlení (jakmile paprsek narazí na objekt, tak ještě musím spočítat jak je osvětlen, jenže nestačí jen poslat jeden paprsek do každého zdroje světla, jelikož je i nepřímé osvětlení, tak těch paprků je potřeba posílat celkem dost aby to vypadalo realisticky :) I tady to ale lze různě urychlit a zjednodušit různými aproximativními algoritmy, kdy lze ovětlení spočítat o dost rychleji s dostatečně dobrou přesností, že si nikdo nevšimne rozdílu.
Vzhledem k tomu že mají problém právě s osvělením bych to tipoval na raytracing.
> Predstava, ze po zruseni polygonu musim mit problem s pocitani fyziky, je v zakladu docela spatna
To jo. S fyzikou v jejich modelu nevidím problém proto, že by neměly polygonu, ale proto, že tam mají tolik částic. Když mám najednou rozpohybovat několik miliard zrnek hlíny, které můžou všelijak navzájem kolidovat se sebou a s okolím, tak je jedno jestli jsou z polygonů nebo atomů, žádný současný CPU ani GPU to v reálném čase neutáhne :)
Z vlastnich zkusenosti musim potvrdit, ze dokud se clovek opravdu vazneji nepokusi pouzivat nejake urychlujici struktury (programujicim doporucuju vyzkouset, je to dost zabavne) ... tak vykon trpi. Ostatne ty metody jsou natolik obecne, ze je jedno jestli mam deleni prostoru a hierarchii pouzitou pro raytrace ci rasterizaci.
A s tim osvetlenim - opet musim potvrdit - pokusit se o simulaci globalni iluminace je vykonovy zabijak (opet stoji za vyzkouseni). Clovek vyplaca stovky paprsku na jeden pixel aby pak zjistitl, ze vysledek je stejne zrnity a musi pouzit bud dalsi hromadu paprsku (nebo nejaky dobry svindl...samozrejme).
Ono cele je to vubec otazka, jak moc maji nastavena omezeni. Par tisic castic poletujicich ve vzduchu tu uz prezentoval kdekdo, ale tezko muzem cekat, ze budou simulovat sterkovou cestu v zavodni hre. Ostatne stejne jako s grafikou - existuje nejaka mez, kde jeste je zajimave/ma smysl pokouset se o detailni simulaci. - Pak se opet clovek dostava k tomu, co lze aproximovat (a to nejen u raytraceru).
A jeste jedna neznama, proc by jim to s nejakou konvencni metodou slo a konkurenci ne.
Viz video- co že celý ten rok co o nich nikdo nešlyšel dělali?? Před rokem udělali kámen do hry, a pak celý rok hledaly nějaký který se mu bude podobataby ho mohli dát na promo video :D
jinak tomuhle vůbec nerozumím, ale když se řešily ty stíny a pod, přece by to šlo zkombinovat s nějakou low-polygonovou mapou na které by už bylo jasné kde mají stíny padat, jak se má postava hýbat + tohle by bylo pozlátko na tom ne??
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.