VRML/X3D (Virtual Reality Modeling Language) unter Unix/Linux: 3D-Welten im WWW

VRML in einer »richtigen« VR Umgebung

Linux, 3D und Hardware

• VRML-Tools sind auf hohe 3D-Leistung angewiesen und benutzen unter Linux entweder OpenGL oder den Opensource Nachbau Mesa3D (http://www.mesa3d.org/ ) unter der graphischen Oberfläche XWindows/X11.
• Neben nützlichen Prozessorfeatures wie MMX, SSE(2), 3D Now(+)!, Altivec usw. sind vor allem 3D-fähige Graphikkarten bzw. Graphikbeschleuniger wichtig.
  
• Die tollste Hardware bringt aber nicht viel ohne entsprechende Treibersoftware. So kann es vorkommen, dass die gleiche Anwendung auf einem Rechnern mit Pentium I/133 und PCI Matrox G450 Graphikkarte bei Verwendung des XIG 2 Treibers deutlich schneller ist als bei der Benutzung eines Pentium III/600 mit AGP Nvidia Gforce2 MX bei Verwendung des Free86 4.1.0 eigenen Treibers liegt.
  Bei Verwendung des von Nvidia direkt stammenden Treibers normalisieren sich die Verhältnisse allerdings wieder.
• Letztendlich muss aber die ganze Kombination Prozessor/Graphikkarte/Graphiktreiber/Anwendungsprogramm betrachtet werden. Dabei kann sich zwar jeder Bestandteil zum Flaschenhals entwickeln, im Idealfall entlasten jedoch die Berechnungen der Graphikkarte weitgehend den Prozessor.
  Solch ein Verhalten wird vor allem bei teuren (vor allem für rechenzeitaufwendige CAD Anwendungen gedachten) Graphikkarten angestrebt. Viele Graphikkarten implementieren (noch ?) nur ein Teil der Berechnungen in Hardware und überlassen die Berechnung von Features dem Prozessor. Abhängig von Alter und Preis der Graphikkarte, kann dies zum Beispiel die Berechnung diverser Texturiereffekte, der Beleuchtung, Antialiasing (Vermeidung des "Treppcheneffekts" bei schrägen Linien), harte Schatten usw.
  Sogar die Hardwareunterstützung von "Curved Surfaces" (NURBS bzw. die einfacheren B-Splines oder Bezierkurven) ist inzwischen ein Thema (der nahen Zukunft ?).
• Vergleicht man die Performance der freien (und damit auch unter Linux verfügbaren) VRML-Browser auf einer SGI IRIX (UNIX) Hardware mit dem unter SGI IRIX verfügbaren Cosmoplayer, so drauml;ngt sich der Eindruck auf, dass man sich unter Linux verstärkt um die VRML-Anwendungsprogramme kümmern sollte.
  Allerdings ist Cosmoplayer erheblich älter (und damit ausgereifter), ausserdem ist es keine Schande, im Vergleich mit dem VRML- und OpenGL-Erfinder SGI schlecht auszusehen...
• Obwohl es unter Linux auch Mesa/OpenGL Programme gibt (gab ?), die direkt von der Linuxkonsole starten können, ist die übliche graphische Oberfläche X11/Xwindow relevant, die allerdings nur eine 2D-Kommunikationsschicht zwischen Programm und Videohardware darstellt.
  Moderne Ansätze wie die Treiber von XIG und XFree86 4 (DRI und Nividia) definieren für den schnellen 3D-Datentransport zusätzliche Kommunikationsschichten unter Einbeziehung des Kernels.
  Es gibt allerdings auch einige ältere Ansätze, mit denen Mesa die Kommunikationsschichtklippe X11 umgehen kann:
  • Das VGA-Signal kommt von der 3D-Hardware
  • Diese Möglichkeit wird benutzt von 3Dfx Voodoo 1/2 Graphikbeschleunigern. Hier stützt sich die Mesa Library auf das für Linux portierte API »glide«. Informationen zur Installation von glide und Mesa für diese Hardware finden sich kochbuchartig im 3Dfx-HOWTO.
  • Problem dabei: das X11 Monitorbild ist nicht sichtbar
  • Der X11-Mauszeiger ist nicht mehr sichtbar
  • Wird die Maus versehentlich ausserhalb des X11-Fensters benutzt, kann über den Windowmanager unbemerkt alles mögliche ausgelöst werden
  • Die Maus ausserhalb des X11-Fensters verändert zusätzlich noch den Keyboardfokus. Der Benutzer erhält unter Umständen keine sichtbare Rückmeldung des Systems mehr und könnte auf die Idee kommen, das System wäre abgestürtzt
  • Lösungsmölichkeiten:
  • entweder:
    Es wird je ein Monitor für die Ausgabe der Graphikkarte und für die Ausgabe des Graphikbeschleunigers benutzt
  • oder:
    Es wird ein (zweiter?) X-Server ohne Windowmanager gestartet, wobei das unsichtbare X11-Fenster den ganzen Schirm bedeckt
  • Die 3D-Hardware schreibt ins Videomemory
  • Diese Möglichkeit existiert ebenfalls für 3Dfx Voodoo 1/2 Graphikbeschleuniger bei Benutzung der glide-Library. Entsprechende Informationen finden sich ebenfalls im 3Dfx-HOWTO.
  • Ein Nachteil dabei ist der Zugriff auf /dev/mem über ein spezielles Device/Kernelmodul
    Damit wird der Speicherschutzmechanismus des Kernels überwunden. Die Stabilität des Systems kann dadurch gefährdet werden.
  • Es tritt eine deutliche Performanceeinbusse bei einer schwachen CPU auf
  • UTAH-GLX-Protokoll
  • GLX ist eine X11-Protokoll-Erweiterung mit eigener Kommunikationsschicht und wurde von SGI zur Integration von OpenGL in X11 und zur 3D-Visualisierung über ein Netzwerk erfunden. Technisch funktioniert UTAH-GLX unter Linux über eine glx.so Library, die vom X-Server geladen wird.
    Neben der Nutzung dieser Protokollschicht für 3D-Hardwarebeschleunigung macht es GLX möglich, dass ein SGI-OpenGL-Programm auf der Linux-X11-Konsole übers Netz gestartet werden kann. Der Name UTAH-GLX dient zur Unterscheidung von anderen Linux-Portierungen des GLX-Protokolls.
    
    Hardwarebeschleunigte Graphikkarten
    • Matrox G200/G400
    • ATI's 3D Rage Pro
    • Intel i810
    • S3 ViRGE (some support)
    • SiS 6326 (some support)
    • nVidia:
      GLX Treiber von nVidia (Mesa 3.0) ist (bei VRML) schneller als der Utah-GLX Treiber
      Problem: Flaschenhals beim Laden grosser Texturen
  • Kinderkrankheit: der XServer kann »einfrieren«
• DRI (ab XFree86 Version 4.0)
• Hier greifen X-Server und Mesa/OpenGL (teilweise) über dieselben Schnittstellen auf die Hardware zu. Damit benutzt man die gleichen Prinzipien wie zum Beispiel OpenGL auf SGI IRIX. Dies gilt als die saubere Lösung der Zukunft.
• Ist zum Beispiel verfügbar für eine steigende Anzahl von 3D-Graphikkarten, u.a.
  • 3Dfx Voodoo 3/5
  • Matrox G200/G400/G?50
  • ATI FireGL4 (basierend auf einem ATI Treiber, auf dem Linuxtag 2002 wurde die Benutzung mit einer Shutterbrille gezeigt)
  • ATI Rage 128
  • ATI Radon
  • Intel i810/i815
  • 3DLabs (MX/Gamma Chipset)
  Dabei muss beachtet werden, dass nicht sofort alle Features zur Verfügung stehen. So war die ATI Radeon 8500 einige Zeit nur mit 8 Bit Farbtiefe unterstützt. Die aktuelle Mesa3D Implementierung quitiert dies mit "no visual found".
  Genaue Informationen über den aktuellen Stand liefert http://dri.sourceforge.net/status.phtml
• Ab XFree86 4.0.2 wird Xinerama unterstützt . Damit ist es möglich, ein X11 Fenster über mehrere Graphikkartenanschlüsse (»Multihead«) zu verteilen.
  Dieses Feature kann zu Problemen führen, da nicht alle Windowmanager damit klar kommen.
  Viele (alle ???) XFree86 4 Versionen unterstützen bei Xinerama/Multihead. allerdings nur 3D-Beschleunigung auf einem Graphikkartenanschluss.
• Nvidia Treiber für XFree86 Version 4
• Der Nvidia Treiber fügt sich (durch Austausch einiger Module) nahtlos in die XFree86 4 Architektur ein.
• Benutzt ein eigenes Kernelmodul für den schnellen Hardwarezugriff.
• Ist im 3D-Bereich sehr viel schneller als der XFree86 4 eigene Nvidia Treiber.
• Es sind keine öffentlich lesbaren Quellen des Treibers verfügbar. Zumindest frührere Versionen des Treibers waren gefürchtet für gelegentliche Abstürtze bis hin zum Kernelcrash.
• Der Zusammenhang mit den Treibern der von SGI gelieferten PC-Linuxworkstations mit Nvidia Graphikkarte ist unklar (Nvidia und SGI haben enge Geschäftsbeziehungen).
• OpenGL/Xi 3D Accelerated-X Version 2(kommerziell)
• Besteht aus einer SGI basierten OpenGL Library und einem angepassten X-Server
• Benutzt im 3D-Bereich ein eigenes Kernelmodul
• Hardwaresupport für 3D-Graphikkarten (die Liste ist unvollständig...)
• 3DLabs: Wildcat II 5110 und andere
• ATI: Xpert, Rage, Radeon
• Permedia3
• Savage 4 Pro
• Matrox Millenium G?00/G?50
• und weitere...
• Unterstützung für Revelator3D und Multihead (siehe unten) wird angeboten.
• Mit der Wildcat II wird eine (von der Hardwarespezifikation im heutigen Vergleich) extrem leistungsstarke Graphikkarte angeboten. Man darf hoffen, dass der Treiber die Graphikkarte nicht ausbremst.


• Linux, VRML und Stereoview durch Shutterbrillen
  Eine Shutterbrille besteht aus 2 LCD Gläsern, die abwechselnd (z.B. mit 50 Hz) verdunkelt werden können. Gleichzeitig wird auf der Projektionsfläche (z.B. Monitor) abwechselnd das Bild für das linke oder rechte Auge präsentiert. Über Kabel oder Infrarot-Emitter wird dabei Monitorsignal und Umschalten der Brille synchronisiert.
  Teure Graphikkarten zum CAD Einsatz und diverse UNIX Workstations verfügem über einen entsprechenden Anschluss.
  
  OpenGL und seine grossen Brüder Iris Performer und Inventor besitzen entsprechende Schnittstellen für Stereoview.
  Soweit mir bekannt, existieren zur Zeit keine greifbaren Linux-Hardwaretreiber für den Graphikkartenausgang zur Ansteuerung von Shutterbrillen.
  
  Einige Crystal-eyes Shutterbrillen von Stereographics, benötigen zwar normalerweise diesen Graphikkartenausgang, sind aber trotzdem von einigen (nicht VRML) Linux Programmen wie "XtalView" oder "Swiss-PdbViewer" benutzbar.
  Dabei benötigt man einen "sync doubler", der abwechselnd die obere und untere Hälfte des Bildschirms zeigt ("splitscreen") und gleichzeitig Signale für den Infrarot-Emitter erzeugt. Als "sync doubling emitter" ist so ein Gerät auch mit eingebautem Infrarot-Emitter erhältlich.
  
  Bei diversen Unixworkstations (z.B. SGI Indy), die "splitscreen" Stereo unterstützen, ist eine Art "sync doubler" in die Graphikkarte eingebaut und steuert den Graphikkartenausgang an.
  Das "splitscreen" Verfahren ist aus zwei Gründen nicht optimal:
  • Aus Anwendungssicht muss der Bildschirminhalt im x/y Verhältnis 2/1 dargestellt werden.
  • Würde man nicht den gesamten Bildschirm verwenden, würde ein merkwürdiges Hintergrundbild erscheinen.
  Diese Probleme vermeidet das "stereo in a window" Verfahren, bei dem abwechselnd das gesamte Monitorbild für das linke Auge und das gesamte Monitorbild für das rechte Auge ausgegeben wird. Bei der Darstellung von 3D ist man bemüht den neuen Bildschirminhalt durch Umschalten zwischen 2 Bildschirmpuffern darzustellen ("doublebuffer"), um zu verhindern, dass man beim Neuzeichnen das Herumfliegen einzelner Polygone sehen kann.
  Für sinnvolles "stereo in a window" benötigt man deshalb insgesamt 4 Bildschirmpuffer (für jedes Auge 2), weshalb man auch von "quadbuffer stereo" spricht.
  Da der Speicherplatz für 4 Bildschirmpuffer auf den Graphikkarten nicht immer ausreicht(e), ist "quadbuffer stereo" auf kleinere Bildschirmaufläsungen oder modernere bzw. bessere Graphikkarten beschränkt.
  
  Da die preiswerte (aber technisch brauchbare) ELSA Revelator Shutterbrille nicht über einen speziellen Graphikkartenausgang, sondern über einen Aufsatz am normalen VGA Ausgang betrieben wird, sieht es bei ihr bei der Linuxunterstütztung völlig anders aus.
  Sie wird vom kommerziellen XIG X11 Server für eine gr&oum;ssere Anzahl von Graphikkarten unterstützt. Ausser "quadbuffer stereo" ist laut Dokumentation auch "split screen stereo" möglich.
  Auf dem Linuxtag 2002 wurde eine Xfree86 Lösung für Revelator 3D Shutterbrillen vorgestellt, die für die ATI FireGL4 Graphikkarte funktioniert.
  Ausserdem verspricht das RT-Linux (RealTime Linux) basierte SoftGenLock Projekt ( http://netjuggler.sourceforge.net/SoftGenLock.php) Shutterbrillenunterstützung für beliebige Graphikkarten (getested für 3Dfx und Nvidia Karten). Dabei kommt das Shutterbrillen signal vom Druckerport.
  Nvidia Quadro (nicht NV10) Graphikkarten unterstützen inzwischen ebenfalls die Ansteuerung einer Shutterbrille. Dabei wird sowohl die Ansteuerung über den speziallen Shutter-Ausgang der Graphikkarte als auch über ein DDC Monitorsignal (über einen Aufsatz am normalen VGA Ausgang) unterstützt.


• Linux, VRML und Stereoview durch Polarisationsbrillen
  Wird mindestens von Lightning und Cover unter Linux unterstützt. Diese Lösung erfordert mindestens zwei Videoprojektoren und eine spezielle Leinwand und ist damit sehr viel teurer als eine Lösung Monitor/Shutterbrille. Dabei müssen die Videoprojektoren unpolarisiertes Licht abstrahlen, was die Auswahl sehr einschränkt.
  Lightning kann je einen Projektor mit einem normalen Rechner ansteuern, die Synchronisation erfolgt extern.
  COVER erfordert eine Graphikkarte mit Xinerama/Multihead. Mit Xinerama/Multihead ist es möglich, ein grosses Fenster über beide Monitore (angeschlossen an die beiden Graphikausgäge der Graphikkarte(n)) zu öffnen, der linke Monitor zeigt das Bild für das linke Auge, der rechte Monitor zeigt das Bild für das rechte Auge.
  Für Stereoview ersetzt man die Monitore durch Projektoren. Vor den Projektoren sorgen (linear oder circular) polarisierende Filter für eine unter unterschiedliche Polarisationsrichtung. Erhät die Leinwand diese Polarisationsinformation, können die Filter der Polarisationsbrille die Information wieder trennen.
  


• Linux, VRML und Datenhelm
  Ein Datenhelm würde bei Benutzung von Xinerama/Multihead sehr einfach den Stereoblick erlauben.
  Das Problem bleibt dann die Navigation, der Blick muss sich ändern, wenn der Benutzer den Kopf dreht.
  
  Der FreeWRL-Browser hat eine Unterstützung für eine Polhemus Positionsbestimmung (Polhemus Magnetfeld Emitter im Bild)
  
  in Verbindung mit einem Virtual Research Datenhelm (Polhemus Sensor im Bild siehe weisses Kabel)
  
  am VGA Output zweier Linux Rechner. Ausgehend von der Positionsbestimmung wird dann pro Auge und pro Rechner ein VGA-Signal erzeugt und an den Datenhelm geschickt.
  
  


• Wieviel Rechner/Graphikkarten ?
  Prinzipiell ist die Synchronisation mehrer Rechner/Graphikkarten ein Problem. Trifft zum Beispiel aufgrund des verschiedenen Renderaufwands das linke Bild eher ein als das rechte Bild, treten bei schnellen Bewegungen störende Effekte auf.
  Dabei tritt der Effekt naturgemäss bei mehreren Rechnern stäker zu Tage als bei mehreren Graphikkarten/Ausgängen (multihead) auf einem Rechner.
  Die Verwaltung mehrerer Graphikkarten/Ausgänge über ein logisches Display (Xinerama) erspart es dem Programmierer, sich um den Pufferwechsel einzeln kümmern zu müssen.
  Um dem Problem mit der Synchronisation zu begegnen, muss/kann die Ansteuerung entsprechender Hardware ("Genlock") programmiert werden.
  
  Die Signale für 2 Projektoren bzw. einen Datenhelm können auch aus nur einem (shutterfähigen) Graphikausgang generiert werden. Dabei wird eine (nicht gerade billige) "xpo"-Box anstelle einer Shutterbrille angeschlossen.
  Damit erspart man sich Programmieraufwand und kann bereits bestehende shutterfähige Programme einsetzen und erhält die Vorteile des "Stereo in a Window".
  
  Nvidia Quadro (nicht NV10) Graphikkarten k&oum;nnen im "TwinView clone mode stereo" Modus betrieben werden, der laut diese Vorteile des "quad-buffered stereo" ebenfalls bietet, ohne auf zusätzliche Hardware angewiesen zu sein.
  
  FreeWRL als Plugin für Netscape auf einer mit Nvidia Quadro "TwinView clone mode stereo" und 2 Projektoren/Polarisation betriebenen Onewall (Linuxtag 2003)

VRML-Hardwarehunger

• Die VRML-Echtzeit-Fähigkeit führt bei überforderter Hardware (oder unzureichenden Treibern usw.) zu ruckhaften Bewegungen.
• Ein Pentium I/133 ohne unterstützte 3D-Graphikkarte reicht nicht aus für VRML (ausser im Wireframemodus des VRML-Browsers)
• Ein Pentium II/266 MMX reicht aus für kleine VRML-Welten
• Ein Pentium III und die richtige Graphikkarte für ein paar hundert Mark
• kann Körper mit 20000 Polygonen (oder mehr) halbwegs ruckfrei animieren
• ist bei einer Welt ohne Texturen mindestens 10 mal schneller als eine SGI Indy R5000/XL24
• kann bei grossen Texturmengen 100 mal schneller als eine SGI Indigo2 R10000/Solid Impact (kein Texturspeicher) sein
• Zur Zeit quillt uns bezahlbare Hardwaregraphikleistung aus den Ohren. Dass wir das nicht unbedingt merken, liegt unter anderem daran, dass Spieleentwickler anfangen, auf die bisherigen Optimierungstrategien immer mehr zu verzichten...

Weiter: VRML-Browser

Veröffentlicht unter der GNU GENERAL PUBLIC LICENSE Version 2
Datenhelm Bilder mit freundlicher Genehmigung von John A. Stewart (CRC).