Failed In Unity5.3+

[LinghanLiu]

Hi Jam,
Are you still working on this? I tried your code in Unity5.3+ and then I opened "intercept.log", not found "Stereo enabled" which I can find within Unity4.5.1f1.

[jam3sward]

I'm still maintaining this when time permits. Some colleagues are running on Unity 5+ and I'll look into this for you...

[LinghanLiu]

It's very kind of you.Thanks for your help.

[jam3sward]

I've had a first look at this in Unity 5.3.6 and it looks like the rendering pipeline has changed somewhat, which may be the cause. It will take some more investigation, but I'll let you know if/when I make progress. In the mean-time, if you could attach some verbose log files, that might help confirm the issue. The logging can be set to verbose as follows:

1. Open "quadifier.ini"
2. Change "logLevel" line to read "logLevel verbose"
3. Run Unity/quadifier (just long enough for the main 3D scene to appear for a couple of seconds), then send the log (the last 40 lines or so would be enough).

[LinghanLiu]

Sorry for my late reply. This is the log that I ran in 5.3.4f1.
intercept.txt

[LinghanLiu]

I found “Command buffer”, may be useful for you

[jam3sward]

Thanks for the log file and suggestion above. I've been away for a few days, but hope to find time to look at this again soon and have some ideas. I'll write back here when I make progress.

[jam3sward]

I've now got this working in 5.3.6f1 at this revision: 95b9b51
Please can you try this version and let me know if it works for you? Please note that the quadifier.js script has changed, and would need to be changed in your Unity project(s) to work with this updated version.

[LinghanLiu]

Hi Jam,
1.I downloaded Unity 5.3.6 and Quadifier at version 95b9b51.
2.I open project with VS 2015.
The process is exited when SetRenderTarget.
quadifier.txt
intercept.txt

[LinghanLiu]

I got this working. "Show Unity Splash Screen" must be enabled.

[jam3sward]

Thanks for the update, much appreciated. I'm pleased to hear you got it working. It shouldn't really be necessary to have the splash enabled, so I'll look into that issue. Anyway, I'm glad you have a workaround in the mean-time.
James

[LinghanLiu]

Hi James,
Some Suggestions:
1.CameraClearFlags of fake camera and right camera need to change to "CameraClearFlags.Depth".
2.In IDirect3DDevice9Proxy.cpp
Function "CreateVolumeTexture" and ”CreateCubeTexture"
add "Usage |= D3DUSAGE_DYNAMIC;"

[jam3sward]

Thanks for the suggestions, it's great to have some feedback.

Regarding (1) I agree this seems sensible (and I had actually tried this at one stage myself). Logically, it seems it should actually be required, but it seems to work without for me (strangely). Strictly, I suppose we should clear all buffers (as the right eye render may not fully overdraw the left eye). There is a performance cost to clearing of course, so in the long term an option on the clear flags may be better (e.g. configuration file). For the moment, I'll do as you suggest and commit this.

Regarding (2) does this fix a problem? Would be interested to understand the detail behind that (my first assumption is that Unity would set the usage) - is it needed because we have changed from D3DPOOL_MANAGED to D3DPOOL_DEFAULT and some interaction between pool and usage?

Please keep the feedback coming as it is appreciated. If there are separate issues, please feel free to create separate tickets for each issue.

[jam3sward]

The suggested CameraClearFlags.Depth change was committed at 446226d

[jam3sward]

I'm not so sure about suggestion (2) to add D3DUSAGE_DYNAMIC inside CreateVolumeTexture and CreateCubeTexture. This MSDN page says:

It is a good idea to create only one dynamic texture per format and possibly per size. Dynamic mipmaps, cubes, and volumes are not recommended because of the additional overhead in locking every level.

However, I can also see that it may be needed in order that they can be locked as described here, as that was obviously possible for the original D3D_MANAGED pool used by Unity.

It also seems there may be a risk of increasing memory usage with this change, for example: OGRE issue and @Jonathan Mee's comment here

However, I don't know enough about the low level behaviour of Direct3D to be sure, so please let me know if you have more information and particularly if this would fix an issue for you. It could always be made into another configuration option of course.

Best regards
James

[LinghanLiu]

I'm not sure if adding "Usage |= D3DUSAGE_DYNAMIC;" is necessary.
But I saw messages below in the log file of compiled unity executable program,

d3d: failed to lock level 0 of face 0 of cubemap 29 [invalid call]
d3d: failed to lock level 0 of 3D texture 33 [invalid call]
d3d: failed to lock level 0 of face 0 of cubemap 34 [invalid call]
d3d: failed to lock level 0 of 3D texture 38 [invalid call]

[jam3sward]

Thanks. As Unity is logging errors, that confirms they need to be locked. I've therefore committed your suggested changes at 028993f.