ZFX + Developia

Bezüglich Unlimited Detail würde ich gerne mit euch darüber diskutieren und vielleicht bekommen wir ja gemeinsam heraus, wie das ganze funktionieren könnte.

Ich habe die letzten Tage viele Stunden ( es waren bestimmt insgesamt 8 ) mit zwei anderen telefoniert und wir haben uns den Kopf bzgl. der Technologie zerbrochen.

Ein paar Sachen sind bekannt. Andere haben wir uns zusammen gereimt. Hier mal der aktuelle Stand:
Also erstmal ist dieser Bruce sehr von dem Überzeugt, was er tut. Er entwickelt seit über 7 Jahren an der Engine. Wenn man sich seine ersten Ergebnisse ansieht, sind diese sehr dürftig. Wir schätzen ihn als ziemlichen Noob, der eigentlich nicht viel Plan hat. Zumindest hatte er das damals nicht. In seinem Interview bezeichnet er z.B. LOD als "Level of Distance"... oder er meint, dass tesselieren Displacementmapping wäre und dass Tesselation deswegen seiner Technik unterlegen ist, da Tesselation keine Holräume unter der Displacementgeometrie ermöglicht. Wie gesagt, für ihn ist Tesselation in erster Linie Displacement. Er erzählt, wie viele Abertrilliarden was weiß ich wie viele Punkte gerendert werden. Aber dabei zählt das ja nicht, da es durch das Culling und LOD ja garnicht zu dieser Menge kommt. Normalerweise würde ich auch nichts sagen, wenn jemand eine Engine Unlimited Detail nennt... es ist ja nur ein Name... aber er betont es etliche male, dass es UNLIMITED ist. Und unlimited gibt es beim Rechner nicht und wird es nie geben, das sollte wohl jedem klar sein.
Laut jemanden, der im Forum sich das angeschaut hat, ist die innere Schleife sehr einfach und darin ist weder Multiplikation noch Division. Er verwendet MASS-CONNECTED-PROCESSING. Die Darstellung wabert ziemlich stark. In den alten Videos ist neben Shadowmapfehlern auch das Frustumculling zu sehen, da Punkte, die das Frustum nach außen hin berühren direkt verschwinden. Das ist in dem neuen Video nicht.

Also es handelt sich definitiv um Punktwolken. Er muss alle Dreiecksobjekte in Punktwolken umrechnen. Dabei wenden die nun auch Kompressionen an. Er behauptet, dass er weniger Speicherbedarf für die Punkte braucht, als man bei Dreiecksnetzen benötigt. Ich habe nicht ganz verstanden, ob er bei gleichem Detailgrad meint.

An einer Stelle im Video fliegt er in den Boden und da sieht man deutlich, dass es sich um kleine Quads handelt. Überhaupt ist die ganze Welt statisch und sehr stark instanziert.

Er muss irgendeinen Trick herausgefunden haben. Als er damals angefangen hat, hat er es so gemacht, wie er sich damals vorgestellt hat, wie 3D funktioniert. Es muss einfacher als Raytracing und einfacher als Rasterizing sein... sonst hätte er ja einfach das verwenden können, aber ich schätze, das war ihm zu kompliziert. Seine ersten Bilder erinnern sehr an eine 2D-Tileengine, nur das die schon 3D sind... allerdings mit gekrümmter Linse. Vielleicht hat das auch was zu sagen. Irgendwann hat es einen mächtigen Sprung in der Darstellung gegeben... er meinte, dass die was entdeckt hätten, um das ganze erst so detailliert machen zu können. Wir vermuten, dass es sich um einen Octree oder eine andere Beschleunigungsstruktur handeln muss. Octrees sind für einen Anfänger doch recht schwierig zu verstehen. Also wenn man einen Octree hinbekommt, dann kann man auch ein normales Dreieck transformieren. Da wir mal davon ausgehen, dass er es nicht konnte, würde das auch gut ins Bild passen.
Er sagt auch immer, dass sein Algo dem eines Suchalgos gleicht. Und er kann direkt an jedem Pixel sagen, welcher Punkt gezeichnet werden muss... das ganze also mit Frustum und Occlusion Culling.
Wir haben überlegt, ob er vielleicht Boxen transformiert und dann die Punkte da drin interpoliert. Er darf ja in der inneren Schleife nur 2D arbeiten, weil Division ist ja nicht. Das Problem bei der transformierten Box wäre die Interpolation in die Tiefe. Ohne Perspektivenkorrektur, die es nur mit Division gibt, ist da glaube ich nichts zu machen.
Aber MASS-CONNECTED-PROCESSING klingt so, als ob er irgendwas anwendet, womit er dann viele Punkte auf einmal behandeln kann.

