Unlimited Detail Technology

[JoeScylla]

Trotzdem haben die auch noch keinen Transparenten Punkt gezeigt mit unterschiedlichen Transparenzeinstellungen bzw. Belichtung mit unterschiedlichen Farben. Es gibt ja auch noch keine Schatten o.ä. Es gibt auch noch keine terrainspezifischen Höhenunterschiede, also Hügel die dann bewachsen/mit Steinen bedeckt sein sollten. Hier befindet sich ja der Knackpunkt des ganzen, im Raum rotierte Objekte und der damit zusammenhängenden Effizienzunterschiede beim Darstellen.

Alles was du angesprochen hast ist machbar mit Point Cloud Engines und wurde auch fast alles schon gemacht, die Frage ist nur mit welcher Performance. Das muss sich noch zeigen. Die Aussage der Firma ist ja auch nur, dass diese einen hocheffizienten Algorithmus entwickelt haben welcher der wichtigste in einer Point Cloud Engine ist: Das Parsen des Octrees.

Dazu ist noch zu bemerken, dass aktuelle Polygonbasierende Engines nur die aktuelle Darstellungsqualität haben können weil es hochoptimierte Hardware dafür gibt.

öhm .... höööööh? ... du weißt schon wieviel du in einen "bit" Speichern kannst ... bist du dir da sicher?

Ja bzw. Korrektur: die Atomontage Engine verbraucht weniger als 1bit per Point.

[Levi]

öhm .... höööööh? ... du weißt schon wieviel du in einen "bit" Speichern kannst ... bist du dir da sicher?

Ja bzw. Korrektur: die Atomontage Engine verbraucht weniger als 1bit per Point.

jetzt wirds lächerlich XD ...

[JesusOfCool]

etwas weniger als 1bit. großartig.

[|Chris|]

JoeScylla hat Folgendes geschrieben:

Levi hat Folgendes geschrieben:

öhm .... höööööh? ... du weißt schon wieviel du in einen "bit" Speichern kannst ... bist du dir da sicher?

Ja bzw. Korrektur: die Atomontage Engine verbraucht weniger als 1bit per Point.

jetzt wirds lächerlich XD ...

etwas weniger als 1bit. großartig.

Er liegt völlig richtig. Erstes Semester im Grundstudium. Lineare Algebra I.
Jedes Modelformat verbraucht 'weniger als ein Bit per Punkt'. Eventuell irre ich mich im Bezug auf Anwendungen in Medizin und CAD Programmen aber es würde mich wundern.

Was das eigentliche Thema angeht, wenn ihr euch etwas ernsthafter mit Unlimited Deail auseinandersetzen möchtet empfehle ich euch diesen Thread im Polycount Forum: http://www.polycount.com/forum/showthre ... 99&page=23

Das muss sich noch zeigen. Die Aussage der Firma ist ja auch nur, dass diese einen hocheffizienten Algorithmus entwickelt haben welcher der wichtigste in einer Point Cloud Engine ist: Das Parsen des Octrees.

So Effizient er auch sein mag und unter der Annahme das Dinge wie disortion und color blending entfallen (da sich das aus der Position im Octree ergibt) hättest du bei relativ kleinen Arealen mit einer Kompression die gegen 90% geht (was , denke ich, utopisch ist) immernoch Millionen (von ursprünglich Milliarden) Voxel/Atome/<insert name here>. Zum Beleuchtungsmodell kann ich jetzt nichts sagen da ich keine Ahnung habe wie man hier die Normalen bekommt (Ausrichtung zum übergeordneten Punkt im Octree? Hat ein Point überhaupt eine Ausrichtung? Oberfläche finden? Shrug. ) EDIT: Anscheinend gibt es eine Art 'Mastertexture' in der die normalen für einzelne pattern eingearbeitet sind, aber möchte ich nun anfangen zu animieren, muss ich teile des Octrees vor dem rendern komplett umstellen. Ich kann mir nicht vorstellen das die das performant gelöst haben wollen. Da müsste schon ein ganz anderer Ansatz verfolgt werden und das traue ich den Leuten dort ehrlich gesagt ( vom Auftreten und der Fachkompetenz die ich bisher erlebt habe ) nicht zu.

