Ist ab heute verfügbar na wer traut sich und berichtet seine Erfahrungen? https://developer.oculus.com/downloads/ Oculus PC SDK 0.6.0.0 Beta (May 15, 2015) Postby cybereality » Fri May 15, 2015 1:39 pm The Oculus SDK 0.6 introduces the compositor, a separate process for applying distortion and displaying scenes and other major changes. There are four major changes to Oculus SDK 0.6: The addition of the compositor service and texture sets. The addition of layer support. Removal of client-based rendering. Simplification of the API. The compositor service moves distortion rendering from the application process to the OVRServer process using texture sets that are shared between the two processes. A texture set is basically a swap chain, with buffers rotated to allow game rendering to proceed while the current frame is distorted and displayed. Layer support allows multiple independent application render targets to be independently sent to the HMD. For example, you might render a heads-up display, background, and game space each in their own separate render target. Each render target is a layer, and the layers are combined by the compositor (rather than the application) right before distortion and display. Each layer may have a different size, resolution, and update rate. The API simplification is a move towards the final API, which primarily removes support for application-based distortion rendering. New Features The following are major new features for the Oculus SDK and runtime: Added the compositor service, which improves compatibility and support for simultaneous applications. Added layer support, which increases flexibility and enables developers to tune settings based on the characteristics and requirements of each layer. Significantly improved error handling and reporting. Added a suite of new sample projects which demonstrate techniques and the new SDK features. Removed application-side DirectX and OpenGL API shims, which results in improved runtime compatibility and reliability. Simplified the API, as described below. Changed Extended mode to use the compositor process. Rendering setup is now identical for extended and direct modes. The application no longer needs to know which mode is being used. Extended mode can now support mirroring, which was previously only supported by Direct mode. Simplified the timing interface and made it more robust by moving to a single function: ovrHmd_GetFrameTiming. Fixed a number of bugs and reliability problems. The following are major new features for Unity: Disabled eye texture anti-aliasing when using deferred rendering. This fixes the blackscreen issue. Eliminated the need for the DirectToRift.exe in Unity 4.6.3p2 and later. Removed the hard dependency from the Oculus runtime. Apps now render in mono without tracking when VR isn't present. API Changes This release represents a major revision of the API. These changes significantly simplify the API while retaining essential functionality. Changes to the API include: Removed support for application-based distortion rendering. Removed functions include ovrHmd_CreateDistortionMesh, ovrHmd_GetRenderScaleAndOffset, and so on. If you feel that you require application-based distortion rendering, please contact Oculus Developer Relations. Introduced ovrSwapTextureSets, which are textures shared between the OVRServer process and the application process. Instead of using your own back buffers, applications must render VR scenes and layers to ovrSwapTextureSet textures. Texture sets are created with ovrHmd_CreateSwapTextureSetD3D11/ OpenGL and destroyed with ovrHmd_DestroySwapTextureSet. ovrHmd_BeginFrame was removed and ovrHmd_EndFrame was replaced with ovrHmd_SubmitFrame. Added a new layer API. A list of layer pointers is passed into ovrHmd_SubmitFrame. Improved error reporting, including adding the ovrResult type. Some API functions were changed to return ovrResult. ovrHmd_GetLastError was replaced with ovr_GetLastErrorInfo. Removed ovr_InitializeRenderingShim, as it is no longer necessary with the service-based compositor. Removed some ovrHmdCaps flags, including ovrHmdCap_Present, ovrHmdCap_Available, ovrHmdCap_Captured, ovrHmdCap_ExtendDesktop, ovrHmdCap_NoMirrorToWindow, and ovrHmdCap_DisplayOff. Removed ovrDistortionCaps. Some of this functionality is present in ovrLayerFlags. ovrHmdDesc no longer contains display device information, as the service-based compositor now handles the display device. Simplified ovrFrameTiming to only return the DisplayMidpointSeconds prediction timing value. All other timing information is now available though the thread-safe ovrHmd_GetFrameTiming. The ovrHmd_BeginFrameTiming and EndFrameTiming functions were removed. Removed the LatencyTest functions (e.g. ovrHmd_GetLatencyTestResult). Removed the PerfLog functions (e.g. ovrHmd_StartPerfLog), as these are effectively replaced by ovrLogCallback (introduced in SDK 0.5). Removed the health-and-safety-warning related functions (e.g. ovrHmd_GetHSWDisplayState). The HSW functionality is now handled automatically. Removed support for automatic HMD mirroring. Applications can now create a mirror texture (e.g. with ovrHmd_CreateMirrorTextureD3D11 / ovrHmd_DestroyMirrorTexture) and manually display it in a desktop window instead. This gives developers flexibility to use the application window in a manner that best suits their needs, and removes the OpenGL problem with previous SDKs in which the application back-buffer limited the HMD render size. Added ovrInitParams::ConnectionTimeoutMS, which allows the specification of a timeout for ovr_Initialize to successfully complete. Removed ovrHmd_GetHmdPosePerEye and added ovr_CalcEyePoses. Bug Fixes The following are bugs fixed since 0.5: HmdToEyeViewOffset provided the opposite of the expected result; it now properly returns a vector to each eye's position from the center. If both the left and right views are rendered to the same texture, there is less "bleeding" between the two. Apps still need to keep a buffer zone between the two regions to prevent texture filtering from picking up data from the adjacent eye, but the buffer zone is much smaller than before. We recommend about 8 pixels, rather than the previously recommended 100 pixels. Because systems vary, feedback on this matter is appreciated. Fixed a crash when switching between Direct and Extended Modes. Fixed performance and judder issues in Extended Mode. Known Issues The following are known issues: Switching from Extended Mode to Direct Mode while running Oculus World Demo causes sideways rendering. Judder with Oculus Room Tiny Open GL examples in Windows 7. The Oculus Configuration Utility can crash when the Demo Scene is repeatedly run. Application usage of CreateDXGIFactory can result in reduced performance; applications should use CreateDXGIFactory1 instead. Support for CreateDXGIFactory is deprecated in this release and will be removed in a future release. For Windows 7 in Extended Mode, any monitors connected to the computer go black when the headset is on and return to normal operation when the headset is removed. For Windows 7 in Extended Mode, if the headset is placed above the monitor(s), all displays might go black. The workaround is to place the headset to the right or left of the monitor(s). PC SDK applications will crash if the OVR service is not running. https://developer.oculus.com/downloads/ Oculus VR - Community Manager User avatar cybereality Team Oculus Team Oculus Posts: 9439 Joined: Thu Feb 14, 2013 2:54 pm Location: Cyberspace https://forums.oculus.com/viewtopic.php?f=26&t=23372
Vermute mal, dass das deswegen rausgenommen wurde, weil das zukünftig die Treiber machen sollen, da man für die finale Rift und deren Bildschirme/Linsen ein angepasstes distortion rendering braucht, dass zukünftig dann direkt Oculus selbst liefert. Und hoffentlich gibts dann in den nächsten Monaten auch direkt DX12 Support.
Hab's mal getestet, doch werde ich wahrscheinlich wieder zur alten "Runtime v0.5.0.1-beta" switchen müssen. "Direct Mode" scheint soweit (was getestet wurde) alles zu laufen. Doch leider scheint der "Extend Mode" Probleme zu machen. (Blackscreen auf dem DK2 plus Maus-Ladeanimation.) Gibt es unter euch noch weiter Tester der neuen "Beta v0.6.0.0"? Habt Ihr das selbe Problem, oder könnte es an meinem System liegen? Oder gibt es sogar schon Workaround's dahingehend? EDIT: Probleme scheint es derzeit nur bei "Elite Dangerous" zu geben. (Beim starten, Permanentes Flackern aller Monitore.) Andere Spiele wie "Euro Truck Simulator 2" od. "BlazeRush" laufen soweit ordnungsgemäß. (Doch der Blackscreen auf dem DK2 plus Maus-Ladeanimation, besteht weiterhin im "Extend Mode".)
Jo, im ED Forum rät man auch davon ab den neuen Treiber zu benutzen und hofft, dass mit dem Powerplay Update auch die Unterstützung für 0.6 kommt.
Dank Dir für die Info! Weiß man schon wann dieses Update erscheinen soll, für ED? Was ich total konfus finde (zumindest bei mir): Das man im "Extend Mode" mit v0.6.0.0beta, ein Schwarzes Bild im DK2 hat. Und der Mauszeiger eine Ladeanimation bekommt. (Ist da schon was bekannt?)
Nein, wie immer geben die Entwickler solche Infos vorher nie raus. Vielleicht kommt es mit der Powerplay Update oder auch erst danach, wie gesagt hoffen die Spieler lediglich auf das PP Update, wissen tut es aber Niemand außer den Entwicklern selbst bisher. Ansonsten kann ich auch nichts genau sagen, hab jetzt noch nicht ins Oculus Forum geschaut ob es da weiter Infos zu dem Bug gibt. Kann man wohl nur hoffen, dass es bald ein weiteres Update gibt. Oculus sollte so langsam eh mal Gas geben mit den Updates, das dauert einfach zu lange bis mal wieder ein Update kommt, vor allem wenn bekannte Bugs im Treiber stecken sollten die auch mal mit kleineren Revision Updates gefixt werden.
Das flackern hatte ich nur unmittelbar nach dem update des SDK und der Runtime. Ich konnte das folgendermassen beseitigen Im oculus configtoll auf directmode umstellen, Demoschreibtisch im Oculusconfig tool starten und wieder verlassen. Danach wieder zurückstellen auf Extended mode im oculusconfig tool. Das wars, seitdem kein Flackern. Ich vermute durch das temporäre umstellen hat das Oculustool sein configfile neu geschrieben und das alte configfile des alten SDK ist nicht hundertprozentkompatibel mit der neuen Version. Elite Dangerous läuft einwandfrei bei mir sowohl im DK2 directmode als auch im DK2 Extended mode mit der neuen SDK 0.6.0.0 und Runtime. mfg axel
Dank Dir Alex für das WorkAround, werde ich bei Gelegenheit mal Testen. (Musst Du jedes mal diesen Trick anwenden, wenn Du ED im ExtendMode betreiben willst?) Hast Du eigentlich auch einen Blackscreen im DK2 plus Mauszeiger-Ladeanimation? ps. Wenn Du kein Coder/Programmierer bist, wird das SDK nicht benötigt.
Und selbst wenn du einer bist braucht man das SDK nur, wenn man direkt damit arbeitet. Mit UE4 kann ich auch ohne SDK für die Rift entwickeln.
Ich weiss die runtime reicht zum spielen aber ich bin neugierig geblieben deswegen die SDK. Games mache ich auch nur noch hobbymässig, aktuell mit der unity engine. Früher musste man die engines ja noch selber programmieren und heute wird man faul diesbzgl. @solkutter normalerweise habe ich die DK2 aus. LEd gelb Wenn ich die DK2 anschalte ist der Screen der DK2 schwarz. LEd blau. Bevor ich ein spiel starte schalte ich die Rift an Starte ich z.b. elite dangerous bleibt der Screen der DK2 schwarz bis das Logo frontier im DK2 erscheint, danach kommt das elite logo, dann der gesundheitliche Warnhinweis bzgl. Rift und dann kommt das Hauptmenu von ED usw. Während ich ED in der rift zocke zeigt der normale Monitor nach wie vor den Desktop an. Ich werde mal schauen wieviel Performance es kostet das Bild vor dem verzerren für die Rift zusätzlich noch auf dem normalen Monitor zu bringen. Dann kann meine Frau sehen wo ich gerade bin . Im Frontierforum hat einer der Entwickler dazu den Trick gepostet.