Bisher gibt es keine Animationen. Er macht sich zwar darüber lustig, dass böse Zungen das behaupten und die welche hätten, aber die will er noch nicht zeigen. Damals hatte er Skelletanimationen. Durch Sichtstrahlenveränderung ( er benutzt keine Strahlen, von daher ist das jetzt nur ein Äquivalent zu z.B. Raytracing ) könnte man Skelletanimationen realisieren, ohne das die Geometrie verändert werden muss.

Einer der beiden, mit denen ich geredet habe, hatte gesagt, dass es bei einem Octree ja möglich ist, mehrfach auf die gleichen Daten zu verzweigen und es so möglich macht, Instanzen zu renden.
Nun ist mir folgendes in den Sinn gekommen: Ich glaube, die Engine, ist nur so effektiv, weil sie Instanzen benutzen! Mal ganz abgesehen vom Speicherplatz. Es ist sehr eigenartig, dass die Objekte gleich orientiert sind. Ich glaube, Instanzen haben bei UD eine etwas andere Bedeutung. Und zwar ist etwas nur Instanz, wenn es die gleiche Ausrichtung im Raum hat. Also mal angenommen man verwendet Sprites... man hat nun eine Palme und sieht sie von vorne... diese könnte auch für andere Palmen, die gleich ausgerichtet sind, verwendet werden. Fliegt man nun nach oben und schaut von oben auf die Szene, so würden wieder alle Palmen gleich aus sehen, man könnte also immer das gleiche Sprite verwenden. Vielleicht benutzt er sowas in der Art... da müsste ja nur noch ne Möglichkeit für die Parallaxe Verschiebung rein. Wobei mir das Occlusion dabei nicht klar wäre.
Die haben die Demo extra 3 Wochen lang programmiert. Und dann sieht alles so kopiert und eingefügt aus? Die programmieren eine solche Engine, wo wäre da das Problem, jeder Grasinstanz eine Zufallsrotation zu geben. Ich glaube sogar, das jede dieser Instanzen, vielleicht weil die für diese Spriteähnliche Technik vorgecached werden müssten, entsprechend Speicher oder Rechenaufwand kosten und das deswegen bei größeren Objekten noch mehr gespart wird, was die Rotation angeht. Denn jeder Elefant ist gleich ausgerichtet. Die Steine auf dem Boden nämlich nicht... da könnten die ja ruhig ein paar fertig machen, verschieden rotieren und dann auch wieder tausende male instanzieren.

Alles in allem ist das ganze zwar nett, aber solange ich das nicht live sehe, denke ich, dass es nur gehypted wird und in Wirklichkeit ziemlicher Schrott ist. Vielleicht wäre da die ein oder andere Sache interessant zu wissen. Aber letztendlich, falls es wirklich so ist, dass alles gleich ausgerichtet sein muss, um effektiv dargestellt zu werden, bringt es ja nur in bestimmten Spielen etwas.

Also eigentlich ist die Demo ja recht mager. Hätten die mit ihrem Unlimited mal einen Wald gerendert, der nicht so kopiert und eingefügt aussehen würde, dann wäre es mit Sicherheit beeindruckender gewesen.
Naja, vielleicht irren wir uns ja auch total, und wir haben es hier mit einem Übergott zu tun... Bruce allmächtig... und wir können seine genialen Wunder gar nicht erst begreifen. Wir werden sehen.

Jo,
also mir kommt er auch sehr überzeugt vor.
Und das er die Begrifflichkeiten durcheinanderbringt... nunja... ich denke das sagt noch nicht viel aus.
Oder aber sehr viel :D ... vlt. is das echt alles nur ein riesen Aprilscherz!

@Punktwolken

Also es handelt sich definitiv um Punktwolken. Er muss alle Dreiecksobjekte in Punktwolken umrechnen. Dabei wenden die nun auch Kompressionen an. Er behauptet, dass er weniger Speicherbedarf für die Punkte braucht, als man bei Dreiecksnetzen benötigt. Ich habe nicht ganz verstanden, ob er bei gleichem Detailgrad meint.

So wie ich das verstanden habe, handelt es sich um Punktwolken, ja!
Aber ob es so läuft, das die Meshes in Punktwolken zerlegt werden... das muss ja nicht sein.
Ich kann mir vorstellen, das es Punktwolken mit verschiedener Auflösung gibt, je nach LOD.
Ich denke da mal spontan an TIFF zB. Also wo dieselben Bilder nur in unterschiedlicher Auflösung abgespeichert werden.
Und je nach dem wie der Zoom (LOD) ist, also, ob man sich das Bild vergrößert oder verkleinert anschauen will werden die Bilddaten aus der jeweilegen Auflösungs-Stufe abgegriffen.
So könnte es ja auch bei den Punktwolken sein... *mal kurz meine Gedanken schweifen lassen*
Es geht nun darum, denke ich, aus der Punktwolke schnellst möglich einen "Mesh" zu machen.
Aber vlt. nicht Mesh im Sinne von Polygon... sondern vlt. etwas anderes.
Wie kann man noch aus Punktwolken eine "Oberfläche" machen?
Die Punkte nicht als Punkte darstellen, sondern als zB. Quad?

