Skip to main content
Inspiring
November 18, 2015

Free DX 12 Rift Engine Code

Hi,

if you want to write code for the Rift using DirectX 12 you might want to take
a look at the code I provided on GitHub https://github.com/ClemensX/ShadedPath12.git

The sample engine is extremely limited on draw abilities: I can only draw lines!
But it may serve as a learning playground for DirectX 12 and Rift programming.

I find it fascinating how a bunch of simple lines suddenly become great if you can walk around them and view them from any direction when you wear the Rift!

The current state of the code is a first step to porting my older DX 11 engine to DX 12.
If you want you are allowed to use any code you like in your own projects.

I want to express gratitude to galopin, who came up with a detailed 8-step guide on how to combine
DirectX 12 with Oculus SDK rendering. See this thread https://forums.oculus.com/viewtopic.php?f=20&t=25900
When I found out that using oculus API ovr_CreateSwapTextureSetD3D11 on a
D3D11On12Device throws NullPointerExceptions I would have given up if he had not given this advice!

Some features of the code example:

  • Engine / Sample separation. Look at Sample1.cpp to see what you can currently do with this engine and see how it is done.

  • Oculus Rift support (head tracking and rendering). See vr.cpp

  • Post Effect Shader: Copy rendered frame to texture - Rift support is built on top of this feature

  • Use Threads to update GPU data. See LinesEffect::update()

  • Synchronize GPU and CPU via Fences

  • Free float camera - use WASD or arrow keys to navigate. Or just walk/turn/duck if you wear the Rift


Any feedback welcome.

    56 replies

    Up and Coming
    March 28, 2016
    This was unexpected, d3d12 support is in 1.3. Will have to check that tonight :)
    lamour42Author
    Inspiring
    March 29, 2016

    galopin said:

    This was unexpected, d3d12 support is in 1.3. Will have to check that tonight :)


    Absolutely. Just when I thought we would never hear again about DX12 support for the Rift SDK. :smiley:
    Let's hope the DX12 API is easy to use and does not require major rewrites.
    lamour42Author
    Inspiring
    March 29, 2016
    Fixed the engine for SDK 1.3. Currently still via D3D11On12 device. This was easier than to switch to the new DX12 Oculus API in one step. Getting rid of D3D11On12 will come next.
    Up and Coming
    April 2, 2016
    Ok, i took the time to update my sample too tonight, it is good to remove all the junk :)

    So it works great, i am still sad of that double time, they did what i was expecting for the support of multiple camera too ^^

    Something i noticed, the ATW works definitely good ( putting myself in a case where the app run at 40 fps constant), the rendering is 20ms, but there is a 5ms gap on the GPU (weird). Inside the head set, it is just as smooth as butter.

    The ATW run on a compute queue (fourth row), it was not the case with the 0.8 runtime. Something badly documented is what should be the resource state for the ovrSwapchain buffers, according to the samples, it is pixel resource, but it seems that non pixel resource is the right one in fact, sadly dx12 is most often incapable to catch barrier errors.

    Other details, they choosed to have 3 buffers in the swapchain, and the temporal aliasing is worse than with the 0.8 runtime. I think the ATW combined with small instability in the tracking give us a hard time, they probably should apply some filtering to the tracking to erase noise and reduce the temporal aliasing.

    And yes, the health and safety message is already going into my nerves...



    lamour42Author
    Inspiring
    May 24, 2016
    Mass rendering and multi-thread support

    As a first step to support rendering of lots of small objects, thread support and a different approach to rendering objects was implemented. See classes WorldObjectEffect and WorldObject.
    While currently some thousand objects can be rendered ok I am still not exactly where I want to be. Most of the performance gain by using multiple threads is eaten up because some classes proved to be not thread save and I had to protect critical sections with mutexes.
    This is mainly for the camera class and some deep down rendering code. Also, I am not too satisfied with the current architecure for mass rendering. Expect more rewrites in the future to fix these shortcomings.

    See HangOn.cpp for example mass rendering. A group of objects that share the same mesh are rendered by splitting the draw calls to any number of threads. Distribution of objects to render threads is done by the engine. All thread creation, maintenance and synchronization has been implemented with standard C++11 features.


    lamour42Author
    Inspiring
    August 22, 2016
    Just a small update on the current status:

    Several small fixes / improvements for the engine, e.g.
    • Default texture that will be rendered if an asset texture is missing
    • On-the-fly movement paths: Specify control points for moving objects in the code, not only via collada import file.
    • Mirror HMD output to app window (before distortion)
    • Collada importer now fixes axis orientation so that you see rendered objects exactly like in blender default mode without need for any rotation
    On application side I am currently working on an animated logo and a game.
    Early logo image:




    The game will take place in an asteroid field, while Mars is approaching your position :smiley:



    lamour42Author
    Inspiring
    December 11, 2016
    Release version 0.1.2:
    • Much improved multi-thread rendering for objects: removed most of the mutexes needed in earlier versions
    • Introduced pak file support. Texture files can now be gathered in pak files. This means I can now publish all textures for the demos because I don't have to add them as individual dds files. (Some licenses of the textures didn't allow posting them publicly without a custom file format.) All demos should now be runnable right from the start with all textures.
    lamour42Author
    Inspiring
    February 19, 2017
    Release version 0.1.3:
    • Touch support: Draw and move hands and controller
    • Sound enhancements: Specify playback volume in playSound()
    Please see this video showcasing touch support: https://www.youtube.com/watch?v=ekqCWcq1EQs&feature=youtu.be

    You see spinning touch controllers. Use the right hand to point at the right spinning controller to draw it towards it's parking position, indicated by a ghost-like controller image. If you move the right hand away from the controller while it is on it's way it will stop.

    After reaching the final position the right controller will rotate into 'bonding position': Simply move your right hand near it to attach it to the hand.








    Participant
    April 17, 2017

    lamour42 said:

    ...
    You see spinning touch controllers. 
    ...

    Are you talking about this example:
    ShadedPath12.exe -vr -app=TouchOdyssey -w=1200 -h=676 -disableLineShadersX
    ? I can not see the hands here:

    Only closely "Big touch controllers" (black) and their shadows are far away.
    Excuse me - if I'm stupid.
    lamour42Author
    Inspiring
    April 19, 2017
    Do your touch controllers work fine in other apps like Oculus Home?
    If yes please post the application log. Either directly from Visual Studio Output window if you run a debug build. If you run a release build you will find the file xapp_run.log somewhere inside your installation.