Problems with NGUI on fast moving objects on 3.0.6

[LTyrosine]

I'm using NGUI for 3D controls onboard a space ship.

From 3.0.6 these controls stop receiving mouse focus and clicks when the ship is moving fast (with rigidbody + force). It worked really well on prior versions.
I'm digging on UICamera source code trying to find the reason for it but any hint or idea would be very welcome.

Thanks.

[ArenMook]

To be honest I'm surprised you didn't run into more issues with a setup like that. Ideally, you need to use a separate camera for your UI, and this camera must be stationary. You can have it match the field of settings of your game camera, but it should still stay in one place. You'll get better performance, and issues like the one you mentioned, and the UI being delayed by one frame will disappear.

If you don't want to alter your setup, comment out the part in NGUI that adds a rigidbody to panels (this improves performance according to Unity 4.3) -- line 520 of UIPanel:

1.                 // Apparently having a rigidbody helps
2.                 if (rigidbody == null)
3.                 {
4.                         Rigidbody rb = gameObject.AddComponent<Rigidbody>();
5.                         rb.isKinematic = true;
6.                         rb.useGravity = false;
7.                 }

[LTyrosine]

Humm, I see.

Currently there is one central UIPanel, under ship's transform, handling all buttons and displays in 3D Space. It is working really well without flicker or any other issue (except that new one).

So, I should move NGUI controls to outside ship and rotate gui camera to match onboard camera (that is controlled with mouse). I'll try that. I don't know for sure but I'm suspecting even that this extra mass added from new Panel's rigidbody is the reason for some movements changes in the game. Cool!

Thanks for such fast reply.

[danfoo]

To be honest I'm surprised you didn't run into more issues with a setup like that. Ideally, you need to use a separate camera for your UI, and this camera must be stationary. You can have it match the field of settings of your game camera, but it should still stay in one place. You'll get better performance, and issues like the one you mentioned, and the UI being delayed by one frame will disappear.

In my humble opinion, NGUI needs to be adapted to work in a situation such as the above. While multiple-camera setups is a usable approach in traditional rendering it quickly falls apart when you need stereoscopic rendering for HMDs such as the Oculus Rift. We have a very similar situation to the above and ran into the exact same issue.
Please consider changing this as soon as possible. Thanks!

[danfoo]

Perhaps I should elaborate a bit more.
First I should note that removing the rigidbody and the code adding it automatically did work. The UI responds as expected even at rapid position changes.

Regarding having NGUI-generated interfaces/displays attached to moving objects, this is necessary as soon as the gui needs to be rendered by stereoscopic cameras. The workaround cited in a few places around the net is to have a UI camera render to a rendertexture and attach that one to your moving object (and thusly being rendered by the Rift cameras). However, this works only if you have a single (or perhaps two) flat menu-like displays. In cases where you would like NGUI to drive cockpit displays, indicator lights etc. such an approach does not work.

This might seem like a situation NGUI was not "intended for", but it is very efficient to use it for displays as opposed to using traditional textures and UV mapping, especially as soon as you incorporate text into the mix.

With Unity supporting the Rift and many (both independent and traditional) studios investing in VR I would argue that it is valuable both for NGUI and the upcoming Unity GUI to take these situations into account and make sure they work as well as possible.

Again, thanks!