Bisher gibt es keine Animationen.

Doch... die gibt es.
Also, laut Video.
Habe ich schonmal gesehen.

Naja, vielleicht irren wir uns ja auch total, und wir haben es hier mit einem Übergott zu tun... Bruce allmächtig... und wir können seine genialen Wunder gar nicht erst begreifen. Wir werden sehen.

Mich düngt dies ist Ironie...?

joggel hat geschrieben:

Bisher gibt es keine Animationen.

Doch... die gibt es.
Also, laut Video.
Habe ich schonmal gesehen.

Damals hatten die Skeletal Animations inklusive Beweisvideo (irgendwo in diesem 1h-Interview), in der neuen Engine ist davon noch nichts zu sehen. Wenn die aber von der gleichen Animationsqualität wie die damals sind, dann kann man damit vielleicht maximal Bodenwellen bei einem Erdbeben animieren ;)

Is doch schonmal was :D

Was ich mich auch noch Frage:
Er meinte, dass das alles ohne Grafikbeschleunigung auskommt, soweit ich das richtig verstanden habe.
Why?

Weil aktuelle Grafikhardware halt nicht auf Voxel ausgelegt ist, sondern auf das Rastern von Dreiecken. Sicher könnten die das super beschleunigen, wenn die ganze Berechnung mit GPGPU läuft.

Soweit ich es verstanden habe, haben die einfach nur eine total tolle neue Datenstruktur mit einem total tollen neuen Suchalgorithmus erfunden, mit dem sie es schaffen, für jedes Pixel des Ausgabebildes sehr schnell die tatsächlich vorhandenen Atome in ihren Daten zu finden...

So LOD Stufen mit Punktwolken hört sich für mich sehr plausibel an. Also man nehme einen Raum hierarchisierenden Baum und jede Abzweigung ist mit einer LOD Stufe versehen. Bei Punktwolken hat man ja den Vorteil, dass man sie "übereinander" legen kann. Die Wolken werden also nur dichter und es muss nicht jeder Punkt mehrfach gespeichert werden. Es könnte in dem Baum dann auch noch Abzweigungen geben, die sich nur auf die LOD Stufe beziehen. Ist die LOD Stufe sehr hoch, werden alle Abzweigungen besucht, ist sie eher niedrig eben nur die Hälfte oder weniger...
Auf diese Weise kann man dann recht genau festlegen in welchem Abstand zur Kamera sich maximal wie viele Punkte befinden sollen. Solange sich keine Modelle überlagern, kann man die Punkte pro Volumen pro Abstand zur Kamera also ziemlich genau festlegen.

Zudomon hat geschrieben:Laut jemanden, der im Forum sich das angeschaut hat, ist die innere Schleife sehr einfach und darin ist weder Multiplikation noch Division. Er verwendet MASS-CONNECTED-PROCESSING. Die Darstellung wabert ziemlich stark. In den alten Videos ist neben Shadowmapfehlern auch das Frustumculling zu sehen, da Punkte, die das Frustum nach außen hin berühren direkt verschwinden. Das ist in dem neuen Video nicht.

Das Original-Zitat davon findet sich hier und lautet:

I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides!

Wenn keine floating-point Datentypen verwendet werden, erinnert mich das übrigens spontan an Grid/Octree-Traversal, welches man auch mit reiner Integer-Arithmetik implementieren kann.

