Diskussion zu Meshsubsets zusammenfassen

[Michael_Poschmann]

Vielleicht lässt sich ja streckenseitig auch noch ein wenig optimieren, z.B. Elemente ohne Gleisfunktion entfernen, die lediglich als Bauhilfe gedient haben. Das wird zwar im ersten Moment lediglich den Ladeprozess beschleunigen, aber jede Kleinigkeit kann beitragen, die Gesamtperformance zu verbessern. Sind im Modul Harburg die Mesh-Subsets zusammengefasst? Diesen Schritt habe ich gerade im Ruhrtal ausgeführt, das bringt in kritischen Bereichen wie Hagen glatt ein paar fps.

Grüße
Michael

[Alwin Meschede]

Vielleicht lässt sich ja programmseitig auch noch ein wenig optimieren, z.B. durch Einsatz eines marktüblich schnellen XML-Parsers. Das wird zwar im ersten Moment lediglich den Ladeprozess beschleunigen, aber jede Maßnahme, die uns erspart dass auch nach Weggang eines Streckenbauers die "Hinterbliebenen" ohne große Krämpfe noch Verbesserungen an seinen Streckenmodulen vornehmen können, sichert die Zukunftsfähigkeit des Datenbestands.

Zur Einordnung: Die auf dem obigen Screenshot zu sehende Stelle, wo der Rechner des Threaderstellers auf Standardeinstellungen (= 1700 m Sichtweite) 14 fps erreicht und die Grätsche macht, läuft auf meinem Notebook mit 36 fps bei ungekürzten 3500 m Sichtweite. Das ist keine performancemäßig kritische Stelle. Man muss nicht mehr tun, als Hardware an den Start zu bringen, die noch nicht das Ende ihrer wirtschaftlichen Nutzungsdauer erreicht hat.

[Michael_Poschmann]

Hallo Alwin,

da hast Du sicherlich Recht mit Deiner Einordnung, dass die eingesetzte Hardware etwas schwachrüstig ist.
Ich bleibe aber dabei, wenn jedes Gewerk seine Hausaufgaben macht und die eigenen Dinge optimiert, kommt das dem Gesamtkunstwerk zu Gute. Und wenn man ein wenig Luft gewinnt, reicht es vielleicht sogar für Detailergänzungen wie z.B. die Beschriftung der Ls-Signale.

Grüße
Michael

[F. Schn.]

Du hast leider vergessen, den Fahrplan dazu zu sagen: Timetables\Deutschland\Hamburg_Kassel\Sorsum-Kassel_2020_06Uhr-09Uhr.fpn ( DGS 59583 )
Ich habe den Zug mal gefahren und an der Stelle einen (einzelnen) reproduzierbaren Mikroruckler bei stabil hohen Fps. Ein Present Fehlgeschlagen bekomme ich aber nicht.

PS:

Ich bleibe aber dabei, wenn jedes Gewerk seine Hausaufgaben macht und die eigenen Dinge optimiert, kommt das dem Gesamtkunstwerk zu Gute. Und wenn man ein wenig Luft gewinnt, reicht es vielleicht sogar für Detailergänzungen wie z.B. die Beschriftung der Ls-Signale.

Meine Meinung ist: Etwas so umzubauen, dass es irreparabel und nicht mehr ohne irgendwelche Quelldateien umbaubar wird, ist kein "Hausaufgaben machen" sondern geht nur zu Lasten der zukünftigen Generation.

[Michael_Poschmann]

F.Schn., was meinst Du denn mit irreparabel umbauen?

Grüße
Michael

[F. Schn.]

Ich habe im Team Süd mit einem fahrbarem LKW experimentiert. Dafür brauchte ich die Straßenvektoren. Ich habe im Modul Paderborn an der Landschaft herum gespielt. Dazu war es notwendig, dass die Mesh-Subsets nicht zusammengeführt sind, ansonsten versenkt man viel Zeit mit dem Zerlegen der Subsets (und bekommt es häufig auch nicht wirklich gut hin).
Ich sehe das sehr skeptisch, wenn man bestimmte Schritte, durch die das Modul schlecht wieder umgebaut werden kann, als "Notwendige Hausaufgaben" ansieht.

[Michael_Poschmann]

OT cont: Es ist ausdrücklich nicht die Zusammenfassung von Detailkachel-Meshsubsets gemeint, so dass z.B. Fahrleitung weiterhand ohne Probleme bearbeitbar bleibt. Aber die grüne Grundplatte, die sich oftmals manuell angelegt um Hauseinbauten herumdrapiert, lässt sich durch diese Funktion prima zusammenfassen. Optimierung der Meshsubsets führt auch oft genug zur Löschung zahlreicher nicht benötigter Punkte und entschlackt die Datein. Viel Wenig ergibt ein Viel, so meine Devise.

