Alpha-Blending Problem unter Linux

[Pius Noel]

Ich habe das Problem auch schon seit langem mit meinem Mesh Haar im SL und bin deshalb auf eine Kurzhaar Frisur umgestiegen und zum Hut-Träger mutiert. Es scheint, dass das Problem zunehmend an Bedeutung gewinnt und möglicherweise in der nächsten Firestorm Version behoben sein wird. Ob der eher triviale Fix auch ausreicht wird sich zeigen.

https://community.secondlife.com/forums/...mesh-hair/
https://hg.phoenixviewer.com/phoenix-fir...296261f0ac

LG Pius

[Dorena Verne]

Ich danke euch für eure Antworten.
@Pius
Tja, dann heißt es wohl abwarten.

[Dorena Verne]

Lass dich knuddeln Pius.



Pius hat mir eine von ihm gefixte Firestormversion zukommen lassen, welche das Problem aus der Welt geschafft hat.

Wenn du Lust und Zeit hast Pius, vielleicht magst du an dieser Stelle ja eine Bauanleitung posten?

[Pius Noel]

Nochmals zum Problem: leider gibt es immer noch Mesh-Haare (z.B. November von Magika im SL) bei denen der Fix keine Wirkung zeigt. Da das Problem ALLE Viewer betrifft, müsste der Fix eigentlich bei Linden Lab erfolgen, aber die haben nie was getan, obwohl das Problem schon sehr lange bekannt ist. Bleibt nur zu hoffen, dass sich endlich was tut, da Bewegung in die Sache gekommen ist.

Wie sich das Firestorm Team über die Freigabe entscheiden wird sei mal dahingestellt. Ich denke aber, dass es keine Freigabe geben wird, bevor das Problem eindeutig identifiziert wurde und besser gelöst ist.

Nun zur Bauanleitung (hust). Leider ist das Ganze nicht so trivial um auf die Schnelle eine funktionierende Anleitung abzugeben. Ich selber habe in der Vergangenheit schon oft Viewer kompiliert und gebildet, so dass ich mit den Zusammenhängen vertraut bin.

Kurz zusammengefasst bin ich wie folgt vorgegangen:
1) Ich habe auf meinem PC Ubuntu 18.04 im Dual Boot. Mein PC verfügt über 16 GB RAM (die Hälfte dürfte auch genügen) und für Linux habe ich eine 120 GB Festplatte frei. Mein Ubuntu ist eher minimal eingerichtet, d.h eine standardmässige Desktopinstallation mit ein paar Tools, die ich im Alltag so brauche und SSH Keys, die ich für meine Serverzugriffe brauche.

Einzig speziell sind bei mir LXD, zfsutils-linux (wird als Filesystem für meine LXD/LXC Container gebraucht), Mono und Git (letzteres ist vermutlich schon mit dabei).

2) Um nun Firestorm zu bilden erstellte ich auf meinem PC zuerst mal mit LXD einen Container mit Ubuntu 18.04 und habe auf diesem SSH eingerichtet, so dass ich ihn aus einem Termialfenster auf meinem PC wie eine externe VM mit ssh und scp ansprechen kann. Darüber hinaus habe ich im Container einen sudo User eingerichtet und auch noch mein Set an Tools für den Alltag installiert. Auf meinen Containern, die ich zum Entwickeln brauche, habe ich in der Regel immer sudo, ssh, vim, mtr-tiny, dnsutils, traceroute, git, gawk, zip, unzip, tmux, und build-essential installiert. Für alles weitere logge ich mich also auf diesem Container ein.

3) Für das weitere Vorggehen habe ich mich an die Links unter https://wiki.firestormviewer.org/#tab-developers gehalten:

Primär habe ich mich dabei unter https://wiki.firestormviewer.org/fs_compiling_firestorm an die aktuellste Anleitung für Debian 9 unter 64-bit Debian 9.x (stretch) - AlexIvy updated 8/18/18 gehalten.

Nachträglich betrachtet wäre es sinnvoller gewesen einen Container mit Debian Stretch (lxc launch images:debian/9 fsdev) zu erstellen, denn es hat sich herausgestellt, dass ich noch einige Probleme mit den Abhängigkeiten hatte.

Da ich aber Debian seit längerer Zeit nicht mehr nutzte fühlte ich mich mit dem mir vertrauten Ubuntu auf der sichereren Seite und habe den Pfad nicht verlassen.

Hilfreich war dann noch ein Blick auf die aktuellste, aber für mich veraltete Doku für Ubuntu 16.04 vom gleichen Autor zu werfen: 64-bit Ubuntu 16.04 (AlexIvy) updated 5/29/19

Mit diesen beiden Anleitungen in Kombination bin ich ganz gut vorangekommmen. Vor allem beim Linken gab es noch die eine oder andere Abhängigkeit, die ich noch nachinstallieren musste und ich musste den Build mehrmals neu starten. Das ganze Prozedere hat so etwa zwei bis drei Stunden gedauert.

Bei den fehlenden Libraries gab es einzelne Komponenten von denen es schwierig war herauszufinden zu welchem Package sie gehören und in einem Fall war es ein Package für die i386 Architektur. Damit hatte ich nicht gerechnet und deshalb etwas Zeit verloren. Google war wieder mal Freund und Helfer.

4) Nachdem alles fertig war habe ich das fertige komprimierte Package mit scp vom Container auf mein Basis-System kopiert und konnte nach dem entpacken gleich mit Testen loslegen. Das .tar.xz File mit dem Package befindet sich nach dem Build direkt im Verzeichnis ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/.