Abgesehen davon, dass ich die, an Arroganz wohl kaum zu überbietende, Präsentation von Bruce Dell/Euclideon einfach nur unglaublich unpassend finde, vermute ich auf technischer Ebene, dass es sich um eine Art Beamtracing in einen Suchbaum handelt.
Ich sehe jedenfalls nicht, wo der besondere Vorteil dieser Technik gegenüber Polygonen liegen soll. Denn Suchbäume kann ich genauso auf Polygonen bauen und damit z.B. einen Tesselator füttern. Vermutlich ist es sogar einfach ein Octree. Das macht das Instancing, wie es in den Demos zu sehen ist, trivial.
Es ist außerdem interessant, dass in sämtlichen Demos die je veröffentlicht wurden, Objekte immer nur im die y-Achse rotiert sind. Eine Vermutung dazu stammt aus der entsprechenden Diskussion auf gamedev.net: Das Licht kommt nur von oben, daher kann man um y rotieren, ohne dass die Beleuchtung sich ändert, die vermutlich einfach statisch in die Objekte gebacken ist.
Auch ist es verwunderlich, dass die ständig ihre tolle Kompression lobpreisen, aber dann Szenen zeigen, wo es traurig wäre, wenn man überhaupt irgendwas komprimieren müsste. Ebenfalls auf gamedev.net hat jemand mal grob überschlagen, wieviel Speicher das Ding so brauchen würde. Überraschenderweise ist er zu dem Schluss gekommen, dass in die 8GB des Laptop, auf dem die Demo im Video gezeigt wurde, ziemlich genau die ~20 Modelle passen, die in keiner Demo überschritten werden.
Ich finde es auch merkwürdig, dass sie immer noch mit der "Programmers Art" Ausrede kommen, obwohl die Firma, laut dem letzten Video, gleich viele Leute für Contentcreation beschäftigt, wie an der Engine programmieren.
Ich könnte mir außerdem vorstellen, dass UD nur schlecht parallelisierbar ist. Das würde erklären, warum es nach all den Jahren noch nichtmal eine multithreaded Implementierung gibt, obwohl sie ständig was davon faseln, die GPU verwenden zu wollen. Komplexe hierarchische Datenstrukturen mappen meiner Erfahrung nach nur schlecht auf hochgradig parallele Architekturen. Eine GPU-Implementierung könnte sich also als schwierig und äußerst ineffizient erweisen. Wenn es nicht parallelisierbar ist, dann verliert es sowieso mit einem Schlag jegliche praktische Relevanz, die vielleicht noch irgendwo hätte gegeben sein können.

Ich finde den Hype um diese "Technologie" jedenfalls völlig ungereechtfertigt. In den veröffentlichten Videos sehe ein paar nette Demos von einem Hobbyprogrammierer, der mir seine Verschwörungstheorien über die bösen "Polygon Companies" glauben machen will. Mehr nicht. Und auf gar keinen Fall finde ich irgendwo einen Hinweis auf etwas irgendwie bahnbrechendes. Um ehrlich zu sein ist es mir unverständlich, wie es passieren konnte, dass die überhaupt von jemandem ernstgenommen werden.

Achja, ebenfalls von gamedev.net: Wenn diese Technologie wirklich wäre, was Bruce Dell uns weismachen will, nämlich ein Suchalgorithmus mit einer Laufzeitkomplexität von O(1), dann müsste man nicht nur die Grundfesten der Informatik neu errichten und dem Erfinder mindestens zwei Turing-Awards und ein paar Fields-Medaillen verleihen. Google würde jeden Preis der Welt dafür zahlen.

joggel hat geschrieben:

Bisher gibt es keine Animationen.

Doch... die gibt es.
Also, laut Video.
Habe ich schonmal gesehen.

Ich meinte mit den Animationen schon auf die aktuelle Demo bezogen. Damals hatten die ja diese Skelettanimationen, wo ich auch drauf eingehe. Aber ich glaube, die liefen auch alle Synchron. Also noch ein Indiz, dass immer das gleiche aus dem gleichen Blickwinkel dargestellt wird.

eXile hat geschrieben:

Zudomon hat geschrieben: Das Original-Zitat davon findet sich hier und lautet:

I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides!

Wenn keine floating-point Datentypen verwendet werden, erinnert mich das übrigens spontan an Grid/Octree-Traversal, welches man auch mit reiner Integer-Arithmetik implementieren kann.

Sagte mir gestern der eine auch, dass die eventuell in der inner Loop das Grid oder Octtree perfekt Traversieren und direkt sagen können, was hinterher angezeigt wird. Er hatte da dann nach "Optimal Frustum Culling" gesucht und herausgefunden, dass "es sich um ein Problem handelt, an dessen Lösung Intel wohl intensiv forscht um ihren Raytracer sauschnell zu machen."

Also, was mich an der ganze Sache etwas stutzig macht ist, das es so extrem gehypt wird.
Da schlagen meine SpiderSensoren irgendwie aus ^^.
Ich frage mal so:
Würde es jemanden geben der von diesem Hype profitieren würde?
Um mal einen auf Sherlock Holmes zu machen... :D
Am Ende doch nur Euclideon.
Stecken da sogar nicht auch Sponsoren dahinter?

joggel hat geschrieben:Stecken da sogar nicht auch Sponsoren dahinter?

Ja ;)

:D das hört sich irgendwie so extrem übertrieben an...
Aber kann ja sein, dass sie da etwas ganz innovatives gemacht haben.

joggel hat geschrieben:Aber kann ja sein, dass sie da etwas ganz innovatives gemacht haben.

Das glaube ich irgendwie nicht. Wenn es so innovativ wäre, warum ist dann Carmack daran nicht interessiert? Wenn er es wäre, dann hätte er bestimmt schon in der Richtung was gemacht und wir hätten es erfahren, weil er recht freizügig mit dem umgeht, was er macht. Selbst von seinem Megatexturing hat er schon erzählt, bevor es dann in einem Spiel raus kam. Wenn es so innovativ wäre, warum sind dann weder Unreal-Leute noch die von Crysis ( wie in diesem Interview ) nicht begeistert? Ich meine, Bruce ist ja keine direkte Konkurenz zu denen. Er hat doch jetzt gerade mal 2 Millionen gesponsert bekommen. Wenn es so innovativ wäre, dann sollte es doch viel viel viel mehr Wert sein. Und ich glaube, wenn er das hundertfache bekommen würde, dann würde er sich auch sicher kaufen lassen.
Soweit ich weiß hatte er ja damals auch ATI und NVidia seine Technologie präsentiert, die auch wenig begeistert waren. Und er redet immer davon, erst genaueres zu sagen, wenn er die Patente hat. Wiso hat er nach 7 Jahren immer noch kein Patent darauf? Vielleicht weil das, was er macht, schon existiert, vielleicht nur nicht in diesem Zusammenhang.
Naja, sind von mir alles nur Mutmaßungen, wissen tue ich nichts.

Aber den Aspekt, dass sämtliche Rotation nur um die Y-Achse geschehen, dass ist mir noch gar nicht aufgefallen, stimmt aber natürlich.

Übrigens hat er zwar Skelettanimationen drin gehabt, aber soweit ich es beurteilen kann, keine Überblendungen im skinning... also ein Atom ist nur einem Bone zugeordnet.

Hier nochmal ein Bild von dem, meiner Meinung nach ältesten, was er hat, mit der gekrümmten Linse, was eben so sehr nach 2D Tile Engine aussieht.
Und hier, dass was 2,5 Jahre alt war. Warum benutzt man ein Testcase, in dem alles gleich aussieht? Also das was er zum Test benutzt, eine verschachtelte Schleife und dann die Instanzen auf der X und Z Ebene verteilen hat wohl jeder, der erstmal ein wenig mit 3D rumspielt, gemacht. Was hält ihn davon ab, da nicht noch pro Instanz eine Zufallsrotation einzubauen?! Gerade wenn man dadurch bei den Graslandschaften diese grausigen Wiederholungen vermeiden kann...
Mich würde auch mal interessieren, ob sein "Suchalgo" wirklich perfektes Occlusion bietet, oder ob es doch kleine Überlagerungen gibt... zumal jedes Atom ja ein paar Pixel abdeckt.

Hm... interessantes Video.
Ich glaube: Stimmt nicht.

Zwar lehne ich mich damit etwas weit aus dem Fenster, aber es gibt da ein paar Anhaltspunkte.
Was mich (neben anderen Sachen) stutzig macht:

1.
Der Typ, der das präsentiert, sieht für mich nicht wie ein Programmierer aus. Oder anders ausgedrückt: Wenn ich euch bitte, mir eure tolle super-3d-engine zu zeigen, wer von euch würde das mit einem XBox-Pad tun?

2.
Die Technik funktioniert angeblich auf alten Karten (vor 2000). Warum treten dann Artefakte bei der V-Sync auf? Das passiert nur, wenn die Graka bzw. die FPS an ihren Grenzen sind.

3.
Die Technik ist angeblich 5 Jahre alt. In der Zwischenzeit sollte man doch einen Sponsor o.ä. gefunden haben, der ne super Demo zaubern müsste.
Warum gibt es auf der Demo-Insel nur 1 Gras und 1 Palme 1 Kaktus und 1 Tile? Wozu dann eine ganze Insel, auf der alles 100 Mal ist?

Es gibt noch mehr, aber das erspare ich mir erstmal :-)
Wir werden sehen, irgendwann müssen die ja damit rausrücken und was aufn Markt bringen.

Hallo zusammen,

