Diskussion zu Meshsubsets zusammenfassen

[F. Schn.]

Pro Modul oder Pro Kachel machte weder dort noch hier einen Unterschied. Was ich deutlich machen will: Mit viel unnötigem Aufwand bekommt man alles hin. Aber wenn das der neue Anspruch für Zusi3 ist...

[Matthias H.]

Verstehe deinen Einwand und den Unterton "neuer Anspruch" nicht.

Die Zusammenführung ist eine reguläre Funktion des 3D-Editors und aus Performance-Gründen sinnvoll. Deshalb nutze ich das auch - außer Fahrleitung - konsequent. Und wie Wolfgang habe ich für mich noch keine negativen Auswirkungen für eine nachträgliche Bearbeitung festgestellt.

Ein falscher Anspruch ist es aus meiner Sicht, mögliche Performance-Verbesserungen für alle Anwender ungenutzt zu lassen, weil man für nach der Fertigstellung wahrscheinlich seltene Anpassungen mal eine halbe Stunde mehr braucht, um eventuell zusammengeführte Subsets wieder auseinander zu nehmen - was ebenfalls mit Standardfunktionen des 3D-Editors möglich ist! Ich brauche dazu nicht mal alte Dateien.

[F. Schn.]

-

Ein falscher Anspruch ist es aus meiner Sicht, mögliche Performance-Verbesserungen für alle Anwender ungenutzt zu lassen, weil man für nach der Fertigstellung wahrscheinlich seltene Anpassungen mal eine halbe Stunde mehr braucht, um eventuell zusammengeführte Subsets wieder auseinander zu nehmen - was ebenfalls mit Standardfunktionen des 3D-Editors möglich ist! Ich brauche dazu nicht mal alte Dateien.

Mit so einer Einstellung ist Zusis Zukunft wohl verloren.

[Matthias H.]

Mit so einer Einstellung ist Zusis Zukunft wohl verloren.

Können wir bitte sachlich bleiben?

[Wolfgang Hüttner]

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.

Zusi3 ist an dieser Stelle mit Zusi2 nicht vergleichbar, bei Zusi2 gab es nur Polygone und keine Meshsubsets.

Das Problem entsteht beim Landschaftsbau im Polygonmodus. Hierbei wird jetzt in Zusi3 für jedes Polygon ein Meshsubset mit wenigen Vertices erzeugt. Tests in der Vergangenheit haben gezeigt, dass die Performance mit jedem zuätzlichen Meshsubset abnimmt. Nicht ohne Grund gibt es die Anforderung bei lod3- Modellen möglichst mit einem Meshsubset auszukommen. Daher ist es eben sinnvoll am Ende des Landschaftsbaus diese hohe Anzahl von Meshsubsets durch das Verschmelzen zu reduzieren und damit die Performance zu steigern. Wie schon mehrfach erwähnt macht das nur Sinn bei reinen Landschaftsmeshsubsets und genau das wird durch die beschriebene Vorgehensweise erreicht ohne das dadurch wirklich unüberwindbare Nachteile entstehen.

Gruß
Wolfgang

[F. Schn.]

Ich denke, ich habe meine Punkte klar gemacht. Ich habe in Zusi 2 (Ebenfalls mit Standardfunktionen des Editors!!) so etwas schon auseinander nehmen müssen, und ich habe das in Zusi 3 spielerisch auch schon gemacht (ja, bei Landschafts-Subsets, und ja mit den Standardfunktionen des Editors!!), wobei ich massive Probleme hatte, weil ich bestimmte Dreiecke einfach übersehen habe. In so fern sehe ich da nichts, was ich dem hinzufügen kann. Ich bleibe jedoch bei meiner Abwägung, und sehe das mit Sorge.

PS: Es gibt innerhalb der Mesh-Subsets auch keine Polygone, sondern nur Dreiecke.

[Matthias H.]

und ich habe das in Zusi 3 spielerisch auch schon gemacht (ja, bei Landschafts-Subsets), wobei ich massive Probleme hatte, weil ich bestimmte Dreiecke einfach übersehen habe.

