Beiträge von Lµkas

Zitat von GermanCity

Zusätzlich noch die Frage von wo man, natürlich auf legalem Weg, Texturen für u.a. Straßenmarkierungen und Gehweg nutzen kann?

Hier befinden sich auch ein paar Texturen:

Zitat von GermanCity

Kann man pauschal sagen, dass für diese Kreuzung inklusive Markierungen und Höhenmesh 2857 Tris viel sind oder lässt sich das so nicht behaupten?

Ich würde pauschal (bin aber immer vorsichtig mit solchen Aussagen...) sagen, dass bis zu 4000-5000 Tris für eine Kreuzung in Ordnung ist. Der Knackpunkt bei Kreuzungsobjekten ist ja, dass sie in der Regel nur einmal vorkommen, Standardkreuzungen (bspw. einfache T-Einmündungen) insb. wenn sie im Hintergrund sind und vom Spieler nicht befahren werden, können dann ein bisschen spartanischer sein.

Wichtiger als das Mesh sind aber erfahrungsgemäß die Texturen: Unbedingt ein 2ⁿ Format benutzen, also beispielsweise 256x512, 64x64, 1024x2048 usw. Außerdem ist das DDS-Format tendenziell besser was Performance angeht - komprimiert allerdings auch. Was die Texturgröße angeht, ist man sich etwas uneinig, ich finde beispielsweise, dass man bei "langweiligen" Asphalttexturen es bei 256px² belassen kann, 512px² kann man dann bei Platten/Kopfstein/... machen, wo es mehr gibt als eine Farbe oder Riffelungen - andere schwören auf 1024px² oder maximal komprimierte Texturen, die sich wiederholen und beispielsweise gespiegelt sind (da kommen dann Exotiker wie 64x512px raus).

Ich glaube, dann wäre tatsächlich die Pfadsegmentlänge anzupassen. Einfach mal ein paar Werte ausprobieren.

Zeile 38-42 müssten natürlich wieder ent-kommentiert werden, so müsste es richtig sein:

=== Created with Simple Spline Editor ===
=== Author: FMI ===

=== Height profiles ===
== Fahrstreifen ==
== Breite: 5 Meter ==
[heightprofile]
-2.5
2.5
0.1
0.1

---------------------------
Textures
---------------------------




[texture]
_Weg1_trans2.tga
[matl]
_Weg1_trans2.tga
0
[matl_alpha]
2


// Texture will be splitted longitudinally


    [patchwork_chain]
    {length of one segment in m}
    {chain of transitions}
    {chain of weight factors}
    {invertable? 0 / 1}

[patchwork_chain]
2
AAAABBAACAAADAAAA
0011311111111133
0000000000000000

=== Textur wrappings ===
== START ==
[profile]
0
== FROM ==
[profilepnt]
-2.5
0.1
0
0.024
== TO ==
[profilepnt]
2.5
0.1
1
0.024
== END ==

=== Pathes ===
[path]
0
0
0.1
3.5
2

Es gibt nun ein erstes (Nightly) Update zur Performance: NightlyBuild - Patch 1.EA.094

Dürfte für den einen oder anderen interessant sein, der leidlich mit der Performance zu kämpfen hat.

Könntest du da nochmal die SLI zeigen? Eventuell hast du den ursprünglichen patchwork-Chain-Eintrag nicht wieder drin.

Und die Logfile, vielleicht steht da etwas drin.

Dann würde ich dir mal empfehlen, den jeweils letzten Wert der [profilepnt]-Einträge zu verändern. (da, wo 0.2 steht)

Das ist der Streckfaktor, der sich wie folgt berechnet:

Umgestellt bedeutet das:

Das heißt, beim Faktor 0.2 ist ein Segment mit der Textur 5m lang. Bei einem Faktor von 0.4 wäre das dann nur noch 2,50m usw.

siehe auch Splinedateien (.sli)

Ne, du musst den folgenden Abschnitt auskommentieren:

[patchwork_chain]
{length of one segment in m}
{chain of transitions}
{chain of weight factors}
{invertable? 0 / 1}

