Beiträge von Klamann

Zitat von Benignus123

Ich starte dieses geniale Programm. Nehm mir einen beliebigen Kartenausschnitt Von 8x8 und "push" Rendern.
Speichere die Karte Im korrekten Ordner.

Starte CIM2 und finde diese dann im Karteneditor vor und starte sie.
Dann blicke ich auf eine Wasserlandschaft.
Der Kartenausschnitt ist aber ein Teil von Berlin.

Kannst du bitte deine Logdatei posten? (Anleitung im ersten Post). Ich würde mal auf einen Fehler beim Height offset tippen, kannst du das Häkchen neben "auto" aktivieren und nochmal rendern?

Zitat von Tomdresden

Egal was ich da eingebe, die Karte verschiebt es immer nach Oben.

Hm, also du meinst obwohl dein Kartenausschnitt bei x Metern liegt, wird auf der tatsächlichen Karte eine Höhe von mehr als x angezeigt? Das ist wirklich ungewöhnlich. Bitte poste doch auch deine Logdatei, dann sehe ich mir das mal an.

Zitat von GT670DN

Wenn irgendwann die OpenSource-Version rauskommt plane ich .osm Dateien direkt einlesbar zu machen,also kann man fiktive Karten schonmal vorplanen als Textdatei. Die werden dann eigelesen und verarbeitet.

Guter Gedanke, sollte technisch jedenfalls nicht allzu schwer umsetzbar sein, von den Overpass-Servern bekomme ich ja auch nichts anderes als OSM XML Dateien, die auf Festplatte zwischengespeichert und dann eingelesen werden. Mit einem Tool wie JOSM eine fiktive Karte zu planen ist eigentlich eine ziemlich gute Idee

vanos, Samsonxxx
Vielleicht sollte ich noch ein tutorial zur Bedienung schreiben oder so, hier mal die Kurzfassung:

• Der Wert "Height offset" bestimmt genau den Höhenversatz, also z.B. ein offset von 500 würde eine Karte um 500m nach unten versetzen (negative Offsets, also nach oben verschieben, sind nicht möglich).
• Standardmäßig ist das Häkchen "auto" neben dem height offset aktiviert, diese Option kann ich jedem nur wärmstens empfehlen: Damit wird vom Programm das offset so ermittelt, dass der niedrigste Punkt der Karte auf 0m gesetzt wird. Hat man also eine Karte die von 600m bis 800m reicht, wird das height offset automatisch auf 600m gesetzt und die Karte reicht dann ingame von 0 bis 200m.
• Mit dem "height scale" kann man das Ausmaß der Erhöhungen bestimmen. Für eine 8x8km Karte ergibt ein height scale von 100% maßstabsgetreue Hügel und Täler. Kleinere Werte flachen alles ab, höhere Werte erzeugen größere Berge. Wer eine realistische Karte mit mehr als 8km erstellen möchte, sollte auch beachten, ggf. das height scale anzupassen. Für eine 16x16km Karte wäre der maßstabsgetreue Wert bei 50%.

Zitat von mediziner

Die Flusslandschaft bestand nur aus kleinen Wasserkratern. Ich wollte das Terrain um ca. 10m versetzen, um die Krater verschwinden zu lassen und Flüsse per Hand einzuzeichnen.

Das wird leider nicht funktionieren, wie gesagt, normalerweise ist es erwünscht, wenn das Meer erhalten bleibt, und auch beim Skalieren soll die Wassertiefe ja nicht abgeflacht werden.
Ich denke die beste Lösung für dich wäre, im Karteneditor das Abflachentool so groß und stark wie möglich einzustellen und einmal ordentlich drüberzubügeln. CiM 2 merkt sich ja alle Texturen, auch die die ursprünglich unter Wasser waren. Damit solltest du die Karte recht schnell so hinbekommen, wie sie in Wirklichkeit aussieht.

