Flickering between a pair of images in curved surfaces using mesh_reflection_cube_base

[garth.denley]

We are currently using mesh_reflection_cube_base to handle a set of four curved mirrors in our simulator

One thing we have noticed is that occasionally the mirrors will begin flickering between two separate images: the correct image and another image. The other image is generally either what appears to be an old projection onto a cube map, a previous render to that same mirror, or possibly a previous render to a different mirror.

The problem seems to occur in fullscreen mode only. The PC in question is running two GTX 980s in SLI. The problem does not seem to appear to occur when windowed. It appears to only occur if we are using a setting apart from 6/6 or disabled for reflection updates. The PC itself is part of an assembled simulator and not the easiest thing to diagnose issues on- we can't presently use the editor on it, for example. We have not yet been able to recreate the problem on another PC.

The issue appears to affect one or two mirrors when it occurs. The affected mirror can change, usually when changing rotating the view, and the previously-affected mirror begins behaving as expected. Reducing the number of mirrors down to one occasionally shows the same issue.

The issue appears to occur more often the lower the reflection update interval (eg. 1/6 is the worst, while 3/6 means it occurs less often). Running at 6/6 or disabled seems to avoid the issue, but it has a severe impact on our frame rate (from about 95FPS without vsync down to 25FPS).

It appears to occur whether or not we share the reflections, or have dedicated separate materials and meshes for the mirrors.

Some locations in our world are more likely to immediately trigger the issue than others.

A video_resart or render_reload appears to clean up the mirrors. However, if we start moving again, it is common for the problem to reoccur, usually with an image flickering based on how the mirror appeared at the point of the restart/reload.

I believe we are using the October/November 2013 SDK, with an update to a newer version of the SDK pending.

I have a few questions that I hope may help us to track down and hopefully avoid the issue:

- When using settings such as 2/6 or 3/6 for reflection updates, does this mean that two or three faces of the cube map are regularly updated each frame, ie. we'd be guaranteed to have a full set of new cube map images after three or two frames respectively? Or is there some algorithm applied to selectively determine which faces to update each time, meaning that some faces could be updating constantly, with others retaining data from an very old view?

- Are there any known bugs in the reflection cube map implementation in the SDK we are using (~Nov/13) that have since been fixed in the latest Unigine SDK, ie. are likely to be solved when we upgrade?

- Are there any suggestions as to additional things to try that might give further information, or possibly work around the issue we are encountering?

Any suggestions and feedback most appreciated.
 

[unclebob]

Hello, Garth!

 

You're right, by using settings such as 2/6 or 3/6 for reflection updates it'll force the engine to render several faces per frame. So 2/6 option will render whole cubemap within 3 frames and so on and so forth.

 

We don't have similar issues in our bug tracker. It could be driver or hardware issue if it's only possible to reproduce it on one machine. Try to use our latest Unigine 1.0 SDK (Jul 7th 2014) and report back.

[garth.denley]

Hi unclebob,

Thanks for the additional information and for chasing things up. We've been trying to guess at the underlying implementation to try to determine a cause and hopefully a workaround- being able to eliminate old textures at the Unigine level as a possible cause narrows things down a fair bit.

As of very recently we were able to get a similar failure on different hardware (the second machine has 3x GTX 780 Ti cards), with updates on 2/6, full-screen with SLI/spanning enabled. Interestingly, the problem seemed to go away when running off a single card (and single display) with no SLI.

At this point it seems non-6/6 updates, SLI, and using mesh_reflection_cube_base are triggering the issues. Based on this new information, is there anything that springs to mind that we may be able to try or experiment with?

Amongst other things, I'll likely be experimenting with the settings in the nVidia control panel today relating to SLI to see if we can narrow the issue down further.

Thanks for the suggestion re trying the latest 1.0 SDK. This could be an easier option than making the jump to 2.0.

Cheers,
Garth

 

[garth.denley]

A quick update: The issue is definitely tied to SLI. We've been able to get the mirrors to behave by either restricting SLI to a single GPU (effectively disabling it) or messing about with the DX1x compatibility bits (mostly guesswork at this point) in Nvidia Inspector.

Interestingly, the default profiles that mention Unigine in Nvidia Inspector (0x088000f5, 0x080000f5) exhibit the problem. We've had the best results with the Nexuiz settings (0x040200F5) for some reason- the problem vanished *and* the framerate improves significantly. I couldn't say why at this point.
 

[unclebob]

Hey, Garth!

 

Thanks a lot for your detailed investigation, we'll try that SLI setup on our testbed and see if we can find something interesting. By the way, have you tried to switch between DX11 and OpenGL?

[garth.denley]

Hi unclebob,

Not a problem. I hope the information ends up being of use.

I haven't been able to test things with OpenGL settings. Our application is (I understand) hardcoded to use DX11, so it's not something I'm readily able to get results on.

A few more things came up today in testing:

- The issue behaves similarly with 2x GTX 980 cards swapped in to the second machine mentioned. Namely, we see the same failure with the default profile, and it is also fixed by the same compatibility bits change (the 0x040200F5 setting).

- Three-way SLI on GTX 780 Ti cards with the 0x040200F5 settings failed- the problem was significantly worse. Restricting SLI rendering to 2 GPUs made things work again. I didn't have the opportunity to dig into this configuration much further than that.

- Going to 3/6 updates with the 0x040200F5 setting actually resulted in consistent failures. This was unusual as testing on the default settings tended have problems less frequently if 3/6 updates were used over 2/6.

I hope this extra information is also of use. We'd definitely be keen to hear anything you end up discovering on the Unigine side of things as it'll help to refine the setup we've got here. We'd be particularly keen on any Unigine endorsed Nvidia DX1x SLI compatibility bit settings if there end up being any. :)

Cheers,
Garth