Zusi-Forum

Das ist auch nicht ganz von der Hand zu weisen. Computergrafik hat eben ihre Eigenheiten. Ich werde mal eine Testrunde mit manuell generierten Mipmaps starten.

Manuell generierte Mipmaps bringen ein bisschen was. In der Version 0.0.5 (siehe oben) habe ich die Textur mal dahingehend angepasst. Ausserdem wurde bislang die Tafel mit Mast 10 Zentimeter hoeher platziert als bei der bisherigen DLL, was ich auch korrigiert habe.

Hier ein Vergleich der Mipmap-Stufen. Links die bisherige Textur, in der Mitte die neue und rechts die Textur der Bestandstafeln. Angegeben ist der Mipmap-Bias (-25/0 -> Mipmap-Stufe 256px, 25 -> 128px, 50 -> 64px, 75 -> 32px, 100 -> 16px)

Habe die Hektometertafel.dll mal ausprobiert.
Auch für mich ist die Hauptanforderung die Lesbarkeit der Hektometertafel und die funktioniert mit "neuen" Hektometertafeln bestens.
Danke für die Arbeit, Johannes!

Beim Testen fiel mir jedoch auf, dass das Plugin beim Erzeugen der Tafeln den absoluten Ordnerpfad beginnend mit dem jeweiligen Laufwerksbuchstaben in die .ls3 im Ordner Kacheln geschrieben hat.
Eigentlich sollte der relative Pfad, wie Routes\usw.., in der .ls3 Datei drinnen stehen.
ZusiSim hat wegen dem absoluten Ordnerpfad dann Fehlermeldungen bei den Hektometertafeln rausgehauen, weil er sie nicht findet.
Als ich mit Notepad den Pfad in der .ls3 Datei bis zum Routes ordner löschte, gab es keine Fehlermeldungen mehr.

Entweder gibt es da noch eine Einstellung im 3D Editor, die ich nicht weiß, oder es liegt möglicherweise am Plugin.

Da ich bislang immer nur im 3D-Editor getestet habe und der sich nicht beklagt hat, hatte ich mir gedacht, das sei Zusi egal. Offensichtlich ist es das nicht

Ist aber weiter kein Problem; ich habe eine neue Version hochgeladen, die einen relativen Pfad an Zusi zurueckgibt.

Eine Option ist übrigens die Umstellung des Parameters TexVoreinstellung="8"/ durch TexVoreinstellung="4"/ in den bestehenden Hektometerzeichen und Kilometersteinen. Das geht mit Notepad++ recht zügig und erspart die Neuerstellung. Ich habe das mal als QS-Maßnahme für die Bestandsmodule Paderborn/Hagen-Kassel und die SFS durchgeführt.

Grüße
Michael

Michael_Poschmann hat geschrieben:Eine Option ist übrigens die Umstellung des Parameters TexVoreinstellung="8"/ durch TexVoreinstellung="4"/ in den bestehenden Hektometerzeichen und Kilometersteinen. Das geht mit Notepad++ recht zügig und erspart die Neuerstellung.

Kann man machen, wenn man mit der schlechteren Performance der alten Tafeln leben will. Die haben bauartbedingt in den meisten Fällen ein Meshsubset mehr als die Tafeln aus der neuen DLL.

Alle zweihundert Meter aufgegstellt, lässt sich vermutlich im Bestandsnetz damit leben.

Grüße
Michael

Ich bin jetzt nicht so der 3D-Crack mit den Wissen über Mesh-Subsets usw. Haben die 2 XML-Knoten Textur in Zeile 9 und 10 einen tieferen Sinn?

Michael

Wenn ich im Editor eine Tafel händisch neu erzeuge, hängt die plötzlich da oben. Ist das Feature? Oder wende ich das falsch an?

