Battery life draining extremely fast on mobile devices

  1. For the repeating elements like trees and stones and stuff I recommend selecting the material and turning “GPU Instancing” on

Ah yeah actually good point. Noob mistake.

A quick question, does Unitys occlusion culling work with Needle engine? The environment is made up of quite large chunks but Ive not set up culling as of yet

by user 259070246382469121

  1. It looks like every single horse has numerous draw calls in itself – if possible I’d combine these into one skinned mesh / one or two materials for the horse

Re (2), there’s at least one enabled light :slightly_smiling_face:

I did actually see the light afterwards. Thank you. Which part of the profiler are you seeing all this in btw? (Complete noob with web dev here)

by user 259070246382469121

  1. Seems that there’s a bunch of disabled assets likely from our starter scene still in the project – if you want them gone you can set them to “EditorOnly” in Unity instead of just disabling them.

If things are just disabled we export it, since you may want to turn it on at runtime – “EditorOnly” removes it

Typically I take a capture with Spector.js (Chrome extension similar to RenderDoc, if you know that) and download the root GLB and check it with our in-house viewer (https://viewer.needle.tools)

Fantastic. Thank you, youve been an unbelievable help today. I’ll address all of the above, and look into the memory leak then.

by user 259070246382469121

Let us know how it goes :slightly_smiling_face:

@herbst🌵 Sorry just one more noob question - where are you seeing the generated root GLB?

by user 259070246382469121

The glb is in your webproject in the assets folder

Ah thank you Marcel. I thought in this context it was something generated by Spector.

by user 259070246382469121

Update
There was a potential memory leak coming from how I was using a custom written FPS calculato. This has since been removed (in place of using the ?stats flag).

The blue line generally looks smoother now @herbst🌵 however, I have definitely ran it some times with the heap allocation graph looking a but zig zag as it did when you tested it so Im still a bit stumped at that.

Performance changes

  • Removed all lighting (and instead used vertex colour info in our models)

  • Static batched everything that could possible be batched @herbst🌵 You recommended in your point 5 above to enable GPU instancing for objects like trees, stones etc, but from what I can gather, if the objects are not going to move, then its better to static batch them instead (as that cant be done along with GPU instancing). Is this correct? Profiling with Spector seems to give more or less the same info regardless but Im not sure if there is something Im missing with this

  • Set unneeded objects to Editor Only

  • Used GPU instancing on the few shared materials that move

  • Removed a lot of materials in place of a shared material and reliance on vertex colour info

  • Reduced poly count by about 100k

Draw calls
Comparing draw calls from certain moments between the old and new build
-Camera 1 = Before: 391 | After: 241
-Camera 2 = Before: 458| After : 300
(around 36%)

Vertex count

  • Before: 386172 | After: 244113 (36% reduction)

Battery life test
The initial version seems to fairly consistently reduce battery life at a rate of 1% per minute with limited interaction (going from 80% to 60% over the course of 30 minutes)

The latest version with all the above changes seems to perform give or take the same so I’ll need to profile this more deeply.

by user 259070246382469121

GPU instancing will save much more than combining meshes (if you mean that with static batching) in the case of mobile devices

0.5-1% per Minute sounds much more reasonable than the 10% per minute you mentioned initially, and similar to what you’ll likely see with any app that renders every frame (e.g. games or videos or pages with motion). Next up would likely be reducing frame rate or the render scale factor.