SDK v0.3.2 Preview 2 Discussion

"karrtoon" wrote:
And did you mean you are working on the RenderTextures instability, or on more clear default settings?

Both, really. We're working on the RenderTexture instability. It's really important to us to render at a higher resolution than the final output. That looks sharper and once it is reliable, it will be the default.

"karrtoon" wrote:
It would be great to get these default settings to a somewhat more acceptable clarity level (for the Unity challenged) or to at least to the 0.2.5.c level, until this "Use Camera Texture" feature becomes a completely viable option

When you run 0.3.2 with the default settings at 1920x1080, the main difference compared to 0.2.5c is that we're using mesh distortion instead of pixel shader distortion. Mesh distortion uses bilinear texture filtering, which will cause some blurring and smoothing. The pixel distortion in 0.2.5c effectively used point filtering. You can disable bilinear filtering in 0.3.2 by adding the following code at the end of OVRCamera.CreateRenderTexture(..):

		CameraTexture.filterMode = FilterMode.Point;

"Kubold" wrote:
What exactly do I have to tweak to make the graphics sharp in deferred?

If the above change doesn't make the defaults sharp enough at 1920x1080, then "Use Camera Texture" may be your only option. Can you enable that and let me know if it works for you?

Unity is ignoring the eyes' viewport rectangles. In 0.3.1, we used a separate RenderTexture for each eye, which avoided that bug. Does 0.3.1 work better for your use case?

Thanks, I'll try it tomorrow and let you know. It's just for rendering the video anyway, I'm sure it all will be resolved until I release a demo. Waiting for my DK2! :)

Is there any update to this?

The current Unity SDK just is not up to scratch and quality has really taken a step backwards.

Are we expecting a new SDK drop next week? Have these issues been addressed?

Regards:


DigitalJohn

An update is a given. You can bet it will get released about the same time the Dev Kits actually start shipping which could be any day now.

Looks like good progress but after exhaustive testing I have found the previous SDK to be quite a bit better in terms of a performance/quality balance when using a forward rendering path and AA - i'm assuming the difference will be even more pronounced for those using a deferred path. To achieve the same look with SDK v0.3.2 it is essential to turn on 'use camera texture' at a scale of at least 1 which results in a huge performance hit. This performance hit gets significantly worse when increasing the scale (obviously), but it is the sheer amount of lost frames that is surprising; and it is is clearly not workable at this stage imo.

Not only that but I have also found that frame-rate fluctuates inconsistently in test builds that leads me to believe there are a few wrinkles in the way the new integration in its 'preview' state actually runs. This is clearly a case of 1 step back before 2 forward and is definitely not in a production-ready state for us. I wanted to share these findings in case people were putting the cart before the horses, like I was

What I find hard to understand is why we have render to texture option.Whilst it works excellently at improving perceived resolution in low resolution device DK1, the DK2 native resolution, i would have assumed, would negate this feature as would future HMDS with ever increasing resolutions. Rendering to texture just doesn't seem fast enough on paper to be viable alternative to AA either; although with so many people wanting deferred in Unity i can see why its being explored.

The reason for switching from a distortion shader to a mesh would be useful to know because for a layman like me it seems less efficient, and its also slightly off compared to the original pixel shader - there is a slight bend towards the edges of the fov.

As a consequence of this uncertainty (im sure im not alone) it would be awesome to see a bit more detail on the new SDK and what is actually going on under the hood and most importantly why; and specifically how Oculus are approaching the performance/quality problem in this Unity integration with the target/supersampling method, because for the life of me I cant fully get my head round what is going on in there now.

Aside from this thanks for what is clearly a huge amount of new work, and for your patience with us lesser mortals :-)

Deflix... I have tried turning on use-camera-texture but that seems to mess up my view. Its like everything is heavily scaled/stretched horizontally.

Have you encountered this by chance?

Regards:


John

"digital" wrote:
Deflix... I have tried turning on use-camera-texture but that seems to mess up my view. Its like everything is heavily scaled/stretched horizontally.
Have you encountered this by chance?

I have but only when lowering the target size - this is probably due to the feature being a wip at this stage as previously mentioned. any value above 1 works fine albeit at a drastic cost to frame-rate, also (hopefully) as a result of it being a wip, although I cant see how render to texture can be more efficient than not doing it at all.

The new distortion method may be having an effect there too, because, if i understand it correctly, this is no longer a discrete distortion shader but rather a more protracted method using a mesh, and filtering.

ps - You will need to 'flip Y' when using the camera texture option.

My advice for developers is to continue with 0.2.5 until the new implementation works properly.

Any update on a new SDK? Unity + deferred lighting is pretty much a no-go. It looks terrible :(