Beiträge von mrecht1

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Kann man eigentlich ein dreck-mesh für die KI erstellen? Denn für sowas kann man ja auch eine Schneetextur anlegen. Im Citybus M301 DLC wurde das ja gemacht. Entsprechend gut sieht dieser im Schnee aus.


    Du meinst für die KI-Fahrzeuge? Wenn die ein Dreckmesh irgendeiner Art bekämen wäre es, denke ich, aus mit jeder Performancefreunlichkeit, da dann einfach nochmal mehrere hundert Faces pro Fahrzeug und eine zusätzliche Textur mitgeladen werden müsste. Gerade bei KI-Fahrzeugen bin ich da sehr vorsichtig, weil die ja zigfach auf jeder Kachel auftauchen.

    Das geht schon, nur nicht mit Dreckmesh sondern mit Schneetextur für die Autos.

    Ich habe das mal eben provisorisch getestet. Die beschmierte Textur des Mercedes liegt Unterordner texture/WinterSnow.

    Die Textur wird auch auf fahrende Ki-Fahrzeuge angewendet.

    Die Autos müssen ja nicht langsam Dreckig werden, wie das Spielerfahrzeug. Eine Schneetextur, die dauerhaft dreckig ist oder auch an einigen Stellen einen Schneebelag z.B. der Front darstellt wäre doch völlig ausreichend.

    Man muss in der Simulator-Szene nur aufpassen, dass man die Langzeitmotivation erzeugt. Die meisten großen Simulatoren, sei es nun der Landwirtschaftssimulator, ETS oder auch DTGs Zugsimulatoren, versuchen das über einen stetig wachsenden Umfang, wobei hierbei dritte immer eingebunden werden. The Bus wird nur mittelfristig erfolgreich sein können, wenn man das Modding zulässt, ob nun durch Jedermann oder durch kommerzielle DLC-Entwickler ist dann nochmal eine andere Frage.

    Ah ja, da sind wir wieder am Rande der Darstellungsmöglichkeiten von gekachelten Oberflächen.


    Ich würde dir folgendes empfehlen:

    Die untere Fläche zum Quadrat machen, indem du sie um eine Ecke in die obere Fläche erweiterst, dann die Textur der Fläche so mappen, dass an den Kanten zur oberen Fläche Fugen sind. Die obere Fläche wird dann etwas mehr unterteilt.


    In etwa so:

    Die Funktion ist denke ich gar nicht das riesen Problem. Ich hab mal ein bisschen mit den Einstellungen experimentiert und selbst wenn man "Eye adaption" deaktiviert und auch das damit verknüpfte "Auto Exposure" ist die Welt immer noch massiv überbelichtet. Ich habe allerdings keine Möglichkeit gefunden daran in den Cofig Dateien etwas zu ändern.

    Ja, da bin ich auch noch mit am hadern. Einerseits sind bestimmte Effekte blöd eingestellt, andererseits sind wir seit Ewigkeiten nur Diffuse-Maps gewöhnt und keine Reflektionen. Mir gefällt z.B. der Boden auf den neuesten Screenshots nicht wirklich, der ist zu gleichmäßig hell. Mit den gegebenen Techniken wird es aber auch schwierig das Licht präzise genug zu berechnen. Entweder schummelt man jetzt oder schraubt die Reflektion des Bodens komplett runter, das sieht aber auch wieder unrealistisch aus.

    Das was du ansprichst wird wohl im Karteneditor direkt eingestellt werden. Mal sehen, was da so möglich sein wird.


    Die bisher gezeigten Editoren sehen jedoch echt brauchbar aus. Gerade sich Umläufe so zusammenklicken zu können ist sehr viel angenehmer als die Möglichkeiten im Omsi.

    Also bleibt am Ende die Frage, ob man sich die Mühe machen wird zwischen MP-fähigen Karten und World Composition Karten zu unterscheiden. Wünschenswert wäre es durchaus. Ich sehe bei Überlandkarten auch nicht einen so großen reiz an einem MP wie in der Stadt, da man sich schlichtweg viel seltener begegnet und weniger Umläufe auf einer Linie unterwegs sind.

    Die Aussage "20 km²" lässt tatsächlich sehr viel Spielraum. Sind damit 20 km² tatsächlich bebauter Bereich gemeint oder die maximale Ausdehnung der Karte?

    Um das beantworten zu können müsste man wissen, wie eine Karte grundsätzlich aufgebaut ist, also als "großes Ganzes" oder in Kacheln (erscheint wahrscheinlicher). Die 20 km² könnte man im zweiten Fall auf eine maximale Anzahl an Kacheln übertragen.

    Ich habe gerade mal abgeschätzt, dass der in Berlin dargestellte Bereich vom Flughafen Tegel bis zur Indira-Gandhi-Straße etwa 12,5 km Ost-West Ausdehnung hat und von Tegel bis zur Schillstraße etwa 5,5 km Nord-Süd-Ausdehnung. Das wären etwa 70 km² Gesamtausdehnung. Da Gil im verlinkten Video explizit die Beziehung Betriebshof-Tegel als fahrbar nennt, erscheint die Gesamtausdehnung als limitierender Faktor als unwahrscheinlich.

    Interessant, dass du das Problem mit dieser Technik in Verbindung bringst. Ich muss sagen den Zusammenhang kann ich nachvollziehen. ich habe auch ein oder zwei selbstgebaute Kreuzungen bei denen das passiert, sonst war mir das noch nirgends aufgefallen. Aber das kann es ja auch nicht, die Verformung wird wohl sehr selten genutzt.


    Spontan würde ich als Workaround eine große Fläche an dem Ende unterhalb der Fahrbahn anbauen, an dem die Kreuzung verschwindet. Ich probier das mal aus.


    Edit:

    Der Workaround funktioniert. Ich habe am Ende der Kreuzung über die Breite eine 3m Hohe Fläche knapp unterhalb der Oberfläche hinzugefügt die aus Richtung der Kreuzung sichtbar ist. Die Kreuzung verschwindet nun nicht mehr.

    Für das Verschwinden dürfte auch tatsächlich die Verformung zuständig sein. Bei einer Version ohne Verformung tritt das Problem nicht auf.

    Die Höhenverformung von Kreuzungen ist tatsächlich eine sehr hilfreiche Funktion. Wenn man allerdings nur kleine Kanten überwinden möchte ist sie etwas übertrieben.

    Wenn die Kreuzung aber insgesamt einen Höhenverlauf aufweist und dieser sich an den Armen auch noch unterscheidet kann man damit mit relativ geringem Aufwand sehr gute Ergebnisse erzielen.


    Im Endeffekt muss man dabei nur zwei Punkte beachten:

    Das Verformungs-Mesh sollte größer sein als das eigentliche Objekt, ansonsten entstehen scharfe Kanten.

    Es wird nur die Höhenlage der Vertices und Pfad-Start- und Endpunkte verschoben, keine Kanten gekrümmt oder geteilt. Das Objekt sollte in Bereichen mit Krümmung also auch wenn es flach gebaut ist feiner unterteilt sein.


    Falls es gewünscht ist kann ich mich bei Zeiten mal um ein kleines Tutorial kümmern.

    Mion,


    für die ersten Gebäude sieht das schon sehr gut aus :thumbup:

    Ich hätte allerdings noch ein paar Verbesserungsvorschläge insbesondere im Hinblick auf die Texturen:


    Die Textur der Fensterfront im unteren Bereich des Schwedenkais ist etwas arg schief. Außerdem könnte man sich überlegen den Vorbau des Eingangs auszumodellieren.


    Bei der Textur der Klinik erkennt man gerade im linken Bereich die Kachelung der Textur enorm. Auch hier kann man mit Bildbearbeitung noch einiges rausholen. Generell wirkt die Textur etwas dunkel im vergleich zu den Bäumen drumherum, das kann aber auch an der Belichtung in Omsi liegen.


    Wenn du explizite Hilfe bei der Verbesserung brauchst kannst du dich gerne melden.


    MfG mrecht1

    Moin,


    das gibt da zwei Möglichkeiten:

    In den Spandau Kreuzungen sind die Markierungen direkt in den Asphalt eingebaut, enthalten also auch Asphalt auf der Textur.

    In neueren Kreuzungen, z.B. aus den Hamburg-Addons oder dem Bad Hügelsdorf-Addon sind die Markierungen separat über dem Asphalt verlegt. Dabei ist es entweder möglich keine Textur mit Transparenz zu verwenden und die Lage der Markierungen durch das Mapping anzupassen (Hamburg) oder jede weiß markierte Fläche ist durch Polygone dargestellt und die Textur hat keine Transparenz (BHD). Eine Erkenntnis, was besser für die Performance ist, gibt es soweit ich weiß noch nicht.


    Soviel zum Allgemeinen. Wenn du dich für eine Option entscheiden hast - welche hängt auch maßgeblich von der bisherigen Gestaltung der Karte ab - kann man über den Einbau sprechen.


    MfG mrecht1

    Stimmt, gerade in dieser Perspektive sieht man sehr gut, dass die Fluchten überhaupt nicht stimmen. Ich hatte aber irgendwo mal gesehen, dass die Darstellung des Innenraums schon jetzt etwas hinter die Glasfassade versetzt ist.

    Der Effekt den du da siehst ist ganz normal bei grob modellierten Krümmungen.

    Der Effekt wird geringer, wenn die Krümmung mit mehr Unterteilungen ausmodelliert wird und lässt sich nur komplett vermeiden, wenn die UV Map jeder Fläche die Form der Fläche hat (also das was mit "projekt form view" aus der Draufsicht erzeugt wird) In dem Falle entstehen dann aber Unterbrechungen in der Textur zwischen den Flächen.


    Der Effekt hängt mit der Funktionsweise des Mappings zusammen. Genau kann ich das auch nicht erklären, aber man erkennt das bspw. dann, wenn man eine Quadratische Fläche in Dreiecke unterteilt. Je nachdem, welche Diagonale gebildet wird, verändert sich das Mapping.

    Das sieht doch nach einer brauchbaren Quelle aus.

    Man sollte jetzt nach der API bzw. den Capabilities suchen, ich finde die aber bei einer einfachen Suche nicht.

    Alternativ kann man sich den Online-Kartendienst mal mit den Entwickler-Tools des Browsers ansehen, dazu muss man "F12" drücken. In Chrome kann ich dann auf den Reiter "Application" wechseln und im Menü auf der Linken Seite unter "frames->top->images" mir alle Bilder anzeigen lassen, die diese Seite gerade benutzt. Hier werden mir nun auch Teile des Luftbildes angezeigt, zum beispiel dieses hier: https://svc.geo.lu.ch/main/res…rver/tile/9/225900/221856

    Wie du siehst endet die URL zwar nicht auf eine Bild-Dateiendung wie".jpg" oder ".png", liefert aber dennoch nur ein Bild zurück.

    Um nun Bilder in Omsi einbinden zu können, braucht man einen Link, der die Zoomstufe "z" und die Koordinaten "x" und "y" der zur Omsi Kachel passenden OpenStreetMaps Kachel enthält.


    Kleiner Exkurs: Eine von der Zoomstufe abhängige Formel bestimmt in wie viele Kacheln die gesamte Erdoberfläche bei dieser Zoomstufe geteilt wird. Übliche Zoomstufen liegen im Bereich von 0 (ganze Welt) bis 20 (ein mittleres Gebäude). Um Kacheln zu erhalten, die den in Omsi genutzten etwa 300x300m großen Kacheln entsprechen, ist eine Zoomstufe von 16 nötig.


    Die oben genannte URL enthält nur eine Zahl, die in der Größenordnung der Zoomstufe liegt und zwar die 9. Ein Bild der Zoomstufe 9 würde bei OpenStreetMap allerdings eine ganze Metropole abbilden und nicht nur einige Häuser. Es ist daher davon auszugehen, dass die Luftbild-Kacheln dieses Dienstes nicht den Kacheln bei OSM entsprechen, daher ist eine simple Einbindung, wie im Falle der österreichischen Luftbilder, nicht möglich.


    Wir müssen jetzt leider etwas tiefer einsteigen und versuchen herauszufinden, welches kachel-System für deine Luftbilder genutzt wird.

    Dazu nutzen wir erstmal unseren Bild-Link und schauen mal, wo wir hinkommen, wenn wir nur die Domain, also "https://svc.geo.lu.ch" aufrufen. Das liefert einen Error 403. Wir nehmen jetzt immer ein Teil der URL zusätzlich dazu, also als nächstes https://svc.geo.lu.ch/main. Hier bekommen wir eine Seite mit einem Menü angezeigt. Diesem Menü können wir entlang der URL des Bildes über "basis->bais_ortho" folgen und bekommen eine Seite angezeigt, die uns Hintergrundinformationen zu den Bilddaten anzeigt.

    Interessant ist hier die Angabe "Spatial Reference: 2056". Diese Nummer ist fest für das amtliche Schweizer Koordinatensystem vergeben. Es wird ersichtlich, dass das Koordinatensystem auf ganz anderen Grenzen beruht und die Lage nicht in [°] sondern in [m] angibt. Beides macht keine Hoffnung auf eine Umsetzbarkeit, aber schauen wir mal weiter.

    Weiter folgend sind dann die Auflösung der Bilder, deren angenommene Pixeldichte und die 13 Zoomstufen beschrieben. Ein Bild mit einer Kantenlänge von 256 Pixeln und einer Pixeldichte von 96 DPI hat eine Kantenlänge von 6,773 cm bzw 0,06773 m. Über die unter den Zoomstufen angegebenen Maßstäbe ("Scale") kann man nun bestimmen welche Größe die Kachel, die abgebildet wird, in der Realität hat.

    Um zu wissen, ob einer dieser Maßstäbe zufällig zur Omsi Kachelgöße passt, müssen wir erstmal bestimmen, wie groß eine Omsi kachel in dieser Region überhaupt ist. Dazu ist im OSM Wiki eine Formel zur Bestimmung der Kantenlänge der Kacheln angegeben. Für die Stadt Luzern liegt diese Größe bei etwa 454,06 Meter.

    Bei der vorhin bestimmten Bildgröße ergibt sich ein anzustrebender Maßstab von 454,06/0,06773=6704. Da dieser nicht Teil der Zoomstufen ist, ist es auch nicht möglich die Kacheln durch irgendeine Verschiebung zu überdecken. Eine Nutzung der Bilder unter einem aus der obigen abgeleiteten URL ist also nicht möglich.


    Am Ende der Seite gibt es allerdings noch den Menüpunkt "Export Map", was eine Seite aufruft, auf der eine Vielzahl von Parametern eingegeben werden kann und die ein in den Grenzen beliebiges Luftbild zurückgibt. Man könnte versuchen über diese Funktion Luftbilder zu generieren, die zu Omsi Kacheln passen. Dies ist allerdings mit einigen zum Teil aufwendigeren Umrechnungen verbunden, die ich hier erstmal nicht weiter durchführen möchte. Falls du da tiefer in die Materie einsteigen möchtest, können wir das ja erstmal per PN klären und Ergebnisse ggf. hier präsentieren.

    Moin,


    wie du richtig erkannt hast, muss der Link, wenn er in den Omsi Optionen eingetragen werden soll, direkt ein Bild zurück liefern, endet also in der Regel auf ".jpg", ".png" o.Ä.

    Deine Open Data Seite erlaubt es dir erstmal einen öffentlich zugänglichen Datensatz zu finden, der Luftbilder enthält. Es wird vmtl. nicht möglich sein direkt über diese Seite die Luftbilder abzurufen.

    Wenn ich auf dieser Seite nach "Luftbild" oder "Orthofoto" suche, bekomme ich eine Vielzahl verschieden alter Datensätze verschiedener Kantone angezeigt. Es scheint also erstmal keinen Datensatz zu geben, der die gesamte Schweiz abbildet.

    (Den gibt es so weit ich weiß auch nicht für die gesamte Bundesrepublik Deutschland, sondern nur von jedem Bundesland einzeln)

    Ich würde dir empfehlen also erstmal zu suchen, ob über diese Seite ein Luftbild-Dienst für die von dir gewünschte Region verfügbar ist.

    Sollte das nicht der Fall sein, können wir mal versuchen einen solchen Dienst anderweitig zu suchen und zu ergünden, ob und wie man darüber Bilder für Omsi beziehen kann.

    Moin,


    ich kann zu dem Thema alternative Luftbilder durchaus einiges beitragen:


    Die Luftbilder der Geoportale der Länder und Verwaltungen nutzen leider in der Regel in UTM-Koordinaten mit Ortsangaben in [m]. Omsi sowie OpenStreetMap, Google Maps oder Bing Maps nutzen hingegen Geographische Koordinaten mit Ortsangaben in [°]. Die unterschiedlichen Koordinatensysteme führen dazu, dass die Kacheln nicht deckungsgleich sind, sondern gegenseitig leicht verdreht sind, in Abhängigkeit von der Lage auf dem Globus. In Omsi würde sich das darin äußern, dass der Versatz der Luftbilder zwischen den Kacheln zunimmt, je weiter man sich vom Äquator entfernt.


    Ich habe es bereits mit der Hilfe eines in der Webprogrammierung bewanderten Freundes geschafft die Luftbilder der Niedersächsischen Verwaltung in Omsi anzuzeigen. Nötig war dazu eine kleine Software, die die an einen localhost gestellten Anfragen von Omsi, die auf der OpenStreetMap API basieren, umwandelt in Anfragen, die der Luftbild-Webdienst versteht. Mir war es damals möglich den eben angesprochenen Versatz für eine einzelne Kachel durch Einfügen von konstanten Versätzen zu beseitigen, dieser tritt ab einer gewissen Entfernung von dieser Kachel aber wieder sichtbar auf.


    Es ist also möglich auch andere Kartendienste zu verwenden, deren Einrichtung erfordert aber gewisse Grundkenntnisse in der Programmierung und ist sehr aufwendig, da die Software für jedes Projekt angepasst werden muss. Leichter , aber durchaus auch aufwendig, wäre es, wenn man das schon aus Omsi1 bekannte Feature eines festen auf dem Rechner hinterlegten Hintergrundbildes nutzt. Es ist relativ leicht herauszufinden, wie die URL aufgebaut ist, über die die Luftbilder angefragt werden. Hier müssen dann UTM Koordinaten in einem 300mx300m Raster eingegeben werden und die Einzelbilder anschließend mit Bildbearbeitungs-Software zusammengesetzt werden.


    Welche Möglichkeit man nun nutzen möchte hängt am Ende wohl davon ab, ob man in Omsi Höhendaten importieren möchte. Das geht nur mit einer Map in Geografischen Koordinaten für die Luftbilder in UTM-Koordinaten eben nur begrenz gut passen. Alternativ kann man ja mal schauen, ob das jeweilige (Bundes-)Land ein Digitales Geländemodell (DGM) anbietet. Dieses ist zum einen meistens sehr viel genauer und passt außerdem perfekt zu deren Luftbildern. Mit der Kombination von beidem ist es möglich in Blender Kachelobjekte zu erstellen, die sowohl einen genauen Höhenverlauf wie auch hochauflösende Luftbilder zeigen. Gemacht habe ich das bisher zum Beispiel für ein Projekt in Hamburg. Dort ist sogar ein DGM mit einer Rasterweite von 1m mit einer Genauigkeit von +-7cm verfügbar!



    Nun zum spezifischen Projekt:


    Meine Recherche hat ergeben, dass basemap.at zwar seine Koordinaten im UTM-Format angibt, die zugrunde liegenden Luftbilder allerdings geografische Koordinaten nutzen und sogar die selben Variablen wie die Kacheln bei OpenStreetMap. Es sollte also theoretisch möglich sein diese direkt ohne Umwege in Omsi einzubinden.

    Der nötige Link steht in den Capabilities und lautet : https://maps.wien.gv.at/basema…/google3857/~z/~y/~x.jpeg


    Ein DGM ist für Österreich auch verfügbar, immerhin in einer Rasterweite von 10m: https://www.data.gv.at/katalog…84-480b-a480-ff63286b35b7


    Ich hoffe das hilft erstmal weiter.

    Du kannst ruhig beim 4000er RAM bleiben. Mir wäre nicht bekannt, dass das irgendwelche Negativ-Auswirkungen auf die Leistung hätte.

    Oh doch hat es! Bei Ryzen empfiehlt sich maximal 3600 MHz, wenn du nicht übertakten willst. Der Fabrik-Clock, kurz F-Clock, der die Taktung der Verbindung zwischen den einzelnen Chips in der CPU untereinander sowie dem Speicher bestimmt hängt vom Takt des Arbeitsspeichers ab. Bis 3600 MHz ist dieser im Verhältnis 1:1 (wobei der angegebene ram Takt ja schon dem doppelten der eigentlichen Frequenz entspricht), darüber hinaus verringert sich das Verhältnis auf 1:2. Die Geschwindigkeit der Verbindung zwischen den Chips untereinander und dem Ram wird also sprunghaft langsamer.



    Zur GPU möchte ich dich mal auf eine gebrauchte RTX 2080 (super) aufmerksam machen. Als ich vor ein paar Tagen geguckt habe, waren 2080 super schon ab etwas mehr als 300€ zu bekommen.