Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Ogre Terrains

Werbeanzeige

Nexus

Alter Hase

  • »Nexus« ist der Autor dieses Themas

Beiträge: 713

  • Private Nachricht senden

1

25.09.2010, 19:15

Ogre Terrains

Hallo zusammen,

Ich beschäftige mich seit Kurzem mit der Ogre-Grafikbibliothek. Ich habe die Tutorials auf der offiziellen Homepage angeschaut, und bin nun bei Terrain-Gestaltung angelangt. Wie dessen Handhabung in Ogre funktioniert, wird meiner Meinung nach aber alles andere als gut erklärt: 150 Zeilen Code auf einmal, ohne wirklich gute Erklärung. Vielleicht hängt das damit zusammen, dass ich diesbezüglich ein ziemlicher Anfänger bin, aber ich habe damit nicht viel anfangen können.

Deshalb habe ich mich nach externen Terrain-Editoren umgeschaut in der Hoffnung, Terrains innerhalb Ogre leicht (mit wenig Code) laden zu können. Kennt ihr diesbezüglich gute Editoren? Man findet ja im Internet etliche verfügbare, auch solche, die nicht auf Ogre zugeschnitten sind. Ich habe mir mal Ogitor angeschaut. Im Prinzip reichen mir Heightmaps und unterschiedliche Texturen für den Anfang, nützlich wäre vielleicht auch die Platzierung von Meshes und Beleuchtung. Aber ich brauche keine x-beliebige Konfigurierbarkeit, die auf Kosten der Benutzerfreundlichkeit geht. Was könnt ihr empfehlen?

Im Weiteren finde ich es etwas merkwürdig, dass die Beispiele von Ogre recht langsam gezeichnet werden (Terrains nur bei etwa 30 FPS). Ich habe zwar nicht den neuesten Computer, aber Landschaften älterer Spiele (wie z.B. Warcraft III) sind von der Performance her nie ein Problem gewesen. Klar ist dort die Grafik vielleicht weniger gut, aber sowas wäre mehr als genug. Ist Ogre generell nicht sehr schnell, oder gibt es Tricks, wie ich Landschaften performant darstellen kann? Wie gesagt, eine "Comic-Style"-Grafik wie in Warcraft III würde mir längstens reichen, ich brauche keine ultra-realistischen Darstellungen.

E122

Alter Hase

Beiträge: 1 372

  • Private Nachricht senden

2

26.09.2010, 11:07

Zuersteinmal: Mit den Tutorials bei Ogre ist das sone Sache, die machen den Einstieg nicht immer einfacher, aber ich muss sagen, sie haben sich doch eigentlich gebessert.
Worauf beziehst du denn die 30 FPS ? Debug oder Release bei welchen Terrainmaßen ?

Jeason

Frischling

Beiträge: 63

  • Private Nachricht senden

3

26.09.2010, 12:11

Zitat

Wie dessen Handhabung in Ogre funktioniert, wird meiner Meinung nach aber alles andere als gut erklärt: 150 Zeilen Code auf einmal, ohne wirklich gute Erklärung.

Naja also mir hats darmals geholfen neben den Tutorials viel selber zu Probieren ;) Ich hab noch kein Tutorial gefunden das mir irgendwas so gut gleich erklären konnte ohne das nicht selber herrumexperimentieren hätte müssen ^^

Zitat

Deshalb habe ich mich nach externen Terrain-Editoren umgeschaut in der Hoffnung, Terrains innerhalb Ogre leicht (mit wenig Code) laden zu können.

Durch einen Terrain Editor wird der Code zum laden nicht kleiner sondern eher größer :D

Leider ist es so das es für OGRE nicht wirklich viele Level Editoren gibt speziell gute... das liegt warscheinlich damit zusammen das wie du schon sagtest OGRE nur eine Grafik-Engine ist und man mit ihr nicht nur Spiele machen kann

Ich schätze du wirst wohl oder übel dir einen kleinen Ingame Editor basteln müssen wenn du dich nicht mit Ogitor anfreunden kannst ;)

Nexus

Alter Hase

  • »Nexus« ist der Autor dieses Themas

Beiträge: 713

  • Private Nachricht senden

4

26.09.2010, 13:31

Danke für eure Antworten!

Zitat von »E122«

Zuersteinmal: Mit den Tutorials bei Ogre ist das sone Sache, die machen den Einstieg nicht immer einfacher, aber ich muss sagen, sie haben sich doch eigentlich gebessert.
Ja, die anderen Dinge bis dahin habe ich eigentlich auch gut verstanden. Aber bei Terrains war es etwas zu viel auf einmal...

Zitat von »E122«