Wegen des Abbruchs: Aus dem Log ist kein Fehler erkennbar, d.h. das Programm rattert bei dir noch. Möglich wäre ein Speicherproblem, d.h. wenn du nur wenig Arbeitsspeicher frei hast wird etwas auf Festplatte ausgelagert und da das Rendern der Karte ein Problem mit mindestens quadratischer Komplexität ist, würde das den Vorgang extrem bremsen. Du versuchst da schon eine recht große Stadt im Maßstab 2:1 zu rendern... probier mal mindestens 512MB oder besser 1GB Speicher für maps4cim freizuräumen oder schau ob das Problem auf kleineren Karten oder mit niedrigerem Detailgrad auftritt.

Zitat von vanos

Wenn ich eine Karte rendern lasse, und anschliessend Flüsse erstellen will, ist deren Wasser immer so tief unten bzw. es entstehen riesige Abhänge zwischen Ufer/Wasser.

Wie schon gesagt: Cities in Motion 2 kennt keine Flüsse und Seen, nur Meer. Du wirst nie Wasser über 0m Höhe bekommen.

Zitat von immi

Wäre evtl hilfreich den Maßstab noch irgendwo im UI anzuzeigen, oder im Tooltip darauf hinzuweisen, dass der gewählt Kartenausschnitt immer auf eine 8x8km Map raufgepflastert wird.

Ich setz das mal auf die todo-Liste, wäre wohl wirklich sinnvoll wenn der Mapper sich dessen auch wirklich bewusst ist...

Zitat von Satan

Scheinen also Downloadprobleme zu sein, nach dem Programneustart hats ja dann geklappt.

Da der Download sofort abgebrochen hat, würde ich mal auf Firewall tippen. Aber dann wäre das ja geklärt.

Zitat von mediziner

- Kartenumfänge von mehr als 8x8 km führen leider zu endlosem Rendern bei mir. (Details auf 20, da 10 nicht mehr akzeptiert wird.)
- Flüsse in Küstennähe werden nicht unbedingt korrekt gerendert
- Verändern der Höhe führt zu schmalen "Deichen" rund um die Wasserstellen. Die Wasserstellen werden nicht mitversetzt.

- wo bleibt das Programm stehen? Kannst du deine logdatei posten?
- Meinst du die eingezeichneten Flüsse, oder die tatsächlichen Erhebungen? Im 1. Fall liegt das oft daran, dass ich meinen eigenen Renderer schreiben musste und der noch nicht wirklich mit Relationen und Multi-Polygonen umgehen kann (sehr große Flächen wie Wälder, Seen und Flussläufe werden daher teils nicht angezeigt). Im 2. Fall sieht man an Küsten oft Wasserlöcher im Boden, das sind Ungenauigkeiten im SRTM-Datensatz, die muss man leider manuell ausgleichen
- Das ist auch so gewünscht: Im SRTM wird nur Höhe 0 als Wasser gespeichert, alles darüber ist Land. Wenn du jetzt ein Offset angibst, das das Wasser "anheben" würde, würdest du eine große ebene Landfläche erzeugen. Daher wird das Wasser standardmäßig auf -30 oder so gesetzt, offset und scale werden anschließen nur auf alles >0 angewandt.

Zitat von vanos

Wasserflächen werden nicht erstellt. Ist das normal?

Kommt auf das Wasser an. Meerwasser wird schon erstellt, Seen und Flüsse gibt es in CiM 2 leider nicht, d.h. kein Wasser über 0m Höhe. Echt schade eigentlich, hätte gerne eine Karte mit Walchensee und Kochelsee erstellt, aber dann wäre der Walchensee leider ein 100m tiefes Loch (Ness)...

Bitte immer die Logdatei (maps4cim.log) oder Auszüge daraus posten, mit "Error" kann ich leider auch nichts anfangen.

Zitat

Du findest die Log-Datei unter:
Windows: %APPDATA%\maps4cim\
bei allen anderen Betriebssystemen liegt die Datei im Ordner .maps4cim in deinem Home-Verzeichnis. Falls der Ordner nicht angezeigt wird, muss du die Anzeige von versteckten Dateien aktivieren.

Falls du auf Windows bist, dieses %APPDATA%\maps4cim\ kannst du einfach in die Textzeile vom Windows explorer einfügen, er öffnet den richtigen Ordner dann automatisch

