[3D rendering]Unlimited Detail, kan het, hoe zou het werken?

[roy-t]

Laatst kwam ik uit op de website http://unlimiteddetailtechnology.com/ een bedrijf dat claimt een nieuwe soort graphics rendering uitgevonden te hebben waarbij je ipv in polygonen (triangles) werkt met point clouds. Het idee lijkt een beetje op een voxel maar heeft volgens hun niet het nadeel dat elk punt dat je toevoegt de scene iets langzamer te renderen maakt. Ook is het geen raytracing (volgens hun) ondanks dat ze net als bij raytracing voor elke pixel op je scherm opzoeken welke point uit de point cloud daar hoort. Ze zeggen dat ze een speciaal zelf bedacht zoek algoritme gebruiken ("Mass connected processing") waardoor een scene met 10.000 points net zo zwaar is als een scene met 10.000.000 points, omdat er niets gedaan wordt met de punten die niet naar een pixel op je scherm mappen.

Ook zeggen ze dat ze alles in software uitreken en dat de techniek licht genoeg is voor mobiele telefoons als geavanceerd.

Nu lijkt me dat als dit allemaal waar is (zelf als je er zeer specialistische hardware voor nodig zou hebben) ATI en Nvidia dat bedrijf al lang opgekocht zouden hebben. Toch lijkt het zelfs alsof de funding een beetje schort (de website is vrij onprofessioneel zelfs).

Ik heb allerlei punten bedacht waardoor de techniek misschien niet zou kunnen aanslaan, maar bij elke punt heb ik ook een tegenvoorbeeld kunnen bedenken.

-Schaduwen? -> Geometrisch onafhankelijke schaduwen (shadowmaps) kunnen altijd, maar dan moet je de scene meerdere keren renderen = geen probleem zo doen we dat nu ook.

-Shaders? -> Voorbeeldje in de video laat een soort van phong shader zien.

-Occlusion detection? -> Filmpje is erg overtuigend dat dit goed werkt.

-Korreligheid? -> Kan aan de artwork liggen (dat er teveel detail in zit) of aan de techniek die maar 1 point naar 1 pixel mapped, maar dat zou met bijvoorbeeld supersampling opgelost kunnen worden.

-Rechte objecten moeilijk? -> Ik kan me niet bedenken waarom een platte muur minder makkelijk zou zijn als een palmboom.

->Te veel werk om modellen te maken? -> Ze hebben software ontwikkeld om polygon based data over te zetten naar point clouds, geen probleem dus.

->Gebruikt te veel geheugen? -> Zou kunnen en er wordt erg veel zelfde data gebruikt in de filmpjes, maar dit zou dan de nieuwe bottleneck worden, die elk jaar leuk iets om hoog gaat. Zo dus zelfs een voordeel zijn voor de vidkaart fabrikanten. (ipv snellere chips, concurreren op meer geheugen).


Ik kan dus niet bedenken waarom de techniek nog niet opgekocht is, of waarom we er niet eerder van gehoord hebben.

Wat denken jullie van deze techniek?

Hier is het filmpje

En hier een plaatje



Hier nog een deel uit een mail die hij stuurde naar iemand anders (een youtube gebruiker)

Update: I sent an email to Mr. Dell asking about how the project was going... His reply is as follows... Hopefully it will give some hope to those who claim this is "vaporware"

"Thank you for your Email, I am afraid our focus has been on speed over anything else, and we are busy optimizing and are up to 25-65 fps depending on whats on screen. We want to be able to bring the system to the point were we can say we are as fast as a graphics card but much more powerful, once speed is out the way we will begin the import of laser scanned point cloud data, at that stage Unlimited Detail should look completely real. Like I said we have no new pictures but ill attach an old one that I dont think is on the web. It doesnt look like much but its actually quite interesting from a technical perspective because those balls and the bottle are really small models which round off and smooth out when they get close. There was always a problem when you use point cloud data ( we say that because voxels have such a bad name , poor little things ) the problem is if you get close to an object the points either separate or they turn in to 2D rectangles to stay joined together, we have had great success this week with a new system that combines the point based on the points around them and smooths them off , thus keeping a nice real looking image, rather then blocky pixels.

The cancellation of larabee in its original form is unfortunate for us because we had hoped to release UD at the same time as larabee and ride the media wave of showing that we can do more with out hardware then they can do with hardware.

Once again thank you for your email, its been a nice break from programming but I must return to my techno slavery now.

Kindest Regards

Bruce Robert Dell"

Wat is jullie oordeel? En hoe zou het werken.

Mijn oordeel tot nu: gaan we meer van horen maar er zit nog een luchtje aan!

[ Voor 1% gewijzigd door roy-t op 12-03-2010 00:12 . Reden: Plaatje stuk ]

[Matis]

Hmm, ik vind het bijna ongeloofwaardig

Die muziek op de achtergrond ook, geniaal.

Dit verhaal doet me bijna denke naan het verhaal over Jan Sloot en zijn Broncode

[roy-t]

Matis schreef op vrijdag 12 maart 2010 @ 00:17:
Hmm, ik vind het bijna ongeloofwaardig

Die muziek op de achtergrond ook, geniaal.

Dit verhaal doet me bijna denke naan het verhaal over Jan Sloot en zijn Broncode

Ja alleen was bij Jan Sloot te bewijzen dat het niet kon. (Zoveel bits waren maximaal zoveel verschillende toestanden en dat was al minder dan het aantal films dat op imdb stond ofzo). Hier zit wel iets in somehow...

[Matis]

Ja, wat ze volgens mij aan willen tonen is het feit dat ze 3d-modellen in 2d willen weergeven.

Aan het begin lijkt het to-good-to-be-true, maar naarmate het filmpje verder verloopt ging het bij mij toch meer spelen, al heb ik geen flauw idee hoe ze *unlimited* puntjes kunnen doorzoeken en sorteren met gelimiteerde rekenkracht.

[RobIII]

* RobIII kijkt op de kalender.... oh. Nog een paar dagen. Mooi op tijd om een grap op 't vuur te gooien

Ik ben geen 3D coder (en misschien maar goed ook ) maar ik kan me voorstellen als je al die punten indeeld in "3D kubussen" van 1x1 "meter" dat je dan iig al als een dolle kunt snoeien in de data als je gaat bepalen wat er in beeld ligt en wat niet (hence "zoekalgo") en met hoeveel detail en als je dat op een paar manieren door trekt kun je misschien nog best wat leuks presteren maar ik geloof bij lange na niet wat ze beweren te kunnen.

Then again: once in a while wordt natuurlijk wel iets uitgevonden dat de huidige manier van denken drastisch op z'n kop zet. Of dit 't is... mijn 'gut' zegt van niet.

[ Voor 79% gewijzigd door RobIII op 12-03-2010 00:41 ]

[MueR]

* MueR noteert hem bij Duke Nukem Forever op het lijstje van wannahaves.

[Skinkie]

roy-t schreef op vrijdag 12 maart 2010 @ 00:18:
Ja alleen was bij Jan Sloot te bewijzen dat het niet kon. (Zoveel bits waren maximaal zoveel verschillende toestanden en dat was al minder dan het aantal films dat op imdb stond ofzo). Hier zit wel iets in somehow...

Sloot z'n tweede algoritme misschien. Z'n eerste ligt gewoon bij het octrooibureau. En zelfs dan kun je claimen dat 64kb aan priem getallen genoeg moet zijn voor z'n tweede claim.

Over dit verhaal. Dat zoek algoritme zou wel een leuke insteek zijn ja, maar dan nog vraag ik me af hoe het fundementeel verschilt van raytracing. Een 3D r-tree maken, dan voor iedere punt op het scherm een mapping maken en zolang de transparency nog niet ff iets dieper zoeken zou een optie kunnen zijn.

Maar dan denk ik ook weer terug aan binary space partitioning...

[DefLite]

Ach ook al klinkt het hele verhaal wel heel erg onwaarschijnlijk, stiekem hoop ik toch dat het kan/klopt. Zelfs in de nieuwste games met alle graphics op high zijn boomstammen bijv vaak nog errug lelijk.

[evangael]

Ik zeg geef die man een kans!

[roy-t]

Wat ook wel voor een beetje geloofwaardigheid zorgt is dat ze al een tijdje bezig zijn (6 jaar geloof ik) en nog steeds bestaan .

[TERW_DAN]

Sowieso kan het niet helemaal kloppen dat je met gelimiteerde power ongelimiteerde dingen kan doen. Dat is gewoon niet mogelijk, dus bij die uitspraak zou ik toch wel een paar kritische noten neerzetten.
Echter, wat hij zegt dat hij enkel de zichtbare pixels rendert door middel van een algoritme kan volgens mij nog best wel eens iets inzitten, dat is op zich logisch en goed mogelijk, de vraag is alleen of het daadwerkelijk zo snel kan gebeuren in software. Hij trekt de vergelijking met google die zegt ook ongelmiteerde zoekkracht te hebben. Maar ook zij hebben dat natuurlijk niet, want ze hebben toch honderdduizenden servers staan op de hele wereld, als ze er maar 1 zouden hebben dan zou het echt niet zo snel en uitgebreid zijn als het vandaag de dag is.
Ik denk dat de techniek erachter best nog wel eens zou kunnen werken, maar het filmpje brengt het imho een beetje te rooskleurig en ik ben ook echt wel benieuwd wat we dan mogen verwachten.

[roy-t]

Terw_Dan schreef op vrijdag 12 maart 2010 @ 08:34:
Sowieso kan het niet helemaal kloppen dat je met gelimiteerde power ongelimiteerde dingen kan doen. Dat is gewoon niet mogelijk, dus bij die uitspraak zou ik toch wel een paar kritische noten neerzetten.
Echter, wat hij zegt dat hij enkel de zichtbare pixels rendert door middel van een algoritme kan volgens mij nog best wel eens iets inzitten, dat is op zich logisch en goed mogelijk, de vraag is alleen of het daadwerkelijk zo snel kan gebeuren in software. Hij trekt de vergelijking met google die zegt ook ongelmiteerde zoekkracht te hebben. Maar ook zij hebben dat natuurlijk niet, want ze hebben toch honderdduizenden servers staan op de hele wereld, als ze er maar 1 zouden hebben dan zou het echt niet zo snel en uitgebreid zijn als het vandaag de dag is.
Ik denk dat de techniek erachter best nog wel eens zou kunnen werken, maar het filmpje brengt het imho een beetje te rooskleurig en ik ben ook echt wel benieuwd wat we dan mogen verwachten.