Worauf beziehst du denn die 30 FPS ? Debug oder Release bei welchen Terrainmaßen ?
Im Ogitor waren es etwa so viel, sobald ich eine Heightmap geladen habe. Ogre selbst war schneller. Terraingrösse weiss ich nicht mehr genau (war glaub ich die Voreinstellung bei Ogitor, sofern das hilft)... Aber sollte nicht primär nur der sichtbare Teil des Terrains die Geschwindigkeit beeinflussen?

Zitat von »Jeason«

Naja also mir hats darmals geholfen neben den Tutorials viel selber zu Probieren Ich hab noch kein Tutorial gefunden das mir irgendwas so gut gleich erklären konnte ohne das nicht selber herrumexperimentieren hätte müssen
Ich habe auch selbst noch ein wenig ausprobiert. Unter anderem habe ich versucht, mit möglichst wenig Code ein Terrain zum Laufen zu kriegen. ;)

Zum Beispiel habe ich die BlendMap-Initialisierung weggelassen. Merkwürdig fand ich es erst, als sich das Programm nicht mehr sauber beendete, sobald ich freeTemporaryResources() aufrief!

Zitat von »Jeason«

Ich schätze du wirst wohl oder übel dir einen kleinen Ingame Editor basteln müssen wenn du dich nicht mit Ogitor anfreunden kannst
Ich bin über dieses Tutorial gestolpert und könnte mir vorstellen, auch sowas zu machen.

Aber ich werde mich vorerst wohl mit Irrlicht beschäftigen. Ich habe oft gehört, der Einstieg sei leichter und die Bibliothek weniger überladen. Was mich an Ogre auch stört, ist die lange Ladezeit des Fensters und das schlechte Design, das bereits Hello-World-Programme fast eine Minute kompilieren lässt. Die hätten ruhig ein wenig Pimpl einsetzen, oder zumindest nur die wirklich notwendigen Header einbinden können...

E122

Alter Hase

Beiträge: 1 372

  • Private Nachricht senden

5

26.09.2010, 13:42

naja, ich würde nicht sagen, dass Ogre schlecht Designt ist.
Du musst es so sehen: Mit OGRE bekommst du jedemenge Großartige Features. Du musst dich selbst entscheiden, ob du eine etwas weniger 'Starke' Engine mit mehr Benutzbarkeit oder anderstherum nutzen willst.

Nexus

Alter Hase

  • »Nexus« ist der Autor dieses Themas

Beiträge: 713

  • Private Nachricht senden

6

26.09.2010, 13:57

Zitat von »E122«

naja, ich würde nicht sagen, dass Ogre schlecht Designt ist.
So pauschal würde ich das auch nicht sagen, ich kenne Ogre ja auch zu wenig. Aber bei einigen Teilen, mit denen ich bisher zu tun hatte, habe ich schon so meine Zweifel.

Die Compiletime-Abhängigkeiten hätten sie reduzieren können, ohne Funktionalität wegzulassen. Zum Beispiel, indem sie weniger Vererbung einsetzen und grundsätzliche Regeln im Bezug auf die Notwendigkeit von #includes beachten.

Ein Beispiel: BaseApplication erbt unter anderem von SdkTrayListener. Diese Klasse sieht so aus:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13

    class SdkTrayListener
    {
    public:

        virtual ~SdkTrayListener() {}
        virtual void buttonHit(Button* button) {}
        virtual void itemSelected(SelectMenu* menu) {}
        virtual void labelHit(Label* label) {}
        virtual void sliderMoved(Slider* slider) {}
        virtual void checkBoxToggled(CheckBox* box) {}
        virtual void okDialogClosed(const Ogre::DisplayString& message) {}
        virtual void yesNoDialogClosed(const Ogre::DisplayString& question, bool yesHit) {}
    };

Also ein reines Interface, das genau null Include-Direktiven benötigt, alles wäre mit Vorwärtsdeklarationen machbar. Leider haben sich die Entwickler hier nicht so viel überlegt und im SdkTrayListener-Header die Datei "Ogre.h" inkludiert, was nicht nur komplett unnötig ist, sondern die Kompilierzeit massiv erhöht. Ein anderes Beispiel ist Ogre::Vector3, zu dem ich vor einiger Zeit etwas geschrieben habe.

Klar macht das die Bibliothek nicht grundsätzlich schlecht, aber mir persönlich fällt sowas schon von Anfang an negativ auf.

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

7

26.09.2010, 14:41

Zitat von »Nexus«

Im Ogitor waren es etwa so viel, sobald ich eine Heightmap geladen habe. Ogre selbst war schneller. Terraingrösse weiss ich nicht mehr genau (war glaub ich die Voreinstellung bei Ogitor, sofern das hilft)... Aber sollte nicht primär nur der sichtbare Teil des Terrains die Geschwindigkeit beeinflussen?