Ich frage mich auch schon seid geraumer Zeit, wie diese Engine wohl funktioniert. Es sei nun dahingestellt, dass hier natürlich stark gehyped wird, jedoch aus meinen eigenen Erfahrungen bzgl. des Voxel-Renderings (Und Point-Cloud-Rendering ist da SEHR ähnlich) weiss ich, wie schwer es ist eine ECHTE 3D Voxel-Engine zu programmieren. Und mit echt 3D meine ich eine Voxel-Engine in der man ohne perspektivische Verzerrung (wie man sie aus alten Spielen wie Comanche, oder Duke3D kennt) nach oben und unten schauen kann. Die einzige mir bekannte echte 3D Voxel Engine ist Voxlap von Ken Silverman und seine "Skillz" sind definitiv nicht die eines Anfängers, wenn man sich den source code anschaut. Die Szenen aus Bruce Dells neuren Videos zeigen, dass seine Engine dazu ebenfalls problemlos in der Lage ist. In seinen älteren Videos sind mir jedoch teilweise einige kleine perspektivische Verzerrungen aufgefallen, doch der wohl stärkste Beweis, dass seine Technologie auf 2.5D Raycasting ala Wolfenstein/Comanche basiert liefert das zuletzt gepostete Bild von Zudomon aus seiner alten Version (vor 7 Jahren). Wenn man sich das Bild anschaut, wird einem der Fischaugen-Effekt auffallen. Wenn man sich das Bild aber etwas genauer anschaut, wird man feststellen, dass dies nur für die horizontalen Kanten gilt und nicht für die vertikalen Kanten. Ein typischer Effekt beim 2.5D Raycasting wenn man die Strahllänge nicht trig. normiert. Um das Bild nun zu vervollständigen möchte ich an dieser Stelle einen Kommentar aus einem anderen Forum einfügen, über das ich gestern schon mit Zudomon diskutiert habe:

I'd like to mention Unlimited Detail, a technology developed by Bruce Dell, which does in fact do exactly what he claims it does... Render incredibly detailed 3D scenes at interactive frame rates... without 3D hardware acceleration. It accomplishes this using a novel traversal of a octree style data structure. The effect is perfect occlusion without retracing tree nodes. The result is tremendous efficiency.

I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides!

Ich denke dieses Kommentar dürfte das Bild etwas vervollständigen. Er benutzt eine Octree-Ähnliche Struktur, was mich aufgrund der Tatsache, dass er wohl 2D (2.5D) Raycasting verwendet, annehmen lässt, er benutzt einen Quad-Tree (2D-Version des Octrees) . Der Vorteil ist hier das er, wie bereits Zudomon erwähnt hat, auch Instancing frei haus bekommt. Dadurch, dass er 2D-Raycasting benutzt, bearbeitet er immer 1 Vertikale-Scanline auf einmal und kann hier den Overdraw nach alter Comanche-Manier gegen 0 reduzieren (perfect occlusion culling). Wer wissen will wie so etwas genauer funktioniert, der brauch nur hier zu schauen:

http://www.flipcode.com/archives/Realti ... ture.shtml

Wenn man diese Technik dahingehend erweitert, dass man mehrere Ebene (Boden unter Decke unter Boden unter Decke) raycasted und die Map in Quadrate aufteilt (oder per Quadtree), so dass man die Möglichkeit bekommt Instanzen zu raycasten, dann dürfte das Ergebnis in etwa genau der Grafik ensprechen, die Ulimited Detail vor 7 Jahren hatte. Er scheint seid dem allerdings wie bereits erwähnt, perspektivische Korrekturen und Ausnahme-Fälle implementiert zu haben, die es ihm ermöglichen ohne Verzerrung nach oben oder unten zu schauen. Alles in allem macht dies seine Engine trotz Instancing und LIMITED-Detail doch zu einer Leistung, denn solche Engines zu programmieren ist schon eine Herausforderung. Mir fällt neben Voxlap z.B. keine weitere echte 3D-Voxel-Engine ein, welche nur die CPU ausnutzt. Und Voxlap hat kein Instancing und dadurch Speicherprobleme bei grösseren Maps.

BTW.: Das dürfte auch der Grund sein, warum es nicht nur Y-Rotationen gibt, sondern auch, warum es nur 90 Grad-Y-Rotationen gibt. ;)

Wenn er einen Quadtree mit 2.5D Raycasting verwenden würde, müsste er diesen doch praktisch ständig neu aufbauen. Denn der Quadtree entspricht ja dem Schnitt durch die Szene in der xz-Ebene der Kamera. Sobald man die Kamera wirklich frei bewegen will, was er definitiv kann, würde das doch unweigerlich auseinanderbrechen!?
Ich glaub, wie gesagt, eher, dass es eine Art Beamtracing in einen Octree ist. D.h., er baut durch jeden Pixel ein kleines Frustrum und schickt dieses in seine Datenstruktur, um den nähesten Octree-Node zu finden, der reinpasst. Damit bekommt er automatisches LOD etc. So würd ichs halt machen^^
Das bedeutet aber auch, dass sein Verfahren im Prinzip die selben Probleme hat wie Raytracing. Und Raytracing ist jetzt auch alles andere als der heilige Gral der Computergrafik. Abgesehen davon, dass es Beamtracing auch schon seit weit über 20 Jahren gibt, ist seine Technik dann mehr oder weniger einfach nur ein Sparse Voxel Octree. Und da gibt es auch genügend andere, die in der Richtung forschen, aber nicht die Dreistigkeit besitzen, auch bei direkter Nachfrage noch darauf zu bestehen, dass es sich um Unlimited Detail handelt und dass alles andere sowieso schlecht ist. John Carmack selbst hat sich sehr intensiv damit beschäftigt, ist, afaik, aber mittlerweile bei weitem nichtmehr so begeistert davon wie noch vor 2 Jahren.

