[Suche] Grafikprogrammierer für Oculus Rift

[sirnoname]

Suche
Unterstützer bei 3D Berechnungen und Manipulationen in DirectX und OpenGL im Raum Augsburg und München (Hardwarenahe Entwicklung)

Informationen zum Projekt

Projektname
X-Rift

Kurzbeschreibung des Projektes/Mission Statement
Ziel ist es einen universellen Windows DirectX/OpenGL Treiber für das Oculus Rift aus diversen API's zu basteln damit die meisten Spiele damit funktionieren

Wie ihr bestimmt schon gesehen habt ist einer der großen Newcomer auf Kickstarter das 3D Headset Rift:
http://www.kickstarter.com/projects/152 ... o-the-game

Wer das Teil aufhatte und die vorherigen Helme kennt weiss das dieses Mal etwas bezahlbares mit richtiger Sicht herauskommt. Primär denke ich über eine Hardware SDK für 300€ nach das man dort bestellen kann. Wenn dort 4000 Leute dasselbe kaufen sind genügend Entwickler dabei etwas auf den Weg zu bringen. Das ist in ganz anderen Dimensionen als die bisherigen Helme verkauft wurden.
Im Moment gibts da freilich nur DOOM, da man dort mit den Sourcen spielen kann. Ich kenne mich aber mit den Techniken von IZ3D (älterer 3D Treiber für AMD Karten) aus, also dem hooken von Spielen und dem manipulieren der Ausgabeansichten. Ich hab da ein lauffähiges Nebenprojekt und mir würde es gefallen diese Technik für alle 3D und OpenGL Spiele umzusetzen. Also 3D splitting für zwei Ansichten und Sichtmanipulation für das Headtracking.

Wenn jemand (vorwiegend Grafikprogrammierer) im Raum München/Augsburg auch Interesse hat und sich zufällig mit der Umrechnung von Blickwinkeln auskennt wäre es super hier ein wenig vorzupreschen, das würde bestimmt auf Anhänger stossen. Das müsste in ein zwei Wochen fürs Erste funzen wenn jemand mit den Grafikberechnungen mithilft.

Projektstatus/Zeitplan
Die Hardware wird Ende des Jahres zugesendet, dann gehts los. Aber man kann schon vorher ohne Gerät arbeiten, da ich selbst einige Cyberhelme älterer Art habe.

Toolchain
C++, DirectX und verschiedene Hook API's

Beteiligte
Wir haben Tester, ansonsten bin bis jetzt nur ich als Treiber Programmierer dabei ;)

Webseite
Nein, es wird evtl. zum Vorgänger Projekt verlinkt da es selbst zu klein ist oder es spielt sich bei Oculus ab.

Informationen zum Gesuch

Anforderungsprofil
Du musst dich mit Matrix Rechnungen und den allgemeinen DirectX 3D Befehlen auskennen, hier wird jeder Befehl wichtig sein ;)

Aufgabe(n)
Wir haben eine 3D Ansicht die zweimal leicht verschoben wird. Hier geht es um Verschub und Blickwinkelberechnungen. Über ein Ingame Overlay wird dann noch der Augenabstand und die Bicktiefe eingestellt wie bei den nVidia Brillen.

Kompensation
Es wird ein kostenloses Projekt, wird auch nicht viel Zeit beanspruchen. Die Sourcen bleiben unter verschluss da richtig gute und erprobte 3rd Party API's in Anspruch genommen werden. Das Produkt ist aber dann Freeware.

Kontakt
pm

Gewünschtes Feedback
Ich bräuchte Feedback in der Umgebung von München / Augsburg. Es sollte eine kleinere Gruppe gebildet werden, Räume mit PC's sind vorhanden.
Ich erwarte das ihr ein Interesse an VR Equipment mitbringt und nicht leicht aufgebt wenn etwas nicht sofort ersichtlich ist. Manche Probleme benötigen ein paar Anläufe.

[Artificial Mind]

Das Rift zeichnet sich mMn nicht durch die 3D Sicht aus, sondern durch die 3D-Rundsicht, die man durch Schwenken des Kopfes hat. Und dass lässt sich nicht einfach mal eben zusätzlich in Spiele einbauen. Die Matrizen sind weniger das Problem, eher die Spiellogik.

[sirnoname]

Hi,