@norlas
Zieh die Straßen nicht gerade von einem Ende der Karte zum Anderen, in der Realität wird auch kaum eine Straße exakt gerade gebaut. Und die SRTM-Daten sind auch nicht immer perfekt
Im Karteneditor färbt sich die Straße gelb, wenn eine Straße den Boden schneidet, dann einfach vorher absetzen und weiterbauen.

Aufrechtgehn
Die JAR-Datei sollte sich auf den meisten Betriebssystemen einfach per Doppelklick starten lassen, das ist das Programm. Wo du es ablegst, ist egal - das JAR muss nicht ins Spielverzeichnis. Wenn es nicht startet, schau mal hier und installier dir ggf. Java: http://www.java.com/verify
Der richtige Ordner um die Karten abzulegen wurde schon vorhin gepostet: *klick*

vanos
Das Rendern dauert je nach Karte und Rechner zwischen 2 und 15 Sekunden, würde ich sagen. Etwas mehr Zeit dauert das Laden der SRTM-Daten (ca. 30 Sekunden), die mit Abstand meiste Zeit wartet man aber auf die Bereitstellung und den Download der OpenStreetMap-Daten, da vergehen in der Regel zwischen 30 und 180 Sekunden...
Die Daten werden aber auch gecachet, d.h. die SRTM-Daten musst du nur einmal laden und auch die OpenStreetMap Daten werden nicht nochmal bezogen, wenn du die exakt gleiche Region z.B. mit anderer Höhenskalierung renderst.

Zitat von Tomdresden

Als ich das schon platziere Feld gerendert habe, gab es keine Problem, als ich jedoch das Feld verschoben habe (auf Dresden) und gerendert habe, stand im Spiel die Karte komplett unter Wasser.

Kannst du mir die genauen Koordinaten von Punkt 1 und 2 nennen? Ist das Problem wieder aufgetreten, wenn du das Programm neu startest und gleich mit Punkt 2 startest?

Zitat von immi

gibt vermutlich einen Haufen Leute die sich freuen würden, wenn du das Programm auch im offiziellen Forum präsentierst

Ich will auf jeden Fall noch ein wenig mehr Werbung für das Programm machen, aber das kommt alles in den nächsten Tagen noch... jetzt bin ich erstmal froh dass der Thread hier nicht schon voller Bugreports ist - was nicht heißen soll dass ich sie nicht lesen möchte!

Danke schonmal für das positive Feedback

Zitat von AlexanderN

Um Flüsse/Seen zu unterstützen könne mandoch evtl das ganze Terrain höher/tiefer setzen, da ja bei CiM immer auf der Höhe 0 der Wasserspiegel liegt, oder nicht ?

Klar, das wäre möglich, aber nur mit Einschränkungen:
Die Karten werden nach Standardeinstellung so erzeugt, dass der tiefste Punkt bei 0 Metern liegt. Aber: In der Regel hat man kein absolut flaches Terrain, und angenommen es fließt ein Gewässer von 50m Höhe zu 0 Meter: Bei 0 Meter kann man recht Problemlos auf -10 gehen, aber wenn man dann von 50 Meter eine Klippe und dann plötzlich -10 hat, sieht das nicht gut aus. Bei mehreren Flüssen in verschiedenen Höhenlagen wirds noch schlimmer.
Bei Seen dürfte das einfacher sein, aber in der aktuellen Programmarchitektur ist nicht vorgesehen, Erhöhungen basierend auf den Straßenkartendaten zu verändern (siehe planned features) - das wäre einfach noch ein wenig Arbeit.
-> es wäre recht aufwändig das alles zu implementieren und die Ergebnisse oft eher unschön. Da überlasse ich es lieber den Nutzern, die Flüsse manuell abzusenken, wenn sie es denn so möchten.

Release!
Hier geht's weiter:

[Beta] maps4cim - a real world map generator for CiM 2

topic in english language @ cimexchange

maps4cim ist ein Kartengenerator für Cities in Motion 2, welcher CiM2-Maps basierend auf einem real existierenden Ausschnitt der Erde erstellt. Die nötigen Quelldaten für das Relief und die Straßenkarte werden dabei nach Bedarf aus dem Internet geladen, aus freien Datenquellen. Die Erhöhungen werden direkt in die Karte integriert, alle weiteren Daten (Straßen, Wälder, Flüsse, Gebäude) werden auf die Bodentextur gezeichnet, so dass sie im Karteneditor dann nachgebaut werden können. Folgende Datenquellen werden genutzt:

• SRTM: Erhöhungen der Erdoberfläche in einer Auflösung von ca. 90x90 Metern pro Datenpunkt. Die Daten kommen direkt von den Servern der United States Geological Survey (besten Dank dafür!)
• OpenStreetMap: Freie Kartendaten, welche die Grundlage für die Texturen bilden, die auf die Karte gezeichnet werden. Die jeweiligen Kartenausschnitte werden von den Overpass-Servern geladen (mit freundlichem Dank an die Betreiber!)

Public Beta

maps4cim befindet sich in der öffentlichen Beta-Phase. Bitte probiert das tool aus, spielt damit herum und meldet alle Probleme, die ihr finden könnt. Da ich ab Juli im Ausland bin, haben wir noch eine Woche Zeit, die gröbsten Bugs zu beseitigen, danach wird die Entwicklung vorerst für eine Weile ruhen. Es wird aber definitiv noch ein Sourcecode-Release unter einer freien Lizenz geben, damit jemand anderes bei Bedarf das Programm weiteretwickeln kann.

Bugs & Features

Wer Fehler melden oder Verbesserungsvorschläge machen will, bitte zuerst überprüfen ob das Thema nicht schon notiert wurde!

Known Limitations
* No rivers

Known Issues
* Overlap at -180°, 180° -> not possible, Overpass rejects requests
* Broken Polygons (mostly when relations are involved)
* Missing support for multi-polygons
* Interpolation of gaps in SRTM dataset sometimes create ugly results

Planned Features (eventually)
* HeightScale: auto
* Relief-Changeset based on OpenStreetMap data (e.g. for rivers)
* Analyze Prefix: Name, Date, Map-thumb, ...
* Support for some Relation types within OSM data: multipolygon (inner/outer)
* Improved interpolation of missing relief data

Not planned Features
* Create ingame objects (roads, buildings, ...) from OpenStreetMap data

Wie Fehler melden?

Wenn dir etwas ungewöhnliches auffällt oder etwas nicht klappt, beschreib bitte Schritt für Schritt so genau wie möglich, was man machen muss, um den selben Fehler zu bekommen.

Wenn es ein Problem beim Generieren der Karte gibt, füge bitte deinem Post die maps4cim.log-Datei bei. Du kannst die letzten 100 Zeilen kopieren und in einen spoiler-Block einfügen oder die Datei einfach als Anhang deinem Post beifügen (am besten zip-komprimiert).

Du findest die Log-Datei unter:
Windows: %APPDATA%\maps4cim\
bei allen anderen Betriebssystemen liegt die Datei im Ordner .maps4cim in deinem Home-Verzeichnis. Falls der Ordner nicht angezeigt wird, muss du die Anzeige von versteckten Dateien aktivieren.

Lizensierung

Grundsätzlich dürft ihr mit den generierten Karten anfangen was ihr wollt. Da die Karten aber auch auf Daten der OpenStreetMap beruhen, müsst ihr dafür einen kleinen Hinweis hinterlassen, wenn ihr die Karte öffentlich zum Download anbietet. Die SRTM-Daten hingegen sind lizenzfrei, und auch ich verlange keinen Hinweis auf maps4cim. Die kürzeste Variante wäre z.B.

Zitat

Based on data from the OpenStreetMap (© OpenStreetMap contributors).
Basierend auf Daten aus der OpenStreetMap (© OpenStreetMap Mitwirkende).

Die verwendete Sprache ist euch freigestellt, eine Übersetzung muss nicht mitgeliefert werden.
Wenn ihr andere auf maps4cim aufmerksam machen wollt, könnt ihr gerne folgenden Hinweis hinterlassen