Und wie du bereits geschrieben hast, ohne die geeignete Hardwareunterstützung seitens Nvidia und AMD (wem gehört eigentlich Matrox?) ist das kaum umsetzbar.

[EnTroXxX]

Es ist wie immer...

was wir nicht verstehen, kann auch nicht sein...


Das der gute Mann nicht so viel verrät, ist ja wohl verständlich. Wenn er verraten würde wie alles funktioniert, hätte es ganz schnell jemand anderes mir mehr Ressourcen entwickelt.

Mal abwarten wie es weitergeht, oder ob ihnen vorher das Geld ausgeht.

[3tagewach]

Wenn ich 30 Millionen im Lotto gewinnen würde, dann würde ich dennen 10 Millionen geben, damit sie sich mal mehr Mitarbeiter anschaffen und schneller entwickeln sollen (und so auch ein Teil der Rechte an der Engine kaufen).

[Nerix]

Oha, ob das eine gute Investition wäre? Risikoreich wäre sie allemal

[JesusOfCool]

Er liegt völlig richtig. Erstes Semester im Grundstudium. Lineare Algebra I.
Jedes Modelformat verbraucht 'weniger als ein Bit per Punkt'. Eventuell irre ich mich im Bezug auf Anwendungen in Medizin und CAD Programmen aber es würde mich wundern.

ok, ich hab zwar informatik studiert, aber daran kann ich mich nicht erinnern. vielleicht liegt es ja daran, dass hier der begriff "bit" anders definiert ist. oder ist das ganze auf einen durchschnitt von komprimierten daten bezogen?

[Levi]

Er liegt völlig richtig. Erstes Semester im Grundstudium. Lineare Algebra I.
Jedes Modelformat verbraucht 'weniger als ein Bit per Punkt'. Eventuell irre ich mich im Bezug auf Anwendungen in Medizin und CAD Programmen aber es würde mich wundern.

ok, ich hab zwar informatik studiert, aber daran kann ich mich nicht erinnern. vielleicht liegt es ja daran, dass hier der begriff "bit" anders definiert ist. oder ist das ganze auf einen durchschnitt von komprimierten daten bezogen?

was anderes kann ich mir nicht vorstellen ... trotzdem ... egal wie man es dreht und wendet: ein Atom lässt sich nicht mit "etwas weniger als ein Bit" darstellen ... eine Menge von Punkten lassen sich logischerweise im Durchschnitt mit weniger als ein Bit darstellen ... für ne Linie mit unendlich vielen Punkten braucht man ja nur zwei Koordinaten ... Für ne Kugel nur nen Mittelpunkt und nen Radius ... etc .. ... schön und gut ... aber ein einzelner Punkt ... geschweige denn weitere Informationen zu diesen Punkt lassen sich egal wie man es dreht und wendet nicht mit "etwas weniger als ein Bit" darstellen ...

und genau darum ging es ...

wenn man jetzt anfängt, die Punkte doch wieder so zu vereinfachen, kann man auch gleich wieder zur Rasterizern mit Polygonen übergehen ... denn nix anderes machen diese ja

[andi2k78]

Interessant ist wie er auf die Fragen antwortet. Ein nein kann auf viele arten ausgesprochen werden.
Der letze Satz ist für mich am interessantesten.
Er darf nichts sagen.
Da er Chef von der Firma ist dürfte er so etwas nicht sagen.
Wenn es heißt er "darf" nicht steckt wahrscheinlich eine NDO dahinter die er mit jemandem von ausserhalb Eucledeons hat.
Ansonsten erwarte ich die Technologie in frühestens 5 Jahren. (einfach mal so in den Raum schmeiss)

[JoeScylla]

