Thema: Kartengröße (für Weltgenerator)

[Dark-Star]

Moin Leute,
ich bräuchte für mal eure Hilfe bei der Klärung einer Frage. (wer nur die Frage lesen will bitte ganz unten )
Es gibt einen eklatanten Mangel an guten Weltgeneratoren, die ihre Generierung nicht auf "fraktalnumerischen Pseudozufallszahlengeneratoren" und "Perlinhöhenheneratoren" basieren lassen. Dadurch bekommt man hauptsächlich nur Berge in den Zentral kontinentenregionen und nicht wie es bei unserer Erde typisch ist auch ab und an in etwas spezielleren Orten wie es z.b mit Fjorden und dem Norwegischen Hochpateaus, den Pyrinäen oder auch schon den beiden Hauptgebirgsen der USA der Fall ist.

Deshalb bin ich, mit ein bischen Designhilfe, dabei einen Weltgenerator zu schreiben der auf richtiger Plattentektonischen simulationen und noch mehr science know-how für Geologie, Klimatologie, Hydrologie... basiert(also alles womit sich Hobbylose Ingenieursstudenten so aus Spass rumschlagen wollen ) .
Klar könnte ich auch einen bestehenden Generator nehmen der nicht all das hat was so richtig cool ,fancy ist und vor allem realistischem Terrain hat, aber wo bleibt dann der drang schöpferisch tätig zu sein.
Dauert dann zwar bis das Endgültige Ziel erreicht ist aber das erste angestrebte Ziel ist der Topographische Generator, und zwar mit der Möglichkeit auch zwischen den Generrieungsschritten  Einfluss auf Kontinentalform, Plattenform, Gebrigszüge... nehmen zu können.

Für die Programmarchitektur bin ich jetzt auf das Problem gestoßen wie viele unterteilungen ich auf dem Planeten den machen darf bevor Ram und Rechenleistung das Programm verlangsamen. Also muss ich die Regionen mit maximalem Detailgrad in ihrer Größe begrenzen, und zur abschätzung brauch ich euch.

Da es sich hierbei ja dann hauptsächlich; neben dem wissenschafftichen Spieltrieb; um etwas handelt das einem beim Rpg nützlich sein soll stellt sich nun folgende Frage:

Wie groß sind die von euch für rpg generierten und bespielten Regionen? (für weltraumoperas natürlich wie groß ihr eure Landezohnen designt)
Muss nicht in km sein, ca so groß wie Hessen/ Spanien/ Europa/... langt auch schon.

[Kardinal]

also auf einem Planeten von Erdgröße möchte ich schon bis auf Gebiete von Großstadt (oder einem größeren Tal) bis "Megacity"  Umfang (mind. 20-30 km Durchmesser) zugreifen können...

[Gasbow]

Bei uns schwankt die größe der Region ganz extrem nach dem gewählten Fokus.
Es kann durchaus ein Planet interessant sein.
Auf diesem Planeten ein Kontinent.
Auf diesem Kontinent eine Stadt
und in dieser Stadt dann sogar ein Gebäude.

Supermegacool wäre natürlich, wenn man für eine bestehende "große" Karte, wie einen ganzen Planeten, einen Ausschnitt wählt, welcher dann auf Grundlage des groben Rasters eine der Größe des Rasters angemessene feinere Karte generiert.

[Sanguaire]

Bei uns schwankt die größe der Region ganz extrem nach dem gewählten Fokus.
Es kann durchaus ein Planet interessant sein.
Auf diesem Planeten ein Kontinent.
Auf diesem Kontinent eine Stadt
und in dieser Stadt dann sogar ein Gebäude.

Supermegacool wäre natürlich, wenn man für eine bestehende "große" Karte, wie einen ganzen Planeten, einen Ausschnitt wählt, welcher dann auf Grundlage des groben Rasters eine der Größe des Rasters angemessene feinere Karte generiert.

+1