Was war denn genau der Anwendungsfall, den du spielerisch nachstellen wolltest? Die Dreiecke, die ich aus einem Subset wieder herauslösen möchte, sehe ich normalerweise vor mir auf dem Bildschirm.

[Alwin Meschede]

Wenn Leute, die selber von sich sagen dass sie noch nie Großumbauten in Bestandsmodulen gemacht haben, mir (der schon mehrfach Großumbauten in Modulen fremder Autoren gemacht hat - Kassel-Wilhelmshöhe, Göttingen Pbf, Lippoldshausen fallen mir da spontan ein) sagen dass das doch alles total easy ist und es auch egal ist ich mal eine Stunde mehr von meiner Zeit opfern muss, dann hat das in der Tat schon ein gewisses Geschmäckle. Das deutet nämlich darauf hin, dass die genannten Großumbauten wohl von den falschen Leuten gemacht wurden. Ich hätte mich da wohl besser zurückgehalten... Also ich glaube gerne, dass man als Ursprungsautor des Moduls ganz prima "nach mir die Sintflut" sagen kann. Die Scherereien mit solchen Vorgehensweisen werden wohl in der Regel andere Autoren haben (nämlich diejenigen, die Zusi noch über den vorhandenen Bestand hinaus voranbringen wollen). Also mir wäre es ein menschliches Bedürfnis, dass ich fremden Autoren nicht zur Last falle mit meinen Baumethoden. Nicht zum ersten Mal fällt mir auf, dass das aber wohl teilweise anders gesehen wird. Das ist dann ein recht effektiver Weg, um Engagement anderer Leute abzuwürgen. Die sagen dann einfach "diese ranzigen Altbestände sind sowieso hoffnungslos unrettbar" und machen halt anderswo weiter.

[Wolfgang Hüttner]

Ich denke, ich habe meine Punkte klar gemacht. Ich habe in Zusi 2 (Ebenfalls mit Standardfunktionen des Editors!!) so etwas schon auseinander nehmen müssen, und ich habe das in Zusi 3 spielerisch auch schon gemacht (ja, bei Landschafts-Subsets, und ja mit den Standardfunktionen des Editors!!), wobei ich massive Probleme hatte, weil ich bestimmte Dreiecke einfach übersehen habe.

Nochmal, ich glaube Du verwechselst da was. In Zusi2 gab es nur eine Funktion zum Einbinden von verknüpften Objekten. Das führte dort in der Tat zu massiven Problemen und machte nachträgliche Änderungen nahezu unmöglich. Davon ist hier aber überhaupt nicht die Rede, verknüpfte Objekte bleiben verknüpft. Durch diese Funktion entstehen weder zusätzlichen Dreiecke noch werden Dreiecke entfernt, diese werden lediglich einem anderen Meshsubset zugeschlagen. Dein Einwand ist somit absolut unbegründet, nach der beschriebenen Operation hast Du exakt noch die gleiche Dreiecksstruktur wie vorher. Daher verstehe ich nicht, wie Du da Dreiecke übersehen willst.

Gruß
Wolfgang

PS: Ich habe nie behauptet, dass es Polygone in Meshsubsets gibt. Dennoch bilden zusammenhängende Dreiecke eines Meshsubsets ein Polygon.

[F. Schn.]

Bettung rausreißen, Weichen rausreißen, Löcher in die Grundplatte machen, um Straßen zu verlegen und ein Haus zu setzen.

Spielerisch bedeutet, dass es in dem Fall nie zu Produktivergebnissen kam - bis auf jetzt Paderborn, dort ist der Fall aber etwas anders gelagert, weil es dort um den Geländeformer geht. (Trotzdem habe ich nichts dagegen, wenn das jemand noch mal professionell macht, das was ich jetzt geschafft habe, sehe ich eher als Provisorium an.)