Nouja als je naar google kijkt zou je eigenlijk naar het aantal woorden wat ze doorzoeken moeten kijken, en ik denk dat google vooral snel is door het algoritme wat ze gebruiken om data op te slaan, er zijn zoveel mensen die google gebruiken dat het niet kan dat iedere gebruiker 1 server ter beschikking heeft, wat bij games wel zo is (naja geen server natuurlijk maar wel een leuke computer).

Echt ongelimiteerd zal het natuurlijk niet zijn, er zit sowieso een memory contraint ergens omdat je toch al die punten moet onthouden.

[naam]

Unlimited kan natuurlijk niet, tenzij het allemaal op basis van een algorithme (= modellen worden realtime bedacht, procedural) is, maar er komt altijd een einde aan de hoeveelheid opslag die je hebt

Edit:
Zoals ik het na even snel skimmen begrijp is het gewoon een nieuwe versie van lod (Level of detail).

Edit2:
Na het even beter lezen, lijkt het me een zeer intresante technologie, mist het natuurlijk waarmaakt wat ze beweren, als dat zo is... dan gaat de hele 3d wereld op z'n kop komen te staan.. Maar het heeft wel een nadeel voor game-developers, de artists moeten namelijk ook voor ieder model een idioot hoog aantal poly's/points maken.. dat kost tijd en geld.

Edit3:
Ben ook zeer benieuwd hoe het zou gaan werken met animatie. En of het mogelijk zou zijn om in bvb een shooter stukken uit de muur te knallen zou natuurlijk zeer vet zijn maar ook heel zwaar om te berekenen. Ook dingen als physics (bomen die bewegen in de wind, doosjes oppakken en neerzetten/weggooien, water dag golft) dat soort dingen kunnen met een berg poly's op een relatief simpele manier, maar ik denk dat het met een gigantische pointcloud wat lastiger gaat worden.

[ Voor 84% gewijzigd door naam op 12-03-2010 09:03 ]

[sopsop]

roy-t schreef op vrijdag 12 maart 2010 @ 00:18:
[...]


Ja alleen was bij Jan Sloot te bewijzen dat het niet kon. (Zoveel bits waren maximaal zoveel verschillende toestanden en dat was al minder dan het aantal films dat op imdb stond ofzo). Hier zit wel iets in somehow...

Dat is dus geen bewijs, omdat er nergens wordt aangegeven dat Jan Sloot een binair systeem gebruikte.

[RobIII]

roy-t schreef op vrijdag 12 maart 2010 @ 08:38:
er zijn zoveel mensen die google gebruiken dat het niet kan dat iedere gebruiker 1 server ter beschikking heeft

offtopic:
De laatste keer dat ik een "inside google" artikel las, las ik dat er voor élke query tot 256 nodes tegelijkertijd aan de gang gaan.

[Matis]

Ik begrijp eigenlijk niet waarom Google erbij gehaald werd. Immers is Google een bestaand iets en dus bevatbaar voor ons.
Deze *ontwikkeling* is dus revolutionair en gaat boven iedereen zijn pet. Om de ontwikkeling te gaan koppelen aan Google's zoekmachine, val je dus weer terug in een bestaand en bevatbaar iets.

Dat doet het verhaal niet veel goeds.

[MLM]