was anderes kann ich mir nicht vorstellen ... trotzdem ... egal wie man es dreht und wendet: ein Atom lässt sich nicht mit "etwas weniger als ein Bit" darstellen ... eine Menge von Punkten lassen sich logischerweise im Durchschnitt mit weniger als ein Bit darstellen ...

Um es vereinfacht zu sagen: Wenn z.B. ein Element einer Datenstruktur N bit an Informationen in sich trägt, kann die gesamte Datenstruktur auf weniger als N bit pro Element kommen. Ein einfaches Beispiel wäre z.B. ein JPG-Bild mit dem Pixel als Element. Ein Pixel trägt - je nach Farbtiefe - N bit Informationen in sich und die Datenstruktur verbraucht aber nur N/x bit pro Pixel.

Der Vorteil eines Sparse Voxel Octree besteht darin, dass der Octree von vorneherein sehr speichereffizient (im RAM) ist während z.B. ein JPG zur Verarbeitung zumindests teilweise decodiert werden muss und daher nicht speichereffizient ist.

So Effizient er auch sein mag und unter der Annahme das Dinge wie disortion und color blending entfallen (da sich das aus der Position im Octree ergibt) hättest du bei relativ kleinen Arealen mit einer Kompression die gegen 90% geht (was , denke ich, utopisch ist) immernoch Millionen (von ursprünglich Milliarden) Voxel/Atome/<insert name here>.

..., muss ich teile des Octrees vor dem rendern komplett umstellen. Ich kann mir nicht vorstellen das die das performant gelöst haben wollen.

Ja der Octtree muss vor dem Rendern teilweise umgestellt werden und genau die liegt die grundlegende Frage: Ist der Algorithmus in der Lage diese Vorgänge so zu beschleunigen das Point Cloud Engines - mit entsprechender Hardwareunterstützung - ermöglicht werden.

In Anbetracht der Tatsache welche Leistungsfähigkeit heutige Grafikkarten haben um das sehr komplizierte und klobige Model von Polygon und Texturen (und sonstiges) zu verarbeiten finde ich die Verarbeitung von 1 Milliarde Points in einem Octree als geringeres Übel. Zudem da ein Sparse Voxel Octree eine Struktur ist welche viel einfacher zu verarbeiten ist. Die Architektur von Hardware für Point Cloud Engines wird wahrscheinlich auch wesentlich einfacher und effizienter sind können (Stichwort RISC).

[Levi]

was anderes kann ich mir nicht vorstellen ... trotzdem ... egal wie man es dreht und wendet: ein Atom lässt sich nicht mit "etwas weniger als ein Bit" darstellen ... eine Menge von Punkten lassen sich logischerweise im Durchschnitt mit weniger als ein Bit darstellen ...

Um es vereinfacht zu sagen: Wenn z.B. ein Element einer Datenstruktur N bit an Informationen in sich trägt, kann die gesamte Datenstruktur auf weniger als N bit pro Element kommen. Ein einfaches Beispiel wäre z.B. ein JPG-Bild mit dem Pixel als Element. Ein Pixel trägt - je nach Farbtiefe - N bit Informationen in sich und die Datenstruktur verbraucht aber nur N/x bit pro Pixel.

wobei meine Beispiele etwas näher am eigentlichen sind ... ändert trotzdem nichts dran ... ein einzelnen Punkt, kann man nicht mit "etwas weniger als ein Bit" darstellen ... und genau das war die aussage ...

die Idee hinter diesen "Sparse Voxel Octree" ist ja im grunde "Gruppierung" von Elementen ... klar ... wenn man zusammenfasst und reproduziert, kann man im durchschnitt weniger als ein bit verbrauchen ... das Streitet glaub ich niemand ab ... aber die Aussage, man könnte ein "Atom" (sie wollen es ja so nennen) in "etwas weniger als ein Bit" (ich liebe diese Formulierung XD) ... darstellen ist so dermaßen daneben ... das sie zurecht als fehlerhaft oder gar lächerlich beschrieben werden darf meiner Meinung nach.

