Beiträge von Chrizzly92

Derzeit kein Mailversand möglich. Wir bitten um Geduld.

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!

    richtig, das könnte ein Parallax Mapping Effekt sein.

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    sieht aber auch nur wirklich authentisch aus, wenn das Interieur nicht zu "tief" ist und man recht nah dran steht. von weiten stimmt dann die Flucht nichtmehr.

    Grundsätzlich muss man hier aber anmerken, dass wir uns in einem 10 Jahre alten Spiel bewegen. Bei neueren Engines, vorallem mit 64-bit unterstützung sind größere Dateien kein Problem mehr, in OMSI geht das allerdings nicht. Bei einem M&R Wagen ist es vermutlich egal, welches Dateiformat verwendet wird - bei so wenig und so niedrig aufgelösten Texturen ist der Texturspeicher auch noch nicht großartig überfordert. Wir wollen ja immer mehr Qualität, immer mehr Texturschärfe - das geht aber irgendwann einfach nicht mehr. Bei großen Texturen ist die Verwendung von DDS fast schon unumgänglich, weil diese "as-is" in den Speicher geladen werden. Da wird auch nix entpackt oder dekomprimiert, eine 600kb DDS ist auch im Texturspeicher 600kb groß. Es ist auch völlig egal, ob eine Komprimierte 8k TGA auf der Platte nur 100kb belegt weil sie kaum Bildinformationen enthält - die ist im Speicher selbst dann trotzdem so groß wie eine 0815 Bitmap.
    Wenn ich mich richtig erinnere, werden bei einer DDS Textur die Informationen aus 4 nebeneinanderliegenden Pixeln zusammengefasst und in ein 565 RGB Format umgewandelt. Das ergibt eine Komprimierungsrate von 6:1. Farbinformationen werden in 5 bits für Rot, 6 bits für Grün, 5 bits für Blau gespeichert. das ergibt eine 16 bit Farbtiefe und damit 216 Farbabstufungen - ~65.000 Farben. Gerade in Graustufen führt das zu den bekannten, sichtbaren Artefakten, vorallem dann wenn es aus einer True-Color Datei (24 bit Farbtiefe oder mehr) umgewandelt wurde. Würde man allerdings 24 bit Farbtiefe nutzen, hätte man über 16 Millionen Farbabstufungen aber damit auch eine wesentlich größere Dateigröße.
    Es gibt keinen Mittelweg zwischen Dateigröße/Texturspeicher und der Qualität der Texturen. verringert man den einen Faktor, verringert sich auch immer der andere. Durch unterschiedliche Komprimierungsmethoden und Einstellungen lassen sich natürlich auch unterschiedliche Ergebnisse erzielen. die DXTBMP Software, welche Perotinus hier angesprochen hat liefert eventuell bessere Ergebnisse bei Graustufen, hat aber eventuell auch mehr Artefakte an anderen stellen. Irgendwo muss man immer Abstriche machen.
    Ich nutze Grundsätzlich DDS für alle meine Texturen. Ausnahmen sind kontrastreiche Texturen wie die VDV-Displaytexturen meiner Fahrzeuge.

    Ich hoffe, dass auch die Animation der Räder angepasst werden. Das war ja mehr als Krebs im Video.

    das ist ein Problem vom TAA - Temporal Anti Aliasing. Da werden quasi mehrere Einzelbilder genommen um daraus eine Kantenglättung zu berechnen. Das ist bei langsamen Spielen kein Thema, aber überall da wo sich Objekte schnell bewegen führt das zu verschwimmen, ghosting und einfach einem unscharfen Bild. bleibt man stehen und betrachtet die stille Szenerie, ergibt TAA dafür sehr schöne Ergebnisse. Auch ist diese Art der Kantenglättung im Vergleich zu anderen AA-Methoden recht unproblematisch im Rechenaufwand.
    Wenn die Nachteile allerdings die Vorteile schlucken, sollte man überlegen hier nicht eine andere AA-Methode zu verwenden und TAA war schon im Fernbus absolut ungeeignet. Hatte damals meine eigenen Einstellungen implementiert die mMn wesentlich "natürlicher" wirkten.



    Die Nutzung von beispielsweise Screen Space Reflexions ist hier und da ganz nett, beim Lack hat das meiner Meinung nach aber nix zu suchen da dieser durch SSR-Artefakte einfach unnatürlich wirkt. Was anderes wäre die nutzung von Raytracing, was wirklich natürliche Effekte ermöglicht. Eine feste Env-Map wie in OMSI würde da natürlicher wirken als SSR und selbst deaktiviert sieht das meiner Meinung nach besser aus:


    Nur weil eine Engine Effekte unterstützt, sind diese nicht grundsätzlich gut und machen überall Sinn.


    Ich finds schade, dass man bei der Optik scheinbar keinerlei Spielraum hat, denn konstruktive Kritik zu dieser gabs schon bei den ersten Screens zu The Bus und passiert ist nix. Klar, in der UE4 kann man auch viel selbst rumspielen aber gerade wenn Shader eine bestimmte Funktion benötigen und man dann die SSR deaktiviert, beeinflusst man gleichzeitig auch Bereiche, wo sie angebracht wären wie Pfützen oder sowas.

    Auch so sachen wie TAA Ghosting sind leider noch nicht abgestellt. das schleppt man auch im Fernbus schon seit Jahren mit. Hier könnten wenige, einfache Tweaks für wesentlich bessere Optik sorgen.

    OK, ich habe gerade erfahren, dass es tatsächlich nicht erst bei der Fahrernummereingabe eine Verbindung gibt.
    Das muss geändert werden auf einen anderen Trigger, nämlich die Eingabe der individuellen Fahrernummer. Danach können dann Werbungen geladen werden.
    Default sollte es offline Modus sein

    Werbungen hätte man auch beim OMSI-Start über den klassischen Weg beziehen können, dafür gibts extra *.itx und *.ipr Dateien im Textureordner von OMSI. Ist der Server nicht erreichbar oder die Dateien sind nicht verfügbar, überspringt OMSI die betroffene Textur automatisch.
    In PluginStart(); Prozedur erstellt ihr einfach eine Form mit ParisOnline und ParisOffline Buttons und lasst den Anwenfer einfach selbst entscheiden. Da isses auch egal ob der Server offline ist oder in 10 Jahren offline genommen wird. Entscheidet sich der User für eine Teilnahme an den Onlinefunktionen, DANN kann man anfangen den Server zu kontaktieren.

    Es geht hier doch auch nicht nur um die Probleme beim OMSI Start, da gehts auch um den Datenschutz.

    Hier wird Seitens der Entwickler überhaupt nicht externen Anwendungen gearbeitet sondern mit Dynamic Link Library, welche keinen Einfluss auf die Performance haben. Eigentlich auch nichts neues, kam bei Düsseldorf auch schon zum Einsatz, nur wurde dort keine Verifizierung mit Steam gefordert.

    Die Verifizierung via Steam wäre mit Sicherheit für den Funktionsumfang nicht notwendig gewesen. Das Plugin aus DUS ist wesentlich weniger invasiv und hat selbst wenn man das Add-on illegal Verteilt keinen Einfluss. Einzig und allein die Illegalen Kopien funktionieren irgendwann nicht mehr.
    Im Übrigen kann eine DLL sehr wohl Einfluss auf die Performance haben. Und was ist wenn die Registrierungsseite in einigen Jahren nichtmehr online sein sollte?

    920 20:53:04 - - Error: Dateizugriff verweigert: AMUAV.CNAVO.MV.E


    hast vermutlich durch eine Mod oder so die Zugriffsrechte verändert und OMSI kann die Datei nicht lesen. Bitte mal OMSI komplett neu Installieren (vorher z.bsp. den OMSI 2 Ordner umbenennen und dann über Steam alles neu beziehen) und schauen obs geht. dann kannst du stück für stück die alten dateien wieder installieren.