(please excuse that this document is german only, but this is for internal use
 and all our current developers are german. If you're interested in it anyways,
 don't hesitate to drop me a mail.)

===============================================================================
=== S3D 0.3 ===================================================================

Bemerkung:

Das ganze ist eine grobe Zusammenfassung der Ideen die ich mir fuers naechste 
Release vorstelle. Fuer jegliche Kommentare, Kritik oder weitere Ideen waere
ich aeusserst dankbar. :)
Bitte benutzt diese ROADMAP wie ein Wiki, d.h. Anmerkungen, Bookmarks etc 
koennen auch gleich hier mit rein.

Um eine Koexistenz zwischen 3D und 2D-Programmen zu gewaehrleisten muessen 
gewoehnliche X11-Programme ohne Nachteile oder Einschraenkungen nutzbar sein, 
um Kompatibilitaet zu schaffen und auf dieser Basis aufbauen zu koennen.

Daher ist das Hauptziel fuer 0.3 eine transparente (im Sinne von nicht 
spuerbare) Schicht zwischen Graphikausgabe und X11-Desktop in Form von S3D zu 
ziehen. Der Desktop soll wie gewohnt bedienbar sein, in Wirklichkeit ist er 
aber nur einen Teil der 3D-Welt in die (bei Bedarf) umgeschalten werden kann. 
Das eroeffnet natuerlich auch neue GUI-Moeglichkeiten (z.B. Expose etc).

Um das ganze durchzufuehren wuerde ich 3 grosesere Schritte vorschlagen, die 
einigermassen unabhaengig voneinander sind:

1. Threads im Server
   --------------------
   Im Moment hat der Server ein recht plumpes Design: Es gibt eine 
   Hauptschleife, in der nacheinander Netzwerkverbindungen (also 
   Client-Requests) geprueft werden, ein neuer Frame gezeichnet wird und 
   Usereingaben (Mouse/Tastatur) gecheckt werden. Falls aber z.B. keine
   Client-Daten kamen und das Bild unveraendert ist, waere es unnoetig
   einen neuen Frame zu zeichnen. Ausserdem muss explizit darauf geachtet 
   werden dass nicht die ganze Zeit nur gelesen wird (sodass keine Zeit
   zum Zeichnen uebrig bleibt) etc.

   Daher sollen diese unabhaengigen Tasks in Threads unterteilt werden
   und parallel abgearbeitet werden. Das bedeutet natuerlich dass die
   Strukturen irgendwie gelockt werden muessen, ohne dass Deadlocks auftreten
   koennen. Idealerweise haette dann jeder Client seinen eigenen Thread
   in dem er auch blockierend auf Eingabedaten warten kann, und der Graphik-
   thread wird nur aufgeweckt wenn es etwas zu zeichnen gibt. Usereingaben
   koennten einen weiteren Thread erhalten, evtl. auch ein Thread der
   regelmaessig Shared-Memory-Updates checkt und Threads weckt (die 
   SHM-Verbindungen muessen nach wie vor gepolled werden).

2. Shared Memory Zugriff auf Texturen
   -------------------------------------
   Texturen werden an der Server gesendet indem sie ins Protokoll verpackt 
   werden und auf der anderen Seite wieder ausgepackt werden. Dieser Overhead
   ist unnoetig wenn Server und Client auf derselben Maschine sind, denn dann
   koennte der Client direkt in einen gemeinsamen Texturespeicher schreiben
   und wenn er fertig ist dem Server ein "Updated"-Event schicken, woraufhin
   dieser dann seine Textur erneuert.

Frage Andreas:
soll es denn überhaupt weiterhin möglich sein, von einem anderen rechner zu 
connecten ?

Ja, auf jeden Fall! Man koennte ja eine Funktion 
"s3d_get_texture_buffer(void **)", die lokal einen Pointer auf den 
shared-memory Bereich zurueckgibt, und remote einfach einen ganz normalen 
Speicherbereich. Wenn jetzt "update" aufgeruften wird, uebertraegt die Funktion
auf dem remote-Rechner wie gehabt diesen Speicherbereich zum Server, auf einem
SHM-Rechner macht sie aber das oben beschriebene (also nur dem Server Bescheid 
sagen).
Damit haetten wir gewissermassen Abwaertskompatibilitaet.
   
3. Aufbau eines Composite-Managers als MCP
   -----------------------------------------
   Um die 2D-Fenster in den 3D-Bereich zu bringen koennen wir die proof-of-
   concept-Implementation comptest zu einem vollstaendigen MCP/Composite 
   Manager umwandeln. Dafuer muessen alle moeglichen X11-Window-Events 
   (Window create/resize/destroy) verarbeitet werden und die Fenster 
   entsprechend dargestellt werden, sowie die Kamera an der richtigen Position
   gehalten werden. Man koennte vorerst einen 2D-Desktop-Modus und einen
   3D-Modus haben, zwischen denen gewechselt werden kann.

Nice to have
------------
Noch ein paar Erweiterungen, die ganz nett waeren, aber jetzt nicht so 
richtig auf die Roadmap draufgepasst haben. :)

Sortieren fuer Alpha-Transparenz
-----------------------------------
- fuer Transparenz-Effekte muss sich eigentlich selbst um Tiefensortierung 
  gekuemmert werden,  d.h. das Bild muss von hinten nach vorn aufgebaut werden.
  S3D ignoriert diese Tatsache derzeit und malt die Objekte einfach irgendwie. 
  :)
  Ein erster Ansatz waere vor dem Zeichnen die Objekte (mal abgesehen von den
  Polygonen die sie enthalten) nach ihrer Entfernung von der Kamera zu 
  sortieren.

Wii-Controller
----------------
- eigentlich das Top-Eingabergeraet fuer 3D-Kram, und auch billig. ^^
  Es gibt das library libcwiid, was auch von wminput verwendet wird
  und scheinbar ganz gut funktioniert. In S3D gibt es virtuelle 
  Devices (z.B. Pointer), die man darueber steuern koennte.

http://abstrakraft.org/cwiid/wiki/libcwiid

kommentar andreas:
http://www.wiili.org/index.php/Wiiuse sieht auch nicht verkehrt aus



Mehrere Displays
------------------
- Wenn man mehrere Displays in den Raum stellt koennte man die Ausrichtung und
  Position an S3D uebergeben, sodass diese wie Fenster in den virtuellen
  Raum wirken, also auch die richtige Richtung haben. Anwendungen fuer sowas
  waeren z.B. CAVEs, bei denen man im Inneren eines Wuerfels steht und auf 
  alle Seiten ein Bild projiziert bekommt, oder 3D-Stereo-Brillen, bei denen
  man 2 leicht voneinander verschobene Bilder fuer beide Augen haben moechte.

http://en.wikipedia.org/wiki/Cave_Automatic_Virtual_Environment

GLUT
------

Kann eigentlich raus, SDL tut alles was wir wollen und mehr, und ist auch 
Defacto-Standard und auf vielen Platformen verfuegbar.