Ich würde den Detailgrad an die Zoomstufe hängen. Das kann fliessend sein wie bei Google-Earth oder in Einteilungen Weltkarte, Kontinentkarte, Landeskarte etc.

[Boba Fett]

Die Frage ist doch, wann es zu langsam wird.
Eine Erdähnliche Weltmit einem Durchmesservon grob 10.000 km hat eine Oberfläche von grob 300 Millionen km^2
Ein Raster von einem Kilometer würde also 300 Millionen Felder (Pixel) ergeben.
Ein Kilometer ist bei Fjorden aber schon recht grob.

Städte spielen imho keine große Rolle. Die werden eher willkürlich vom User festgelegt, anhand von taktischen Erwägungen.

Bei Flüssen sieht es aber schon wieder anders aus, denn die fliessen nach bestimmten Gesetzen. Und sie beeinflussen auch sehr stark die Oberflächenbeachaffenheit ganzer Regionen. Und da ist ein Kilometer als Raster schon erheblich...

Insofern ist schon die Frage, ob die Auflösung nicht unterschiedlich sein sollte.
Sozusagen ein grobes Raster um die Grobeinstellungen zu definieren und dann partiell ein feines an interessanten Stellen. Ggf. Könnte deren Auswahl ja teilweise sogar interaktiv geschehen.

[Sanguaire]

Du hast recht, das eine Welt schon viele Pixel hat. Aber man muß nicht die ganze Welt in maximal Auflösung nicht im Arbeitsspeicher halten. Man lagert normalerweise die unsichtbaren Bereiche/Details der Welt in einen Puffer aus. Hierdurch erhält man eine höhere Performance des Programms.

Ich denke Dark-Star sollte am Programmdesign noch etwas feilen. Auch bei den heutigen Arbeitsspeicherausbauten ist eine Pufferung ab einer gewissen Datenmenge nötig.

[Grimnir]

Zunächst einmal: Das Projekt finde ich super. Ich habe mich auch schon sehr über Fraktale Weltgeneratoren geärgert, aus den gleichen Gründen, die Du anführst: Gewaltige Gebirgsmassive oder Hochebenen in der Mitte des Kontinents und so gut wie nie Küstenketten. Daher 

Was die Größe anbelangt, bin bin eigentlich für eine ganze Welt in Erdgröße. Selbst wenn ich mir später nur eine Region zum Bespielen aussuche, habe ich für mich gerne eine Verortung der mythisch-magischen Orte, die in der bespielten Region nur als Sagen auftauchen, z.B. sowas wie "Uluk hinter den Stürmen" oder "die Leviathane des gräsernen Meeres".

Außerdem ist durch die Generierung einer ganzen Welt diese auch gut für eine SF-Entdecker-Kampagne à la Traveller gut zu gebrauchen.

[Tudor the Traveller]

Da (je nach Spielstil) die SC nicht immer in der gewählten Region bleiben, ist es zumindest grundsätzlich wünschenswert, das insgesamt erreichbare Gebiet wenigstens grob abgedeckt zu haben. Das ist natürlich je nach verwendetem System bzw. Genre auch wieder verschieden. Insofern sollte man wohl oder übel grundsätzlich von der ganzen "Welt", d.h. i.d.R. vom gesamten Planeten ausgehen.

Für die Größe des bespielten Gebiets hängt es davon ab, welche Klimazonen (natürlicherweise) vertreten sein sollen. Wenn ich sowohl Ewiges Eis als auch tropischen Regenwald drin haben will, sollte der Ausschnitt schon entsprechend groß sein. Dabei ist die Erde für Distanzen als gewohnter Bezugsrahmen immer ein solider Ausgangspunkt, finde ich.

[Dark-Star]

Erstmal danke an euch 

Die Implementierung von Städten war für den Anfang nicht geplant, kann ja für Version 2 noch gemacht werden am Anfang sollte es nur die Möglichkeit geben das man Städtesymbole setzen kann, evtl auch ein automatischer Algorythmus den der Benutzer drüberlaufen lassen kann wenn er ein Gebiet generisch besiedeln lassen will.