This map was created using [url='http://www.nx42.de/projects/maps4cim/']maps4cim[/url], with data from the [url='http://www.openstreetmap.org/']OpenStreetMap[/url] (© OpenStreetMap contributors) and the [url='http://www2.jpl.nasa.gov/srtm/']SRTM[/url].
Diese Karte wurde erstellt mit Hilfe von [url='http://www.nx42.de/projects/maps4cim/']maps4cim[/url], mit Daten aus der [url='http://www.openstreetmap.org/']OpenStreetMap[/url] (© OpenStreetMap Mitwirkende) und der [url='http://www2.jpl.nasa.gov/srtm/']SRTM[/url].

Downloads

• maps4cim (plattformunabhängig), 5.6 MB

Voraussetzungen: Installierte Java Runtime 6 oder höher.

Viel Spaß beim Mappen!

Zitat von pasadio3

Wie wird es aussehen, wenn eine Stadt (z.B. Mainz) auf einer Grenze des SRTM-Datensatzes liegt?

Die SRTM-Datensätze lassen sich problemlos zusammenfügen, auch Orte die auf glatten Koordinaten liegen (z.B. 47.0,11.0), welche ja dann 4 SRTM-Tiles benötigen würden, lassen sich erstellen. Ich hab schon Karten bestehend aus 9x9 tiles erstellt, aber da passt dann der Maßstab nicht mehr so ganz
Also kurz: Es lassen sich Karten völlig unabhängig von den Koordinaten erstellen.

Gute Nachrichten: Es wird diesen Monat noch ein Release geben, wahrscheinlich sogar mit einer rudimentären Nutzeroberfläche, damit ihr euch nicht mit der Konsole rumschlagen müsst
Der Grund dafür ist auch einem Zeitlimit geschuldet, dem ich mich beugen muss; ich bin ab Juli im Ausland und kann mich da nur noch wenig um die Weiterentwicklung kümmern. Fehler sollten daher möglichst früh gemeldet werden, damit ich sie noch vor der Abreise ausbügeln kann, ab Juli wird die Latenz diesbezüglich wohl wesentlich höher werden.

Die Kernfunktionen des Kartengenerators sind jetzt implementiert, d.h. man kann unter Angabe von Koordinaten sich eine fertige CiM2-Karte ausspucken lassen, die Downloads der nötigen Geodaten laufen automatisch ab. Also, noch ein wenig Geduld, dann kann der Spaß losgehen.

Gegen eine Portierung auf CiM 1 sollte technisch nichts sprechen, denke ich, allerdings habe ich da kein Interesse dran, da
- CiM 1 allein wegen der beschränkten Straßentypen nie reale Straßenkarten erlauben wird
- ich zu wenig Freizeit für so ein zeitintensives Projekt habe
- ich CiM1 sowieso nicht mehr spiele ;D
Aber da ich wohl das Programm samt Sourcecode veröffentlichen werde, kann sich ja jemand anderes dran versuchen.

Zitat von Steinlaus

wird es auch die möglichkeit geben die größe des kartenausschnitts zu verändern?

Ich kann jetzt schon Karten mit beliebigen Abmessungen erstellen, das Limit dürfte da eher die Kapazität der Server sein, von denen die eigentlichen Daten kommen, und natürlich der Sinn des Unterfangens, weil es irgendwann dann doch zu klein auf der Map wird ;D
Ich würde ein soft Limit mal bei ca. 50x50km ansetzen, mit abgespecktem OpenStreetMap-Download (nur Hauptverkehrsverbindungen) sollten sogar bis zu 200x200km in akzeptabler Zeit möglich sein - wer das denn möchte. Aber wie gesagt, das braucht noch ein wenig...

