Skip to main content
Up and Coming
July 25, 2014

SDK v0.4 Discussion

Woo! SDK 0.4! Congratulations to the Oculus Dev Team! :D

I hope you're all having a well-earned break! I do however have a couple of questions for other devs:

Is anyone else having trouble getting a preview going in the Game View in Unity?

I have the runtime installed and everything works correctly when I build the standalone player, but the Game View is just blank gray and looks the same as if there were no cameras present at all. This is with the DK1.

IsHMDPresent() also doesn't seem to be functioning correctly at all when I don't have my DK1 connected. Anyone else having trouble with it?

Edit: I just wanted to go ahead and make sure the Oculus Dev Team knows that we really appreciate what they do!

Having worked with software ourselves I'm sure most of us know how horrible it can be when you work incredibly hard for a deadline and then there's immediate unexpected issues.

We're just all really excited about getting our projects updated and working for our imminent DK2s and want to help get all these bugs hammered out so we can all enjoy working with and playing with all the new DK2 features. :)
    This topic has been closed for replies.

    64 replies

    Up and Coming
    July 28, 2014
    "sh0v0r" wrote:
    "JonDadley" wrote:
    "mdk" wrote:
    I'm also having issues with image effects. If I place an image effect script on OVRCameracontroler it applies the effect to both eyes. However when I compile the scene and run the application there is no effect.

    If I place the image effect script on each eyecamera Unity won't allow me to change the order of the scripts so that the effect is above the OVRCamera script. So I'm unsure if the effects are applied in the correct order.

    What is the proper workflow for image effects?


    Once you have moved the order of the image effects, you have to apply the changes to the prefab itself (scroll to the top of the inspector, hit apply). If you don't, when you run the game the order will revert.


    This doesn't sound right, if you modify an instance of a prefab in your scene and make a build you should get the modified version it doesn't instantiate a new prefab at runtime because there is instance data in the scene. Ideally you want to avoid changing the default OVR prefabs incase you want to revert.


    It was a documented issue on 0.25, it was Team Oculus who told us about the 'apply to prefab' fix here and here.

    In all honesty I haven't checked to see if this is fixed in 0.4 and when updating I copied the image effects components from a dummy object and hit 'apply' to the prefab out of habit.
    My VR projects - Stage Presence and LMD VR Projects I've contributed to The Matrix VR and Star Citizen Follow me on Twitter @JonDadley
    Up and Coming
    July 29, 2014
    I'd like to know if the plan is to abandon Oculus's own Deltatime function for the unity built in Time.deltatime, I'm not sure if it's still used anywhere else in 0.4.0, but in the OVRPlayerCpntroller.cs script it's all Time.deltatime now. I'm sticking with 0.25 for now but I'll change all my code from Deltatime to Time.deltatime if that is deffinetly the way it's going to be going forward, or is that still being decided?
    Inspiring
    July 29, 2014
    "sh0v0r" wrote:
    I would recommend avoiding doing any sort of hacks and workarounds to get it to work, it is broken and will be fixed.

    We are planning to fix the shadow and image effect corruption issues soon. Baking may help in the short-term, but I wouldn't recommend reworking your whole project just yet. You can continue to use a previous SDK release until we provide a fix.

    "molton" wrote:
    I'd like to know if the plan is to abandon Oculus's own Deltatime function for the unity built in Time.deltatime

    Yes, Time.deltaTime is the way to go. The old DeltaTime was essentially the number of frames that had been rendered, which you can still get from Time.frameCount or Time.renderedFrameCount.

    "mdk" wrote:
    If I place an image effect script on OVRCameracontroler it applies the effect to both eyes. However when I compile the scene and run the application there is no effect.

    OVRCameraController has a camera on it for internal reasons. It no longer affects the rendered image. In general, you should only ever put image effects on the OVRCameras' GameObjects, not the OVRCameraController's.
    Up and Coming
    July 29, 2014
    Just as a suggestion, it might be best to make the prefab have only one camera on it, which gets duplicated using GameObject.Instantiate at runtime in script. This way we can put all of our image effects and settings on that one camera and know that both eyes will get the same settings when we hit play. Makes for a lot less error prone use of copy and paste, and less confusing duplication of fields in the camera controller object.

    As a bonus, it could stay with one camera in the case that there is no rift available, simplifying the workflow for those who want VR to be optional.
    Participant
    July 29, 2014
    "vrdaveb" wrote:
    "sh0v0r" wrote:
    I would recommend avoiding doing any sort of hacks and workarounds to get it to work, it is broken and will be fixed.

    We are planning to fix the shadow and image effect corruption issues soon. Baking may help in the short-term, but I wouldn't recommend reworking your whole project just yet. You can continue to use a previous SDK release until we provide a fix.

    Any chance this'll get fixed till the 5th? :)

    Gotta finish a project till about then and start another one soon after and so far I'm still on 0.2.5c because of the various issues the "Beta" releases have had since. I'd really love to include DK2 support since I've just gotten it delivered and sitting here.

    I'm presuming the overwhelming lack of Demos to try so far (really only got Couch Knights and Elite Dangerous working very well on Day 1 so far and I had to End the OVR driver component to be able to do both) is due to the various issues with the different SDKs in regards to actually working.
    Up and Coming
    July 29, 2014
    "D3x" wrote:
    ...I'm presuming the overwhelming lack of Demos to try so far (really only got Couch Knights and Elite Dangerous working very well on Day 1 so far and I had to End the OVR driver component to be able to do both) is due to the various issues with the different SDKs in regards to actually working.

    probably not helping. I had a weird thing when I tried to use 0.4.0, if I turned my head around there would be a black box in my view like a big black square surrounded me on me left and right side and when I turned past it what I saw behind me was upside down. Other than that I thought it ran really good, the performance was much better, no more ovrdistortion script on the cameracontroller, is that using the SDK rendering they were talking about for that now? Whatever it is it's better
    Inspiring
    July 29, 2014
    "owenwp" wrote:
    Just as a suggestion, it might be best to make the prefab have only one camera on it, which gets duplicated using GameObject.Instantiate at runtime in script. This way we can put all of our image effects and settings on that one camera and know that both eyes will get the same settings when we hit play. Makes for a lot less error prone use of copy and paste, and less confusing duplication of fields in the camera controller object.

    As a bonus, it could stay with one camera in the case that there is no rift available, simplifying the workflow for those who want VR to be optional.

    I agree in principle, but I personally would still want to have full control over individual effects on different eyes, along with maybe having a different set of effects on the non-VR camera. (Non-VR is higher res, viewed on monitor, more performance to spend, etc)
    Titans of Space PLUS for Quest is now available on DrashVR.com
    Participant
    July 29, 2014
    Is there any way I can test my DK2 on OSX before SDK.4 for Mac comes out?
    Participant
    July 30, 2014
    "molton" wrote:
    probably not helping. I had a weird thing when I tried to use 0.4.0, if I turned my head around there would be a black box in my view like a big black square surrounded me on me left and right side and when I turned past it what I saw behind me was upside down. Other than that I thought it ran really good, the performance was much better, no more ovrdistortion script on the cameracontroller, is that using the SDK rendering they were talking about for that now? Whatever it is it's better

    I need Deferred Lighting to work as Rendering Path since I have a bunch of lights (8+ in one room for instance) and also more than a few Animated moving elements that wouldn't exactly take when baked in as Light maps, setting the scene to Forward Rendering makes it look kind of shit.

    I know that at least several other people had stated the same, for instance: http://www.reddit.com/r/oculus/comments/2bveku/dreadhalls_dk2_update_will_take_some_more_time/

    I also had a few other issues that I have largely solved, but this is the main big one.
    excelynxAuthor
    Up and Coming
    July 31, 2014
    I'm not 100% sure if this is a Unity issue or not, as I don't have any dark enough non-Unity demos to test with (and it might just be that the only really dark demos right now are Unity ones), but I have only thus far really seen this reported with Unity demos so it might be worth listing here:

    http://www.reddit.com/r/oculus/comments/2c8smy/one_eye_is_darker_than_the_other/

    As per my post in that thread I'm getting cases in very low light scenes where the right eye is noticeably darker than the left.
    VisiR - Virtual Reality Music Visualisation