darum geht es ja, denn ich weiss wie man das einbaut und es geht sehr einfach.
Der Headtracker ist mein Part und soweit schon gegessen, nur der stereoskopische Part benötigt noch Hilfe.
Bei meinem Vorprojekt werden alle D3D und OGL Bibliotheks aufrufe die zur Sichtberechnung verwendet werden gehooked und dann aus der Sicht die Position und Sichtrichtung sowie Telemetriedaten ausgegeben. Die erstellte SDK bekommt von D3D8 bis 11 und OGL1-3 alles mit. Diese werden jetzt halt manipuliert nach dem Hook zurückgegeben, das wars. Einfacher geht es nicht. Reine custom Pixelshader Spiele funzen nicht, die sind aber sehr selten da sich alle an die Lehrbücher halten.

Grüße
SirNoName

[Schrompf]

Reine custom Pixelshader Spiele funzen nicht

Sicher? Ich hätte behauptet, jedes Spiel seit 2005 ist ein reines Custom-PixelShader-Spiel.

[sirnoname]

Sicher! Der Fail liegt in der Matrix Bibliothek :)
D.h. keiner rechnet selber sondern ruft immer die Sichtberechnungen aus D3D oder OGL auf wie es im Buche steht. Egal ob D3D dann danach Pixelshader nimmt oder nicht, die Sichtberechnung gehört mir.
Wie gesagt, ich hab da mit einem Vorprojekt meine Erfahrung gesammelt wie fremde achsodolle Spieleprogrammierer arbeiten. Der Treiber ist also schon im Einsatz in unserer Community.

[Schrompf]

Achso, Du hast Dich in D3DXMatrixPerspectiveFovLH() und Konsorten gehookt? Und Du hast auch ausprobiert, dass das mit den gängigen Engines wie Unreal3, Unity und Konsorten funktioniert? Ich bin immernoch voller Zweifel... ich hätte gedacht, die würden für die Plattform-Abstraktion eh die Mathematik selbst machen.

[sirnoname]

D3DXMatrixLookAtLH und alle Konsorten in den verschiedenen D3D Versionen und OGL Versionen sind die wichtigen Hooks, aber es ist ein Set von Hooks und je nach Spiel kann man per Overlay auswählen was für eine Spielwelt es ist (Left Right Handed) und was man manipulieren möchte. Schliesslich soll die Headtracking Unit später wissen wohin der Winkel berechnet wird.
Unreal geht, aber ich hab nicht im Kopf was dort zu Hoocken ist. Wenn ein Spiel eingestellt wurde kommts in eine Online Datenbank um es nicht nochmal zu machen.
Du kommst in den meisten Büchern an diesen Befehlen nicht vorbei, daher nimmts auch jeder so kommts mir vor.

[Artificial Mind]

Womit willst du zwischen Schatten-Viewmatrices und normalen Viewmatrices unterscheiden? (bzw. der Projektions-Matrizen)
Ich stell mir das lustig vor, wenn die Schatten sich drehen, weil man den Kopf dreht.

Die Standardmathelib für OpenGL ist imho glm und das ist Header-only und wird doch bestimmt ge-inlined. (ergo kein Hooking möglich)

Für OpenGL kann ich mir eher vorstellen, den Shadercompiler zu hooken und dort View-Matrices anhand der Uniform-Namen zu erkennenn und dann beim setUniform die View-Matrices zu ändern.

Trotzdem wird das für viele Spiele im Desaster enden. Sämtliches View-Frustum-Culling wird falsch, sobald man mit der falschen Matrix rechnet. Picking wird falsch. In Rage bekommt man sehr lustige Texturartefakte.


Ich will dich nicht abhalten, nur du wirst auf immense Schwierigkeiten stoßen.
Das Oculus Rift habe ich mir auch "bestellt", ich werde meine Spiele ab jetzt einfach immer darauf auslegen ;)

Könntest du nicht stattdessen (bzw: zusätzlich) versuchen, den Windows Desktop Rift-Ready zu hooken? Ich habe Erfahrung mit dem Hooken vom DWM und dem Manipulieren von DWM-Drawcalls und würde mich dafür interessieren. (lies: bei dem Teil wäre ich sogar dabei bzw. würde ihn selber versuchen)

[sirnoname]

Wird unterschieden, ich zähle die Aufrufe mit und der letzte vor dem Rendern ist es meistens. Lässt sich bequem per OSD auswählen wer es ist.
Ich wiederhole mich gerne öfters, das ist schon realisiert und läuft.
Schwierigkeiten gibt es da nicht, jedoch wenn sich keiner findet der beim 3D Stereoskopischen Teil mithilft wird es nicht realisiert, so einfach ist das.

[Artificial Mind]

Wie stellts du dir den stereokopischen Teil vor?

Soll das Game nochmal gerendert werden, nur mit etwas veränderter Kamera? (viel Aufwand)
Oder soll am Ende mithilfe des Tiefenbuffers zwei Ansichten generiert werden? (wenig Aufwand)