Ist ja auch logisch: OMSI erkennt das Schlüsselwort [patchwork_chain] und sucht in den folgenden Zeilen nach den Angaben, kann aber keine Zahlen (die gefordert sind) erkennen.

Du musst Zeile 32(-36) auskommentieren, zB mit einem TAB anfangen, andernfalls liest Omsi das als Schlüsselwort ein und kann mit den Zeilen 33-36 nichts anfangen.

Ich würde einfach mal diesen Wert vergrößern/verkleinern: {length of one segment in m} Dann sollte sich die Textur "proportional" anpassen.

Zitat von GermanCity

Verstehe ich die grundsätzliche Reihenfolge richtig, dass zuerst in Blender die Kreuzung/das Straßenobjekte flach erstellt wird (mit zugehöriger Texturierung und Exportieren ins .o3d Format) und dann in einem zweiten Schritt das Höhenmesh ebenfalls in Blender erstellt wird, anhand dessen OMSI dann die Kreuzung "verbiegt". Die KI-Pfade werden dann normal im Kreuzungseditor anhand der flachen Kreuzung verlegt und werden ebenfalls in OMSI "verbogen". Ist da meine Denkweise richtig?

Genau so funktioniert es.

Zitat von Bamp

Wenn du im Editor mit realen Höhendaten arbeitest, könntest du auch diese Kachel vom Editor exportieren und in Blender als Höhenmesh nutzen. Das musst du dann nur etwas hin- und herschieben, bis es passt.

Das Problem dabei ist, dass die Verformung meist ungleichmäßig ist - Straßen sind jedoch in der Regel gerade. Besonders in bergigen Regionen oder wenn die Höhendaten ungenau sind, wird das zum Problem.

Ich habe es bei meinem einen Projekt wie folgt gemacht und damit ganz gute Ergebnisse hinbekommen:

1. Zunächst die Kreuzung "flach" gebaut (liegt Dir ja bereits vor)
2. Anschließend im OMSI-Editor die angrenzenden Splines auf die passende Höhe gebracht inklusive Neigung.
3. Die Splines dann aus dem Editor exportiert (gibt dazu eine Funktion) und in Blender importiert.
4. Zwischen die Splines ein plane-ähnliches Polygon gespannt, das jeweils auf der Höhe der Straße verläuft
   (alternativ könnte man wenn man keine lineare Steigung hat die Linien anhand einer Curve ausrichten)
5. Die Verformung wird "sanfter", wenn sowohl das Kreuzungsmesh als auch das Plane-Mesh gleichmäßig kleine Faces haben, dazu ggf. das Round-Messer aktivieren (STRG+R oder so ähnlich...)

Meine Blender-Kenntnisse sind schon etwas eingerostet, aber so hab ich es immer gemacht.

Ohne das Ausfüllen der Vorlage kann dir kaum jemand helfen. Bei welchen Bussen / Mods besteht das Problem genau? Hast Du vorher etwas installiert, bevor das Problem auftritt?

Zitat von Aki

r2d2_2 Ich werde damit jetzt vermutlich viele Leute enttäuschen, aber das ist leider nur fotografiert und funktioniert nicht, aber wer wüsste wie man das zum funktionieren bringen könnte, kann sich gerne bei mir melden.

Tatsächlich gibt's da einige (Vor-)Überlegungen zu inklusive eines Prototyps. Ich weiß aber leider nicht mehr, wer daran beteiligt war. Hamburg und der_Nik_ haben da (glaube ich?) mitdiskutiert.

Mit Erlaubnis veröffentliche ich an dieser Stelle ein Statement von Staaken79:

Zitat von Staaken79

Leider muss ich hier ein kurzes Statement abgeben, da BusDriver30 die Tatsachen nicht mehr ganz überblickt und hier leicht verdreht.

Gestern Abend bin ich aus dem Projekt Spandau Real ausgetreten, da eine dauerhafte Zusammenarbeit mit BusDriver30 wegen privater Differenzen nicht mehr möglich ist. Seine Aussagen, dass ich das Projekt boykottieren möchte, entsprechen auch nicht der Wahrheit.

