Configuring for runtime performance at the expense of load time

[simon.wade_]

In Unigine 1 we often use the render_manager_check_shaders option, before delivery to the customer, to reduce frame rate stalls that may be noticeable when our simulator is used for the first time (we're in the enviable position of supplying both hardware and software, which makes this approach feasible). Subsequently we use the other render_manager_* options that prioritize runtime performance at the expense of loading time, as we consider a consistent frame rate to be critical.

Unigine 2 appears to have the render_manager_create_meshes/shaders/textures options, but enabling these doesn't have the same effect, so once again we're experiencing some runtime stuttering.

Does anybody have suggestions for the best settings to use, or any other techniques, that prioritize runtime performance in this manner?

(I should note that performance seems fine after we've navigated the world a few times and the shader cache ceases growing. Also, we tried adding all our materials to the world file, but that didn't appear to improve things.)

[esger.abbink_]

Having the same issue we would also be interested in techniques/settings to reduce (initial) stutter at the expense of load time. Even if load time would be magnitudes longer, that would still be acceptable as that normally would be at most a once-per-day operation.

[silent]

Hello!

render_manager_create_textures 1 / render_manager_create_meshes 1 are working as expected and will work fine if GPU VRAM is not the bottleneck (all the meshes, textures and shaders should fit into it). You can see real GPU VRAM usage with GPU-Z tool. If you having very extensive GPU VRAM usage you can try to reduce textures resolution a bit via render_textures_max_resolution command to see if there any difference.

render_manager_create_shaders 1 working for DX11 API only, and may not create shaders for the dynamic materials (such as particles that enabled only by user interaction). But all the static shaders that initially available at the world will be created just fine.

You can check Superposition sources (Warming.cpp) to see how we manually doing the warming-up process. For the small room it's pretty easy to implement, but it should not so difficult to extend to the larger worlds as well.

Thanks!

[simon.wade_]

Thanks! I investigated our VRAM usage, and that's definitely not a bottleneck (real usage is about 1.2GB out of 8GB).

Using render_manager_create_shaders improves things, but doesn't eliminate every issue. We're not injecting any content at runtime; the world is pretty much static if you exclude the sun & moon world lights, and a cloud layer.

On further investigation it appears that the issue occurs when WorldClutter objects enter the frustum. Is this to be expected? Do these fall under the "dynamic materials" category, and hence require warming? As an aside, I don't think our clutter is particularly dense, and the mask image is mostly empty.

[silent]

If you are loading your world and Game camera is not seeing any Clutter objects they will not be loaded. Maybe you need just to set couple of additional cameras and during the loading time just do a quick switch between them.

Thanks!