Ein Editor wird meist sehr viel langsamer laufen, als wenn du das wirklich Realtime einsetzt. z.B kann ich den Editor für Crysis kaum aufstarten, aber Spielen kann ich es eigentlich ohne grosse Probleme.
Was die sichtbaren Teile anbelangt: Jain, es sind natürlich enorme Einsparungen möglich, wenn man nur den sichtbaren Teil beachtet, aber einen gewissen Overhead hat der Rest schon auch.
http://www.drakon.ch | Weltweit 31. Bester Solitär Spieler (Standard XP)

Zero

Treue Seele

Beiträge: 145

  • Private Nachricht senden

8

26.09.2010, 14:59

Also ich muss sagen, unser Editor hat so die gleiche Anzahl an Frames wie bei uns im Spiel bei mir^^

@SdkTrayListener: Naja das ist so ne Sache, ist halt alles nur zum testen und so, die Sachen brauchst du später nie wieder irgendwo, weil du da ja alles "alleine" machst. Ist halt nur ne Klasse für ihren neuen Samplebrowser.

Und sonst muss ich sagen das Ogre vieles zu bieten hat, na klar muss man sich einarbeiten, aber wenn man das erstmal geschafft hat, kann man recht gut mit der Engine arbeiten.

So mal zum Terrain, das ist auch so nen riesen Ding und auch noch sehr "jung", also kann es da immer noch zu Fehlern kommen.

Hier mal nen bisschen Code um ein Terrain zu erstellen:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    Ogre::Terrain *pOgreTerrain = new Ogre::Terrain(pSceneMgr);
    Ogre::Terrain::ImportData imp;
    imp.terrainSize = 513;
    imp.worldSize = 2048;
    imp.inputScale = 1.0;
    imp.minBatchSize = 33;
    imp.maxBatchSize = 65;

    imp.layerList.resize(1);

    // Grundtextur setzen
    imp.layerList[0].worldSize = 100;
              // Hier solltest du deine eigenen Texturen verwerden^^ Das erste ist die Textur und dann die Normal
    imp.layerList[0].textureNames.push_back("kpx_nature_sand_02-texture.dds");
    imp.layerList[0].textureNames.push_back("kpx_nature_sand_02-normal.dds");

    pOgreTerrain->prepare(imp);
    pOgreTerrain->load();


Hoffe das kann dir helfen.

Nexus

Alter Hase

  • »Nexus« ist der Autor dieses Themas

Beiträge: 713

  • Private Nachricht senden

9

26.09.2010, 16:32

Vielen Dank für den Code, Zero! Ich muss allerdings ehrlich sagen, dass ich etwas Mühe habe, ihn richtig einzuordnen (wenn das Tutorial-Framework gegeben ist). Das ist eigentlich mein Hauptproblem, ich muss wahnsinnig viele Dinge konfigurieren und aufeinander abstimmen, um nur etwas Kleines zu erreichen. Zusammen mit meiner relativ geringen Erfahrung und den nicht allzu ausführlichen Tutorial-Erklärungen ist das nicht gerade einfach.

Deshalb befasse ich mich jetzt mit Irrlicht. Falls ich später mehr Funktionalität benötige, kann ich mir Ogre immer noch anschauen. Wenn ich die Grundkonzepte gut verstanden habe, wird mir der Ogre-Code vielleicht auch leichter fallen... Und sonst frag ich nochmals nach. ;)

Der Einstieg in Irrlicht sieht zumindest schon mal gut aus: Die gesamte "irrlicht.h" kompiliert in nur 3 Sekunden! Da haben sich die Entwickler wirklich angestrengt. Und das Programm lädt auch in einer Sekunde statt 10. Vom benötigten Code wollen wir gar nicht erst anfangen... :)

Tobiking

1x Rätselkönig

Beiträge: 1 231

  • Private Nachricht senden

10

27.09.2010, 00:40

Ich glaub man konnte die Compilezeit mit Ogre deutlich drücken wenn man statt der Ogre.h lieber gezielt includiert. Die Ogre.h includiert halt alles, was doch schon recht viel ist. Da war nichtmals das Nutzen von precompiled Headern möglich da das Teil über 100 mb groß wurde.

Zum Ogre Verständniss kann ich nur sagen das mich das Tutorial Framework auch total verwirrt hat. Das Basic Tutorial 6 zeigt aber wie man Ogre von Hand initialisiert und ohne dem Tutorial Framework auskommt. Da wird einem erstmal klar wie das mit den Ressourcen etc. läuft und man braucht auch nicht die Standardressourcen mehr mitliefern.

Werbeanzeige

Ähnliche Themen