ISMCs and HISMCs performance optimization for mobile VR (Gear VR, etc.)

motorsep · January 5, 2017, 2:49pm

Modular level design is essential for mobile VR due to how culling of surfaces is done on mobile GPUs. However, ISMCs and HISMCs perform poorly on Gear VR (referencing Gear VR here because that’s the platform I’ve been working on and testing intensively). Not only they perform poorly, but also distance culling per instance doesn’t work. Distance culling works only for the entire (H)ISM Component, which makes it useless.

Imagine dungeon built of modular (H)ISMCs and player being in the middle of it. All instances beyond whatever distance culling value was set should not render and whatever instances are visible should perform at least at the same level as if it was built with individual actors. Currently level built with (H)ISMCs performs worse than the one built manually having all pieces as individual actors.

Thanks beforehand

motorsep · January 11, 2017, 2:48pm

Crickets… Dear Epic, do you think you folks can make this happen, please ?

Zireael07 · January 11, 2017, 3:22pm

Copied from reddit, might be related:

Hmm, I installed 4.14.1 to test if it changed things, but it works like 4.13.2.

What is happening is that the lighting solution is adding triangles to the render batch. I am not sure if this is a bug or what, but I will look into it more. Apologies for misleading on the HIM frustum polygon culling, I was working under the assumption that they required tweaking in order for that, but it appears they just make clever use of the LoD groups to LoD them down to 0 (and thus don’t show culling in VisualizeCulledPrimitives mode until the actor is culled).

There is definitely a bug with HIM lighting. The IM object interacts correctly.

r.VisualizeCulledPrimitives shows you occluded objects, but as far as we see there is no occlusion culling with HISMs. Frustum culled objects can’t be visualized with that command as they are not on screen. Or did I get something wrong? Did you maybe refer to the situation where one Instance seems to occlude the others (still don’t know what to make of this)?

I also tested Freezerendering - no effect on HISM, all instances are visible when returned into view - I guess this works only for the whole bounds of the entire component.

I noticed that HISM doubles my tris. i.e. 10 instances of the 1200 tri sm_rock result in 24000 tris displayed under stat Engine, instead of the expected 12000 (at all times). Is that what you meant by “the lighting solution is adding triangles to the render batch” can you elaborate how you noticed that (not sure what to look for in your attached picture)?

Yea, I knew the number of tris in the scene before hand (1000x9800) on my meshes, and then checked them vs the Stat.Engine tris being rendered.

When most of the HIM is behind the camera, the Stat.Engine shows ~20,000,000 tris being rendered, which is more than 2x the total triangles of the mesh. When I turn lighting off (Unlit) the rendered TRI’s is a number more reasonable, but even then is still more than expected. Each ball mesh should be 9,800 tris, but with only one in the frustum it was still doing ~32,000 tris. I believe this is part of the bug.

The second album I posted shows the IM object, and its proper function. Same tris rendered with Lit/Unlit, and no triangles are culled, 9,800,000 rendered at all times when blue is visible.

motorsep · January 11, 2017, 3:40pm

Host likely very related and more :eek: