Unity feature request list

"DaveA" wrote:

True. I posted my solution here: viewtopic.php?f=38&t=760 It works quite well and has the added bonus that it's more than just a static-image skybox, it can contain anything like moving clouds, birds, blimps, planets, etc.

Honestly something like the Skybox should have long been fixed by either Oculus or Unity. There are many users who would expect for such a "trivial" thing as a skybox to simply work as expected. Just my 2 cents :)

Hey again everybody,

I opened up a new thread on the Unity forum to raise awareness of current issues and "experiences". Please take a minute and share your thoughts there as Unity officials will be monitoring/checking it periodically.

LINK: http://goo.gl/1Zs6tA



Thanks!

Thomas Pasieka

Unity does render shadows twice. In fact, the shadow map is thrown away as soon as that light finishes rendering for opaque geometry, so it is not available for later render passes, even the transparent queue.

This means that when the second eye gets rendered it has to start all over again. They call this an "optimization" because it doesn't keep information in memory longer than their tutorial scenes need it, but in VR it just means you have to make about 33% more draw calls than are necessary (assuming you have only one dynamic light), reducing throughput and increasing latency.

The best solution would be for Unity to support multiple bound viewports, so you can use a geometry shader to draw to both eyes at once. This way both eyes are drawn in one pass, before the shadow buffers get discarded. It would generally reduce the CPU cost of rendering to half of what it is now, at the cost of some GPU time. Carmack verified that this is generally a win, even without the above mentioned Unity limitations. In terms of GPU memory efficiency as well it's far better to draw each object twice in a row than to draw all objects, then draw all objects again.

Also Unity does a lot of other CPU processing for every render pass that is pretty redundant when both cameras are in pretty much the same position with the same orientation. Their baseline overhead is already pretty high by industry standards, so doubling it unnecessarily is very bad.

These kinds of issues are the main reason why there is a perception that VR games need to look like they were made in 2004 to hit 60 fps.

My biggest gripe with Unity, is not being able to have Rift support in my games when built with Unity Free.

I don't care how they do it, but they need to do it!

"owenwp" wrote:
Unity does render shadows twice. In fact, the shadow map is thrown away as soon as that light finishes rendering for opaque geometry, so it is not available for later render passes, even the transparent queue......

It would be awesome if you could also posts this on the Unity forum as devs will be monitoring it: http://forum.unity3d.com/threads/228197-The-Oculus-Rift-experience-Tell-us-what-you-think!

Thanks for your input on that matter.

That's a good one owenwp.

As for my own requests, I'm not even sure what the specific issues are that need to be fixed or if ultimately it's my own user-error, but it sure seems like a Unity problem at this point. I've been having some pretty low level problems working with render textures and viewports in order to implement dynamic resolution rendering.

This technique came up on reddit a month or so ago, but here's a brief description:

• Different than just setting up supersampling once (and once per camera!) and then leaving it, dynamic resolution rendering has a single render texture set up at the start to which all cameras draw (in their respective viewports), and then scaled down/up to the screen size after all cameras are done.
• 
  The magic is, theoretically, that you could automatically tune the size of the overall viewport being rendered on this render texture to ensure a good framerate is being hit, without the churn of creating and destroying render textures, and by only having one big render texture for the whole screen instead of one per camera.
• Plus, you could do away with the resolution selection that we normally see when firing up a Unity demo. It would just start at 1280x800 and go up as much as it is able while maintaining stable framerate and ultimately mimic the way we/I just set these demos at 1920x1080 to take advantage of downsampling but always wondering if this is going to screw things up in the game.

Here's a quick little video and in the description are the problems I've been having with it (you may want to go to YoutTube in order to watch it full screen to better see the effect):

First part of the video shows the concept working while running it in the Unity editor (might need to view fullscreen at 720p to see the effect). Zero filtering or anti-aliasing applied which of course will have to change once the basics are solid (along with better pixel centering at the lower resolutions).

The second part of the video shows what happens if you enable a simple "pass-through" image effect onto one of the cameras. By passthrough, I mean in OnRenderImage(), there is a single line of code: Graphics.Blit(source, destination). Pulling my hair out trying to figure out why. (And this means no Rift lens correction, no image effects!)

And still worse than that is, with Unity 4.2.1, this whole thing just shows a black screen when run from a built executable. In Unity 4.3, it doesn't work at all in the editor itself.

I wrote a dynamic resolution rendering system once, but Unity gets in the way in a few places. The biggest problem is that when you change the viewport in Unity's APIs, it doesn't actually use a viewport in many stages of the pipeline (mostly post processing). It will actually allocate new render textures of the viewport rect size every time you change it, causing a visible stall. As usual Unity thinks it knows your intentions better than you do when you make a low level API call. This is probably the source of your passthrough post effect issue as well.

Internally it seems to use the GetTempRendertarget method, so this can kinda sorta be worked around by pre-allocating a wide range of discrete temporary render targets, assuming you have boatloads of spare VRAM.

This worked for me until I tried using it in outdoor scenes. Having terrain in your scene creates a separate stall when you change the viewport for unknown reasons. There must be some resolution dependent computation going on that gets cached and invalidated, maybe LOD-related.

Both stalls were bad enough (and sometimes multi-frame, probably due to chains of cache eviction) to completely negate the benefits and then some. In any case they make measurements too inaccurate to update the resolution continuously.

If this could be made to work correctly, it would be a great boon to VR where stability is critical.

Thanks for that info owenwp. That's too bad it didn't pan out!

Hey Owenwp and Drash,

If you could be so kind to copy/paste your findings/bugs on the Unity forums and perhaps even file bugs? If we want stuff to get fixed then that's pretty much key :) Please check this forum thread:



http://forum.unity3d.com/threads/228197-The-Oculus-Rift-experience-Tell-us-what-you-think!



Thanks in advance!

Thomas Pasieka