Ich erlaube, den Fans der Map und der Community zu liebe, die weitere Nutzung meiner Änderungen an Splines und Kreuzungen, die mit dem Zusatz Staaken79 gekennzeichnet sind. Ohne diese Objekte wäre eine weitere Nutzung der letzten Mapversionen(seit der Einbindung in Omsi 2) nicht mehr möglich.

Nochmal eine Klarstellung für alle: Da er dem Projekt nicht vertraglich verpflichtet ist, kann er jederzeit entscheiden, aus dem Projekt auszuscheiden und ist über diese Entscheidung auch niemandem Rechenschaft schuldig. Natürlich ist es schade, wenn ein langjähriger Projektpartner nicht mehr mitmacht. - Es muss aber akzeptiert werden. Ein Nachtreten, Anschuldigungen oder Veröffentlichungen von Interna sind in diesem Fall höchst kontraproduktiv, sowohl für das Klima an sich als auch für potenziell künftige Projektpartner.

Außerdem gehören private Streitigkeiten hier nicht an die Öffentlichkeit. Wenn private Differenzen bestehen, würde ich euch empfehlen, eine unabhängige Drittpartei ("Mediator") hinzuzuziehen, um den Konflikt zu lösen - soweit beide Parteien einverstanden sind. Ebenso verhält es sich mit Inhalten aus nicht-öffentlichen Projektforen.

Zitat von Bamp

eine Chronologie von -∞ bis x

Um in diesem Fall "korrekt" zu arbeiten, müsste man die Chronologie negieren, d.h. du baust auf der Map standardmäßig den Zustand bis X ein und machst dann ab X eine Chronologie ohne Enddatum, mit den Änderungen, die ab da wirken sollen.

Zitat von BS110V

Würde es auch funktionieren, nur die transparente Fläche als separate o3d in die SCO der Schranke einzubinden? Grund ist, dass ich bereits alle 200 Schrankenmodelle fertig gebaut habe und ein ändern der Sco einfacher wäre als der Neubau aller Modelle

Ich denke, das würde auch funktionieren.

Zitat von BS110V

Jetzt schneidet er mir ein Loch ins Terrain...

Es sollte aber einfach nur das Terrain aufgeschnitten werden, sodass alles darunter liegende (also hier der Kasten) zu sehen ist...

Gibts da noch einen Trick oder liegt es daran, dass die Loch-Plane ein separates Objekt ist?

Ich vermute, da ist die Renderreihenfolge entscheidend, ist mit Glas ja ähnlich. Setz den mesh-Eintrag der Schranke mal ganz nach unten oder über den shadow-Eintrag. Ansonsten müsstest du es mal als "ganzes" Objekt probieren.

Ich glaube, um presurface nutzen zu können, benötigt man noch eine zusätzliche Fläche mit transparenter Textur, in etwa so:

Diese Fläche sollte auf dem Nullpunkt liegen und mit einer vollständig transparenten Textur gemappt sein (oder Teile davon - Beispiel: Sceneryobjects\Streetobjects_MC\rw_digging.sco inklusive zugehöriger Textur rw_digging.tga). Dann benötigt das Ganze natürlich noch einen matl- und matl_alpha-Eintrag.

TTOmsi  Hamburg Besteht das Problem immer noch? Ich kann es mittlerweile nicht mehr reproduzieren.

In der Zwischenzeit haben sowohl wir ein paar Updates gemacht als auch Chrome.

@PG_97 Da Bowsy mittlerweile einen neuen Artikel übersetzt hat, müsstest Du vor kurzem eine Benachrichtigung bekommen haben.

Ansonsten nochmal schauen, ob die Kategorien wirklich abonniert werden und die Benachrichtigungen aktiviert sind:

Wie sieht es denn aus, wenn du diese Seite mit allen Benachrichtigungen aufrufst? Evtl gibt's da noch ein paar alte, die du noch nicht gesehen hast. Ansonsten einfach mal den Haken drücken mit "alle gelesen markieren".

Unter https://srtm.kurviger.de/SRTM3/ kann man auch die anderen Kontinenten durchsuchen. Das dürften tatsächlich auch die "richtigen" Daten sein, diese waren nämlich auch im SRTM-Format.