Unlimitied Detail: "Alles Betrug"

[Typhox]

Interessant, wie hier zwar keiner eine Ahnung von der Materie hat, aber alle meinen, es besser zu wissen.
Offensichtlich sind euch die Hoffnungen in diese Technologie sehr viel Wert.
Eines solltet ihr jedoch beachten: Diese Technik wird niemals in Spielen zur Verwendung kommen. Denn sie wird nicht gebraucht.
Schon heute haben wir viel mehr Probleme mit Texturierung und Physik als mit dem Anzeigen von ein paar Millionen Polygonen pro 60stel Sekunde.
Und die Technik wird sich sicher noch weiterentwickeln.
Außerdem sei noch einmal erwähnt, dass Polygone schon sehr nah am Optimum sind. Mit irgendwelchen Polynomen, Fraktalen oder Voxeln lässt sich die Grafik unmerklich verbessern - dafür muss man aber die viel wichtigeren Features alle aufgeben.
Rendern von vielen Polygonen ist längst kein Problem mehr (für Spiele).

Und was auch immer dieser Notch gesagt hat. Er hat mit Sicherheit immernoch mehr Ahnung von der Materie, als die meisten Forenuser hier.
Damit steht dann auch Wort gegen Wort und es macht dann mehr Sinn, einer unseriösen Firma, welche das Blaue vom Himmel verspricht, lieber skeptisch gegenüber zu treten.

[OPH]

Also das die Menge der Polygone in Spielen optimal ist, ist mir zienlich neu. Ich sehe in Spielen immernoch viele Stellen wo extrem an Polygonen gepspart wird, da geht noch viel mehr. Und das der Boden nicht glattpoliert ist, sondern echt "rau" ist und aus Partikeln besteht, wäre sowas wie ein quantensprung.

[N16]

Also das die Menge der Polygone in Spielen optimal ist, ist mir zienlich neu. Ich sehe in Spielen immernoch viele Stellen wo extrem an Polygonen gepspart wird, da geht noch viel mehr.

Zeigst du mir, wie das geht?

Ich habe schonmal ein 3D-Programm geschrieben, welches eine Landschaft generiert.
Es nimmt eine Heightmap und erstellt eine Landschaft mit sovielen Polygonen, wie es Pixel im Bild gibt (und verschiebt jedes Polygon entsprechend des Farbwert des dazugehörigen Pixels).

Aber wenn mein Bild zu gross ist, krieg ich folgenden Fehler: "XNA Framework HiDef profile supports a maximum of 1048575 primitives per draw call."
Das sind also 1'048'575 Polygone pro Bild.

Also sag schon, wie krieg ich mehr Polygone hin?

Und das der Boden nicht glattpoliert ist, sondern echt "rau" ist und aus Partikeln besteht, wäre sowas wie ein quantensprung.

Gibt's schon, mit Tesselation + Displacement Mapping.
Das schöne an dieser Technik ist: Der Boden besteht aus 2 Polygone, welche in kleinere Polygone zerteilt wird, die danach von der Displacement Map nach oben, bzw. unten verschoben werden (und somit wird der Boden rau)
Je näher an die Kamera, desto feiner die Zerteilung, was zur Folge hat, das nur diejenigen Details dargestellt werden, die auch sichtbar sind.

[Scorcher24_]

Also das die Menge der Polygone in Spielen optimal ist, ist mir zienlich neu. Ich sehe in Spielen immernoch viele Stellen wo extrem an Polygonen gepspart wird, da geht noch viel mehr.

Zeigst du mir, wie das geht?

Ich habe schonmal ein 3D-Programm geschrieben, welches eine Landschaft generiert.
Es nimmt eine Heightmap und erstellt eine Landschaft mit sovielen Polygonen, wie es Pixel im Bild gibt (und verschiebt jedes Polygon entsprechend des Farbwert des dazugehörigen Pixels).

Aber wenn mein Bild zu gross ist, krieg ich folgenden Fehler: "XNA Framework HiDef profile supports a maximum of 1048575 primitives per draw call."
Das sind also 1'048'575 Polygone pro Bild.

Also sag schon, wie krieg ich mehr Polygone hin?