Du hast wahrscheinlich "immer ohne Mast" gewählt. Das ist nur für Spezialfälle (Tunnel) gedacht, wo man im Modus "eigener Standort" anstatt "Anbau an Ankerpunkt" unterwegs ist, aber keinen Mast haben will. Das Hektometertafel-Menü im 3D-Editor ist an der Stelle leider etwas kurzsichtig entworfen worden. An die Bedürfnisse von Tunnels hat Carsten beim Entwurf der Benutzeroberfläche wohl nicht gedacht. Deswegen ist der Mast in der neuen DLL gesondert über das Konfigurationsmenü abwählbar.

Ich habe tatsächlich den Haken ohne Mast absichtlich gesetzt. Ich habe "ohne Mast" als Rohr im Boden und freistehend ohne Oberleitung interpretiert.

Die DLL erzeugt eine Tafel

• mit Oberkante bei z=0, wenn "Montage am Ankerpunkt" angewaehlt ist
• mit Oberkante bei z=2.4, wenn "Eigener Standort" angewaehlt ist

und

• ohne Mast, wenn "Montage am Ankerpunkt" angewaehlt ist oder die Konfigurationsoption "Immer ohne Mast" aktiviert ist
• sonst mit Mast

Wenn du also eine Tafel manuell erzeugst, die du spaeter an einen Ankerpunkt anbauen willst, musst du trotzdem "Anbau am Ankerpunkt" auswaehlen.

Michael Springer hat geschrieben:Ich bin jetzt nicht so der 3D-Crack mit den Wissen über Mesh-Subsets usw. Haben die 2 XML-Knoten Textur in Zeile 9 und 10 einen tieferen Sinn?

Ja. Die Tafeln bestehen aus einem Subset mit zwei Texturen (eine fuer die Tafel-Grundflaeche und eine fuer die Ziffern). Da die hektometertafeln.dds sowohl Tafeln/Mast als auch Ziffern enthaelt, sind Textur 1 und 2 hier gleich.

Michael_Poschmann hat geschrieben:Eine Option ist übrigens die Umstellung des Parameters TexVoreinstellung="8"/ durch TexVoreinstellung="4"/ in den bestehenden Hektometerzeichen und Kilometersteinen. Das geht mit Notepad++ recht zügig und erspart die Neuerstellung.

Die Neuerstellung liesse sich uebrigens automatisiert erledigen; ich habe fuer diesen Zweck bei mir ein kleines Skript liegen. Aber wie man sieht, gibt es an der DLL und der Textur zuerst noch ein wenig zu feilen.

Neben der besseren Performance ist die Ziffernhoehe bei den "neuen" Tafeln noch ein wenig naeher am Vorbild (oder zumindest an dem, was ich als Vorbild kenne).

Hallo

Dieser Beitrag hat mir keine Ruhe gelassen durch diese Aussage "ohne Halbtransparenz".
Ohne jetzt sie Arbeit an der Erstellung der dll und der Textur zu kritisieren.
Johannes bist du dir sicher dass die Ziffern nicht mit Halbtransparenz gezeichnet werden?

Die Texvoreinstellung 3 "Textur1 standard/Textur2 transparent" nutzt nämlich für den Transparentbereich auch Alphablending also Halbtransparenz sofern
in der Textur Halbtransparenz vorhanden ist. In deiner Textur ist Halbtransparenz um die Ziffern vorhanden.
wie im Ausschnitt zu erkennen

Um Volltransparenz zu nutzen müssen die Ziffern sauber freigestellt sein ohne halbtransparenten Übergang.
Was im Nachgang eine größere Textur nach sich zieht um die Kanten sauber abzubilden.



Das beste Ergebnis wäre Texvoreinstellun=1 " 1 Textur standard" ohne irgendwelche Transparenzen, wobei dann in der Textur hinter den Ziffern
schon der Tafelhintergrund liegen müsste.

oder pro Tafel eine Textur erzeugt würde die komplett beschriftet ist für den jeweiligen Standort, was aber den Texturspeicher ausufern lassen würde da ja für
jede Tafel eine eigene Textur da sein muß.