Zu den Dreiecken: Bei Zusi 2 konnte ich immer ein Polygon löschen - außer Zusi 2 hat die Triangulation schlecht gemacht. Bei Zusi 3 kann ich die Funktion der "Nachbarn im Subset" nur nutzen, wenn sie nicht doch irgendwie verbunden sind. Wenn doch, bin ich auf Dreiecke angewiesen. Und wenn ich dann gerade ein langes, schmales Dreieck übersehe, stehe ich weit schlechter da, als in Zusi 2. Noch schlimmer ist es, festzustellen, dass überhaupt das Subset noch verbunden ist. Ich habe auch schon Texturen getauscht und später erst festgestellt, dass da irgend ein anderes Dreieck an einer anderen Stelle der Kachel noch im selben Subset hing. Diese Fußangeln hatte man bei der Polygonbasierten Vorgehensweise von Zusi 2 nicht. Deswegen habe ich so getan, als seien beide Vorgehensweisen vergleichbar.

Da das keine professionellen Aktionen waren, ich dafür keine Workflows vorbereitet habe, und nicht kontrolliert habe, welche Tricks ich noch alles anwenden kann, um die Mesh-Zusammenführung rückgängig zu machen, kann ich in meinen Augen daraus nur Rückschlüsse auf eine bevorzugte Datenstruktur bzw. Datenarchitektur ziehen, nicht auf einen Idealen Workflow. Nachdem Alwin aber mit Sicherheit schon professionelle Workflows macht, scheint meine Analyse aber nicht ganz daneben zu liegen.

[oberstrom (Markus)]

Vorhersagen nach dem Motto "brauchen wir ohnehin nie (mehr)" sind oft riskant und können einem später böse auf die Füße fallen. Ich denke da u.a. an nicht abfotografierte Schalterstellungen für Zusi 2-Führerstände, was vor allem dann ärgerlich ist, wenn die Bildauflösung ein Hochskalieren zugelassen hätte. Eine Möglichkeit wäre, das Zusammenführen der Mesh-Subsets immer als letzten Arbeitsgang zu machen, diese Kacheln nochmal in einen separaten Ordner zu speichern und Zusi so zu programmieren, dass bei Vorhandensein aus diesem Verzeichnis geladen wird.

[Jens Strumberg]

Nur mal aus der Erfahrung heraus: In 13 Jahren Zusi 3-Arbeit habe ich mit der Funktion zum markieren von Dreiecken selten Probleme gehabt. Gerade eben habe ich mit einem Mausklick problemlos ein Gleisbett entfernt und per Shape gegen ein ausgekoffertes Gleisbett ersetzt. Dauer: Vielleicht drei Sekunden für 300 Meter. Da möchte ich nicht klagen.

Bevor wir uns hier die Köppe einschlagen, sollten wir vielleicht herausstellen, welcher Nutzen wertvoller ist: Die Performance auf schwächeren Rechnern oder ein angenehmeres, nachträglicheres Ändern des Altbestandes. Wollen wir den Vielen, die Nutzen, das Leben leichter machen, oder den Einzelnen, die wertschöpfend arbeiten? Das ist ein durchaus philosophischer Ansatz.

[F. Schn.]

Nur mal eine Bitte an Carsten: Sofern das Thema noch mal irgendwo auftaucht, glaube ich kaum, dass ich es im Modul Göttingen wieder finde. Ohnehin habe ich wie oben beschrieben in diesem Modul stabil hohe fps, aber stattdessen einen einzelnen Mikroruckler, der vermutlich nicht von der Anzahl der Subsets kommt. Kann ich daher eventuell eine Auslagerung des Themas beantragen?

[Carsten Hölscher]

Manchmal liegt die Wahrheit auch in der Mitte. Auf der Siegstrecke, die ja wirklich nicht besonders komplex ist, lief die Strecke auf meinem PC gar nicht mehr durch wegen zu vieler Subsets. Auf dem flachen Land muss man sich sonst auch weniger Gedanken machen als in den fps-kritischen Knoten. Was ist denn das Bearbeitungsproblem bei zusammengefassten Subsets? So ganz klar ist mir das noch nicht.

Carsten

[Matthias H.]

nämlich diejenigen, die Zusi noch über den vorhandenen Bestand hinaus voranbringen wollen

Ja, und damit haben wir doch irgendwie alle das selbe Ziel. Ich möchte alle mir möglichen Maßnahmen ausschöpfen, damit der Anwender (mich eingeschlossen) mit der bestmöglichen Performance durch die Zusi-Welt fahren können.

Ich finde es etwas schade, wenn mir und anderen mit diesem Ansatz pauschal Egoismus und Gefährdung der Zukunft von Zusi unterstellt wird.

Ich habe auch nicht gesagt, dass alles easy ist. Die Problematik mit dem Zusammenführen von Fahrleitungs-Subsets habe ich verstanden, und tue es seitdem auch nicht mehr.

Und ich sage auch nicht, dass es egal ist, wenn DU für Autoren mit "nach mir die Sintflut Mentalität" Zeit opfern musst. Du hast jahrelang hinter anderen her aufgeräumt, den Frust verstehe ich.
Ich kann für mich selber sagen, dass ich als Konsequenz dieser Zusammenführungs-Maßnahmen in den von mir gestalteten Modulen bereit bin, nachträglich mehr Zeit zu investieren, wenn es sein muss. Ich hoffe auch, dass ich noch ein paar Jahrzehnte lebe...

So, das reicht dann auch jetzt. Wie anfangs schon gesagt werden wir uns in dieser Sache wohl nie alle einig. Aber vielleicht ist ja eines Tages doch mal Zeit für mehr programmseitige Unterstützung. Sei es gezielteres Zusammenführen, die Möglichkeit, das Zusammenführen wieder rückgängig zu machen oder den Simulator diese Aktion "online" erledigen zu lassen.

Gruß
Matthias

[Matthias H.]

Was ist denn das Bearbeitungsproblem bei zusammengefassten Subsets? So ganz klar ist mir das noch nicht.

Wenn man ein Subset markiert und die Funktion "Zusammenführen" ausführt, werden nicht nur Subsets mit diesen Eigenschaften zusammengeführt, sondern die Aktion greift für sämtliche Subsets auf der Kachel.
Wenn ich also z. B. mir ein Stück "Terrain"-Landschaft im Polygonbaumodus zusammengebastelt habe, kann ich es nicht einfach durch die Funktion zusammenführen lassen, wenn ich nicht will, dass z. B. gleichzeitig auch alle Bettungs-Subsets angefasst und zusammengeführt werden.

EDIT: Das war gar nicht deine Frage... Mir ist es - außer der Fahrleitung - auch immer noch nicht ganz klar, was hinter dem "Großumbau" und in dem Zusammenhang die Schwierigkeit mit zusammengeführten Subsets steckt. Alwin, vielleicht kannst du ein paar Beispiele bringen?

[Thomas U.]

Wenn man ein Subset markiert und die Funktion "Zusammenführen" ausführt, werden nicht nur Subsets mit diesen Eigenschaften zusammengeführt, sondern die Aktion greift für sämtliche Subsets auf der Kachel.
Wenn ich also z. B. mir ein Stück "Terrain"-Landschaft im Polygonbaumodus zusammengebastelt habe, kann ich es nicht einfach durch die Funktion zusammenführen lassen, wenn ich nicht will, dass z. B. gleichzeitig auch alle Bettungs-Subsets angefasst und zusammengeführt werden.

Dennoch eine Sache, die mich auch als kleiner Gelegenheitsbastler gerne mal ärgert und wegen der ich schon wundersame Momente hatte, weil am anderen Ende der Kachel ebenfalls was zusammengeführt wurde... klar, jetzt könnte man sagen "dann lass' halt die Finger davon", aber mehrere kleine Bereiche einzeln anzupacken, ist dann auch doof.

Vorstellbar wäre für mich eine "Multifunktion":
- keine Subsets markiert: alle zusammenführen (wie bisher)
- ein Subset markiert: alle Subsets des ausgewählten Typs zusammenführen
- zwei oder mehr Subsets markiert: nur die markierten zusammenführen


Ansonsten verstehe ich die Diskussion auch nur so halb. Änderungen an zusammengeführten Flächen fand ich bisher nicht wirklich problematisch und wüsste nicht, wo da nun der extreme Mehraufwand bei eventuellen Nacharbeiten sein soll, der dagegen spricht, diese Funktion für eine bessere Performance zu nutzen. Aber wie gesagt, ich bin ja nur Gelegenheitsbastler.