Indem du nicht alles zeichnest, sondern nur das was momentan auch sichtbar ist.
Stichwort Frustum Culling.
Danach kannst das ganze in mehrere Draw Calls aufteilen. Du brauchst ja nicht alles auf einmal batchen.

[OPH]

Zeigst du mir, wie das geht?

Ich meinte weder das ich das kann, noch das es heute schon möglich ist. Aber es wird auf jeden sicherlich noch Techniken geben, mit denen man irgendwann keine großen flachen Polygonflächen und keine ecken mehr an runden Objekten mehr sieht.
Das video behauptet halt, sie haben eine möglichkeit gefunden das zu schaffen, und was sie zeigen sieht halt toll aus. Ob es ein fake ist oder nicht kann ich nicht beurteilen.

[johndoe1082890]

Hört sich ziemlich unglaubwürdig an was die Leute da kritisieren. Warum sollten die einen so verarschen? Schließlich wollen die damit doch offensichtlich Geld verdienen indem sie es an Entwickler verkaufen. Sie meinten ja selbst, dass es noch weit weg von "fertig" ist.
.

Also erstens sollte man sich in dem Gebiet auskennen um mitreden zu dürfen aber viel wichtiger, wieso sollte wohl eine Firma bei einem Produkt die Nachteile verschweigen. Das ist doch nicht Praxis? Oder doch? Scheiße ja es ist Praxis das zu Unterschlagen. Egal in welchem Bereich der Industrie ihr schaut, es passiert immer und immer wieder.

Letztes großes Beispiel...wie wäre es mit den Banken. Sollte ja doch wohl einigermaßen jedem bekannt sein oder nicht? Muss ich mehr aufzählen? Falls da einer nun ja sagt: "Les endlich mal Zeitung, und damit ist die mit den 4 Buchstaben nicht gemeint!"

@Thypox. Solange wir Konsolen auf den Markt haben wird das auch so stimmen

[unknown_18]

Ihr könnt das Polygon System noch so schön reden, Tatsache ist, dass es bis heute immer noch die Möglichkeiten einschränkt, denn es fängt schon mit der Sichtweite an, nutzt man viele Polygone, wird oft die Sichtweite beschnitten und von den schönen Popins von Objekten in einer gewissen Entfernung bzw. sichtbare Änderung von Low zu Highpoly Modelle brauchen wir gar nicht erst reden, denn das sind nichts anderes als Notlösungen um mehr Polygone in der näheren Umgebung verwenden zu können. Wie man davon sprechen kann, dass das Polygon System ja heute absolut gut genug ist, ist mir schleierhaft. Das System ist noch weit davon entfernt all die Nachteile mal hinter sich gebracht zu haben. Tesselation nimmt im Grunde auch nur den Entwicklern etwas Arbeit ab, braucht aber genauso mehr Rechenpower.

Wenn dieses neue System funktionieren würde, hätten wir eine ziemlichen Grafiksprung vor uns, aber dazu muss die Engine erst mal einen Status erreichen, mit der man arbeiten kann, so weit ist diese aber längst nicht. Ist auch kein Wunder, dass das lange Zeit braucht, eine Polygon Engine zu schreiben ist ja keine Kunst mehr, weil hier schon über viele Jahre Erfahrungen gesammelt werden konnten. Für die neue Engine muss man aber auch noch richtig Problemlösungssuche betreiben.

[N16]

Indem du nicht alles zeichnest, sondern nur das was momentan auch sichtbar ist.
Stichwort Frustum Culling.
Danach kannst das ganze in mehrere Draw Calls aufteilen. Du brauchst ja nicht alles auf einmal batchen.

Ich kenne Culling schon, das ist eine Technik, die verwendet wird, um die Leistung zu steigern.
Ob mit oder ohne Culling, Polygone muss man irgendwo speichern und bearbeiten, und XNA unterstützt nun mal nicht mehr als 1'048'575 Polygone pro Szene.