een goed opgezette spatial-division structuur kan je gebruiken om vrij snel uit te vinden wat je set met "kandidaten" voor rendering is, en wellicht kan je iets slims doen met punten (alle "punten" in de cloud zijn 1 pixel groot ofzo) zodat dat nog sneller kan. (in een high-end rendering engine word dit natuurlijk ook al gedaan, dus om nou te zeggen dat dit zo'n enorme stap is, nee), alleen een ander type primitive moet verwerkt worden

maar ik kan me niet voorstellen dat het zo snel is als aangegeven in het algemeen. daarnaast heb je behoorlijk wat punten nodig om voldoende detail in je scene te krijgen (uitgaande van 1080p moet je al 2M punten "zichtbaar" hebben in elke mogelijke "kijkhoek", als die punten echt 1 pixel zijn). maar goed, ze geven aan afhankelijk te zijn van LRB, dus ik zou zeggen, gebruik OpenCL/DXComputeShaders oid om een demo te maken die draait op een moderne GPU... afhankelijkheid van vapor-hardware is geen goed idee voor je technologie

maar goed, ik zeg niet dat het onmogelijk zou zijn, maar het is niet de eerste keer dat mensen een nieuwe technologie aankondigen en vervolgens niet over de brug komen, dus ik ben wel voorzichtig voordat ik een gat in de lucht ga springen

[ Voor 7% gewijzigd door MLM op 12-03-2010 09:46 ]

[roy-t]

Ik ben ook erg voorzichtig, vandaar dit topic, ik hoop we dat het werkt. Verder is 2M punten eigenlijk peanuts als je vergelijkt wat de GPU nu al moet doen. (Allemaal berekeningen over de polygonen en daarna zelfs sowieso minstens 2M punten bedenken die in een polygoon zouden moeten zitten. Volgens UD hoeven zij eigenlijk een verkorte eerste stap en de laatste stap te doen ipv de 2 hele stappen.

Volgens mij wordt Google aangehaald omdat ze juist willen laten zien dat de techniek revolutionair is op het gebied van graphics maar dat het op dit moment al wel in andere sectoren bewerkingen gedaan worden op 'ongelimiteerde data'.

[Matis]

@MLM, in de video wordt volgens mij aangegeven dat het op software-basis draait, bij mij betekent dat er geen gebruik wordt gemaakt van hardware-acceleratie. Het geen zij dus stellen, dat op mobiele telefoons (mede door hun kleinere resolutie) Unlimited Detail mogelijk is.

@roy-t, ik weet niet precies hoe ze het doen, maar je zou (theoretisch) voor elk pixel de vector in de *ruimte* kunnen berekenen. Als je voor dat pixel een *atoom* tegenkomt, dan ben je klaar voor die pixel en ga je naar de volgende. Je geeft elk atoom zijn eigen kleur en er hoeven ook geen sprites meer gerendered te worden. Anti-aliasing hoeft ook niet, want je werkt op pixelbasis.

Edit; desalniettemin, vind ik het een toffe ontwikkeling, die misschien een hoax blijkt te zijn, maar wel stof doet opwaaien in GPU-land

[ Voor 9% gewijzigd door Matis op 12-03-2010 09:47 ]

[MLM]

Matis schreef op vrijdag 12 maart 2010 @ 09:46:
@MLM, in de video wordt volgens mij aangegeven dat het op software-basis draait, bij mij betekent dat er geen gebruik wordt gemaakt van hardware-acceleratie. Het geen zij dus stellen, dat op mobiele telefoons (mede door hun kleinere resolutie) Unlimited Detail mogelijk is.

Definieer de grens van "software" dan Ik zou argumenteren dat een shader op de GPU ook software is (immers, de shader-unit is programmeerbaar met code). Dat gaat ook op voor de LRB, het zijn gewoon gespecialiseerde processors, die snel parallel data kunnen werken aan de hand van mijn instructies (software).

Laat ze eerst maar es een demo geven op die telefoon dan... Ik wil zien hoe ze die miljoenen punten in (het op telefoons) slome RAM gaan houden en nog realtime kunnen verwerken Op een desktop PC wil ik dat nog wel geloven, die hebben genoeg bandbreedte tussen RAM<->CPU danwel VRAM<->GPU om al die punten/pixels/voxels te verwerken.

Daarnaast, we moeten niet vergeten dat onze huidige graphics meestal meerdere (honderden) shaders gebruiken om 1 frame op te bouwen. De screens die ik hier zie zouden prima allemaal met 1 "shader" gebouwd kunnen zijn (phong). Ik zeg niet dat dat slecht is, maar een minder flexibel systeem kan verder geoptimaliseerd worden, dus dan is het niet echt een eerlijke vergelijking meer

[Matis]

De telefoons van tegenwoordig hebben iets van 800 bij 480 pixels, daarmee kom je op ongeveer 400k pixels. Tevens worden de processoren in mobieltjes steeds beter en sneller en ook de hoeveelheid RAM zit eindelijk in de lift.

Ik wil niets bagatelliseren, maar je moet met deze (zoals ze zelf zeggen) revolutionaire doorbraak, out-of-the-box denken, wat veel mensen helaas niet kunnen.

[MLM]

Matis schreef op vrijdag 12 maart 2010 @ 10:06:
De telefoons van tegenwoordig hebben iets van 800 bij 480 pixels, daarmee kom je op ongeveer 400k pixels. Tevens worden de processoren in mobieltjes steeds beter en sneller en ook de hoeveelheid RAM zit eindelijk in de lift.

Ik wil niets bagatelliseren, maar je moet met deze (zoals ze zelf zeggen) revolutionaire doorbraak, out-of-the-box denken, wat veel mensen helaas niet kunnen.

Het blijkt niet echt van mijn posts, maar ik ben best enthousiast over dit soort ontwikkelingen Ik hoop dat het werkt, maar zien is geloven, zeker met dit soort dingen

[Jrz]

Is het niet gewoon het segmenteren van voxels in een octtree, gecombineerd met een soort van LoD iets voor zaken die ver weg zijn?

[p_van_logchem]

Ik heb recent gemailed met de coder van deze engine : http://atomontage.com/ , Branislav Siles. Hij gaf aan dat zijn engine in staat is om ongeveer 500 Km2 aan voxel-data te verwerken. Hij werkt aan het integreren van zwaartekracht en enkele (simpele) chemische reacties (jawel!).
Zijn engine is ook gebaseerd op voxels, en ziet er zeer gelikt uit. Hij gebruikt een datastructuur waarmee het mogelijk is om redelijk goedkoop (uitgedrukt in bits per voxel) allerlei eigenschappen aan 'gebieden' toe te kennen, zodat hij fysieke en anders-soortige kenmerken kan toekennen : denk aan gewicht, richting van de zwaartekracht, frictie, wind, chemische samenstelling, elektrische lading, transparantie, of materiele waarde, etc. Waanzinnig eigenlijk - en het werkt echt!

Unlimited detail kende ik ook al een tijdje, maar vriend Bruce reageert niet (meer) op mail, waarschijnlijk heeft 'ie het te druk met optimalisatie-werk. Overigens is het ook goed om te vermelden dat hij heeft beweert dat z'n engine ook animatie aankan, en dat er permanente deformations mogelijk zijn (dat zie je in atomontage ook terug).

Persoonlijk hoop ik dat mensen die dit soort startups proberen zo vriendelijk zullen zijn om hun uitvinding publiek bekend te maken als hun bedrijfje het er niet mee redt. Natuurlijk, ik begrijp de secrecy, maar zoals we hebben kunnen zien in het (terecht al eerder genoemde) geval 'Sloot' is een potentieel veelbelovende (of op z'n minste zeer interressante) techniek nu verloren...

[NC83]

Ik zie echter een probleem met deze techniek en dat is transparantie, die hebben ze namelijk nog niet laten zien. En als ze echt unlimited power hebben dan zou dat ook niet moeilijk moeten zijn.

[YopY]

Beetje lelijke graphics in dat filmpje, . Doet me wat denken aan de technologie die ze gebruikten voor de grond in Outcast (was dat niet een vroege vorm van height maps oid?).

En we zien wel of het wat is. 'unlimited' doen we niet aan, in ieder geval, en het is één ding om een nieuwe renderingtechniek uit te vinden, maar een ander waar je ook mooie dingen mee kunt maken.

[RobIII]

YopY schreef op vrijdag 12 maart 2010 @ 13:01:
Beetje lelijke graphics in dat filmpje, . Doet me wat denken aan de technologie die ze gebruikten voor de grond in Outcast (was dat niet een vroege vorm van height maps oid?).

Nee, dat waren voxels AFAIK (ik heb 'm toevallig origineel in de kast liggen )

Edit: Oh:

quote: http://en.wikipedia.org/wiki/Outcast_%28game%29

Although Outcast is often cited as a forerunner of voxel technology[3], this is somewhat misleading. The game does not actually model three-dimensional volumes of voxels. Instead, it models the ground as a surface, which may be seen as being made up of voxels. The ground is decorated with objects that are modeled using texturemapped polygons. When Outcast was developed, the term "voxel engine", when applied to computer games, commonly referred to a ray casting engine (for example the VoxelSpace engine). On the "Engine Technology" page of the game's website, the landscape engine is also referred to as the "Voxels engine".

[ Voor 49% gewijzigd door RobIII op 12-03-2010 13:10 ]

[Bozozo]

Cruciale opmerking in het filmpje:

"We've got about eight billion points running here, because we've also doubled them all, and put them underneath to make reflections"

Dat is gewoon cheaten. Elke pixel opzoeken is niet zo heel moeilijk, al is het knap als ze echt miljarden punten kunnen weergeven. Zaken als transparatie, schaduw, anti-aliasing en reflecties zie ik met deze techniek niet gebeuren.

[PrisonerOfPain]

MLM schreef op vrijdag 12 maart 2010 @ 09:31:

een goed opgezette spatial-division structuur kan je gebruiken om vrij snel uit te vinden wat je set met "kandidaten" voor rendering is, en wellicht kan je iets slims doen met punten (alle "punten" in de cloud zijn 1 pixel groot ofzo) zodat dat nog sneller kan. (in een high-end rendering engine word dit natuurlijk ook al gedaan, dus om nou te zeggen dat dit zo'n enorme stap is, nee), alleen een ander type primitive moet verwerkt worden

De meeste (alle?) huidige spatial-division structuren die er zijn schalen logaritmisch met het aantal punten dat er opgeslagen word. Wat ze hier hebben gedaan is een manier van renderen gebruiken die een constante performance heeft met het aantal punten dat opgeslagen word of in ieder geval word er in het filmpje gehint naar een schaalbaarheid linear aan het aantal pixels.

Verder wordt er in de video gesproken over het zoeken door documenten, wat me doet vermoeden dat ze een soort "3D inverted index" datastructuur hebben weten te bouwen. Immers is die manier van dataopslag de voornaamste reden dat fulltext search zo performant is. (Het schaalt niet met de lengte van het document, maar constant).

Bozozo schreef op vrijdag 12 maart 2010 @ 13:31:
Cruciale opmerking in het filmpje:

"We've got about eight billion points running here, because we've also doubled them all, and put them underneath to make reflections"

Dat is gewoon cheaten. Elke pixel opzoeken is niet zo heel moeilijk, al is het knap als ze echt miljarden punten kunnen weergeven. Zaken als transparatie, schaduw, anti-aliasing en reflecties zie ik met deze techniek niet gebeuren.

Shadowmapping word ondersteund, en anti-aliasing zou niet zo heel moeilijk moeten zijn, daarvoor hoef je immers alleen maar een grotere rendertarget voor te maken (welke je vervolgens downscaled). Transparante objecten valt nog te bezien, maar goed die zou je eventueel gewoon op de oude manier op de GPU kunnen doen. Dat is immers wat de hedendaagse defered engines ook al doen.

[ Voor 26% gewijzigd door PrisonerOfPain op 12-03-2010 13:47 ]

[MLM]

PrisonerOfPain schreef op vrijdag 12 maart 2010 @ 13:42:
[...]


De meeste (alle?) huidige spatial-division structuren die er zijn schalen logaritmisch met het aantal punten dat er opgeslagen word. Wat ze hier hebben gedaan is een manier van renderen gebruiken die een constante performance heeft met het aantal punten dat opgeslagen word of in ieder geval word er in het filmpje gehint naar een schaalbaarheid linear aan het aantal pixels.

Verder wordt er in de video gesproken over het zoeken door documenten, wat me doet vermoeden dat ze een soort "3D inverted index" datastructuur hebben weten te bouwen. Immers is die manier van dataopslag de voornaamste reden dat fulltext search zo performant is. (Het schaalt niet met de lengte van het document, maar constant).

dat is wel netjes dan dat ze 2x4 miljard indices kunnen hebben. Dat hint op in elk geval 33bits (ie >32bit) indices. met 32bit kleuren en 3x16bit positions zit je dan al aan 10bytes per punt. toch al snel 40GB (ervanuitgaande dat spiegelen niks kost) dataset

Shadowmapping word ondersteund, en anti-aliasing zou niet zo heel moeilijk moeten zijn, daarvoor hoef je immers alleen maar een grotere rendertarget voor te maken (welke je vervolgens downscaled). Transparante objecten valt nog te bezien, maar goed die zou je eventueel gewoon op de oude manier op de GPU kunnen doen. Dat is immers wat de hedendaagse defered engines ook al doen.

Ligt er nogal aan hoe die mysterieuze datastructuur werkt, of dat nodig is sowieso. Misschien werkt het wel heel anders. Maar goed, die datastructuur lijkt me intressanter dan de performance

[RayNbow]

Dit vond ik via Google:

quote: http://ompf.org/forum/vie...=3&t=904&start=250#p14671

Here what Bruce Dell writes in his Linked-In profile: The Unlimited Detail system consists of a compiler that takes point cloud data and converts it in to a compressed format, the engine is then capable of accessing this data in such a way that it only accesses the pixels needed on screen and ignores the others generating real-time graphics that look like unlimited polygons. it is also the best available way of displaying laser scanned environments, they can be of unlimited size and this will not slow down the system.

[PrisonerOfPain]

MLM schreef op vrijdag 12 maart 2010 @ 14:02:
[...]

dat is wel netjes dan dat ze 2x4 miljard indices kunnen hebben. Dat hint op in elk geval 33bits (ie >32bit) indices. met 32bit kleuren en 3x16bit positions zit je dan al aan 10bytes per punt. toch al snel 40GB (ervanuitgaande dat spiegelen niks kost) dataset

Dat is nu eenmaal de orde van grootte aan data die je hebt als je meerdere miljarden elementen (points, in dit geval) hebt. Dat maakt ook verder niet (al) te veel uit als je maar een element per pixel benadert, het word in dat geval vooral zaak dat je je data op tijd van je disk kan streamen.

[MLM]

dan is het niet meer unlimited
wat als ik al die 4 miljard voxels in een mooie sphere heb opgesteld rond de camera, en ik bestuur die camera in realtime, dan kan ik (mits ik snel omdraai) zeker de helft van die voxels "gezien" hebben in een seconde...
geen enkele HDD of SSD (zelfs in dikke array opstelling) gaat 20GB/sec halen
en al HELEMAAL telefoons (die schijnbaar ook geschikt zijn) niet, ik mag blij zijn als dat ding 0.01% daarvan haalt

[naam]

MLM schreef op vrijdag 12 maart 2010 @ 15:30:
dan is het niet meer unlimited
wat als ik al die 4 miljard voxels in een mooie sphere heb opgesteld rond de camera, en ik bestuur die camera in realtime, dan kan ik (mits ik snel omdraai) zeker de helft van die voxels "gezien" hebben in een seconde...
geen enkele HDD of SSD (zelfs in dikke array opstelling) gaat 20GB/sec halen
en al HELEMAAL telefoons (die schijnbaar ook geschikt zijn) niet, ik mag blij zijn als dat ding 0.01% daarvan haalt

misschien hebben ze daar ook een oplossing voor bedacht, misschien met Level of detail gebaseerd op bewegingssnelheid. Bijvoorbeeld: als jij de camera heel snel omdraait, renderen ze niet alle points, maar een aantal (aantal dus gebaseerd op de bewegingssnelheid) en vullen ze de tussenliggende ruimte op met een poly, dan krijg je dus wel een soort hybride engine, maar als de poly's klein genoeg zijn merk je het verschil niet, maar is het wel een heel stuk sneller dan alleen met points. Nu weet ik niet hoe ze dit in de praktijk gedaan hebben, als ze er al een oplossing voor gevonden hebben

[NC83]

Ik denk dat het meeste zit in het taggen van de gecomprimeerde data zodat je enkel de data decomprimeerd die benodigd is, dus de pixels die zichtbaar zijn. Hier in Southam zijn we nog steeds een beetje sceptisch over deze technologie

[PrisonerOfPain]

NC83 schreef op vrijdag 12 maart 2010 @ 17:07:
Ik denk dat het meeste zit in het taggen van de gecomprimeerde data zodat je enkel de data decomprimeerd die benodigd is, dus de pixels die zichtbaar zijn. Hier in Southam zijn we nog steeds een beetje sceptisch over deze technologie

Begrijpelijk, het nare aan de situatie is dat er nog geen paper over verschenen is en dat de technische details erg schaars zijn.

[MLM]

marabunta2048 schreef op vrijdag 12 maart 2010 @ 15:55:
[...]

misschien hebben ze daar ook een oplossing voor bedacht, misschien met Level of detail gebaseerd op bewegingssnelheid. Bijvoorbeeld: als jij de camera heel snel omdraait, renderen ze niet alle points, maar een aantal (aantal dus gebaseerd op de bewegingssnelheid) en vullen ze de tussenliggende ruimte op met een poly, dan krijg je dus wel een soort hybride engine, maar als de poly's klein genoeg zijn merk je het verschil niet, maar is het wel een heel stuk sneller dan alleen met points. Nu weet ik niet hoe ze dit in de praktijk gedaan hebben, als ze er al een oplossing voor gevonden hebben

LoD dacht ik ook al aan, maar dat is niet echt constante tijd om te genereren, en als het offline gedaan is heb je een nog grotere dataset. Daarnaast, LoD van een punt is een moeilijke, je kan em niet echt kleiner maken. Je kan wel een groep dicht bij elkaar liggende punten samenvoegen misschien, maar dan verlies je wel vrij snel detail (immers, de grootte van de punt neemt dan behoorlijk toe, en je verliest dan "vorm" van de "wolk" als die wolk niet bolvormig/kubusvormig is (ik weet niet hoe ze hun punt gedefinieerd hebben), omdat je niet kan "freeformen"...

Hoe dan ook zit je dan nog steeds met streaming en de dataset. Zelfs met dikke compressie heb je het al snel over meerdere GB's voor een miljard punten lijkt me, en dat streamen van je HDD kost ook wel even... desondanks een intressant verhaal

quote: PrisonerOfPain

Begrijpelijk, het nare aan de situatie is dat er nog geen paper over verschenen is en dat de technische details erg schaars zijn.

Als ik hun was zou ik niet zo snel technische details vrijgeven totdat je een verkoopbaar product hebt Volgens mij zijn ze nog verre van dat stadium (ook in termen van beschikbare hardware bij consumenten)

[NC83]

Ik heb het gevoel dat ze een depth traversal van hun point cloud doen, en dan als een pixel eenmaal naar het scherm geschreven is/ bevonden is dat deze zichtbaar is, alle andere in die depth region laten vallen. Dat neemt nog steeds niet weg dat je een hoop data door moet maar er valt snel veel weg op deze manier. Ook een van de redenen waarom ik transparantie wilde zien want als je dat gaat doen vervalt dit verhaal natuurlijk.

[Skinkie]

NC83 schreef op vrijdag 12 maart 2010 @ 20:56:
Ook een van de redenen waarom ik transparantie wilde zien want als je dat gaat doen vervalt dit verhaal natuurlijk.

Zoals ik al eerder schreef, dan ga je gewoon door tot dat de som niet meer transparant is.

[NC83]

Zo simpel is het niet want als ik twee punten heb die beiden 0.5 alpha hebben dan is de som 1 en niet meer transparent waar het in werkelijkheid nog steeds voor 0.25 transparant is. Addition blending werkt niet voor alpha je moet vermenigvuldigen.

[Skinkie]

NC83 schreef op zaterdag 13 maart 2010 @ 03:07:
Zo simpel is het niet want als ik twee punten heb die beiden 0.5 alpha hebben dan is de som 1 en niet meer transparent waar het in werkelijkheid nog steeds voor 0.25 transparant is. Addition blending werkt niet voor alpha je moet vermenigvuldigen.

En vervolgens kom je op een waarde uit die met de beste wil van de wereld niet meer verandert omdat de significantie te klein is, van het display uiteraard

[roy-t]

Maarja je hebt natuurlijk veel minder transparantie effecten nodig dan nu.

[H!GHGuY]

Als ik mag gokken dan hebben ze gewoon een voxel graph waarbij je van elk punt de buren bijhoudt.
Wanneer je een object op de scene plaatst, raytrace je welke voxels zichtbaar zijn. Eens je 1 voxel hebt gevonden gebruik je de graph om de naburige voxels te renderen,... voeg wat LoD toe en optimalisaties en je kan al redelijk wat.

Maar ik ben dan ook geen expert op 3D-ontwikkeling

[PrisonerOfPain]

H!GHGuY schreef op zaterdag 13 maart 2010 @ 09:54:
Als ik mag gokken dan hebben ze gewoon een voxel graph waarbij je van elk punt de buren bijhoudt.

Ik heb steeds meer het idee dat het om een sparse voxel octree implementatie gaat, na wat gegoogled te hebben op de betrokken personen. Kortom, mega-textures achtige techniek toegepast op voxel rendering. Dat zou ook meteen de streaming problemen verhelpen omdat je dan simpelweg zorgt dat er een lagere LOD (mipmap) level ingeladen staat op de nog overgebleven stukken geheugen.

[terje7601]

Ik ben helemaal geen expert, maar kan iemand mij eens uitleggen wat het fundamentele verschil met ray-tracing is? Daar heb je toch ook al unlimited detail, want ik kan een "perfecte bol" (i.e. zonder polygonen & met oneindig veel punten) weergeven, enkel door een 3D coordinaat & een straal bij te houden. En met Bezier-curven e.d. kun je waarschijnlijk ook vanalles in raytracing, zolang je maar een algoritme hebt om te bepalen of een ray een bepaald object snijdt, juist?

Dus in feite beweren ze hier dat ze de "visuele correctheid" van ray tracing kunnen combineren met de snelheid van rasterizing. En in die mail beweert de maker bovendien dat zij "meer kunnen doen zonder hardware" dan Intel kan (zal kunnen, als hij uitkomt) met hun Larrabee...tja, ik geloof er alvast niet erg in...

[PrisonerOfPain]

terje7601 schreef op zaterdag 13 maart 2010 @ 14:55:
Ik ben helemaal geen expert, maar kan iemand mij eens uitleggen wat het fundamentele verschil met ray-tracing is? Daar heb je toch ook al unlimited detail, want ik kan een "perfecte bol" (i.e. zonder polygonen & met oneindig veel punten) weergeven, enkel door een 3D coordinaat & een straal bij te houden.

Je kunt ook een perfecte sphere rasterizen; dat is het probleem niet. Zowel bij raytracing als bij rasterizing ligt de focus nu eenmaal voor het overgrote deel op op triangles omdat deze een aantal enorm handige eigenschappen hebben.

Overigens is het zo, dat als deze techniek gebaseerd is op sparse voxel octrees, die dingen nog steeds geraycast moeten worden. (Eg. ze doen de primary rays van je raytracing oplossing).

[Zoijar]

Nou, mijn eerste indruk is "ik geloof er niet veel van". Point-cloud rendering is helemaal geen nieuwe tak; dat gebeurt al tijden en er zijn ook zelfs apparte conferenties over.

Nou geven ze niet echt specifieke claims, dus het is alstig er iets over te zeggen. Wat wel zo is, is dat je het visibility probleem niet in constante tijd kan oplossen. Als dat wel kon, dan nam je een set van N punten met dezelfde x,y coordinaten maar verschillende dieptes. Die render je dan in constante tijd en dan zie je alleen de voorste. Die knip je weg en sla je op en dan doe je het opnieuw. Dat moet je N keer doen om de set te sorteren, wat sorteren dan een O(n) operatie maakt. Maar dat is bewezen onmogelijk.

Maar goed, point-cloud rendering heeft zeker toekomst. Zeker omdat we die 3D data uit foto's kunnen verkrijgen en dan ipv polygonen te modellen, we gewoon een bestaand object voor een camera kunnen rond draaien en capturen.

[roy-t]

Zoijar schreef op zaterdag 13 maart 2010 @ 18:35:
Nou, mijn eerste indruk is "ik geloof er niet veel van". Point-cloud rendering is helemaal geen nieuwe tak; dat gebeurt al tijden en er zijn ook zelfs apparte conferenties over.

Nou geven ze niet echt specifieke claims, dus het is alstig er iets over te zeggen. Wat wel zo is, is dat je het visibility probleem niet in constante tijd kan oplossen. Als dat wel kon, dan nam je een set van N punten met dezelfde x,y coordinaten maar verschillende dieptes. Die render je dan in constante tijd en dan zie je alleen de voorste. Die knip je weg en sla je op en dan doe je het opnieuw. Dat moet je N keer doen om de set te sorteren, wat sorteren dan een O(n) operatie maakt. Maar dat is bewezen onmogelijk.

Maar goed, point-cloud rendering heeft zeker toekomst. Zeker omdat we die 3D data uit foto's kunnen verkrijgen en dan ipv polygonen te modellen, we gewoon een bestaand object voor een camera kunnen rond draaien en capturen.

Het is bewezen onmogelijk om dat ad-hoc te doen, maar als je een slimmere datastructuur gebruikt (UD geeft aan van te voren de data de compilen) kun je wel zeker sneller zijn O(n log n) (wat de bewezen lower bound op comparison based sorting/searching is). Kijk maar naar alle zoek algoritmes voor strings ( Wikipedia: String searching algorithm ) met een preprocessing tijd ter grote van het patroon kun je daarna zoeken met theta(lengte van te zoeken string).

Edit: dit is oa ook wat google doet, en door die vergelijking in het filmpje moest ik hier meteen aan denken.

[ Voor 3% gewijzigd door roy-t op 14-03-2010 08:55 ]

[Phyxion]

p_van_logchem schreef op vrijdag 12 maart 2010 @ 11:24:
Ik heb recent gemailed met de coder van deze engine : http://atomontage.com/ , Branislav Siles. Hij gaf aan dat zijn engine in staat is om ongeveer 500 Km2 aan voxel-data te verwerken. Hij werkt aan het integreren van zwaartekracht en enkele (simpele) chemische reacties (jawel!).
Zijn engine is ook gebaseerd op voxels, en ziet er zeer gelikt uit. Hij gebruikt een datastructuur waarmee het mogelijk is om redelijk goedkoop (uitgedrukt in bits per voxel) allerlei eigenschappen aan 'gebieden' toe te kennen, zodat hij fysieke en anders-soortige kenmerken kan toekennen : denk aan gewicht, richting van de zwaartekracht, frictie, wind, chemische samenstelling, elektrische lading, transparantie, of materiele waarde, etc. Waanzinnig eigenlijk - en het werkt echt!

Unlimited detail kende ik ook al een tijdje, maar vriend Bruce reageert niet (meer) op mail, waarschijnlijk heeft 'ie het te druk met optimalisatie-werk. Overigens is het ook goed om te vermelden dat hij heeft beweert dat z'n engine ook animatie aankan, en dat er permanente deformations mogelijk zijn (dat zie je in atomontage ook terug).

Persoonlijk hoop ik dat mensen die dit soort startups proberen zo vriendelijk zullen zijn om hun uitvinding publiek bekend te maken als hun bedrijfje het er niet mee redt. Natuurlijk, ik begrijp de secrecy, maar zoals we hebben kunnen zien in het (terecht al eerder genoemde) geval 'Sloot' is een potentieel veelbelovende (of op z'n minste zeer interressante) techniek nu verloren...

Dat eerste filmpje met die auto ziet er best OK uit eigenlijk. Ze zouden eens wat meer demo's moeten maken met ook animaties erin.
Unlimited Detail lijkt mij niet te kunnen in ieder geval (Al dan niet aan beperkingen aan GPU Memory), maar we shall see

[Zoijar]

Misschien gebruiken ze procedural geometry op het laagste niveau. In dat geval hebben ze wel echt unlimited geometry; i.e., je stelt bepaalde roughness vervormings functies vast aan de hand van fractal-achtige functies. Daar doorheen raytracen is gewoon eindig als je stopt als je ziet dat je geprojecteerde voxel (of point) niet groter dan een pixel is. Ik geloof wel dat zoiets kan. Bovendien in die hele grote scenes met al die beesten is het ook steeds hetzelfde beest; dat is gewoon instancing van dezelfde data. Ook staan die beesten in een bekened fractal patroon, dus de instance positie data kan berekend worden. Kortom, niet meer opslag dan een enkel beest.

Waar ik niet zo in geloof is dat ze een revolutionair nieuw algoritme hebben, een algoritme dat fundamenteel anders werkt. Ik denk dat het gewoon een vorm van voxel of point-cloud rendering is. Overigens is dat ook gewoon behoorlijk snel. Ray tracing is neit traag omdat het zo lang duurt een primairy hit te vinden, dat gaat heel snel, zeker met packet tracing; ray tracing is traag omdat je ontzettend veel secondary rays moet schieten en dat de cache performance daarvan meestal slecht is.

roy-t schreef op zondag 14 maart 2010 @ 08:54:
Het is bewezen onmogelijk om dat ad-hoc te doen, maar als je een slimmere datastructuur gebruikt (UD geeft aan van te voren de data de compilen) kun je wel zeker sneller zijn O(n log n) (wat de bewezen lower

Ja, ok, dat was even een denkfout Te slim proberen te zijn hehe.

[ Voor 14% gewijzigd door Zoijar op 14-03-2010 12:13 ]

[marlamin]

Ik ben niet zeker in hoeverre er regels zij qua bumpen hier op Tweakers.net, maar het team hierachter heeft een nieuwe video geupload van hun huidige status, en ik denk dat dat wel een valide reden is om de topic weer te bumpen.

Het is nu 3x meer ongelofelijk.

[YopY]

Ik vind het nog steeds veel marketing, weinig daadwerkelijke verkopen. Waarom hebben ze niet een verkoopbaar product? Waarom hebben ze geen tech demos laten bouwen door gamefabrikanten? En waarom hebben ze zich een jaar lang stilgehouden ipv dat ze hun voortgang bleven doorgeven?

Wat ik ook mis (en dit is niet onbelangrijk): Animaties. Alles blijf stilstaan (behalve de camera). Zonder dat kun je het niet als game-engine gebruiken.

en ook zoals ze zelf opmerken, ook de belichting is nog (verre van) af of realistisch.

[Soultaker]

Ik vind het persoonlijk zeker de moeite van het bumpen waard.

Ik denk niet dat er veel nieuws over de techniek valt te zeggen. Het lijkt nog steeds een voxel engine met procedureel gegenereerd datamodel. Wat het precies is, en of het echt zo goed werkt als de makers zeggen, kunnen we pas beoordelen als er een echte demo gereleased wordt.

Het filmpje ziet er indrukwekkend uit, maar blijkbaar durven ze het nog niet aan om hun eiland-demo publiek beschikbaar te stellen.

[Henk007]

Wat zijn de eisen aan de resources ?
Opslagruimte ? CPU ? Kan dit op een GPU draaien ?
Een online filmpje is leuk, maar ik geloof het pas als het realtime op mijn eigen hardware draait.

[Matis]

MueR schreef op vrijdag 12 maart 2010 @ 00:32:
* MueR noteert hem bij Duke Nukem Forever op het lijstje van wannahaves.

Duke Nukem is al weer een paar weken uit

[Cavorka]

Wat mij opvalt, als 3D'er, is dat niets animeert in hun filmpjes... (zoals YopY ook zei, zie ik net). Ik heb eens wat wetenschappelijke publicaties gelezen over voxels (waar al dit toch naar wijst) en daar waren de conclusies, voor zover ik het me kan herinneren, dat animeren met voxels relatief erg onhandig en zwaar is.

Hoe zit het bijvoorbeeld met deformatie van een karakter? Skin wrappen (zeg maar binden aan de oppervlakte van een poly-model) ze die, of gaat alles met bones? Een point-cache lijkt me namelijk uitgesloten met deze hoeveelheid data.

Nou ja, ik vind het maar twee hele wazige filmpjes, heel amateuristisch, slecht commentaar, vreemd gekozen muziek, en 0,0 echt technische informatie. Geef eens een 1:1 vergelijking tussen hetzelfde model die met polygonen en met hun manier gerenderd wordt.

[CoolGamer]

Ik vond dit toch een interessant onderwerp en ben over gaan googlen. Na even zoeken kwam ik een site tegen van iemand die onderzoek doet naar voxels rendering. Als je dit zo bekijkt ziet het eruit dat hun al véél verder zijn dan in de demo van Unlimited Detail te zien was.

Een voorbeeld: Interactive Indirect Illumination and Ambient Occlusion Using Voxel Cone Tracing

Realtime op een NVIDIA GTX 580 (claimen ze zelf).

Dit is dus gewoon mooie marketing. Goed gelukt overigens. Heel veel media hebben dit opgepikt. Gewoon een paar grote getallen noemen. Noem het point cloud i.p.v. voxels (ondanks ze dat zelf min of meer ontkennen). Omschrijf het "zoek"-algoritme cryptisch, i.p.v. serieuze implementatiedetails te geven. Lekker interessant zeggen dat de bestaande fabrikanten er bang voor zijn, terwijl de fabrikanten zelf onderzoeken ondersteunen over dit onderwerp (zo is dit voorbeeld ondersteund door NVIDIA). Ze zullen daarom dus de techniek niet hoeven kopen van hun.

Een conclusie die ik hieruit trek: als ik dit zo bekijk zouden hun claims over hun eigen product goed waar kunnen zijn (de overige claims moet je met een korreltje zout nemen). Het niveau van de demo laat zien dat het product nog niet goed genoeg is om de games van tegenwoordig te vervangen (bijvoorbeeld nog geen animaties). Dat ze werken aan een complete SDK klinkt veelbelovend en - mochten ze hun claims waarmaken - gaan we hier in de toekomst meer van horen. Hun zijn echter niet de enige die met deze techniek werken. Misschien wel de enige die op korte termijn (echter nog geen concrete datum) met een SDK zullen komen. Dat laatste maakt dit project zeker interessant om te volgen. Ik verwacht echter de komende jaren geen enkele game die is gemaakt met behulp van de technologie van hun.

[ Voor 22% gewijzigd door CoolGamer op 02-08-2011 02:11 ]

[D4NG3R]

Ik vind het allemaal erg gaaf zo, maar ik vraag me af hoe het gaat reageren als je Physics en destructible surroundings gaat toevoegen? Alles wat je in die filmpjes ziet is namelijk 100% static..

[djexplo]

D4NG3R schreef op dinsdag 02 augustus 2011 @ 12:47: ... Alles wat je in die filmpjes ziet is namelijk 100% static..

Dat is logisch. Ze moeten namelijk eerst hun data pre-processen en dat kost veel tijd.
Pre-processing
- Van de point-data van een object word een grove convex-hull gecreeerd van polygonen.
- Daarnaast word er van de point-data van elke object, 3 verschillende octrees gebouwd, 1'tje voor de x richting 1'tje voor de y richting en natuurlijk 1' voor de z richting.

Rendering,
- De convex-hull polygoon data word gerenderd
- De diepte buffer word uitgelezen, en op elke pixel word een ray-getraced, door de point-data
Ray-tracing kan erg snel met behulp van een shearpwarp algorithm en octrees uit de pre-processing stap.
- Na de ray-tracing, word er een simpel edge-detectie filtertje over het beeld gehaald (convolutie), op plekken van edges, word daarna extra net iets verschoven rays gestart om anti-aliasing doen.

"Infinite detail", word bereikt door als je het punt van ray-surface intersection hebt gevonden in een octree, dit sub-blokje van de octree te vervangen door een geschaalde versie van de orgineele octree en dan een nauwkeurige ray-surface intersection te vinden.

The legendary games programmer John Carmack, in an interview on PC Perspective in mid-March 2008 , spoke of a new technology he is working on:

“It involves ray tracing into a sparse voxel octree which is essentially a geometric evolution of the mega-texture technologies that we’re doing today for uniquely texturing entire worlds. It’s clear that what we want to do in the following generation is have unique geometry down to the equivalent of the texel across everything.”

[ Voor 19% gewijzigd door djexplo op 02-08-2011 13:11 ]

[Bozozo]

TheCoolGamer schreef op dinsdag 02 augustus 2011 @ 01:26:
Een voorbeeld: Interactive Indirect Illumination and Ambient Occlusion Using Voxel Cone Tracing
[video]
Realtime op een NVIDIA GTX 580 (claimen ze zelf).

Bedankt voor het Googelen, reuze interessant!

[Domdo]

Dit komt min of meer ook op hetzelfde neer als unlimited detail.

YouTube: ‪Atomontage Engine - The Future Is Volumetric, Atom-Based - Unofficial video-blog #1 (part 1 of 3)‬‏ - YouTube
YouTube: ‪Atomontage Engine - The Future Is Volumetric, Atom-Based - Unofficial vblog #1 (part 3/3;1st half)‬‏ - YouTube

[lezzmeister]

Die Atomontage engine komt op mij een stuk beter over, die jongen laat al wat zien.
Bandensporen in het zand, polygonen en voxels mengen geen probleem, al wat rudimentaire physics.
Ook komt hij niet met verhalen van gesimuleerde atomen.

[Plasma_Wolf]

Via een gameforum ben ik deze link tegen gekomen. Hierin worden ongeveer dezelfde vragen gesteld als in de GoT discussie hier.

Ik vind het filmpje van Atomonage Engine veel interessanter dan de film van Euclideon. Bij Atomontage Engine wordt nog echt wat gedaan, in plaats van "We hebben dit en DERP IT'S AWESOME". Dat is echt de indruk die ik krijg bij de Australische film. Het kan best waar zijn dat je dat er mee kunt, maar als je er zo over praat, neem ik het direct met een grote berg zout.

[Verwijderd]

Het is zeker mogelijk, een half jaar geleden ook een svo-ray caster geschreven, die zo'n 5 fps runde op full hd( cpu) en zo'n 10 a 12 IIRC op de gpu( opencl ) beide niet geoptimalizeerd. En bestond uit 1.3 miljdard leaf nodes en totaal denk ik 2.0 zie plaatje:


Maar ik zie dit zeker niet de komende jaren mainstream worden voor games, want de opslag is huge, zelfs voor deze op vrij low density gescand dorp(350 bij 200 meter) zit je al op de 29 gig aan pure voxel data.
Daarom zie ik in dat filmpje waarschijnlijk zoveel instanced 'voxel' objects.


just my 2 cents;)

[PrisonerOfPain]

Verwijderd schreef op woensdag 03 augustus 2011 @ 22:47:
Maar ik zie dit zeker niet de komende jaren mainstream worden voor games, want de opslag is huge, zelfs voor deze op vrij low density gescand dorp(350 bij 200 meter) zit je al op de 29 gig aan pure voxel data.
Daarom zie ik in dat filmpje waarschijnlijk zoveel instanced 'voxel' objects.

Het lijkt me eerder dat dat een streaming probleem gaat worden en hoe snel of hoe langzaam je de benodigde hoeveelheid data van disk kunt krijgen en decompressen. Mega meshes & mega textures zijn hier ook op gebaseerd en zolang je geen 180°-turns hoeft te ondersteunen kun je redelijk wat cachen lijkt me.

[Verwijderd]

Ja klopt, je moet hoe dan ook als je in een 'nieuw' gebied komt de data instreamen, wat echt de beperkende factor is. En ik geloof niet in 'unlimited' compressie

[.oisyn]

Plasma_Wolf schreef op woensdag 03 augustus 2011 @ 22:24:
Via een gameforum ben ik deze link tegen gekomen.

Meneer Notch vergeet daarbij even dat niemand heeft beweerd dat die volledige scene uit unieke elementen bestaat. Ze maken waarschijnlijk gewoon gebruik van de pointcloud-equivalent van models, die heel veel keer geinstantieerd zijn.

Veel frappanter vind ik het gezever over de "polygon conspiracy". Ja sorry hoor, maar als je wilt dat mensen je serieus nemen dan moet je gewoon niet zo zielig lopen blaten over hoe de industrie zijn rug toekeert naar dat soort technieken. Wat sowieso ook niet waar is, maar zelfs nog los daarvan. Demonstreer gewoon je techniek (liefst onderbouwd met wetenschappelijke whitepapers) en laat dat voor zichzelf spreken.

[ Voor 7% gewijzigd door .oisyn op 03-08-2011 23:18 ]

[PrisonerOfPain]

Verwijderd schreef op woensdag 03 augustus 2011 @ 23:07:
Ja klopt, je moet hoe dan ook als je in een 'nieuw' gebied komt de data instreamen, wat echt de beperkende factor is. En ik geloof niet in 'unlimited' compressie

Mwa; je kunt in een frame tijd (33ms) redelijk wat data van disk streamen en decompressen - desnoods met een paar frames latency. Of je het ook van DVD/Bluray kunt streamen lijkt me sterk; maar een gemiddelde HDD die rond de 50MB/s trekt zou redelijk moeten kunnen. Als je dan niet in een keer alles opnieuw in hoeft te laden (180° turns) zou je dit redelijk moeten kunnen bijhouden.

.oisyn schreef op woensdag 03 augustus 2011 @ 23:17:
Veel frappanter vind ik het gezever over de "polygon conspiracy". Ja sorry hoor, maar als je wilt dat mensen je serieus nemen dan moet je gewoon niet zo zielig lopen blaten over hoe de industrie zijn rug toekeert naar dat soort technieken. Wat sowieso ook niet waar is, maar zelfs nog los daarvan. Demonstreer gewoon je techniek (liefst onderbouwd met wetenschappelijke whitepapers) en laat dat voor zichzelf spreken.

Sowieso raar omdat NV onderzoek doet in deze richting en de medische/historische sector er redelijk bij gebaat is om dit snel te kunnen doen.

[ Voor 41% gewijzigd door PrisonerOfPain op 03-08-2011 23:30 ]

[Chip.]

[Verwijderd]

Het klinkt allemaal leuk en aardig, maar zodra iemand beweert Ünlimited" haak ik al af. Polygons kunnen theoretisch ook unlimited.

Maar ik blijf het even volgen, want om dat puntje na is het toch wel intressant.

[PrisonerOfPain]

Verwijderd schreef op donderdag 04 augustus 2011 @ 10:25:
Het klinkt allemaal leuk en aardig, maar zodra iemand beweert Ünlimited" haak ik al af. Polygons kunnen theoretisch ook unlimited.

Ach kom op; al de unlimited claims die gemaakt worden in CS komen altijd met een catch. Unlimited compression? Sure, als je files uit enkel zero-bytes bestaan. Unlimited precision? Sure, als je genoeg ram hebt om het allemaal in te passen, en het is traag. Infinite lists? Sure, als ze procedural zijn. Etc. De claim hier gaat over unlimited graphics detail, niet unlimited compression, mem of cpu.

[roy-t]

Toevallig zie ik net in PrisonerOfPain's twitter stream een linkje naar een techniek om voxels te animeren op een nieuwe manier. Misschien relevant voor UD?

http://bautembach.de/wordpress/?page_id=7

[PrisonerOfPain]

Andere relevante papers:

http://jonolick.weebly.co...-parallelism-in-games.pdf (Jon Olick - iD software - 2008)

http://www.nvidia.com/docs/IO/88889/laine2010i3d_paper.pdf (NV 2010 op GPU)

[Spinal]

Mogelijk al gezien door iedereen, misschien niet: YouTube: Euclideon & Unlimited Detail - Bruce Dell Interview - YouTube
Rond 15:30 wordt iets gezegd over animaties, rond 16:10 en 21:30 iets over specificaties, maar het interessants is te vinden rond 22:20, waarin de "interviewer" speelt met de demo.
Eigenlijk is het allemaal interessant atomontage wordt ook nog even aangehaald en John Carmack wordt onderuit gehaald

[CoolGamer]

Ik geloof wel dat wat ze hier hebben laten zien technisch haalbaar is. De voxel-demo's van andere fabrikanten laten ook al super mooie dingen zien. De vraag over het geheugengebruik werd helaas heel erg kort en ontwijkend beantwoord. Ik denk ook dat daar een van de grotere problemen zal zitten. Echter valt daar misschien met streamen en hergebruik van objecten ook wel een en ander te doen. Maar zonder echte implementatiedetails blijft het speculeren.

Het grote probleem zal ook – naar mijn verwachting – zijn om er een complete SDK van te maken die een beetje voldoet aan de verwachtingen van een hedendaagse grafische engine voldoet. Als je kijkt wat een game engine tegenwoordig aan grafische mogelijkheden biedt: objecten en terrein maken, animaties, belichting, schaduwen, shaders, enz.. Er is heel wat onderzoek gedaan om die dingen goed te krijgen voor rendering op basis van polygonen. Er zal ook heel wat onderzoek nodig zijn om dat goed en efficiënt te doen op basis van voxels. In de video is te zien dat ze al een goede basis hebben gelegd. Ze zullen op het gebied van polygonenrendering de concurrentie misschien verslaan, maar dat is niet het enige want een goede grafische engine moet kunnen doen. Van een complete grafische engine zijn ze nog ver vandaan. Dat zal misschien ook de reden zijn geweest dat de investeerders afhaakten. De techniek is heel erg veelbelovend, maar het gaat nog een hele tijd duren voordat ze de eerste echte versie kunnen gaan uitbrengen.

Maar aan de andere kant: Waarom zouden ze, de mensen bij Euclideon, ons overtuigen? Het product is nog lang niet af. Ze hoeven het product vervolgens ook niet aan ons te verkopen. Er gaat nog een hele tijd overheen voordat we deze technologie echt in spellen gaan zien. En zelfs als we het in spellen zien, hoeven ze het niet aan ons, de gamer, te verkopen. Ze moeten het verkopen aan de ontwikkelaars. Ons overtuigen op dit moment levert niks op. Alleen de investeerders tevreden houden is eigenlijk nodig.

Maar ja, dan weer van ene kant: Waarom maken dan zo'n filmpje vol met grote claims? "Het is een complot van de fabrikanten!" Het zal zeker investeerders trekken, want het ziet er toch goed uit. Maar dan moet je niet zo zielig gaan lopen doen, zoals te zien is aan het einde van het filmpje. Je maakt grote claims, zonder hard bewijs te tonen. Dan moet je ook niet raar gaan staan kijken wanneer mensen hard gaan terugroepen. Dat vind ik zelf gewoon erg zwak.

Interessant product hebben ze daar, maar het is nog lang niet af.

[roy-t]

Dat interview is erg interessant.

Ik zat nog even te rekenen. Als je een object (Olifant) in deelt in blokken van variabele grote dan zou je per atom maar 1 float / 4 bytes nodig hebben. Je definieert een blokje als bijvoorbeeld een array van 100x100x100. Elk blokje heeft een X,Y, en Z coordinaat. De positie van het atoom is dan de positie van het blok + atomSize * positieInArray. Je hebt dan nog wel kleur nodig, maar die kun je zonder moeite opslaan in 1 float, dan heb je 4294967296 kleuren, lijkt me wel even zat.

Dit geeft bij 4GB werkgeheugen dan 268435456 atomen, waarbij nog wat overhead er af gehaald moet worden (ook krijg je zo atomen die 'lucht' zijn, maar door de blokjes van grote te laten varieren kun je het aantal 'lucht' atomen goed terugdringen) een beetje zoals dit:



Natuurlijk hoeven niet alle objecten tegelijkertijd in het geheugen, dus ze kunnen gecomprimeerd op de hardeschijf staan. En als 1 maal zo'n in blokken opgedeeld model hebt kun je deze natuurlijk vaker gebruiken in levels (net als nu). Dus ipv 10 polygoon bomen, krijgen we dan 10 'echtere' bomen.

Tot zover lijkt me dat gehele geheugen probleem niet te bestaan iig.

Ook is het wel leuk dat ze 100 atomen per vierkante mm hebben, maar een echte game gaat natuurlijk nooit zoveel detail opslaan, 100 atomen per vierkante cm lijkt me voor de meeste games veel meer dan genoeg, en dat is toch weer een groot verschil.

Anyway, wat denken jullie van deze kort door de bocht berekeningen?

TheCoolGamer schreef op vrijdag 12 augustus 2011 @ 02:33:
Maar aan de andere kant: Waarom zouden ze, de mensen bij Euclideon, ons overtuigen? Het product is nog lang niet af. Ze hoeven het product vervolgens ook niet aan ons te verkopen. Er gaat nog een hele tijd overheen voordat we deze technologie echt in spellen gaan zien. En zelfs als we het in spellen zien, hoeven ze het niet aan ons, de gamer, te verkopen. Ze moeten het verkopen aan de ontwikkelaars. Ons overtuigen op dit moment levert niks op. Alleen de investeerders tevreden houden is eigenlijk nodig.

Heb je het interview gezien? (staat boven gelinked) daarin legt hij uit waarom dat filmpje uberhaupt op youtube stond (voor een interne presentatie, waarnaar ze na de overvloed van reacties toch nog een keer wilden reageren voordat ze weer verder gaan, het had niets te maken met youtube gebruikers aan hun kant krijgen, maar het was gewoon een sales pitch, ook hebben ze backing van een groot software bedrijf en een subsidie van 2M van de Australische overheid). Ook zegt hij (gelukkig) niets meer over de polygoon maffia. En laat hij oa animaties zien en een realtime demo waarmee de presentator zelf even mag spelen.

[MacWolf]

John Carmack geeft ook zijn mening over een Unlimited Detail Engine:

YouTube: John Carmack Interview: GPU Race, Intel Graphics, Ray Tracing and Voxels and more! - PC Perspective - YouTube

[roy-t]

Carmack begint even over UD maar daarna heeft hij het ineens over procedural generated content, waar UD dat juist helemaal niet is. Het infinite by UD komt er van dat de limitatie de scan technologie en de resolutie van het beeldscherm is, niet de engine zelf.

[Bozozo]

Carmack doelt op de 'unlimited detail' claim, die alleen kan worden waargemaakt met instanced geometry. Zoals je ziet in de demo's van UD kunnen ze alleen maar enorme arrays van instanced geometry weergeven... leuk voor procedurally generated environments (gras, bomen, zandkorrels?!) maar verder volkomen nutteloos in videogames.

Ik vind het interview waardeloos. De interviewer heeft geen kennis van zaken en laat die glibberige dude alle vragen ontwijken. Wat mij betreft staat alle kritiek nog steeds overeind... voxel engines zijn niet nieuw, instanced geometry is een niche, opslag en animatie zijn problematisch, etc. John Carmack zegt in dat andere interview meer nuttige dingen in een fractie van de tijd.

[Verwijderd]

t zijn allemaal instances, ik heb deze week, ook weer even tijd, dus ff de ray marcher oppakken, die een grid van 1000x1000 tiles (each 150 miljoen points) ray traced. Wij (als bedrijf ) hebben ook wat andere filmpjes van hem, onder NDA, maar daarin claimed ie dat ie maar 40mb aan memory nodig heeft, iets wat ik dus niet geloof als alles unieke voxels/atoms zijn. want je wilt altijd je secondary cache hebben, voor als je bijv 180 ronddraait,

maar ja we zullen t wel zien;)

Edit: je komt in principe weg met svo's met 8 bits per node(child indices ), zonder rgba, zonder normals etc. Maar dan heb je niks, je zou rgba in je leafs kunnnen opslaan, maar dan moet je altijd tot je leafs recursen, iets wat je niet wilt hebben

[ Voor 20% gewijzigd door Verwijderd op 13-08-2011 12:51 ]

[MacWolf]

Bozozo schreef op zaterdag 13 augustus 2011 @ 12:29:
Carmack doelt op de 'unlimited detail' claim, die alleen kan worden waargemaakt met instanced geometry. Zoals je ziet in de demo's van UD kunnen ze alleen maar enorme arrays van instanced geometry weergeven... leuk voor procedurally generated environments (gras, bomen, zandkorrels?!) maar verder volkomen nutteloos in videogames.

Ik vind het interview waardeloos. De interviewer heeft geen kennis van zaken en laat die glibberige dude alle vragen ontwijken. Wat mij betreft staat alle kritiek nog steeds overeind... voxel engines zijn niet nieuw, instanced geometry is een niche, opslag en animatie zijn problematisch, etc. John Carmack zegt in dat andere interview meer nuttige dingen in een fractie van de tijd.

Wat ik uit het interview met Carmack haal, is inderdaad zoals je aangeeft dat er vooral sprake is van procedureel gegenereerde content bij UD, waar zo'n engine blijkbaar goed mee om kan gaan. Carmack geeft aan meer toekomst te zien in raytracing, waar momenteel nog steeds erg krachtige hardware voor nodig is, maar wat steeds meer bereikbaar wordt voor de gewone consument. Ook lijkt Carmack vooral een praktische kijk op zaken te hebben, in zoverre dat hij infinite detail minder belangrijk vindt dan dat de artistieke visie goed in het spel terecht komt.

[PrisonerOfPain]

roy-t schreef op zaterdag 13 augustus 2011 @ 11:21:
Dat interview is erg interessant.

Ik zat nog even te rekenen. Als je een object (Olifant) in deelt in blokken van variabele grote dan zou je per atom maar 1 float / 4 bytes nodig hebben. Je definieert een blokje als bijvoorbeeld een array van 100x100x100. Elk blokje heeft een X,Y, en Z coordinaat. De positie van het atoom is dan de positie van het blok + atomSize * positieInArray. Je hebt dan nog wel kleur nodig, maar die kun je zonder moeite opslaan in 1 float, dan heb je 4294967296 kleuren, lijkt me wel even zat.

Dit is ongeveer dezelfde berekening als die Notch heeft gedaan in z'n blogpost. Zo werkt het dus niet

[roy-t]

Hoe werkt het dan wel?

[Soultaker]

Bozozo schreef op zaterdag 13 augustus 2011 @ 12:29:
Wat mij betreft staat alle kritiek nog steeds overeind... voxel engines zijn niet nieuw, instanced geometry is een niche, opslag en animatie zijn problematisch, etc.

Je moet wel bedenken dat toen Quake geschreven werd, 3D rendering, BSP trees, texture maps, light maps en dergelijke ook niet nieuw waren. Maar waarin Quake uniek was, was dat John Carmack het voor elkaar had gekregen om op gangbare PC-hardware (50 MHz 80386s geloof ik?) een indrukwekkend grote wereld in realtime te kunnen renderen (door heel veel te preprocessen en de render routines extreem te stroomlijnen).

Op dezelfde manier zijn inderdaad voxel engines, raytracing en proceduraal gegenereerde modellen niet nieuw, maar als je het op de een of andere manier voor elkaar krijgt om het met grote ruimtes in realtime uit te voeren, dan kan het resultaat toch verbluffend zijn.

[ Voor 6% gewijzigd door Soultaker op 13-08-2011 21:59 ]

[Verwijderd]

Lekker vroeg wakker!! check ook eens deze link: bestaat als sins '99

http://graphics.stanford.edu/software/qsplat/

Hier nog wat leuke data:

http://graphics.stanford.edu/dmich-archive/

[ Voor 30% gewijzigd door Verwijderd op 14-08-2011 10:03 ]

[PrisonerOfPain]

roy-t schreef op zaterdag 13 augustus 2011 @ 18:56:
Hoe werkt het dan wel?

Check de papers die ik eerder postte om een globaal beeld te vormen. Het zal niet 100% overeen komen (die gast heeft 5-6 jaar lang aan het product gewerkt en dus het een en ander waarschijnlijk wat extremer geoptimaliseerd) maar je kunt je een redelijk beeld vormen van de technieken er achter.

[Verwijderd]

Ook wel grappig, de actual inventor of t octree formaat

http://octree.com/

heeft een plugin voor IE only die alles in software rendered ook, draw calls zijn volgens mij wel GL want ik zie gpu usage oplopen

[boe2]

Verwijderd schreef op zondag 14 augustus 2011 @ 14:24:
Ook wel grappig, de actual inventor of t octree formaat

http://octree.com/

heeft een plugin voor IE only die alles in software rendered ook, draw calls zijn volgens mij wel GL want ik zie gpu usage oplopen

Een ongelofelijk brakke site, met pagina's waar niet meer dan een brakke jpg opstaat en bovendien ook al niet meer geupdate is in meer dan een jaar. Ik roep nog steeds "scam".

[ Voor 21% gewijzigd door boe2 op 14-08-2011 15:41 ]

[ZpAz]

Ik heb de filmpjes en interview bekeken, en ik vind het best plausible klinken. Het is gewoon een compleet andere aanpak en het kan best wat opleveren.

[.oisyn]

Verwijderd schreef op zondag 14 augustus 2011 @ 14:24:
Ook wel grappig, de actual inventor of t octree formaat

Wat is "het octree formaat"? Een octree is een datastructuur die al decennia bestaat, en heeft tal van toepassingen.

[ Voor 18% gewijzigd door .oisyn op 15-08-2011 00:01 ]

[Verwijderd]

Nou die kerel claimt dat ie t uit heeft gevonden zo'n 30 jaar geleden

Ieder formaat moet ergens zn origine hebben:)

[ Voor 26% gewijzigd door Verwijderd op 15-08-2011 08:49 ]

[Verwijderd]

maar goed ik zit eraan te denken om een (opensource) project te starten iedereen die zich geroepen voelt om mee te doen is welkom, qsplat is een goeie basis om mee te werken

[PrisonerOfPain]

Verwijderd schreef op maandag 15 augustus 2011 @ 08:29:
Nou die kerel claimt dat ie t uit heeft gevonden zo'n 30 jaar geleden

Ieder formaat moet ergens zn origine hebben:)

Kom op, een octree is wel zo'n hersendode datastructuur dat iedereen die zonder al te veel moeite bedacht zou kunnen hebben.

[Rekcor]

PrisonerOfPain schreef op maandag 15 augustus 2011 @ 10:47:
[...]


Kom op, een octree is wel zo'n hersendode datastructuur dat iedereen die zonder al te veel moeite bedacht zou kunnen hebben.

Tsja, dat geldt natuurlijk ook voor het wiel, vuur, etc. Maar kom er maar eens op als het er nog niet is .

[.oisyn]

Verwijderd schreef op maandag 15 augustus 2011 @ 08:29:
Nou die kerel claimt dat ie t uit heeft gevonden zo'n 30 jaar geleden

Wat bullshit is, want de octree is al bijna zo oud als computer graphics zelf. Waar staat die claim precies? Op octree.com zelf kan ik bijzonder weinig over het bedrijf zelf vinden.

En een datastructuur is geen formaat. "Het octree formaat" slaat dus nergens op, tenzij je echt een file formaat bedoelt.

[ Voor 32% gewijzigd door .oisyn op 15-08-2011 11:19 ]

[D4Skunk]

Even kort door de bocht; je berekeningen zitten een beetje verkeerd; een octree is niets anders dan een gespecialiseerde vorm van bsp icm voxels.; een eenvoudige uitleg:

- Veronderstel een heel grote kubus die je wereld voorstelt.
- Verdeel deze kubus in identieke stukken door er zowel horizontaal, verticaal als in de diepte met een mes door te snijden; je hebt dan 8 identieke kubussen, die elk een deeltje voorstellen van de hele wereld.
- Het feit of 1 childkubus leeg is of niet kan je voorstellen met 1 bit, dus met 8 bits/1 byte, kan je voor de parentkubus bepalen of deze leeg is of niet.
- Herhaal voor elk van de childkubussen die niet leeg zijn dezelfde procedure, en sla deze bytes erachter op.
- Herhaal dit tot je precisie groot genoeg is en je dus voldoende detail hebt. De eerste keer is je precisie dus de grootte v/d wereld/2; elke keer je dit herhaalt voor de child elements verdubbel je je precisie.
- Om van een grootte van 1km naar +/-1 meter te gaan zou je dit proces dus 10x moeten herhalen (factor 2^10, of 1024), om van een grootte van 1km van +/-1mm moet je dit dus 20x herhalen(factor 2^20).

Als je nu wilt weten welke pixel je moet tonen op een bepaalde positie op je scherm, kijk je of de positie van de player door een schermpixel via een ray de kubus hit.
Als hij de kubus niet hit, dan render je de lucht, bevat die wel iets, dan ga je dit proces herhalen voor alle childkubussen. Het spreekt vanzelf dat je natuurlijk kan stoppen van zodra je iets hit.
Door de opbouw van de data kan je heel eenvoudig incrementeel de data opzoeken.
Daarnaast kan je ook afhankelijk van de afstand van de player tot de pixel, beslissen om minder diep te gaan omdat er minder detail nodig is=> minder stappen+free LOD.

De kracht van het renderen zit dus in de snelheid waarmee je 1 bepaalde schermpixel kan opzoeken in het systeem.

Het grootste nadeel is natuurlijk dat de geometry fixed is => geen/weinig bewegende objecten.

Er bestaat wel een manier om dit op te lossen, maar dat kost relatief gezien wel redelijk wat performance (het komt er op neer dat je je bounding box vergroot voor elke voxel).

Wat unlimited detail hoogstwaarschijnlijk ook doet, is in plaats van elk kubusje apart op te slaan, een pointer te gebruiken naar die kubus info, en zo dus ipv duizenden keren iets op te slaan het slechts 1 keer hoeft te doen. Dat verklaart ook de blokkerigheid van hun testmap.
Je kan zelfs een kubus naar zichzelf laten verwijzen, waardoor deze op die manier effectief ook unlimited detail krijgt (denk een soort van fixed fractal)=> vandaar waarschijnlijk de naam.

Of deze techniek ook effectief bruikbaar wordt, daar heb ik mijn twijfels bij. Ik ben persoonlijk toch meer aanhanger van Carmack, die iets vergelijkbaar aan het doen is, maar dan zonder die fixed fractals, maar met caching/Streaming (think:megatexture voor geometry)

Men zou natuurlijk ook wel een mix van beiden kunnen doen, waarbij je een soort van lossy compressie doet, en zegt van "als de zaken genoeg op elkaar lijken, dan gebruik ik gewoon dezelfde kubus", of een soort van morphing achtig iets... Fractals ftw.

Wat ik persoonlijk wel interessant vind, is de evolutie eens te bekijken=>
- Wolfenstein 3D: 2D voxel map v/d grond (elk blokje = 1 eenheid)
- Doom: polygon map v/d grond+delta hoogte
- Quake: BSP's (vergelijkbaar met een octree, maar slechts 1 "snede" ipv 3 per kubus
- Cube3D: de eerste bekende octree shooter afaik

In Cube3D werd de "grid-achtigheid" opgelost door slopes toe te voegen aan voxels om zo de grootte van de data te beperken.
Unlimited detail doet dit waarschijnlijk niet, maar herhaalt gewoon volledige stukken.
Carmack lost dit dan weer op dmv streaming/caching.

Als je deze evolutie bekijkt, dan verwacht ik na de octree als volgende freeform deformations (denk bv een 3-zijdige piramide opgedeeld in 4 nieuwe piramides door 1 vertex in deze piramide te positioneren... => De mogelijkheden zijn dan quasi onbegrensd, omdat je dan minder bytes nodig hebt om niet-grid-data te modelleren, en je heb nog steeds de mogelijkheid om stap per stap naar meer detail te gaan...

[.oisyn]

D4Skunk schreef op maandag 15 augustus 2011 @ 13:32:
Even kort door de bocht; je berekeningen zitten een beetje verkeerd; een octree is niets anders dan een gespecialiseerde vorm van bsp icm voxels.;

Een octree is niets anders dan een spatial subdivision structuur dat elke node onderverdeeld in 8 child nodes. Een octree heeft an sich niets met voxels te maken. Die unlimited detail engine maakt trouwens niet gebruik van voxels, maar van point clouds. Het grote verschil is dat voxels over het algemeen vast zitten op een grid.

En Doom had overigens ook een (2d) BSP tree

[ Voor 19% gewijzigd door .oisyn op 15-08-2011 15:36 ]

[D4Skunk]

.oisyn schreef op maandag 15 augustus 2011 @ 15:31:
[...]

Een octree is niets anders dan een spatial subdivision structuur dat elke node onderverdeeld in 8 child nodes. Een octree heeft an sich niets met voxels te maken. Die unlimited detail engine maakt trouwens niet gebruik van voxels, maar van point clouds. Het grote verschil is dat voxels over het algemeen vast zitten op een grid.

True, ik denk dat ik mijn tekst iets te veel ge-edit heb alvorens te posten My apologies, al moeten het imho wel 8 identieke nodes zijn, gealigneerd met de X/Y/Z-axis ?
Als ze effectief met point clouds werken, dan ben ik wel benieuwd naar de details, maar als je naar de structuur van de map kijkt, dan denk je IMHO toch echt wel "octree all over the place"...

En Doom had overigens ook een (2d) BSP tree

Ah, ik dacht dat die werkten met convexe polygons, en een soort van visible area's ? Think raycasting van wolfenstein 3d, maar dan met polygons ipv cubes... - tenminste, dat is hoe ik mijn software renderer implementeerde tijdens mijn demo days -

De kracht van die sparse voxel octrees zit hem trouwens in de manier waarop de data gerepresenteerd wordt; haal daar nog wat Carmack-mumbo-jumbo ver, en je heb volgens mij wel echt iets super-duper™

[ Voor 12% gewijzigd door D4Skunk op 15-08-2011 21:09 ]

[PrisonerOfPain]

D4Skunk schreef op maandag 15 augustus 2011 @ 21:04:
De kracht van die sparse voxel octrees zit hem trouwens in de manier waarop de data gerepresenteerd wordt; haal daar nog wat Carmack-mumbo-jumbo ver, en je heb volgens mij wel echt iets super-duper™

De Carmack mumbo-jumbo komt in dit geval via Jon Olick. Maar het is hetzelfde bedrijf

[.oisyn]

D4Skunk schreef op maandag 15 augustus 2011 @ 21:04:
Ah, ik dacht dat die werkten met convexe polygons, en een soort van visible area's ? Think raycasting van wolfenstein 3d, maar dan met polygons ipv cubes... - tenminste, dat is hoe ik mijn software renderer
implementeerde tijdens mijn demo days -

Doom is ook gewoon raycasting, maar dan door een bsp tree ipv door een grid zoals bij wolfenstein

.edit: ik lees net dat Doom helemaal geen raycasting doet. Het is natuurlijk wel prima zo te implementeren.

[ Voor 14% gewijzigd door .oisyn op 15-08-2011 22:27 ]