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!
Werbeanzeige
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.
Zitat
Deshalb habe ich mich nach externen Terrain-Editoren umgeschaut in der Hoffnung, Terrains innerhalb Ogre leicht (mit wenig Code) laden zu können.
Ja, die anderen Dinge bis dahin habe ich eigentlich auch gut verstanden. Aber bei Terrains war es etwas zu viel auf einmal...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.
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?Worauf beziehst du denn die 30 FPS ? Debug oder Release bei welchen Terrainmaßen ?
Ich habe auch selbst noch ein wenig ausprobiert. Unter anderem habe ich versucht, mit möglichst wenig Code ein Terrain zum Laufen zu kriegen.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 bin über dieses Tutorial gestolpert und könnte mir vorstellen, auch sowas zu machen.Ich schätze du wirst wohl oder übel dir einen kleinen Ingame Editor basteln müssen wenn du dich nicht mit Ogitor anfreunden kannst
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.naja, ich würde nicht sagen, dass Ogre schlecht Designt ist.
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) {} }; |
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?
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(); |
Werbeanzeige