Ihr könnt das Polygon System noch so schön reden, Tatsache ist, dass es bis heute immer noch die Möglichkeiten einschränkt, denn es fängt schon mit der Sichtweite an, nutzt man viele Polygone, wird oft die Sichtweite beschnitten und von den schönen Popins von Objekten in einer gewissen Entfernung bzw. sichtbare Änderung von Low zu Highpoly Modelle brauchen wir gar nicht erst reden, denn das sind nichts anderes als Notlösungen um mehr Polygone in der näheren Umgebung verwenden zu können.

Polygone werden nicht schöngeredet, sie sind nunmal effizient.
Eine Fläche kann mit 3 Punkte eines Polygons dargestellt werden, währenddessen sie (abhängig von der Flächengrösse) unglaublich viel mehr Punkte braucht, wenn sie als "Atom" dargestellt wird.

Mit der Atomtechnik wird man zu genau denselben Notlösungen greifen müssen.
Weit entfernte Objekte werden mit Low-Atom-Modelle dargestellt (Modelle mit wenigen, dafür riesigen Atome), was ebenfalls Popups beschwören wird.
Ein Atommodell hat mehr Punkte pro Modell, somit hat die Grafikkarte mehr im Speicher zu halten und mehr darzustellen.

Informationstechnologie beschäftigt sich nunmal unter anderem mit der Frage: "Wie kann ich möglichst viel, mit möglichst geringem Aufwand leisten"

Ich sage nicht, dass die Atomtechnik schlecht ist.
Irgendwann werden Polygonmodelle so kleine Polygone nutzen, dass man genausogut Atome nutzen könnte.
Nur bis dahin braucht's noch einige Jahre.

Tesselation nimmt im Grunde auch nur den Entwicklern etwas Arbeit ab, braucht aber genauso mehr Rechenpower.

1. Was ist falsch daran, den Entwicklern Arbeit abzunehmen?
Spiele werden auch nicht besser, wenn sie die gesammte Arbeit allein machen müssen.

2. Tesselation ist auch relativ neu (in Games).
Es gibt kaum eine Technologie, die von Anfang an "perfekt" ist.

Ich meinte weder das ich das kann, noch das es heute schon möglich ist. Aber es wird auf jeden sicherlich noch Techniken geben, mit denen man irgendwann keine großen flachen Polygonflächen und keine ecken mehr an runden Objekten mehr sieht.

Dafür gibt es bereits was: Tesselation & Displacement Mapping.
Dafür brauchst du aber eine Dx11 Karte, und die Techniken sind relativ neu, weshalb sie erst in etwa 5 Jahre oder später erst richtig gut genutzt werden (oder auf den next Gen Konsolen mit Dx11 Karten, da der Entwickler dann nicht auf die alten Dx9/10 Karten achten muss)

[Scorcher24_]

Indem du nicht alles zeichnest, sondern nur das was momentan auch sichtbar ist.
Stichwort Frustum Culling.
Danach kannst das ganze in mehrere Draw Calls aufteilen. Du brauchst ja nicht alles auf einmal batchen.

Ich kenne Culling schon, das ist eine Technik, die verwendet wird, um die Leistung zu steigern.
Ob mit oder ohne Culling, Polygone muss man irgendwo speichern und bearbeiten, und XNA unterstützt nun mal nicht mehr als 1'048'575 Polygone pro Szene.

Hmm, ich kenne XNA jetzt nicht wirklich, aber die Fehlermeldung spricht von EINEM DrawCall. Wer hindert dich daran mehrere DrawCalls zu machen? Oder eben nur partiell zu zeichnen?
Falls XNA wirklich so beschränkt ist, dann würde ich mal DirectX oder OpenGL nehmen. Mich beschränkt bei OpenGL eigentlich nur die Größe des VRAMS.
Und die knapp 200MB für die Million Polygone sollten eigentlich nicht stören. Dabei gehe ich von 64 Byte pro Vertex aus, inkl. Attribute. Meine Graka hat 1GB VRAM. Also hochladen kann ich das ohne Probleme.

[OPH]

Dafür gibt es bereits was: Tesselation & Displacement Mapping.
Dafür brauchst du aber eine Dx11 Karte, und die Techniken sind relativ neu, weshalb sie erst in etwa 5 Jahre oder später erst richtig gut genutzt werden (oder auf den next Gen Konsolen mit Dx11 Karten, da der Entwickler dann nicht auf die alten Dx9/10 Karten achten muss)

