[Gear VR] ISM/HISM/foliage optimization for mobile VR - when ?

Oculus and Epic are working together on an easier and more optimized Gear VR path for 4.14, but there is not specific work addressing your static-lit HISM use case. I would recommend trying a stationary light or avoiding HISM. Also keep in mind that UE4's Gear VR support is relatively new compared to, say, Unity's. It will take some time to make it as easy to use.

vrdaveb said:

Oculus and Epic are working together on an easier and more optimized Gear VR path for 4.14, but there is not specific work addressing your static-lit HISM use case. I would recommend trying a stationary light or avoiding HISM. Also keep in mind that UE4's Gear VR support is relatively new compared to, say, Unity's. It will take some time to make it as easy to use.

Yeah, that use case somehow is specific to my hardware/software combination. I posted test case project on Answer Hub (here it is in case you want to try it https://drive.google.com/open?id=0BwE6dxM0O2PsdUFxcFU0ZG1SdDA ) and other folks tried it, but it worked for them. For me the ISM is always black on the device. So I gave up on that until I get new PC.

The performance issue I am talking about it this - I have a modular building, a crypt (at about 0:31 sec):

https://www.youtube.com/watch?v=0tPwIhq4Pco

I turned repeating elements into ISM, to cut down drawcalls. Fps improved only slightly. Apparently instances aren't being culled per instance, but rather ISM is treated as while one actor.

What you see in the video is made with merged actors. I simply merged actors by material and got normal fps vs ~20'ish fps with ISMs. Polycount is identical to what I had with ISM, and number of drawcalls should have been the same too (unless ISM is not the same as batching in Unity).

Aye, I was just wondering about UE4 and Gear VR as it seems that Unity is miles ahead of UE4 in terms of performance and support for Gear VR. We all keep our fingers crossed for UE4 get there rather sooner :)

> instances aren't being culled per instance, but rather ISM is treated as while one actor.

Have you seen this thread? If any mesh in an ISM is visible, the whole ISM gets rendered. You will probably be better off using plain static meshes.

> unless ISM is not the same as batching in Unity

No, ISM is designed to reduce draw calls for multiple copies of the same mesh. Unity's batching coalesces draw calls for meshes with the same material. Unlike UE4, Unity's dynamic batching does not include meshes that aren't visible.

> Unity is miles ahead of UE4 in terms of performance and support for Gear VR.

Not sure that is a fair statement in general, but for your particular project I would probably recommend Unity.

vrdaveb said:

Have you seen this thread? If any mesh in an ISM is visible, the whole ISM gets rendered. You will probably be better off using plain static meshes.

Not sure that is a fair statement in general, but for your particular project I would probably recommend Unity.

Oh, I see. Yeah, I am just gonna have to go over the art and come up with something clever to optimize performance.

I really don't like Unity overall and on top of that I would have to learn C# (and I definitely prefer Blueprint instead of conventional programming/scripting). In a long run UE4 is a better engine for what I am planning on doing with it (including non-VR projects). I guess I'll just have to figure out a way to deal with limitations.

Btw, I wanted to record a video of black ISMs to show you, but after rebuilding lighting in my test case and doing full rebuild I no longer get black ISMs on the device :D