Bei den Straßen hängt es davon ab, ob diese Vektorzüge später mal von Nutzen sein können, z.B. bei getrennten Fahrspuren. Ohne Nacharbeiten wird man da unter anderem in Kreuzungsbereichen eh nicht auskommen. Dank Versionskontrolle ist die Wiederherstellung von Bauzuständen ja kein Hexenwerk.

Beim schnellen Blick auf Harburg habe ich diverse Elemente ohne Gleisfunktion gesehen, die z.B der Erstellung von Stützmauern gedient haben. Ob die in einer veröffentlichten Modulversion gewinnbringend genutzt werden können, lässt sich sicherlich diskutieren. Natürlich sind diese Aufräumarbeiten mühsam und kosten Zeit. Aus meiner Sicht lohnt es sich.

Grüße
Michael

[Alwin Meschede]

Optimierung der Meshsubsets führt auch oft genug zur Löschung zahlreicher nicht benötigter Punkte und entschlackt die Datein.

Es ist zu unterscheiden zwischen den Funktionen Meshoptimierung (sinnvoll, und schadlos machbar, weil sie nur dysfunktionale Teile der Landschaft entfernt) und Meshsubsets zusammenführen (nicht rückgängig zu machende Veränderung intakter Landschaftsteile).

Dank Versionskontrolle ist die Wiederherstellung von Bauzuständen ja kein Hexenwerk.

Theoretisch ja, aber in der Praxis will ich mal sehen, was jemand macht der zu dem Schluss kommt "ich brauche Teilstücke der einstmals gelöschten Elemente ohne Gleisfunktion jetzt doch nochmal wieder und muss die jetzt irgendwie aus einer uralten Version der Strecke restaurieren und in die aktuelle Streckenversion übernehmen". Dieser Jemand müsste schon ziemlich gut in seinem Handwerk sein. Mir fällt nämlich keine wirklich effiziente Methode ein, um diese einfache Aufgabe zu bewerkstelligen. Ganz abgesehn von der Frage, ob denn die handelnde Person in der Zukunft noch Zugriff auf das Versionskontrollsystem mit der notwendigen Urversion der Streckendatei hat.

Beim schnellen Blick auf Harburg habe ich diverse Elemente ohne Gleisfunktion gesehen, die z.B der Erstellung von Stützmauern gedient haben. Ob die in einer veröffentlichten Modulversion gewinnbringend genutzt werden können, lässt sich sicherlich diskutieren

Beispiel: In der Zukunft hat jemand vielleicht das Bedürfnis, eine schönere Stützmauer an genau dieser Stelle zu bauen, die eine andere u/v-Aufteilung hat, und deshalb nicht einfach durch Texturtausch erstellt werden kann.

Also man sieht: Das mit den nicht rückgängig zu machenden Optimierungen ist eine politische Frage, die man so oder anders sehen kann. Da sind wir uns halt nicht einig, was die beste Vorgehensweise ist.

[Michael_Poschmann]

Hallo Alwin,

wie wahrscheinlich es ist, mit Liebe und Sorgfalt erstellte, schöne Landschaft grundhaft zu überarbeiten, sei dahingestellt. Ebenso die Frage, ob da dann wirklich ein Fremdautor ohne Zugriff auf die Ausgangsressourcen Hand anlegen möchte. Ich halte es da mit der Medizinerweisheit aus der Suche nach Krankheitsursachen: "Häufiges ist häufig, Seltenes ist selten."

Du hat Recht, das ist eine "politische" Frage. Natürlich werde ich meine Vorgehensweise nicht als allgemeingültig erklären. Unter Abwägung der Chancen und Risiken komme ich für meine Bauvorhaben zu der Einschätzung, dass diese durchaus zeitraubenden Arbeiten sinnvoll sind, um den Endanwendern eine möglichst schnell ladende und performante Strecke zur Verfügung zu stellen. Es gibt Bauprojekte wie z.B. Grenzlandbahnen, die das genauso handhaben. Aber das ist die Entscheidung des jeweiligen Teams.

Lassen wir es am besten dabei bewenden.

Grüße
Michael

p.s.: Zusammengefasste Landschafts-Meshes lassen sich bei Bedarf schnell wieder auftrennen. Der Editor bietet zum Handling sogar gute Hilfsfunktionen, z.B. für die Auswahl zusammenhändender Dreiecke.

[Matthias H.]

Das mit den nicht rückgängig zu machenden Optimierungen ist eine politische Frage, die man so oder anders sehen kann

Genau, das wurde ja schon mehrmals diskutiert, und darüber werden wir uns wahrscheinlich nie auf ein einheitliches Vorgehen einigen können.

Was die Landschafts-Subsets angeht (nicht die Fahrleitung!), stelle ich persönlich den Nutzen für alle (ein paar fps mehr in kritischen Bereichen) vor meinen persönlichen Komfort (wenn ich nochmal an der Landschaft arbeite, muss ich ggf. erst über Dreieck-Selektion wieder Teile aus dem zusammengeführten Subset separieren).

Entgegen meiner früheren Annahmen bleibt die Detail-Kachel (und damit die Fahrleitung) unberührt, wenn man ein Subset auf der normalen Kachel selektiert und dann die Zusammenführung durchführt. Es ist also möglich, die Landschaft unabhängig von der Fahrleitung zusammenzuführen.

Um wirklich ohne Bedenken eine sinnvolle Zusammenführung über alles durchführen zu können, müsste man die Datenhaltung wohl in eine Entwicklungs- und eine Produktivversion trennen. Nach einer Anpassung schickt man die Bau-Kacheln durch einen Optimierungsprozess mit Zusammenführung und erhält dann eine Produktivversion, die im Simulator verwendet wird. Aber das ist auch wieder Träumerei

Gruß
Matthias

[Alwin Meschede]

Um wirklich ohne Bedenken eine sinnvolle Zusammenführung über alles durchführen zu können, müsste man die Datenhaltung wohl in eine Entwicklungs- und eine Produktivversion trennen.

Habe ich schonmal folgende alternative Idee hier im Forum ventiliert? Der Ladethread des Simulators lastet ja für gewöhnlich seinen Prozessorkern nicht aus und hat noch Zeit übrig. Der könnte beim Laden einer Kachel doch die Funktion "Meshsubsets zusammenführen" aufrufen, bevor er die Kachel an den Grafikthread des Simulators übergibt? Vorteil dieser Lösung: Wir bräuchten die Landschaften nicht irreparabel verändern oder doppelte Datenhaltung betreiben, und hätten trotzdem die Annehmlichkeiten gesteigerter Performance.

[Carsten Hölscher]

Kurz zur Einordnung: Streckenelemente ohne Gleisfunktion kosten keine fps und nur minimalst Speicher und Ladezeit. Also da dürfte der Nutzen der Löschung extrem gering sein.
Meshsubsets zusammenführen in kritischen Bereichen erscheint mir aber sinnvoll, wenn es zu fps-Steigerungen führt.
Die Meshsubsets "online" zusammenzuführen wird den Ladeprozess entsprechend verlängern, also z.B. bei Zeitraffer ist dann früher die Landschaft weg. Ich kann aber gerade den Aufwand dafür schlecht abschätzen, also wie groß dieser Effekt ist.

Carsten

[Wolfgang Hüttner]

Habe ich schonmal folgende alternative Idee hier im Forum ventiliert? Der Ladethread des Simulators lastet ja für gewöhnlich seinen Prozessorkern nicht aus und hat noch Zeit übrig. Der könnte beim Laden einer Kachel doch die Funktion "Meshsubsets zusammenführen" aufrufen, bevor er die Kachel an den Grafikthread des Simulators übergibt? Vorteil dieser Lösung: Wir bräuchten die Landschaften nicht irreparabel verändern oder doppelte Datenhaltung betreiben, und hätten trotzdem die Annehmlichkeiten gesteigerter Performance.

Der Vorschlag war schon einmal hier im Forum gemacht worden, wartet aber immer noch auf eine Umsetzung durch Carsten.
Daher bin ich der gleichen Meinung wie Michael Poschmann, dass man jetzt mit vergleichsweise geringem Aufwand eine Lösung hat, die sofort wirksam ist.
Da ich davon ausgehe, dass es sich um die ursprünglich von mir vorgeschlagene kachelweise Meshoptimierung handelt, schätze ich einmal wir reden über 10 Minuten pro Modul.
Es müssen ja nicht alle Kacheln bearbeitet werden, es reicht bei denen z.B. größer als 500kB. Diese in den 3D-Editor laden, ein Meshsubset markieren, die Funktion Meshsubsets optimieren und Meshsubsets zusammenführen auswählen und wieder abspeichern.

Was die Streckenelemente ohne Funktion betrifft möchte ich hier nochmals für meine Arbeitsweise mit 2 Streckendateien werben. Ich habe eine Streckendatei, die nur die tatsächlichen Gleiselemente enthält (und natürlich z.B. die für Bahnübergänge notwendigen Hilfselemente) und eine weitere mit allen für den Landschaftsbau benötigten Streckenelementen ohne Funktion. Die erste Datei ist die, die für die Veröffentlichung für den Fahrsimulator verwendet wird. Die zweite Datei könnte im SVN abgelegt bleiben und steht damit auch weiterhin für Verbesserungen oder auch für zukünftige zusätzliche Funktionen wie Straßenverkehr zur Verfügung. Wer sich das einmal anschauen möchte, der kann gerne einmal im SVN einen Blick in die Module Steinheim oder Schieder werfen, da ist das so gehandhabt.