Beides hat wahrscheinlich Probleme mit Post-Processing-Effekten, letzteres hat mehr Ghosting-Probleme, aber ist konsistenter was PostProcess angeht.

PS: hab dir eine PN geschickt.

[sirnoname]

Tjaaaa, wenn ich das jetzt schon wüste, ich bin da nicht so bewandert wie beim Treiber Schreiben und Hardware naher Programmierung.
Ich kenne noch das Oculus stereo SDK nicht, daher ungefähr so:
-Hook bekommt ein "CreateDeviceD3D9" mit und macht zwei draus? (Oder halt optimiert für die Oculus SDK)
-Alle Befehle von DX9 werden verdoppelt für das Programm wenn der Hook darauf zurückgreift (ist eh schon im Code, muss halt auf 2 Devices gehen)
-Alle Ansichten werden auf die Devices gesplittet und manipuliert nach Augenabstand und Helm Ausrichtung

Naja, wie auch immer IZ3D halt gemacht hat mit den Hooks, ist ja nix neues. Ist wohl ein Lernen mit Programmieren.
Achja, ich hab noch den Hinweis auf More3D bekommen, ist so eine Art Nachfolger von IZ3D.
http://www.more3d.com/3-D/morestereodxgl.html

Leider nicht Quelloffen und man muss hier halt alles doppelt und neu schreiben.
Man könnte noch über eine Startnext Förderung für das Projekt nachdenken. Kickstarter ist ja nur für die Amis.

[Artificial Mind]

Wenn man zwei Grafikkarten hat, sind zwei Devices natürlich einigermaßen optimal (am Ende einmal syncen und gemeinsam anzeigen), bei einer Grafikkarte würde ich wahrscheinlich die Befehle queuen und dann nochmal ausführen oder so.

Das Oculus SDK wird ca. so aussehen: Für die Ausgabe gibt man einfach Split-Screen-Style die Daten für das linke Auge links und das Rechte rechts aus. Dann stellen die einem einen Shader bereit, mit dem dieses Bild nochmal verzerrt wird, um die Linsen-Distortion auszugleichen. Die Eingabe-API ist noch nicht ganz fertig wurde uns gesagt, aber es wird wohl ein einfacher Polling-Mechanismus sein, der einem die aktuelle Kopf-Richtung gibt.

[sirnoname]

Ich bin nicht so der Fan von SDK's. In diesem Fall möchte ich von denen eine offene SDK und die Teile von der Grafikausgabe in den Treiber übernehmen. Das geht dann etwas flotter als mit Framework Slowdowns. Das Polling des Headtrackers geht am besten von aussen mit einem Service und der legt es in einen Memory Mapped Bereich ab, das lässt sich am besten in einem Hook abfragen.

[Artificial Mind]

Das Oculus SDK wird nicht offen werden, da die Algorithmen für Headtracker usw. teilweise nicht offen sind. Man sagte uns aber, dass alles, was offen sein kann, offen sein wird. Die Verzerrung vom Shader soll glaube ich auch nicht teil des SDKs sein, sondern quasi beiliegen, damit man eine Referenz hat.

[sirnoname]

Wenn der Headtracker ein HID USB Gerät ist und sich als solches meldet verzichte ich auf jedwede SDK und hole mir die Daten selbst. Wenn es ein extra Treiber ist würde ich die oculus SDK in einen Service packen und die Daten global im Speicher verfügbar machen. In dem Hook hat man keine Zeit auf die Daten aus dem Gerät zu warten. Hoffentlich stimmt das mit der Verzerrung, wenngleich mir das noch nichts sagt.

[Artificial Mind]

Von http://www.jamesiliff.com/how-immersive ... culus-rift
kommt das Bild


Da sieht man die Verzerrung.

[sirnoname]

Ich meld mich heute abend zum Thema ICQ.
Was ist das für eine Auflösung im Endeffekt pro Seite? 512x640?

[sirnoname]

So, das Oculus ist nun unterwegs und die Sache wird nun ernst.
Leider bekam das Gerät in der GDC eine schlechte Wertung. Große Pixel, Tracker triftet, viele Umänderungen in bestehenden Spielen wegen 1,2m 3rd Person etc.
Weiterhin brauche ich Hilfe. Im ersten Schritt von Leuten mit Hook Erfahrungen, dann mit Grafikberechnungen.

Ich fange nun an den bestehenden Hook Treiber zu "modernisieren" und brauche Rückmeldungen welche SDK da zur Zeit empfehlenswert ist.
Ich mache hierzu einen extra Thread auf ... beinhaltet dann beides, Hook und Grafik Overlay Berechnung.
http://zfx.info/viewtopic.php?p=37179#p37179