wirklich nichts lässt sich in "etwas weniger als ein Bit" speichern, weil es schlicht und ergreifend in unserer heutigen Digitalen Technik nichts gibt, was "etwas weniger als ein Bit" realisiert ... ein Bit ist 0 oder 1 ... an oder aus .... steigend oder fallend ... wahr oder falsch ... es geht einfach nicht, "etwas weniger als ein Bit" zu verbrauchen ... ein Bit ist das kleinste ..
Für einen einzelnen Punkt in einen dreidimensionalen Koordinatensystem braucht es eben mindestens drei Werte ... im simpelsten vorstellbaren dreidimensionalen Koordinatensystem (tiefe breite und höhe von jeweils einer Einheit) verbraucht ein Punkt somit mindestens 3 Bit ... von Farb oder Materialinformationen mal ganz zu schweigen ...

[JesusOfCool]

hätte man aber auch gleich so schreiben können ^^

der satz liest sich trotzdem immer noch sehr witzig

[JoeScylla]

...snippped...

wirklich nichts lässt sich in "etwas weniger als ein Bit" speichern, weil es schlicht und ergreifend in unserer heutigen Digitalen Technik nichts gibt, was "etwas weniger als ein Bit" realisiert ... ein Bit ist 0 oder 1 ... an
oder aus .... steigend oder fallend ... wahr oder falsch ... es geht einfach nicht, "etwas weniger als ein Bit" zu verbrauchen ... ein Bit ist das kleinste ..

Ich bewundere ja deine Kenntnisse des Binärsystem aber ich habe nie behauptet, dass ein Point weniger als 1 Bit an Informationen in sich trägt. Meine Aussage betrifft den Speicherverbrauch. Alles andere haben Du und andere "konstruiert".

Aktuelle Point Cloud Engines haben einen Speicherverbrauch von 1Bit pro Point (nix Pixel); siehe z.B. Atomontage Engine.

Als Gleichnis:

Aktuelle Kompressionsformate für Bilder haben einen Speicherverbrauch von weniger als N Bit pro Pixel; siehe z.B. JPG.

Ich finde das ziemlich unmissverständlich.

...snipped...
Für einen einzelnen Punkt in einen dreidimensionalen Koordinatensystem braucht es eben mindestens drei Werte ... im simpelsten vorstellbaren dreidimensionalen Koordinatensystem (tiefe breite und höhe von jeweils einer Einheit) verbraucht ein Punkt somit mindestens 3 Bit ... von Farb oder Materialinformationen mal ganz zu schweigen ...

PS. Du hast keine Ahnung wie ein Octree funktioniert. Hinweis: Die Informationen eines Element in einem Octree enthalten keine Koordinaten.

[Levi]

Aktuelle Point Cloud Engines haben einen Speicherverbrauch von 1Bit pro Point (nix Pixel); siehe z.B. Atomontage Engine.

Und wie kamst du beim besten Willen dann auf diese Behauptung?
Meine Grundkenntnisse in Deutsch sagen mir, dass du behauptest hast, dass ein Point/Atom/Punkt ... ein Bit verbraucht.
( ... später dann korigiert zu "weniger als ein Bit")


Wenn man sich darüber bewußt ist, wie es funktioniert, dann sagt man doch nicht "verbraucht ein Bit" ... dass die Daten jetzt in "Octtrees" gespeichert werden, ist ja schön und gut ... aber das ändert nichts an den Verbrauch eines einzelnen Punktes ... geschweige denn der Behauptung, er verbrauche "weniger als ein Bit" ... da spielt dann wieder das von uns oben bereits festgestellte

du weißt mehr als der durchschnitt, davon bin ich überzeugt, wahrscheinlich auch bei diesen Thema mehr als ich ... aber irgendwie wirfst du einfach mit Begriffen und Werbephrasen um dich, ohne es zu hinterfragen, beziehungsweise darauf zu achten, was du genau sagst ... und das stößt doch etwas sauer auf ... denn egal wie du es drehst und wendest ... ein ganz individueller Punkt der nicht teil eines festgelegten Gebildes ist wird nie weniger als ein Bit Speicher verbrauchen ...