Das Programm wird allein für die Plattentektonik schon den gesamten Planeten generieren. In diesem Rahmen wird das noch grob geschehen. Was Speicherbedarf und Rechenzeit angeht habe ich erstmal an einem Programm getestet das Punkte gleichmäßig auf einer Kugel verteil. Man muss ja wissen wie hardwarefressend ein Prozess in der Größenordnung überhaupt sein wird.
Grade schreibe ich an einer Methode wie man die einzelnen Bereiche in Abhängigkeit der Detailstufe ansteuert. (Hab mir schon meine Gedanken gemacht)
Für mich war hauptsächlich die Frage wie groß die feinstrukturierten Bereiche ausfallen werden damit ich es vermeiden kann, das man wenn nicht der Bedarf besteht alle Feinstrukturen überall generiert und gespeichert werden müssen. Sondern nur die in den Größenordnungen in denen Nutzer ihre Zoomkarte erzeugen wollen.
Aber das was Boba über die "Pixelzahl" sagt trifft schon teils recht gut. Wenn man sich auf Google Earth mal anguckt welche Strukturen man auf vollem Zoom out noch sieht bekommt man einen nett erschreckenden Detailgrad. Auf guter globaler Auflösung bräuchte man Punkte mit einem Abstand von grob 8km. Mit Abstrichen könnte man auch auf grob 18 oder 36km gehen.
Die darunterliegende Feinstruktur muss dann mindestens in 1km abstand ihre Punkte haben. Besser wäre noch ein 250m Abstand aber das kommt in Angriff wenn Speicher und Performance das noch zulassen.

An dem Sanguaire angesprochenen Auslagerungssystem arbeite ich grade Auch wenn ich nach Möglichkeiten suche so wenig Speicher wie möglich zu verbrauchen. Aber mir ist auch klar das ich nicht 1,5 GB(aus der Luft gegriffene Zahl) mal völlig egomanisch an Stackspeicher anfordern kann.

Aber so wie viele von euch meinten das man grobe Züge generiert und nur auf Bedarf beim Zoom in oder auf Befehl interessante Bereiche verfeinert(am besten einstellbar) war schon so geplant.
Also das man auch sagen kann die SC´s wollen mal den anderen Kontinent besuchen fahren weil der interessant aussieht und man dann nach Reisezeit bzw Reinzoomen in den entsprechenden Bereich gleich dort weiter machen kann.

Aus diesem Grund versuche ich ja grad anhand eurer Angaben, für die Gebietsgrößen die ihr detailiert braucht, das Optimum für die Aufteilung und Größen der Feinstrukturbereiche auszuloten.

[Sanguaire]

Mit welcher Programmiersprache arbeitest Du. Manchmal kann man sich durch die Wahl der Programmiersprache manche Optimierungen sparen.

Ich hoffe wirklich, das Du nicht soviel Stackspeicher reservierst  . Dynamisch angelegter Speicher landet auf dem Heap  .

[Dark-Star]

hmm dynamisch anlegen oder künstlich den Stack erhöhen. Standardmäßig macht der ja (bei mir zumindest) bei 2 MB dicht wenn man ihn nicht erweitert. Für manche rekursiven Sortierverfahren muss man ja anscheinend den Stack erweitern.

Das war das erste was ich beim Punkte auf der Kugel verteilen umgemodelt habe. Dynamische Speicherplatzverschwendung.

Den ersten Unfug hatte ich Spasshalber in Phyton gemacht.
Bin aber Grad mit C++ am schreiben und werde wohl auch dabei bleiben.
Fortran macht die Numerik zwar nochmal einen tick schneller aber ich hab hier ein paar nette Bücher zu C++ und keine Ahnung wie nett man die Grafikanbindung über Fortran machen kann.

[Sanguaire]

