Angepinnt Bump-Maps erstellen und im FSX anwenden

    • Tutorial

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Bump-Maps erstellen und im FSX anwenden

      Mit dem FSX können nun auch Bump-Maps verwendet werden. Damit kann der Detailgrad von Modellen extrem erhöht werden, ohne zusätzliche Polygone verwenden zu müssen.
      In diesem Tutorial werde ich aufzeigen, wie man eigene FSX kompatible Bump-Maps herstellt und anwendet.
      Das ganze funktioniert mit Photoshop oder dem kostenlosen Gimp, das ich für das Tutorial benutze.
      Zum jeweiligen Grafikprogramm wird ein spezielles Plugin benötigt:

      Photoshop: developer.nvidia.com/object/photoshop_dds_plugins.html

      Gimp: code.google.com/p/gimp-normalmap/

      Zum erfolgreichen Gelingen werden ein wenig Gmax kenntnisse vorausgesetzt. Man sollte wissen, wie man ein einfaches Objekt in Gmax erstellt, eine Textur auflegt, exportiert und im FSX platziert. Auch wäre es von Vorteil, wenn man den Umgang mit dem entsprechenden Grafikprogramm schon etwas kennt.

      Nun kanns losgehen! :rolleyes:

      Wir erstellen ein verchromter Zylinder, den wir mit einer einfachen Bump-Map aufpeppen werden.
      Als erstes müssen wir eine Grundtextur machen. Diese kann einfach aus einer grauen Fläche bestehen und muss ein passendes Format haben (z.B. 512x512 Pixel).
      Nun können wir den Zylinder in Gmax modellieren, dann erstellen wir ein neues FlightSimX- Material:



      #1 Hier geben wir wie gewohnt unsere Grundtextur ein, im Feld Specular können wir nun eine beliebige, helle Farbe auswählen für den Glanz.
      #2 Wir setzten den Haken, damit das Modell Reflektionen hat. Dabei wird die Standard reflection-map verwendet.

      Die restlichen einstellungen können wir auf Standard lassen.
      Mit einem Klick auf Apply fügen wir das Material dem Zylinder zu.

      Jetzt muss ein UVW Mapping gemacht werden:



      #1 ist unsere Auswahl, dann klicken wir auf Fit (#2). Falls das Ergebnis nicht wie auf dem Bild werden sollte, kann bei Alignment X oder Y ausgewählt werden.
      #3 mit einem Rechtsklick öffnen wir das Menu und wählen "Collapse All"

      Jetzt speichern wir das ganze erstmal ab und exportieren das Modell.
      Nach dem Platzieren im FSX können wir unser Werk erstmals betrachten.



      Wir sehen, dass alles geklappt hat! Das Modell ist Spiegelblank glänzend, sieht langweilig und unrealistisch aus! :S


      Das ändern wir jetzt!
      Meine Idee ist, dass das Modell aus mehreren Blechen mit leichten Dellen zusammengenietet ist.
      Dazu kommt jetzt das Grafikprogramm zum zug. Als erstes erstellen wir eine Textur, dunkle Stellen sind Vertiefungen, helle Erhebungen.



      Ich hatte in Gimp unter Filter/Render/Wolken plastisches Rauschen hinzugefügt, dann das Gitter hinzugefügt. Dieser Filter ist unter Filter/Render/Muster zu finden. Zuletzt malte ich mit dem Pinsel die Nieten auf.
      Möchte man z.B. eine Mauer mit Bump-Maps versehen, kann die originale Mauer-Textur für die nächsten Schritte verwendet werden.

      Jetzt können wir das normalmap Plugin laden, bei Gimp findet man dies unter Filter/Abbilden/Normalmap
      Im neu geöffneten Fenster klicken wir auf 3D Preview.



      Im Vorschaufenster können die Einstellungen nach belieben so getätigt werden, dass das Objekt gut erkennbar ist.
      Im kleineren Fenster wird das Bump-Mapping gesteuert. Da kann mit den Einstellungen rumgespielt werden, bis es einem passt. Es ist darauf zu achten, dass man den Effekt möglichst über die Textur steuert, wenn man zuviel im Plugin verstärken muss, kann es dazu führen, dass der Effekt schnell zu stark wird.
      Mit einem Klick auf OK wird die Normalmap erstellt.
      Das Bild speichern wir als Photoshop-Bild mit der Endung .psd ab. (Auch in Gimp!)



      Der nächste Schritt besteht darin, dass wir die Textur FSX kompatibel machen müssen. Dazu verwenden wir das ImageTool, zu finden im SDK (...\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Terrain SDK).
      Wir erstellen ein Ordner, kopieren das ImageTool hinein und auch die unsere soeben erstellte Normalmap. Zum Konvertieren benötigen wir spezialfunktionen des ImageTools. Dazu erstellen wir eine Textdatei mit folgenden Inhalt:
      imagetool -nobeep -nomip -dxt5 -RedInAlpha -dds -nodither *.psd

      Die Datei speichern wir unter einem beliebigen Namen mit der Endung .bat ab. (z.B. psd2bump.bat)
      Mit einem Doppelklick auf die .bat wird die Normalmap automatisch umgewandelt und als .dds gespeichert.



      So ist die Textur bereit für den FSX. Man kann erkennen, dass sie verändert wurde und einen Alphakanal bekommen hat.

      Jetzt geht es in Gmax weiter. Wir öffnen unsere Datei mit dem Zylinder, dann den Materialeditor.



      #1 Da weisen wir die Bump-Map zu. Dazu nehmen wir die .psd-Datei, da Gmax keine .dds-Files verarbeiten kann.
      #2 Hier kann eingestellt werden, wie oft die Bump-Map Textur auf der Diffuse-Textur wiederholt wird. Das lassen wir auf 1.

      Weitere Einstellungen sind nicht nötig. Nun können wir das Modell wieder Exportieren und im FSX Platzieren.



      Sieht doch schon viel besser aus als am Anfang! :D

      Hier noch ein Vergleich:



      Nun wünsche ich viel Spass beim Experimentieren! :thumbup:

      In diesem Tutorial verwendete Software:
      Windows XP mit DirectX 9
      FSX SP2/Acceleration und entsprechendes SDK
      Gmax V1.2 mit dem FSX Gamepack
      the Gimp V2.6 mit dem normalmap plugin V1.2.2

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ThomW ()

    • Sehr schön Thomas.

      Vielen Dank für die Anleitung.

      (Kein Meckern, eher ein Hinweis, weil es geht ja nicht um die Bump Map.

      Jede Texture mehr im FS erhöht den DrawCall - ergo auch weniger Performance.
      Man sollte wirklich nachdenken ob solche Eyecandys nötig sind. Bei einem kleinen Airport mag das noch gehen,
      aber bei Megaairports kann sowas auch schon zu Microrucklern führen. )
      MfG
      Dr. f.s. Sandra Marion R.
      Polygon-Dompteuse

      Hurrraaaaa - es wird Morgens hell und Abends dunkel.
    • Sandra_007 schrieb:

      Sehr schön Thomas.

      Vielen Dank für die Anleitung.

      (Kein Meckern, eher ein Hinweis, weil es geht ja nicht um die Bump Map.

      Jede Texture mehr im FS erhöht den DrawCall - ergo auch weniger Performance.
      Man sollte wirklich nachdenken ob solche Eyecandys nötig sind. Bei einem kleinen Airport mag das noch gehen,
      aber bei Megaairports kann sowas auch schon zu Microrucklern führen. )
      Sorry Sandra,

      aber bis Du Dir bei deinem sicher nett gemeinten Hinweis wirklich sicher, dass er korrekt ist?

      Ein Bump-Map Texture ist ein Parameter der Materialdefinition und wird mit dieser übertragen, daher ist mir völlig neu, das eine Bump-Map einen zusätzlichen "Drawcall" erzeugen soll.
      Ein Wechsel der Materialdefinition erzeugt einen erneuten Drawcall, aber nicht ein zusätzlicher Parameter der Selbigen.
      mfg
      Oliver Pabst

      Beitrag von Gast ()

      Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.
    • Jede Texture mehr im FS erhöht den DrawCall - ergo auch weniger Performance.
      Im FSX kann ich aber auch deutlich grössere Texturen als 1024x1024 verwenden. Ausserdem können die meisten Materialeigenschaften nun via Textur definiert werden. Wer für FSX optimiert baut, der verzichtet auf die bei FS9 scenery üblicherweise benutzte hohe Anzahl kleiner Texturen, und verwendet bestenfalls ein halbes Dutzend extrem grosse FSX Texturen. Das Mapping ist zwar eine Heidenarbeit, aber die Performance im FSX ist phänomenal.

      Tom
    • opabst schrieb:

      Sandra_007 schrieb:

      Sehr schön Thomas.

      Vielen Dank für die Anleitung.

      (Kein Meckern, eher ein Hinweis, weil es geht ja nicht um die Bump Map.

      Jede Texture mehr im FS erhöht den DrawCall - ergo auch weniger Performance.
      Man sollte wirklich nachdenken ob solche Eyecandys nötig sind. Bei einem kleinen Airport mag das noch gehen,
      aber bei Megaairports kann sowas auch schon zu Microrucklern führen. )
      Sorry Sandra,

      aber bis Du Dir bei deinem sicher nett gemeinten Hinweis wirklich sicher, dass er korrekt ist?

      Ein Bump-Map Texture ist ein Parameter der Materialdefinition und wird mit dieser übertragen, daher ist mir völlig neu, das eine Bump-Map einen zusätzlichen "Drawcall" erzeugen soll.
      Ein Wechsel der Materialdefinition erzeugt einen erneuten Drawcall, aber nicht ein zusätzlicher Parameter der Selbigen.
      Da sind 2 Texturen im Material Editor:



      Ergo auch 2 Texturen im FS Texture Ordner.

      Jede Texture im Texture Ordner ein Drawcall.

      Möchtest du mir das Designen beibringen Oliver ?
      MfG
      Dr. f.s. Sandra Marion R.
      Polygon-Dompteuse

      Hurrraaaaa - es wird Morgens hell und Abends dunkel.
    • Sandra_007 schrieb:

      Ergo auch 2 Texturen im FS Texture Ordner.
      Jede Texture im Texture Ordner ein Drawcall.
      Möchtest du mir das Designen beibringen Oliver ?
      Wenn das Zählen der Texturen BMP's für Dich die Anzahl der Drawcalls bestimmt, nein, dann kann ich Dir nichts beibringen, da fehlt dann wohl zu viel und vorallem die Bereitschaft sich mit dem Thema fachgerecht zu beschäftigen.
      mfg
      Oliver Pabst
    • Du weißt was Drawcall Batching ist ?
      Warum hat wohl MS im FSX die Größe der Texturen erhöht ?

      Deswegen sind die ja die Performancen der Europäischen Software Entwickler so Gut. :P

      Auf der Süd-Kugel haben die etwas mehr Wissen.

      Aber mit dir möchte ich ja auch nicht diskutieren.
      Weil du auch keine Bereitschaft zeigst.
      (Thema beendet)

      Es war nur eine Anmerkung.
      MfG
      Dr. f.s. Sandra Marion R.
      Polygon-Dompteuse

      Hurrraaaaa - es wird Morgens hell und Abends dunkel.
    • tomPA schrieb:

      Jede Texture mehr im FS erhöht den DrawCall - ergo auch weniger Performance.
      Im FSX kann ich aber auch deutlich grössere Texturen als 1024x1024 verwenden. Ausserdem können die meisten Materialeigenschaften nun via Textur definiert werden. Wer für FSX optimiert baut, der verzichtet auf die bei FS9 scenery üblicherweise benutzte hohe Anzahl kleiner Texturen, und verwendet bestenfalls ein halbes Dutzend extrem grosse FSX Texturen. Das Mapping ist zwar eine Heidenarbeit, aber die Performance im FSX ist phänomenal.

      Tom
      Hallo Tom,

      wenn man die größeren BMP's nicht zur Auflösungsverbesserung nutzt, ja dann kann das extreme Vorteile bieten, aber nur wenn man sie in einem MDL Export komplett nutzt, also nicht mit mehreren MDL die gleich Texture verwendet, dann wäre es eher kontraproduktiv.
      Leider kommen halt auch die flächige Ausdehnung der Objekte noch ins Spiel, wäre es in der Theorie möglich, ein Flughafen mit einer MDL zu bauen, die eine große BMP nutzt, hätte man das Optimum, zumindest bezüglich der Calls, aber man hätte dabei keine Optimierung bezüglich Sichtfeld etc., dh. das geschickte "dazwischen" ist dann letztendlich entscheident.

      Aber das ist ja eigentlich nicht das Thema hier, Bump-Map Texturedefinitionen sind jedenfalls bei vernünftigem Einsatz sehr hilfreich, schaffen Polygoneneutral Volumen, sind drawcalls neutral, aber natürlich Speicherrelevant und bei unmäßigem Einsatz auch ggf. optisch nicht wirklich hilfreich.
      mfg
      Oliver Pabst
    • opabst schrieb:

      Leider kommen halt auch die flächige Ausdehnung der Objekte noch ins Spiel, wäre es in der Theorie möglich, ein Flughafen mit einer MDL zu bauen, die eine große BMP nutzt, hätte man das Optimum, zumindest bezüglich der Calls, aber man hätte dabei keine Optimierung bezüglich Sichtfeld etc., dh. das geschickte "dazwischen" ist dann letztendlich entscheident.
      Stimmt so auch nicht ganz.

      Im FS9 gibt es da keine Begrenzung (im FSX habe ichs noch nicht getestet) alles in eine bgl zu stecken.

      Das Kreuz hat einen Radius von 8 km - und soweit ich weiß gibts keine Airports mit mehr als 16 km Durchmesser.



      An jedem Ende der Kreuzbalken steht ein Haus.

      Es ist zwar nicht ganz so einfach, aber möglich ist es, alles in eine bgl zu stecken.
      MfG
      Dr. f.s. Sandra Marion R.
      Polygon-Dompteuse

      Hurrraaaaa - es wird Morgens hell und Abends dunkel.
    • Sandra_007 schrieb:

      opabst schrieb:

      Leider kommen halt auch die flächige Ausdehnung der Objekte noch ins Spiel, wäre es in der Theorie möglich, ein Flughafen mit einer MDL zu bauen, die eine große BMP nutzt, hätte man das Optimum, zumindest bezüglich der Calls, aber man hätte dabei keine Optimierung bezüglich Sichtfeld etc., dh. das geschickte "dazwischen" ist dann letztendlich entscheident.
      Stimmt so auch nicht ganz.
      Im FS9 gibt es da keine Begrenzung (im FSX habe ichs noch nicht getestet) alles in eine bgl zu stecken.
      Sandry,
      es ging nicht um Sichtweite, sondern um Sichtfeld.

      Also um die Frage, ob es überhaupt Polygone im aktuellen Sichtfeld (Bildschirmausschnitt) des Objektes gibt, oder ob die Engine bereits vor dem Übertragen an die Grafikkarte entscheiden kann, dass dieses Objekt für die Darstellung irrelevant ist, da es hinter oder neben dem Sichtfeld liegt und es somit garnicht erst zu einer Übertragung kommt, also auch ein Drawcall entfällt.

      Wenn man durch die Möglichkeit größerer BMP's zu verwenden dort mehr Polygonefläche reinpackt, also mehr Objekte durch ein Material abdeckt und in einer MDL zusammenfasst um Drawcalls einzusparen, dann muss man dennoch darauf achten, dass diese Objekte möglichst in einem überschaubaren und abgegrenzten Radius liegen. Der Compiler (xtoMdl oder BGLC) bestimmt die Ausdehnung/Radius eines Objektes und hinterlegt diesen im Code. Daran ermittelt die Engine, ob ein Objekt überhaupt im Sichtfeld liegt und gerendert werden muss. Hier wird es dann passieren, dass keines der Polygone im Sichtfeld liegt, aber alles gerendert wird, da die Engine aufgrund der Ausdehnungdaten der Meinung ist, das Objekt ist relevant.

      Ein Beispiel:
      Ich habe an jedem Runwayende eine Localizer Antenne. Diese nutzen beide das gleiche Material, also könnte ich sie in einer MDL zusammenfassen und als ein Objekt platzieren, dass dann aber eine extrem Ausdehnung hat.
      Im Anflug ist das gut, da ich beide Antennen sehe, durch die Zusammenfassung einen Drawcall spare.
      Bin ich über die eine Antenne hinweg, sehe ich nur eine von beiden, die Hälft der Polies wird angezeigt, aber alle gerendert, auch wenn sie hinter mir liegen. Auch noch unkritisch, da es ja nachwievor nur ein Drawcall ist, der auch bei zwei Objektplatzierungen nötig wäre.
      Stehe ich aber quer zur Runway, sehe also keine der beiden Antennen, kann die Engine dies nicht wissen, da die Ausdehnung des Objektes ihr vorgaukelt, dass das Objekt noch im Sichtfeld ist. Hier wird also alles weiterhin durch die Graflkkarte gejagt, obwohl nichts davon angezeigt wird.

      Im ungüstigsten Fall kann es also passieren, dass alles durch die Engine verarbeitet werden muss, obwohl nur ein kleinster Teil im Sichtfeld liegt, das hilft dann bezüglich der Performance auch nichts, selbst wenn man die Drawcalls reduziert hat.
      mfg
      Oliver Pabst
    • Ein hochinteressanter Beitrag Oliver! Schade dass man derlei nicht öfter zu lesen bekommt. Im Gegensatz zu dem üblicherweise publizierten "gefühlten Wissen" hat das nachvollziehbare Substanz. Leider muss man sich seine FSX und Gmax-Techniken mühevoll aus dem Netz zusammenkratzen. Die meisten Tutorials bleiben leider immer bei den Basics hängen, oder sind nur schlecht aus dem Englischen übersetzte Plagiate. Gerne mehr von dieser Art.
    • Mich würde interessieren, was genau ein "DrawCall" ist - im Internet finden sich dazu widersprüchliche Angaben. Ist damit ein Satz "Primitives" gemeint, die alle dasselbe Material (und Transformation) haben?

      Ich frage, weil technisch gesehen ein Primitve (also Dreieck) mehrere Texturstufen durchlaufen kann (Mutlitexturing). Es ist daher nicht notwenig, ein Dreieck zweimal durch die ganze Pipeline zu jagen, wenn ich "Decals" und "Bumpmapping" haben möchte.

      Beitrag von Gast ()

      Dieser Beitrag wurde gelöscht, Informationen über den Löschvorgang sind nicht verfügbar.
    • Ja okay Oliver akzeptiert die Erklärung.

      Aber was solls, wir müßen eben mit dieser *Engine* leben, wir bekommen keine Neue, *Intelligente*.

      Und ich bin immernoch nicht zufrieden.

      Ich fliege eine Kurve - es kommt zu Rucklern weil viel *Neues* in mein Sichtfeld gerät.
      Es dürfte ja nicht sein, weil ja die Engine schon alle bgl gelesen haben sollte und im Grakaspeicher vorliegen sollte.
      Shi(t)) Happen.

      Wie dem auch sei, wir müßen eben mit dem *Müll* leben, wenn wir fliegen wollen.

      Es gibt keinen neuen Flight Simulator in absehbarer Zukunft.

      Ich kann sehr gut mit dem FS9 leben und er erfreut mich immer wieder.
      Ich brauche auch nicht jeden Kaugummi-Automaten am Airport. :)
      MfG
      Dr. f.s. Sandra Marion R.
      Polygon-Dompteuse

      Hurrraaaaa - es wird Morgens hell und Abends dunkel.
    • Was hier "umgangsprachlich" als Drawcall bezeichnet wird, ist quasi die Übergabe der Liste von Dreieckspolygone, die mit einem bestimmten Material dargestellt werden sollen. Ein Objekt kann also aus mehreren solcher Listen (also auch Drawcalls) bestehen, mindestens dann wenn mehrere verschiedene Materialien zugeordnet wurden. Im BGLC asm Sourcecode sind das dann quasi die Anzahl der DRAW_TRI_BEGIN/END Listentabellen, im xtoMDL Zwischenfile wird es als <IndexGroup> Tag bezeichnet.
      Letzendlich überträgt die Engine via Directx Call ja zunächst eine Tabelle mit den Materialdefinition (dort steht dann auch drin, wenn eine BUMP Map verwendet werden soll, welche Tag/Nachttexture zugeordnet sind und div. andere Definitionen für die Darstellungform), eine weitere Tabelle definiert die Vertex Punkte, also die Eckpunkte der Dreieckspolygone, deren Lichtvektoren und die UV Mappings auf die Texture. Dann wird eine Liste von Dreiecken übertragen, die mit einem bestimmten Material aus der Materialliste dargestellt werden sollen, wobei die Parameter der Liste jeweils 3 Indexe in die Vertexliste sind.
      Genau diese Anzahl von "Draw_TRI Tabellen" hat dann eine signifikant spürbare Auswirkung auf die Performance, weniger die Größe der selbigen. Baue ich also im 3Dmax/GMax ein Objekt oder eine Objektgruppe und weise dieser verschiedene Materialarten zu, z.B. den Dächern ein Material mit Texture A, den Wänden ein anderes Material mit Texture B, dann kommt beim Export zwar eine Materialliste (mit zwei Einträgen) und eine Vertrexliste mit allen Eckpunkten heraus, aber eben auch mindestens 2 Draw Listen mit den Polys die jeweils das zugeordnete Material A oder B verwenden.

      Die "Drawcalls" sind aber sicher nur ein Baustein im Ganzen, wenn auch einer, bei dem man am meisten Performance verlieren oder gewinnen kann.
      mfg
      Oliver Pabst
    • Sandra_007 schrieb:

      Ja okay Oliver akzeptiert die Erklärung.
      Ich kann sehr gut mit dem FS9 leben und er erfreut mich immer wieder.
      Du wirst lachen, aber mit dem FS9 (sofern Du den BGLC Code des FS2002 SDK nutzt, lebst Du auch viel viel besser als mit dem FSX oder FS2004er Kram. Werden einige nicht gerne hören, ich weiß, aber das ist so.

      Der einzige Vorteil des FSX SDK Codes ist (zumindest wenn wir über 3D Objekte sprechen), die erweiterte Parameterisierung der Materialdefinition, die somit optisch mehr Optionen bietet. Der Rest ist nur für die automatische Codegenerierung alla Microsoft hilfreich, nicht aber im Sinne einer schnellen und optimierten Verarbeitung in der Engine.

      Bruce Artwick hat mit der Einführung von BGLC im FS5 und der schrittweisen Erweiterung bis zum FS2002 schon eine geniale Codebasis geschaffen, die der rein statischen Tabellenform im FSX MDL Code weit voraus ist.
      Natürlich ist Voraussetzung, das man nicht die uralten Op-codes für die Polydarstellung nutzt, sondern die Variante, die mit dem Gmax/3dmax Exporter erzeugt werden. Letztendlich war es nicht Gmax (auch wenns jeder als Feature in die Produktbeschreibung geschrieben hat) die zu schnellerem Ablauf führte, sondern die dort genutzten neuen Opcodes, die eben auf Directx optimiert sind.

      Bezüglich der Darstellungsgeschwindigkeit stehen diese Opcodes den FSX Codeformen in keiner Weise nach, leider wurde halt die Materialliste nicht erweitert, als MS die Codeprogrammierung übernommen hat. Man wollte es alles auf "Hausstandard" haben, sprich XML als Codeliste, damit man einfacher die Codetransformation automatisieren konnte um die Defaultscenery zu erzeugen. Aber, da bei BGLC die Engine ja quasi einem Programmablauf folgt, ist das Verhalten und damit die Darstellungform klar vorgegeben und auch (meist) nachvollziehbar. Bei dem Objekten in Tabellenform alla MDL, weiß man leider nie und was die Engine daraus macht und der FSX weiß es offensichtlich abundzu auch nicht :)
      Und durch die "Programmierbarkeit" des Codes im BGLC hat man eben auch Eingriffsmöglichkeiten während der Laufzeit (zur Not bei jedem Frame) und kann damit die Darstellung verändern, wie zum Beispiel jahreszeitabhängige Materialienwechsel vornehmen, was ja leider in der FSX Definition "vergessen" wurde.

      Klar hat alles immer zwei Seiten, aber aus Sicht eines Programmierers muss Altbewährtes nicht immer schlechter sein, als vermeindlich Neues. Wären heute alle Programme in Assembler geschrieben, hätten wir sicher keine Probleme mit der Ablaufgeschwindigkeit ;)
      mfg
      Oliver Pabst

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von opabst ()