Gruß
Wolfgang

[Matthias H.]

Da ich davon ausgehe, dass es sich um die ursprünglich von mir vorgeschlagene kachelweise Meshoptimierung handelt, schätze ich einmal wir reden über 10 Minuten pro Modul.

Ja, der Aufwand ist wirklich gering. Ich bin zuletzt genau so gemäß deinem Vorschlag vorgegangen und habe sowohl die Mesh-Optimierung als auch die Mesh-Zusammenführung kachelweise vorgenommen.

Die Gründe, die Zusammenführung evtl. nicht durchzuführen, liegen aber ja nicht im zeitlichen Aufwand begründet, sondern in der Endgültigkeit der Aktion ohne Möglichkeit, diese für spätere Anpassungen als Ganzes wieder zurücknehmen zu können.

Gruß
Matthias

[Wolfgang Hüttner]

Die Gründe, die Zusammenführung evtl. nicht durchzuführen, liegen aber ja nicht im zeitlichen Aufwand begründet, sondern in der Endgültigkeit der Aktion ohne Möglichkeit, diese für spätere Anpassungen als Ganzes wieder zurücknehmen zu können.

Für solche Fälle kann man sich ja auch noch eine Sicherungsdatei aufheben, das mache ich z.B. bevor ich die .lsb Varianten erstelle.
Außerdem ist es sehr unwahrscheinlich, dass ich bei einer späteren Nacharbeit an einem Modul wirklich exakt ein komplettes Landschafts - Meshsubset zu bearbeiten habe.
Es wird eher darauf hinauslaufen einzelne Dreiecke zu löschen und die entstandenen Lücken wieder aufzufüllen, dabei spielt es keine Rolle wie groß das Ausgangsmeshsubset ist.

Gruß
Wolfgang

[F. Schn.]

Es wird eher darauf hinauslaufen einzelne Dreiecke zu löschen und die entstandenen Lücken wieder aufzufüllen, dabei spielt es keine Rolle wie groß das Ausgangsmeshsubset ist.

Aber sobald man das macht, kann man diese Sicherungsdatei auch nicht mehr herauskramen kann, um doch etwas nachzurüsten. Und sofern du das in lsb bearbeitest, ist selbst die ohnehin sehr schwierige SVN*-3-Wege-Diff wahrscheinlich erfolglos.

* wobei das mit SVN nichts zu tun hat, sollte sich bei Git nicht ändern

[Matthias H.]

Für solche Fälle kann man sich ja auch noch eine Sicherungsdatei aufheben, das mache ich z.B. bevor ich die .lsb Varianten erstelle.

Sobald aber eine Änderung an der Kacheldatei vorgenommen wird, ist die Sicherungsdatei wertlos, weil dann inkonsistent zur Kacheldatei.

Man müsste also vor jeder Änderung die Sicherungsdatei wieder über die Kacheldatei speichern, die Änderung vornehmen und die Datei mit der Änderung wieder als Sicherungsdatei speichern. Dann wieder optimieren und lsb-konvertieren.
Das erfordert viel Disziplin und ist aufwändig.

Gruß
Matthias

[Wolfgang Hüttner]

Das erfordert viel Disziplin und ist aufwändig.

Das ist natürlich richtig und bisher habe ich das auch noch nicht wirklich benötigt. Ich hatte bislang noch nie den Fall, das in einer bereits optimierten Kachel jemals nochmal genau der Zugriff auf ein oder mehrere verschmolzene Meshsubsets erforderlich war. Es gab immer nur Änderungen an einzelnen Dreiecken.

Der Weg zurück ist im Notfalle über Umwege auch noch möglich wenn ich unbedingt die unverschmolzenen Meshsubsets benötigen sollte. Ich müsste dann in der aktuellen Datei das verschmolzene Meshsubset löschen und den Bereich aus der alten Sicherungskachel extrahieren und in der neuen Kachel wieder einfügen. Bekanntlich führen viele Wege nach Rom und bisher habe ich eigentlich auch für jedes Problem eine Lösung gefunden...

Gruß
Wolfgang

[F. Schn.]

Ich hatte zu Zusi-2-Zeiten auch Änderungen an der Seestrecke durchgeführt, während Ade_420 nicht erreichbar war. Dort waren die Polygone direkt ein eine ls-Datei pro Modul eingebacken. Ging auch. Wir sollten da nicht wider hin.

[Matthias H.]

Dort waren die Polygone direkt ein eine ls-Datei pro Modul eingebacken [...] Wir sollten da nicht wider hin.

Aber davon ist hier ja auch nicht die Rede. Ob zusammengeführt oder nicht, die Polygone bleiben auf der Kachel. Die Subsets werden nie kachelübergreifend zusammengeführt.