Puh, da hast Du Dir aber etwas vorgenommen. Mit was erstellst Du die Grafikausgabe und das Benutzerinterface?

[Dark-Star]

Das weis ich noch nicht so genau, aber da ich nicht der einzige im team bin, mal sehen.

Bin für die Numerik und damit auch die Grundrechenarchitektur des Programs zustädig. Wollt erstmal das stehen haben.
Die ersten tests werde ich wohl einfach in eine bmp dumpen um zu sehen ob es tun und dann kommt die GUI.
Wäre ja auch blöd wenn die numerik nicht tun will oder es vom Prinzip schon zu Hardwarehunrig würde und man das erst merkt wenn alles andere schon steht.

[Gasbow]

Ich denke es ist sinnvoller ein Modell auf einem feineren Gitter nicht auf dem gesammten Planeten zu berechnen, sondern nur bei bestimmten Regionen.
Möglicherweise wird eine Region dann halt erst später gerechnet, wenn man merkt, dass man dort gerne eine genauere Karte hätte.

Aus reiner Neugier? Was für ein Modell verwendet ihr? (also mathematisch, von Geophysik hab ich keine Ahnung)

[Sanguaire]

Das weis ich noch nicht so genau, aber da ich nicht der einzige im team bin, mal sehen.

Bin für die Numerik und damit auch die Grundrechenarchitektur des Programs zustädig. Wollt erstmal das stehen haben.
Die ersten tests werde ich wohl einfach in eine bmp dumpen um zu sehen ob es tun und dann kommt die GUI.
Wäre ja auch blöd wenn die numerik nicht tun will oder es vom Prinzip schon zu Hardwarehunrig würde und man das erst merkt wenn alles andere schon steht.

Stimmt, aber achte darauf, das deine Rechenbibliothek threadsicher ist. Dadurch bekommst Du anschließend keine Probleme mit dem Userinterface (Blocking und so). Um die Berechnungen zu beschleunigen würde ich die unterschiedlichen Berechnungen auch auf Threads aufteilen (ein hoch auf den Multicore).

[Dark-Star]

Aus reiner Neugier? Was für ein Modell verwendet ihr? (also mathematisch, von Geophysik hab ich keine Ahnung)

Was für ein Modell meinst du? Das Punktverteilungs-/index-modell oder das Modell um die Tektonik nachzuahmen?

Sehr grob gesagt ist die Punktverteilung über ein gestückeltes verfeinertes Ikosaedernetz für das Globale Netz in dem die Tektonik nachgeamt wird. Und dort werden auf bedarf(zoom in) feinere netze eingespannt werden.

Die Platten müssen noch getestet werden aber höchstwarscheinlich wird es darauf hinauslaufen das Plattenumrisse generiert werden, und dann lässt man die driften und guckt mal wo Gebirge, Vulkaninseln ... entstehen. Also grob gesagt das was unsere Erde auch tut
Aber ich will mich für genaue Kentnisse mal durch eine Geovorlesung durchhöhren bevor ich dort murks mache. man hat ja noch ein paar mehr Einflüsse auf Gebirgsaufbau als nur die Plattenverschiebung. Wie z.b. Klima(gletscherwanderung...), Gesteinsarten und warscheinlich noch ne Hand voll.

Sanguaire, da sagst du schon was, muss ich doch mal gucken wie man multithreading implementiert.

Aber an sich seid ihr alle toll.
Ihr schreibt gute denkanstöße aber meine Hauptfrage wie groß ihr bis jetzt eure detailierten Spielgebiete gebaut hat mir bis jetzt nur einer wirklich ne größe dazugeschrieben. Soll zwar frei seitlich erweiterbar sein und zoomstufen unterstützen aber wenn ich keine Idealwerte habe wähle ich nach eigenem ermessen und dann darf sich nachher keiner beschweren.
Ihr kennt es ja warscheinlich auch alle vom Autofahren wenn man grad auf einer Geschwindigkeit ist in der, der eine Gang zu wenig und der nächste zu viel ist. Muss mein Programmgetriebe doch möglichst passend auslegen 

