Meshutility zum 2.

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

Meshes

Und mal wieder ein Tool für Xrodon: Der Mesh Editor.

Allgemein

Da Xrodon II ja irgendwann mal mehr als ein Paar dutzend Spielobjekte haben wird, muss bei der Darstellung auch auf Performance geachtet werden. Abgesehen von den andren Wahnsinnsmöglichkeiten, die Ogre3D in dem Performancesektor bietet, gibt es ja noch das gute alte Level of Detail. Und damit sich kein Grafiker unnötig damit herumplagen muss, dass per Komandozeile zu generieren, hab ich jetzt einen Editor für Geschrieben. Hier kann man angeben, welches LOD ab wann geladen werden soll, und wieviel Prozent der Vertices pro LOD wegfallen sollen,  und diese dann generieren. (Was schlussendlich Ogre selber übernimmt. Siehe Ogre::Mesh::generateLodLevels ) Eigentlich hatte ich früher noch an ein Paar ausbaumöglichkeiten für den Editor gedacht, allerdings scheint Ogre nicht allzuviele Modifikationen am Algo zu erlauben, ohne dass man im Code der Engine rumpfuscht. (mein persönlicher Eindruck)

Technik

Wie schon der Languageeditor ist das ganze in wxWidgets (unter erweiterung durch eigene Controls) geschrieben, Ogre3D ist natürlich auch dabei.  Ansonsten gibts eigentlich nicht viel Interessantes dazu zu sagen, da er mehr die Möglichkeiten von Ogre3D in eine Grafische Oberfläche kapselt.

“Bildchen”

Und natürlich gibts noch nen Screen

Hier ist der Screen. Die Anzeige unten zeigt an, wieweit die Kamera von der Scenenode entfernt ist.

Sprachen über Sprachen

Und nachdem ich schon länger nichtsmehr von mir verlauten lassen habe, ein neuer Artikel:

Aktuell schlag ich mich damit rum, mehrere Sprachen zu unterstützen. Da Xrodon MyGui verwendet, wird dessen Languagesystem verwendet.

Sprachen und MyGUI

Erstaunlicherweise hat MyGUI zwar ein Sprachsystem, allerdings beschränkt sich dieses darauf die Sprachen zu verwalten. Die Einzelnen Einträge sind im klassischen Wörterbuchprinzip mit Tag und zugehörigem Value gespeichert. Dabei wird das ganze aus einer oder Mehreren XML-Dateien ausgelesen. Man hat eine XML, in der die Einzelnen Sprachen “deklariert” sind, und zugehörige Source xml’s.

Was ich persönlich sehr schade finde, ist das die Texte der Steuerelemente dann nicht automatisch gesetzt werden, bei einem Sprachwechsel. Das muss man selber tun. Zu diesem Zweck gibt es ein Multi-Delegate im MyGUI::LanguageManager-Singleton, der eine Callbackmöglichkeit bei Sprachwechsel bietet.

EDIT: Er macht das Doch. Wenn in der Caption des Widgets #{derNamedesTags} is, macht ers.

Dabei muss man allerdings feststellen, dass es sich schwierig gestaltet sich durch die Einzenlen Fensters eines MyGUI-Roots zu iterieren. Dieser bietet nämlich nur eine Methode zum bekommen des Enumerators auf das erste Top-Level Window an, aber nicht auf die anderen. Deshalb muss die ganze GUI für solche Zwecke einem einzigen MyGUI::Widget zugeordnet sein, womit sich mit folgendem Code rekursiv durch die einzelenen Childs Iterieren lässt.

void setWidgetLang (MyGUI::Widget* wid )
{
if (wid->getChildCount () == 0)
{
// Tu den Text ändern
return;
}

for (size_t i = 0; i< wid->getChildCount(); i++)
{
setWidgetLang (wid->getChildAt (i));
}
}

Der Xrodon Languageeditor

Ein Screenshot vom Xrodon Languageeditor

Doch wer will schon jeden Tag in der XML-Datei bearbeiten,

das könnnen bei einem

Großen Projekt ja mehere Tausend werden, und das auf mehrere Dateien verteilt. Daher gibt es für Xrodon einen Spracheditor, in dem diese gesamte Bearbeitung komfortabel geschehen kann.

Im TreeView Rechts kann man nach Sprache gruppiert die einzelnen Dateien auswählen, und dann die Tags einer solchen Datei komfortabel in einer Tabelle bearbeiten.

Der Editor selbst ist unter der Verwendung von wxWidgets geschrieben.

void setWidgetLang (MyGUI::Widget* wid )
{
// Rekursiv
if (wid->getChildCount () == 0)
{
wid->setCaption (MyGUI::LanguageManager::getInstance().getTag (wid->getCaption()));
return;
}

for (size_t i = 0; i< wid->getChildCount(); i++)
{
setWidgetLang (wid->getChildAt (i));
}
}

Mitarbeit an Xrodon II

Von nun an werde ich an Xrodon II (alternativlink hier) mitarbeiten. Daher wird es weniger News zu Bomb3D geben, da ich mich ansonsten mehr auf die Technische Seite Konzentrieren werde