Gibt es denn schon Spiele, die das nutzen? Würde gern mal sehen was da heut schon möglich ist. Ich hab nähmlich leider noch kein Spiel gesehen, wo man nicht, (wenn man genau genug schaut) noch genau die Polygone sehen kann, und schönen Boden hab ich auch noch nie gesehen.
ABer das is meckern auf sehr hohem Niveau Man muss meistens schon sehr genau schauen, damit sowas auffällt.

[N16]

Wer hindert dich daran mehrere DrawCalls zu machen? Oder eben nur partiell zu zeichnen?

Es geht um eine einzige Landschaft, deren Polygone abhängig meiner Heightmap generiert wird.

Ich weiss jetzt nicht, ob ich das Programm so umschreiben kann, dass die Landschaft in Teillandschaften aufgeteilt wird und deren Darstellung von je einem DrawCall übernommen wird.

Werd's versuchen.

Gibt es denn schon Spiele, die das nutzen? Würde gern mal sehen was da heut schon möglich ist. Ich hab nähmlich leider noch kein Spiel gesehen, wo man nicht, (wenn man genau genug schaut) noch genau die Polygone sehen kann, und schönen Boden hab ich auch noch nie gesehen.

Momentan gibt es nur wenige.
Das Problem liegt nämlich bei PC UND Konsolen gleichermassen.
Konsolen unterstützen keine Tesselation und Displacement Mapping (zumindest nicht offiziell), während beim PC nur eine kleine Anzahl von PCs gibt mit Dx11 Karten.
Viele Spiele werden noch mit Dx9 Unterstützung angeboten, somit wird Tesselation und Displacement Maps nur wenig genutzt und nicht ganz ausgereizt.

[Scorcher24_]

Wer hindert dich daran mehrere DrawCalls zu machen? Oder eben nur partiell zu zeichnen?

Es geht um eine einzige Landschaft, deren Polygone abhängig meiner Heightmap generiert wird.

Ich weiss jetzt nicht, ob ich das Programm so umschreiben kann, dass die Landschaft in Teillandschaften aufgeteilt wird und deren Darstellung von je einem DrawCall übernommen wird.

Werd's versuchen.

Entwickel lieber eine ordentliche Methode nur das zu rendern was wirklich sichtbar ist. Und auch nur das an den DrawCall zu schicken. Das ist die gängige Praxis. Techniken hierzu nennen sich Binary Space Partitioning, Quadtree und Octree.
Einfach mal nach googlen .
Du musst halt die Daten nicht nur einlesen, sondern auch richtig verwerten.

edit: Ich hab schon öfters gelesen, dass Quadtrees die gängigste Methode ist für Terrain und BSP sich mehr für indoor level eignet. Aber das muss nicht stimmen. Ich beschäftige mich nicht mehr so sehr mit 3D Rendering, da es einfach ein zu breites Feld ist. Ich konzentrier mich auf meine 2D Engine.

[dcc]

Klar ist es Betrug. Vor 2 Jahren kursierte der gleiche Kram durch das Internet.
Eine Veränderung bleibt aber aus - es sieht immer noch gleich aus.

Ich würde eher auf Tesselation setzen, dadurch werden Wände, Bäume usw. plastischer und Teile stehen ab. Sieht man perfekt im Heaven Benchmark. Der Vorteil davon ist, man kann es an oder abschalten.

http://www.pcgameshardware.com/aid,6980 ... /Practice/

Wenn die Technik für unlimited Detail raus ist, dann kann man auch RayTracing benutzen.

[Minando]

Die Zeit wird zeigen, wer richtig liegt- aber dass es in alle Zukunft beim Polygon bleiben muss ist auch kein festgeschriebenes Gesetz. Ich WÜNSCHTE mir jedenfalls dass der Typ recht hat, so wie wohl jeder Spielefreak, aber so ganz glauben kann ich es auch nicht- es ist zu schön um wahr zu sein.

[pSyCeNeTiC]

http://vimeo.com/27522131

Anschauen