Btw: Ich würde das Instancing weniger als Feature, denn als Symptom eines wirklich grundlegenden Problems der Technik sehen ;)

Also erst einmal sendet er beim 2.5D Raycasting ja nicht 1nen Strahl pro Pixel, sondern 1nen Strahl pro Bildspalte aus...bei 1024x768 sind das nur 1024 Strahlen pro Bild. Zweitens benutzt er dafür den 2D-DDA-Algorithmus, der ohne Multiplikation und Division auskommt. Um das Instanzing zu erreichen benutzt er entweder einen Quad-Tree, kann genausogut aber auch ein 2D-Grid benutzen (in seinen 7 Jahre alten Sachen sieht es wegen der regelmäßigen Blockstruktur ganz danach aus). Er scannt zwar mit nem Strahl jeden Voxel ab, benutzt aber das Grid um die jeweilige Zelle zu bestimmen. Diese verweisst auf ein Element von einer im Hauptspeicher liegenden Liste von Map-Elementen (Objekten). Die Zellen Koordinate kann bei 2^n-Grössen leicht über Bitshifting errechnet werden. Der Offset in der jeweiligen Zelle und damit im Map-Objekt über eine Subtraktion. Gerendert wird dann mit jedem Voxel ein Y-Slice bzw. mehrere Y-Slices von Objekten die übereinander liegen. Durch benutzung des Z-Buffers oder eines Scanline-Algos kann hier in jeder Spalte dann auch perfektes occlusion culling erreicht werden, da der Strahl ja von vorne nach hinten traversed. Was deinen Einwand bzgl. der eingeschränkten Sichtweise betrifft bei einer 2.5D Engine, so habe ich ja bereits erwähnt, daß hier algorithmen existieren die den Fehler im Nachinein wieder ausgleichen bzw. für den Fall des direkten nach oben oder unten schauens die Strahlen im 360 Grad-Winkel aussenden. Demo-Crews haben solche 2.5D-Voxel-Engines, die perfekte 3D-Voxel (inkl. Persp. korrektur) abbilden bereits auf einem Amiga 1200 realisiert. http://www.youtube.com/watch?v=H4c-cvos ... page#t=78s

BTW.: schon mal irgendwo in seinen Videos gesehen, dass er die Kamera um die Z-Achse dreht und dabei nicht nach unten oder oben schaut? So ganz frei kann er sich also anscheinend doch nicht bewegen.

Es gibt jetzt einen Nachbau von Unlimited Detail; wie wirklichkeitsgetreu der ist, steht natürlich in den Sternen. Allerdings ist wohl die Implementierung nicht so weit vom Original entfernt, denn

DrBalthar auf http://www.geeks3d.com/20120905/opencl-voxel-splatting-demo/ hat geschrieben:Yep looks nearly as crappy as the unlimited detail guys stuff

;)

Ich glaube, das größte Problem von UD ist, dass man die innere Schleife auf keinen Fall mehr ausbauen darf. Sämtliche Beleuchtung, prozedurale Texturen etc. kann es nur vorgespeichert geben, was dann traversiert wird.

Es gibt Neuigkeiten – allerdings nicht von den Unlimited-Detail-Heinis. D.h. ihr könnt aufatmen; ich werde heute bei euch keinen Hautausschlag verursachen ;)

Der Atomontage Renderer hat ein paar neue Bildchen generiert. Ich frage mich allerdings, wann die endlich eine trilineare Farbinterpolation einbauen.

Die Bilder sehen jedesmal richtig gut aus, aber mir fehlt immer eine Angabe, wieviel Rechenzeit dafür jetzt draufgegangen ist. Dass das keine Echtzeit ist, steht ja irgendwo auf der Webseite.

Schrompf hat geschrieben:Die Bilder sehen jedesmal richtig gut aus, aber mir fehlt immer eine Angabe, wieviel Rechenzeit dafür jetzt draufgegangen ist. Dass das keine Echtzeit ist, steht ja irgendwo auf der Webseite.

Laut den Youtube-Videos war mit einem Screen-Recorder keine Echtzeit-Aufnahme möglich, aber es wurde mit einer Videokamera vom Bildschirm abgefilmt.
Was mir aufgefallen ist, ist dass die Transformationen an der Landschaft nur im Sekundentakt auch in der Grafik aktualisiert wurden.

Die Engine kann *auch* Echtzeit, das ist klar. Aber speziell bei diesen neuen Bildern und auch bei einigen anderen Bildern glaube ich, dass das eher Offline-Rendering war.