[Sanguaire]

Einfach mal aus der Hüfte geschossen. So groß wie Europa bzw. Kontinent, wobei mir noch nicht ganz klar ist, was Detailliert und nicht Detailliert bei dir heißt.

[Dark-Star]

Gnau versuch ich ja grad rauszufinden aber es entwickelt sich grad. Grob hatte ich ja gemeint.

Auf guter globaler Auflösung bräuchte man Punkte mit einem Abstand von grob 8km. Mit Abstrichen könnte man auch auf grob 18 oder 36km gehen.
Die darunterliegende Feinstruktur muss dann mindestens in 1km abstand ihre Punkte haben. Besser wäre noch ein 250m Abstand aber das kommt in Angriff wenn Speicher und Performance das noch zulassen.

Wenn man auf google Earth unseren kleinsten kontinenten Australien, der auch noch eine maximalausdehnung von 4000km hat, nimmt und so hinzoomt das man nur den sieht entspricht 1 pixel grob 5km Abstand.
Also das wäre noch im Kontinentalmaß.

Auf der kompletten Hawaianischen Inselgruppe hätte man alle 750 m einen Pixel.
Bei Island würde ich auf genau 250m pro pixel kommen.
Das wäre dann detailiert.

Honolulu hätte, als 50km große Struktur pro Pixel 33m.
Da bräuchte ich wohl noch eine Zoomstufe in bergigem Terrain, im Flachland wäre das wohl nicht so schimm wenn man das dort nicht hat
Für Andorra wären es 13m pro Pixel.
Das wäre schon sehr fein. Da wäre aber die frage ob man das noch braucht. Ok mehr ist immer besser .

[Thorgest]

Ich möchte da die Seite www.donjon.bin.sh empfehlen...da gibt es verschiedenste Generatoren für unterschiedlichste Meisterangelegenheiten, von Classic AD&D Dungeonmap bis zum Star Wars Systemmap-generator...ich nutze die Seite seit schon lang und bin als Meister sehr zufrieden ...ist natürlich auf englisch aber das ist für die meisten RPler sicher kein Thema, oder?

[Boba Fett]

Der Link tuts nicht.

[Thorgest]

Sorry, ohne www. gehts...
Korrekter Link: http://donjon.bin.sh/

[rettet den wald]

Die Karte der Runde die ich derzeit leite (Steinzeitsetting) ist etwa 50x50km, also im Vergleich zu einem kompletten Planeten kein besonders riesiges Gebiet.

Anmerkung: Ich hab bereits einen Weltgenerator auf Basis von Ikosaeder-Unterteilung programmiert (in C#), bin aber nicht besonders weit gekommen. Kein Bitmap-Output, keine Plattentektonik, keine Klimazonen, etc. Einfach nur die Oberflächengeometrie einer Kugel, mit zufällig bestimmten Abweichungen. Dann hab ich aufgegeben und was anderes gemacht, weil der Speicherbedarf zu hoch wurde, und ich keine Ahnung habe wie ich das einschränken könnte.

[Skeeve]

Den ersten Unfug hatte ich Spasshalber in Phyton gemacht.
Bin aber Grad mit C++ am schreiben und werde wohl auch dabei bleiben.
Fortran macht die Numerik zwar nochmal einen tick schneller aber ich hab hier ein paar nette Bücher zu C++ und keine Ahnung wie nett man die Grafikanbindung über Fortran machen kann.

Nur um es mal zu erwähnen: Ich suche ja immer noch Unfug um mal etwas mit Stackless Python rum zu spielen (für die Numerik dann mal schauen ob NumPy auch mit Stackless Python zusammen arbeitet).

Aber weil ich eigentlich gerade meine Fantasy-Kampagne weiterbaue, komme ich wohl derzeit nicht zum programmieren...