Guten Abend,
ich habe in den letzten Wochen lange Abende an meinem Kartengenerator gebastelt und erste einigermaßen ansehnliche Ergebnisse bekommen.
Aber seht selbst - hier findet ihr exemplarisch meine Heimatstadt Freising (siehe Kartenausschnitt

Freising-alpha1.zip (4,6mb)
Freising-alpha1.7z (2,5mb)
(wegen Verwendung von Daten aus der OpenStreetMap stehen die Dateien unter den Bedingungen der ODbL)

Sämtliche Markierungen auf der Oberfläche kommen aus der OpenStreetMap, dazu gehören Straßen, Eisenbahnlinien, Flüsse und Gebiete (Feld, Wald, Weide). Das Relief basiert auf dem SRTM-Datensatz der NASA. Die Karte ist nicht im Maßstab verkleinert, sondern wurde 1:1 mit Daten aus der echten Welt gefüttert; die ingame-Kartengröße von 8x8 km wird damit voll ausgenutzt.

Die Karten lassen sich mit meinem Generator aktuell in ca. 8 Sekunden generieren (abzüglich Downloadzeit), allerdings sind wichtige Programmteile wie der Download der Quelldaten nicht automatisiert und überhaupt braucht das Programm noch einiges an Pflege, ein Release wird also noch eine Weile dauern (und auch dann wird es nur eine Kommandozeilen-Version geben).

Ich hoffe es gefällt

So, der erste Versuch eines Terrain-Modells, basierend auf SRTM-Daten (Anahng ist mittlerweile zu groß fürs Forum):
N47E011.7z

Die karte zeigt den Ausschnitt zwischen (47,11) und (48,12) Grad, das ist folgender Ausschnitt:
OpenStreetMap

Die Löcher in den Bergen sind Lücken im Datensatz, ich arbeite gerade an Möglichkeiten, die irgendwie "wegzuinterpolieren". Auch mit der Skalierung bin ich noch nicht wirklich zufrieden. Das fällt bei der großen Fläche vielleicht nicht so auf, aber eine reale Karte soll letztendlich 8x8km und nicht 100x70 haben
Wer sich schonmal ein wenig mit bikubischer Interpolation beschäftigt hat, ich würde mich über Hilfe freuen:
java - Scale 2D-Array using Bicubic Interpolation - Stack Overflow

Gerade hab ich wieder ein wenig daran weiter gearbeitet, hab aber im Moment einfach wenig Zeit. Ich habe eine Abstraktionsebene entwickelt, die aus 2049x2049er Matrizen mit Werten zwischen -1048,5 und +1048,5 die Reliefs generiert. Das gleiche Schema gilt für die Texturen (2048x2048er Matrix), wobei man die Werte für die Texturen jetzt einfach über ein enum abrufen und auch mischen kann, z.B. mit Textur.ROUGH_GRASS.draw(alpha).
Das Tool soll definitiv entwicklerfreundlich sein, auch daher braucht es ein wenig Zeit.
Der nächste Schritt wäre dann natürlich ein einfach zu bedienendes Frontend, damit man sich eine eigene Karte auswählen und generieren lassen kann.

Zu den Datenquellen:
Die topographischen Daten bekommt man nicht aus der OpenStreetMap, ich wollte dafür auf den SRTM-Datensatz zugreifen. Die Daten sich leider nicht so umfangreich wie ich mir das gewünscht hätte (ein Datenpunkt deckt bis zu 90x90m ab), aber dafür sind die Daten praktisch weltweit verfügbar. Wenn jemand einen genaueren, frei verfügbaren Datensatz kennt, ich würde mich sehr über einen Hinweis freuen
Bathymetrie (Topographie des Meeresbodens) interessiert mich nicht primär, aber auch da wäre mindestens ein Datensatz verfügbar.

Die Kartendaten aus der OpenStreetMap möchte ich über die XAPI herausholen. Vorteil gegenüber der normalen API: Nur Lesezugriff, Filterfunktion, Server akzeptieren auch große Gebiete, kein hartes Trafficlimit.

Also, es geht voran, aber alles zu seiner Zeit. Noch kann ich keine CiM2-Maps aus den frei verfügbaren Kartendaten generieren.
Sobald eine gewisse Grundstruktur steht, werde ich auch über ein Quellcode-Release nachdenken.

Zitat von immi

Woher kommt die Limitierung auf 25bit Werte bei 32bit Integerzahlen (wenn ich dass richtig sehe)? Akzeptiert die GameEngine einfach keine höheren Werte? Nicht dass das groß ne Rolle spielt, 1km hohe Berge sind für den Nahverkehr völlig ausreichend, bin nur neugierig.

Ich nehme mal an die Entwickler haben die Höhenwerte einfach als 32bit Integer gespeichert und sich nicht weiter um die Effizienz des Formats gekümmert. Insgesamt ist das Dateiformat sowieso nicht als besonders sparsam zu betrachten, allein dass die Erhöhungen und Texturen unkomprimiert gespeichert werden ist völlig unnötig. Die von mir hochgeladene Map bekomme ich mit 7zip auf gute 100kb, da ist also einiges Einsparpotential vorhanden.

Es würden sogar 20bit-Zahlen (bzw. 21bit für positiv/negativ) ausreichen, geringfügig größere und kleinere Werte werden einfach ignoriert (also auf die maximal erlaubte Höhe bzw. Tiefe gekürzt). Ich habe aber auch einmal eine Map erstellt, die komplett unter Wasser war, weil ich versehentlich einen Wert eingetragen hatte der weit außerhalb des darstellbaren Bereichs liegt, also damit sollte man nicht zu viel Blödsinn treiben

Zitat von immi

Man könnte auch sagen die Höhe wird in Millimetern gespeichert.

Stimmt daran hatte ich gar nicht gedacht
Im Editor wird die Höhe in Meter auf bis zu 3 Nachkommastellen angezeigt, also dachte ich mir ich halte mich einfach daran. Ist auch intuitiver, finde ich.

Jetzt konnte ich es mir doch nicht nehmen lassen, mit dem Bau eines Kartengenerators anzufangen... Ein erstes Ergebnis (siehe Anhang).

Header und den Gameobject-Stub wurden aus einer leeren Karte extrahiert, Erhöhungen und Bodentexturen sind selbst generiert. Mein Skript kann somit schon auf Knopfdruck valide Karten ausspucken

Hi, ich würde mich auch gerne in die Diskussion einklinken

Da sich ja schon ein paar Leute fleißig in den Programmablauf und die Bundles hacken, dachte ich mir ich sehe mir die Karten ein wenig genauer an. Mir gefallen die Möglichkeiten der rasterfreien Kartengestaltung, ich glaube CiM 2 könnte das erste Spiel sein in dem man ein Verkehrsnetz für eine (Klein)Stadt maßstabsgetreu nachbauen kann.

Mein Gedanke ist daher, ein Grundgerüst aus frei verfügbaren Kartendaten, z.B. OpenStreetMap, zu generieren, bestehend aus
* Heightmap
* bestimmten Bodentexturen, die den Verlauf von Straßen, Bahntrassen, Flüssen etc. nachbilden
* Bodentexturen wären auch für Gebiete denkbar (besiedelt, Ackerland, Wiese, Wald...)
* Wahrscheinlich nicht leicht machbar, aber denkbar wäre auch, Objekte zu generieren: Bäume, Gebäude, Straßen

Mit dem letzten Punkt rechne ich nicht wirklich, da das Objektformat nur schwer aus den Maps zu lesen ist und z.B. gewisse reale Straßenverläufe im CiM 2 nicht nachgebildet werden können. Außerdem ist die Verknüpfung der Straßen alles andere als trivial. Um eine reale Gegend 1:1 nachzubauen dürfte aber eine korrekte Heightmap und Markierungen für sämtliche Straßen völlig ausreichen.

Nun hab ich mich für ein paar Stunden in den Hex-Editor gehängt und das *.map-Format ein wenig analysiert...

Grundaufbau:
* Header: dynamisch, relativ kurz
* HeightMap: statisch, 16.793.604 Byte (2049 * 2049 * 4)
* TextureMap: statisch, 16.777.216 Byte (2048 * 2048 * 4)
* GameObjects: dynamisch

Header:
Der Header beginnt mit dem String "GameState+SerializableMetaData" und enthält ein paar Metadaten wie den Namen der Map, sowie ein PNG-Bild der Minimap (binär codiert). Am Ende des Headers findet sich nach einigen Nullen der String "GameState+SerializableTerrainData" und darauf die Reihenfolge der verwendeten Texturen.
Viel genauer hab ich da noch nicht reingeschaut, sind sicher noch ein paar wichtige Daten drin versteckt.

HeightMap:
Wie genau man den Einstiegpunkt findet, weiß ich leider nicht, nur so viel: Nach der "SerializableTerrainData" kommt eine Reihe von Nullen und wenn die erste Ecke nicht auf Höhe 0 ist, kann man den ersten Eintrag != 0 als Startpunkt wählen.
Die Heightmap ist eine statische, unkomprimierte Matrix (deshalb kann auch keine Map <32MB werden, je 16MB entfallen nämlich immer auf die Heightmap und Texturmap).
Jede Zeile besteht aus 2048 Feldern, aber die Heightmap wird über ihre Kanten definiert, daher stehen uns je Zeile 2049 Werte zur Verfügung. Mit 2049 * 2049 Werten zu je 32 bit kommen wir auf 16.793.604 Byte, was ca. 16MB entspricht.

Die Höhe wird in Werten von - 1.048,575 bis + 1.048,576 angegeben, im Spiel werden dann Höhenmeter daraus. Wir können also Berge mit bis zu 1km Höhe, bzw. Ozeane mit 1km Tiefe anlegen (aber praktisch keine Flüsse ;(). Die Zahlen werden einfach als 32bit signed Integer (little Endian) gespeichert. Um jedoch auf die spielinternen Höhenmeter zu kommen, wird an der drittletzten Stelle ein Komma eingefügt.

Zwei Beispiele:
06 b5 01 00
Als 32bit Integer interpretiert wird die Zahl 111877 daraus, mit den Komma vor der drittletzten Ziffer kommt man auf 111,877 m Höhe.
34 cf fc ff
Dieser Wert als signed Integer ergibt -209100 oder spielintern 209,1 m unter dem Meeresspiegel.

TextureMap:
Direkt auf die HeightMap folgt die TextureMap, diesmal nur mit 2048 x 2048 Einträgen, weil Flächen, nicht Kanten, definiert werden.
Zunächst etwas Grundwissen: Vielleicht ist dem ein oder anderen schon aufgefallen, dass es im Mapeditor nur 4 Texturen gibt. Das hat seinen Grund: Das aktuelle Kartenformat unterstützt nämlich nur die Verwendung von 4 Texturen. Eine Karte besteht immer aus einer Basistextur mit 100% Deckkraft. Auf diese können die anderen 3 Texturen mit beliebiger Deckkraft hinzugemischt werden. Daneben gibt es noch zwei Spezialtexturen: Den Betonboden aus den Städten und ein schwarzes Nichts (wozu auch immer das gut ist...)

Zurück zum Format; auch hier besteht jeder Eintrag aus einem 32-bit Wort mit folgender Belegung:
Byte 1, 2 und 3 geben jeweils die Deckkraft der 3 Nicht-Basistexturen an (Werte von 0 bis 255 werden übersetzt in 0% bis 100%)
Byte 4 bestimmt über die Basistextur mit einem recht eigenartigen Verhalten
- Werte unter 0x50 erzeugen das schwarze Nichts, je kleiner der Wert desto größer ist der schwarze Fleck auf dem Quadranten
- Werte über 0xa erzeugen den versiegelten Boden mit braunem Rand. Auch hier gilt: Je größer der Wert desto größer die ausgefüllte Fläche. Alle Werte dazwischen erzeugen die Basistextur mit 100% Deckkraft.

Nach exakt 16.777.216 Byte ist auch der Spaß vorbei und es geht weiter mit den

GameObjects:
damit hab ich mich noch gar nicht auseinandergesetzt, sry ;D

Also, was lässt sich damit anfangen?
- Heightmaps lassen sich aus frei verfügbaren Kartendaten generieren
- Bodentexturen können auch an beliebiger Stelle gezeichnet werden, die Auflösung (jedes Feld hat 4x4 Meter) ist auch hoch genug, um Straßen zu tracen.
- Die Spielfläche ist mit 8x8 km (also 64km^2) groß genug, um kleinere Städte maßstabsgetreu wiederzugeben.

=> einer Simulation von real existierenden Städten steht damit nichts mehr im Weg

Ich hab schon Ideen für einen Karten-Generator der mit OpenStreetMap-Daten arbeitet, aber bis da produktive Ergebnisse rauskommen wird wohl noch ein Weilchen vergehen.