Kann es sein, dass das Unlimited Detail immer schlechter wird?
Mal abgesehen von dem ganzen Statischen, keine Effekte, keine Animationen, würde ich sagen, dass es gegen aktuelle Spiele überhaupt nicht mehr mithalten kann.

Zur Zeit beeindruckt mich the vanishing of ethan carter sehr und ich hab einfach mal ein Bild aus der Nature Szene genommen, die in dem Video von Euclideon vorkommt:
https://www.youtube.com/watch?v=DbMpqqCCrFQ

Darunter ist ein Bild aus dem Spiel, allerdings nochmal Gamma angepasst, weil es sonst zu dunkel war. Ich würde aber sagen, unten sieht es bei weitem beeindruckender aus! :D
Ich weiß ja nicht, wem die da noch einen erzählen wollen?!

Danke für den Hinweis zu The Vanishing of Ethan Carter. Ich hoffe du weißt, dass das für mich wie Porno ist ;)

Krishty hat geschrieben:Danke für den Hinweis zu The Vanishing of Ethan Carter. Ich hoffe du weißt, dass das für mich wie Porno ist ;)

Ja! Spiel das mal! Das ist auch Porno von der Grafik her... selbst dem Gronkh geht da alle paar Meter einer ab!
Hab da stundenlang in den Wäldern verbracht um mir alles genau anzusehen. Das Spiel selbst ist allerdings recht kurz und die Fläche ist auch relativ klein für ein ganzes Spiel. Die haben ja zwei Jahre dafür gebraucht und tausende Fotos gemacht.
Wenn man weiß wo man lang muss und was man auslassen kann ist es tatsächlich ein recht kurzes Spiel. Hab es in 28 min geschafft (aber davor schon 3 mal durchgespielt).

Unlimited Detail Demo ist da!

http://udserver.euclideon.com/demo/html5_viewer.html

Und entweder ich kann diese Technologie nicht annähernd einschätzen, oder das Ding ist [...]. Zumindest hält es nicht was es verspricht und ähnelt für mich doch stark nach einem normalen Voxelrenderer. :o

Ich glaube nicht, dass diese Web-Demo der Algorithmus ist der in den Videos immer gezeigt wird. Das hätte ja irgendjemand ruck zuck reverse engineered. Deswegen haben sie halt irgend einen Web-Viewer gebaut.

Keine Ahnung, wie das implementiert haben, aber von der Qualität her ist es so dermaßen enttäuschend, dass ich bezweifle, dass irgendwer danach krähen wird. Die Kompressionstechnologie ist immernoch bemerkenswert, der Software-Renderer ne nette Sache, aber am Ende ist es halt nur ein System für Punktwolken. Und das ist mit der Online-Demo so offensichtlich geworden, dass spätestens jetzt alle Spiele dieser Welt abgesprungen sein dürften. Für die Landvermesser dagegen ist das ne geile Sache, glaube ich.

Ich weiß nicht, ob es Sinn machen würde, wenn die da auf der UD Seite nur einen Viewer für UD-Daten machen. Also ich glaube schon, dass es sich hier um die UD Technik handelt. Immerhin ist das ja, soweit ich weiß Software-Rendering und das mit JavaScript. Eigentlich schon krass (nur halt nicht unendliches Detail krass).
Jedenfalls lässt sich nun schon einiges über die Technik sagen. Es handelt sich, da die "Voxel" axis Aligned jeweils halbiert angeordnet sind also definitiv um einen SVO. Zumal nicht jedes Leaf in vollstes Detail runtergeht. Die Voxel werden als Volume gerendert, wenn man also mit der NearPlane da rein ragt, dann sieht man dass die Dinger ausgefüllt sind. Außerdem gibt es halt für jeden Parent-Leaf einen Mittelwert bzw. wird dann der Wert genommen, der in dem Leaf steckt. Das sieht man an den ersten beiden Maps sehr gut, wo dann die Voxel kleiner werden, wenn man näher ran kommt. Bei ersteren ist die Near Plane auch näher, also kann man näher ran und wenn man sich in kleinster Geschwindigkeit dann so einem "Voxel" nährt erscheinen seltsame Artefakte (die auch auf die Technik schließen lässt). Also Raycasting ist das definitiv nicht. :D

Jedenfalls, scheint Bruce ja seine Nische gefunden zu haben. War vielleicht nicht schlau, vorher so rumzuprotzen, dass es eine revolutionäre Spielerendertechnik geben würde. Ich muss ihm dennnoch danken, denn wäre UD nicht gewesen, hätte ich nicht die Motivation gehabt, bei mir so aufs Detail zu gehen, um UD zu schlagen... :D