Und nun eine Korrektur des Letzten Artikels, da sich meine Taktiken doch geändert haben:
Ein neuer Screen
Ich erlaube mir jetzt einfach mal die Änderungen Aufzuzählen:
- Neuer Ansatz zum Angeben der Distanz
Ab jetzt wird die Distanz nicht Mehr in Metern angegeben, da das viel zu unflexibel ist/war. In Anbetracht dessen, dass die Sichtweite flexibel einstellbar ist, werden die Distanzen für die LOD’s nun in Prozent der Sichtweite angegeben. Wobei das die Sichtweite auch in einen gewissen Bereich eingeschränkt ist, unter andrerem durch die LOD’s. (Man stelle sich die – unsinnige – Sichtweite 1 Meter vor: 20cm vom Mesh weg, und schon erscheint ein Imposter !)
- Neue Leveltypen supported
- Imposter
Imposter - Bitte verzeiht mir die Schiefe. Seht es als Moderne Kunst 
Bei einem Imposter handelt es sich um zwei Rechtecke, die gekreuzt in der Szene stehen, wie die Zeichnung anbei Verdeutlicht. Diese können wie alle anderen Level auch individuell Konfiguriert werden. Für den Imposter stehen hierbei zur Auswahl, ob er Automatisch Generiert oder Von einer Datei stammen soll. Wenn das Automatische generieren ausgwählt wird, generiert das Utility die Textur für den Imposter automatisch aus dem Mesh. Hierbei ist natürlich zu Beachten, den Lod-Bias der Ogre::Camera entsprechend zu setzen, damit auch wirklich der Ausgangsmesh auf dem Imposter landet, der im übrigen die Größe 256×128 Pixel hat. Ansonsten liegt der Knackpunkt hierbei auf der Kameraposition, der Imposoter soll ja im Endeffekt die Selbe Größe haben wie der Ausgangsmesh. Das geschieht durch einen (zu meiner Schande Try-and-Error) Algorithmus, der Einfach die Kamera etwas weiter entlang der Distanzachse bewegt, bis der Mesh vollständig auf der Textur zu erkennen ist. Das lässt sich (wie so vieles mit Ogre) mit Ogre::Camera::projectSphere feststellen. Leider hat dieser Anstatz mehrere Probleme:
- der Step-Wert für die Distanz muss gewählt werden, ist er zu groß erscheint das Objekt nachher unter Umständen zu klein auf der Textur, ist er andererseits zu groß wird kostbare Rechenzeit verschwendet.
- er ist einfach nicht das Gelbe vom Ei
Der Rest der Texturgeneration ist einfaches Render-To-Texture. Die Impostergeometrie selbst wird durch einfache Benutzung der Ogre::ManualObject Klasse erstellt.
- Andere Interne Realisierung des generierens
Nachdem ich in der letzten Version an dem Mix aus Manuellen und Generierten LOD-Levels gescheitert bin, musste diesmal ein neuer Ansatz her. Und nach (zu meiner Schande muss ich eingestehen – es war mehr als 1 Woche 
– ist dann endlich der Groschen Gefallen. Wieso nicht einfach eine Kopie des Originalmeshes mit generierten Indexdaten als Manuellen LOD-Level benutzen ? Das ganze bringt die Kehrseite mit, dass man alle Vertexdaten & Co. doppelt hat, und auch 2 Getrennte Dateien, aber das musste ich jetzt einfach in Kauf nehmen.
- Rewrite des Speicherns
Dadurch dass ja jeder Level mit Ogre::Mesh::createManualLodLevel hinzugefügt wurde, wird jetzt auch für jeden Level eine Eigene *.mesh-Datei benötigt. Die Namensgebung orientiert sich dabei weitgehend an dem Level 
- UI überarbeitet
Ich habe nach längerer Überlegung und auch konstruktiver Kritik die UI nochmal überarbeitet und vereinfacht. Unnötige und teils auch Verwirrende/Falsche Dinge wurden gnadenlos rausgeschmissen, Beispiel dafür wäre z.B. die Basismeshstatistiken mit dem Trianglecount. Stattdessen sind einige Hilfreiche Dinge hinzugekommen, darunter:
- Inaktive LOD-Level werden in der Tabelle ausgegraut
- Wenn es Fehler beim Generieren gab, werden diese Ausgegeben, und deren Ursprungszelle rot eingefärbt
- Einige Vorbeugende Fehleranalysen
- Das Grid wurde auf Normalgröße gebracht (ich meine, 9 statt den ursprünglich 100 möglichen Leveln reichen doch ^^)
- Die Spaltenüberschrift passt sich jetzt individuell der Markierten Zelle und deren Level an. Steht dort bei Generieren z.B. “% der Vertices des Ausgangsmeshes” so steht dort, falls man versucht ein Parameter für den Typ Manueller Mesh anzugeben “Dateiname des Meshes” und es öffnet sich ein Dateiauswahldialog.
Euer E333