Das erste Mal hatte ich das gesamte Verzeichnis aus ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged rüber kopiert. Das war insofern falsch als dadurch das versteckte Unterverzeichnis bin/.debug mitkopiert wurde, was nahezu 2 GB Daten enthält, die nicht benötigt werden. Ansonsten war aber kein Unterschied spürbar und das Verzeichnis konnte einfach gelöscht werden.
Vielleicht komme ich gelegentlich mal dazu eine vollständige Anleitung für Ubuntu 18.04 zu erstellen, wenn ein Interesse daran besteht.

Nachwort:
Ich bin ein grosser Fan von LXD/LXC Containern. Sie verhalten sich vom Feeling her wie eine VM, sind aber schneller und weniger resourcen-intensiv, da sie immer den Kernel des Hosts teilen. Ist man einmal damit vertraut, so sind sie sehr handlich. Die wichtigsten Befehle sind schnell erlernt und ich finde sie weit weniger kompliziert als etwa Docker Container.

lxc launch ubuntu:1804 fsdev und nach wenigen Sekunden (das erste Mal nach ein paar Minuten) steht ein Container mit einem Ubuntu Server bereit. Mich hat es seinerzeit ca. einen Tag gekostet mich damit vertraut zu machen um soweit zu gehen, dass ich meine Oracle Virtual Box auf einem bei Hetzner gemieteten Server durch LXD ablösen konnte.

Der Vorteil liegt darin, dass ich praktisch jede Linux Distro auf einem Container installieren kann, sofern sie sich noch mit dem aktuellen Kernel verträgt und so von der "Dependency Hell" weitgehend befreit bin, der ich in Entwicklungsprojekten immer wieder begegne.

Und natürlich habe ich auch einen Container mit dem Namen osdev. Darauf ist Mono installiert und Opensimulator, so dass ich auch immer gleich mit der aktuellsten Opensim Version testen kann.

LG Pius

[Dorena Verne]

Also, ich habe Linux Mint 19.2 als alleiniges System auf dem Desktop, denke das macht den ganzen Containerkrams überflüssig.
Denke das alles was du beschreibst ist alles andere als trival für jedermann, mich trotz einiger Linuxerfahrung eingeschlossen, umso mehr bewundere ich deinen fix.
Soll er als Testviewer für mich bleiben, oder darf ich ihn bei Bedarf weitergeben?

[Bogus Curry]

Hallo Pius ;D

Ich kann mich Dorena nur anschliessen und sehr tief den Hut vor dir ziehen ;D Wollte eigentlich schon immer mit den LXC Containerystem was machen, hab bisher mit Docker - naja mehr rumgespielt - was versucht. Aber vielleicht versuche mal in einer ruhige mit Minute an so einen System.

Wenn ich nicht so ein SpielKind wäre, dann könnte ich auch Windows adjeu sagen, aber leider bin ich einer der gerne spielt *gg Und einige meiner Lieblingsspiele laufen leider nicht unter LInux, aber was solls ;D

Ist ja nicht das Thema hier ;D

[Pius Noel]

@Dorena Verne: Ich habe nichts dagegen, wenn du es bei Bedarf unter Freunden vereinzelt weitergibst. Aber du musst dir bewusst sein, dass es sich um eine nicht freigegebene Developer-Version vom Stand 10.8.2019 handelt, die noch ungetestete Bugs enthalten kann.

Was LXD/LXC betrifft, so ist das für mich trotz Desktop eben nicht hinfällig. Angenommen du willst zwei Viewer bilden, der eine ist Original von Linden Lab, der andere ist Firestorm. Es mag sein, dass es zur Zeit nicht so ist, aber in der Vergangenheit gab es immer wieder Situationen, wo die Abhängigkeiten der benötigten Bibliotheken und/oder die benötigten Tools unterschiedlich waren.

Immer wieder habe ich mir dabei mein System zerschossen. Ein Container mit dem was ich brauche ist einfach viel schneller aufgesetzt als ein vollständiges Desktop Linux, auf dem ich unter anderem auch meine persönlichen Daten habe.

Unter Windows habe ich zwei User, das geht so halbwegs. Für Spezialitäten habe ich noch Oracle VirtualBox, das ist aber mit einem Windows Desktop grottenlangsam und die Grafik ist auch nicht vollwertig, da die Hardware nicht an die VM durchgereicht wird. Letzteres gilt übrigens auch für LXC/LXD Container, die für grafische Anwendungen eigentlich gar nicht zu benutzen sind. In dem Fall sind aber im Container gebildete Programme zum testen und Debuggen schnell auf den Host übertragen.

In der Zwischenzeit bin ich noch ein bisschen tiefer in die Materie bezüglich des Problems eingestiegen und habe dabei herausgefunden, dass das Problem nicht nur im Zusammenhang mit SL/Opensim besteht, sondern auch mit Spielen, die auf OpenGL unter Unity basieren.

Spiele die forciert werden können, dass sie das Vulcan-API (früher Next Generation OpenGL) verwenden, können den Bug umgehen. Ich kenne mich in der Spiele-Welt so gut wie gar nicht aus, aber soweit ich verstanden habe betrifft dies alle Spiele, die auf Unity 5.6 und höher basieren (Einstellung -force-vulkan in der Steam Library, was immer das ist).

Mit dem Opensim-Viewer sind wir da chancenlos. Ich versuche trotzdem mal herauszufinden ob es noch andere Workarounds gibt, die man evtl. im Opensim Viewer implementieren könnte.

LG Pius

[Dorena Verne]

Gerade habe ich festgestellt, das der aktuelle CoolVL dieses Alpha-Blending Problem unter Linux wohl nicht hat.