Mein Ansatz wäre dahingehend die Standard Textur von dir auf mindestens 1024x1024 px zu vergrößern und die Ziffern sauber freizustellen um wirklich eine Voll
transparenz zu nutzen.

Ich sehe im Moment den Performancegewinn nur in dem Unterschied 2 Meshes alte dll und 1 Mesh neue dll, der aber in der Häufigkeit in der Strecke vorkommend
fast nicht messbar sein sollte.


Wie oben schon bemerkt, keine Kritik an der invesierten Arbeit deinerseits.
Ich wollte nur darauf hinweisen daß in diesem Fall mit den Texturvorraussetzungen auch Alphablending genutzt wird.

Jörg_S hat geschrieben:Die Texvoreinstellung 3 "Textur1 standard/Textur2 transparent" nutzt nämlich für den Transparentbereich auch Alphablending also Halbtransparenz sofern in der Textur Halbtransparenz vorhanden ist.

In der genannten Voreinstellung ist das Haekchen bei D3DRS_ALPHABLENDENABLE nicht gesetzt, also wird kein Alpha-Blending genutzt.

Das Mischen der beiden Texturen (wo natuerlich schon Texture Blending mittels Halbtransparenz beteiligt ist) passiert vorher in der Textureinheit und innerhalb desselben Draw Calls. Entscheidend ist, dass fuer das Blending nicht auf die bereits gezeichneten Pixel zugegriffen werden muss.

Der Performancegewinn kommt aber letztlich schon durch den Verzicht auf ein Subset zustande, und das eingesparte Subset hatte eben auch noch Alpha Blending aktiviert. Je nach Sichtbarkeitseinstellungen (die Tafeln sind bis in 3 km Entfernung sichtbar) spart das eine zweistellige, im Extremfall dreistellige Anzahl Draw Calls ein. Das erlaubt es dann, bei gleicher oder besserer Performance die Tafeln detaillierter zu gestalten.

Volltransparenz funktioniert meines Wissens wiederum nur mit zwei Subsets, da man fuer einzelne Texture Stages keinen Alpha-Ref-Wert einstellen kann.

Ok du hast natürlich recht. Ich geb mich geschlagen. Hab nicht weit genug gedacht.

Wäre es denn möglich ein Tool zu entwickeln das die bestehenden Tafeln zusammenbackt und auf die Texvoreinstellung 3 stellt?

damit würde nämlich in den Bestandsmodulen eine komplette Neuerzeugung der Tafeln entfallen.

Jörg_S hat geschrieben:Wäre es denn möglich ein Tool zu entwickeln das die bestehenden Tafeln zusammenbackt und auf die Texvoreinstellung 3 stellt?

Das waere ziemlich aufwaendig, wohingegen das Neuerzeugen ziemlich einfach ist, da die Tafeln ja alle nach Schema F generiert sind. Ich habe ein kleines Skript geschrieben, das die Geometrie einer bestehenden Tafel analysiert und Parameter fuer die neue DLL ausspuckt. Ich wuerde anbieten, dass ich, sobald alle mit der DLL zufrieden sind, das einmal ueber den Bestand laufen lasse und das Ergebnis ans ZPA schicke. Wer von den Streckenbauern will, koennte die so generierten Tafeln dann in seine Strecke uebernehmen, indem er die Dateien ins Hektometertafel-Verzeichnis kopiert.

Hallo Johannes,

danke für Deine Amtshilfe. Dabei wäre es natürlich sinnvoll, auch die noch nicht veröffentlichten Module zu beglücken, um einen durchgehenden, sauberen Stand zu schaffen.

Grüße
Michael

Dabei wäre es natürlich sinnvoll, auch die noch nicht veröffentlichten Module zu beglücken, um einen durchgehenden, sauberen Stand zu schaffen.

Bin ich im ersten Moment nicht glücklich mit. Ich weiß nicht ob euch bewusst ist, dass ich im Team Süd in einigen Modulen schon verwitterte Hektometertafeln im Einsatz habe, die andere (abgedunkelte/dreckigere) Texturen benutzen?

Michael