Hi,

ich habe die Frage schon mal in einem anderen Thread gestellt, dort ist sie aber untergegangen, wahrscheinlich wegen des trivialen Subjektes ("Wie Newton installieren?", unter Allgemein). Also, meine Frage bezieht sich auf den Renderalgorithmus von Delphic, beschrieben in seinen Terrain-Tutorials. Ich wollte wissen, inwieweit dieser Algorithmus praxistauglich ist oder ob das Ganze eher als Designstudie aufzufassen ist. Das Ausprobieren ist so eine Sache, weil da viele Dinge dranhängen.

Was ich suche, ist ein LOD-Algorithmus zum Rendern sehr großer Terrains, indem man sich ziemlich schnell bewegt. Ohne Optimierung geht es nicht. Wichtig ist auch, dass das Gelände mit Fliesen texturiert wird; eine große Textur, evtl. mit Dingen wie Detailmaps aufgeschönt, ist nicht geeignet. Dazu kommt dann noch das Problem, wie die Übergänge zwischen verschiedenen Fliesen verwischt werden, aber das wäre ein Folgeproblem.

Seid so gut und verweist nicht auf die seite vterrain.org. Was da steht, ist geeignet, die LOD-Programmierung zu einem Vollzeitjob für mehrere Jahre zu machen. Ich suche einfach nur einen Algorithmus, den ich ohne große Umstände anwenden kann.

Gruß,
erin

Ich hoffe dir ist der Widerspruch bewusst. Auf der einen Seite, willst du etwas hochkomplexes (ein großes Terrain mit viel Detail rendern), aber auf der anderen Seite möchtest du keine Zeit investieren. Ich hoffe dir ist klar, dass es ohne komplexe Algorithmen nicht geht.

Ich würde zuerst mal versuchen, die Psyche des Anwenders auszunutzen. Wenn du sagst, ziemlich schnell, was meinst du dann? Flugsimulation z.B.? Dann würde ich sagen, render das Terrain abhängig von der Geschwindigkeit in unterschiedlichen Detailstufen. Die kannst du einfach durch die schon mehrorts vorgeschlagene Heightmap-Rendering-Mit-Vertex-Shader-Methode lösen: Du nimmst dann einfach unterschiedlich genaue Meshes für sowas. Natürlich sieht das nicht so gut aus wie mit einem echten, guten LOD Algorithmus, aber für die willst du ja auch keine Zeit investieren.

Was die Texturierung anbelangt wirst du auch da Abstriche machen müssen; Mein Vorschlag ist hier, einen Texturatlas je nach aktuellem Bedarf zu befüllen und so nur die wenigen Texturen, die gerade gebraucht werden, im GRAM zu halten. Keine Ahnung, ob das schon unter Texture Streaming oder Virtual Texture oder $buzzword fällt.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich versuche, den Widerspruch zu entdecken, aber es will nicht so ganz gelingen. Ist es widersprüchlich, wenn man bei einem zugegebenermaßen komplexen Teilproblem auf den bewährten Code anderer zurückgreift und das Rad nicht selber neu erfindet? Ist das nicht der Sinn von universellen Libraries?

Doch zur Sache: Ich wollte das Projekt erst bei Gelingen bekannt machen, aber sei's drum. Es soll eine Art von Flugspiel werden (Simulation ist der falsche Begriff), wobei sich alles in Bodennähe abspielt. Man könnte sich den Flugkörper als Insekt vorstellen. Durch die Bodennähe sind natürlich die Details im Bodenterrain erkennbar, und die Geschwindigkeit ist - wenngleich absolut nur begrenzt - im Verhältnis zur Umgebung schon rasant. Damit dürfte auch klar sein, warum ich in einem anderen Thread die Wichtigkeit der Kollisionen betont habe, denn es gilt, Bäumen, Felsen, Gebäuden usw. auszuweichen.

Das alles muss in Gedanken noch reifen, und im Augenblick schätze ich die Erfolgschancen etwa 25 % ein. Nur am Rande: So ganz ohne Erfahrungen bin ich nicht, wenngleich sich meine bisherigen OpenGL-Erfahrungen auf C/C++ beschränken. Ich hatte z.B. wesentlichen Anteil am Rewrite von Extreme Tux Racer. Da die Initiative auseinandergefallen ist, ist es nicht mehr zur Veröffentlichung gekommen. Außerdem waren noch einige Teilprobleme zu lösen. u.a. auch der Renderalgorithmus, womit ich wieder beim Thema bin. In ETR (überhaupt in Tuxracer) wurde ein in die Jahre gekommener Quadtree-Algorithmus von Ulrich Thatcher benutzt, der aber seine Schwächen hat und dringend ausgetauscht werden musste. Doch wie gesagt, dazu ist es nicht mehr gekommen, und bevor ich an ein anderes, ähnliches Projekt herangehe, möchte ich gerne im VORFELD erkunden, ob es eine Lösung gibt. Brute force und irgendwelche statischen LODs scheiden aus, weil die Blickwinkel sich schnell verändern können und die höchste Detailstufe nur im absoluten Nahbereich notwendig ist. Da aber zwingend. Irgendwelche Wischi-Waschi-Texturen würden alles kaputt machen.

So, kann sein, dass ich zuviel gesagt habe. Aber irgendwie hatte ich das Gefühl, nicht ganz verstanden worden zu sein.
Gruß

Es gibt einen Unterschied zwischen „auf bewährten Code zurückgreifen“ und auf „algorithmen“. Bisher hast du (korrigiere mich, wenn ich falsch liege) immer von Algorithmen gesprochen, und diese sind nun mal allein das theoretische Konzept; Die müssen verstanden und selber implementiert werden.

Wenn du fertigen Code suchst kann ich dir leider auch nicht helfen, außer mit dem, was ich schonmal hier verlinkt habe. Man kann das auch nutzen, um das Terrain in Grafikkartenverträgliche Häppchen zu teilen und immer nur diese Häppchen auf der GPU liegen zu haben. Aber gut zu wissen, vielleicht können dir dann andere zur hand gehen.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ok, das sehe ich ein. Ich habe bisher die beiden Begriffe eher synonym verwendet, oder zumindest annähernd. Nun kann ich es klar sagen: Mit den Algorithmen (z.B. auf vterrain.org) kann ich nicht viel anfangen, weil es viel zu aufwändig wäre, sie zunächst zu verstehen und dann zu codieren. Und da konkreter Code eher rar zu sein schein, steht das Projekt schon auf der Kippe bevor es gestartet ist. Aber noch kann ich die Sache rechtzeitig stoppen.

Danke für die Bemühungen
Gruß erin