Hi all,
When I launch my application and view it on a device (iPhone8, iPhone12, and iPad), the battery drains at an alarming rate. It can deplete 10% battery in a one minute. This has been tested on the devices above with both Chrome and Safari. I’ve never changed any of the default browser settings. Performance wise, we are hitting 60 FPS, and everything in the scene is static bar maybe 6 objects.
Its just the battery seems to deplete at an alarming rate. Are there known contributors to this from Needle engine that I need to be aware of? For example, a directional light, or some other component? I know this is a broad question, but any advice is helpful. Again, performance is actually very good, its just the battery issue.
Hello there – we have an experimental AI bot that might be able to help you with your question. Would you like to try this out?
How it works:
Reply to the messages of the bot that end with a thread_id to interact with it and ask follow-up questions. You can also mention the bot directly in this channel to get help.
The rapid battery depletion you’re experiencing is often caused by high resource usage. Even if the scene appears static, certain features or components can be particularly demanding. Here are a few factors from Needle Engine that could contribute to high battery usage:
Post-processing effects: If your application uses post-processing effects (handled by the Volume component in Needle Engine), these can be quite GPU-intensive, especially on mobile devices.
Physics calculations: If physics components like Rigidbody or Collider are in use, especially with moving objects, these could be draining the battery due to continuous calculations.
High-resolution textures: If your application uses high-resolution textures and a lot of them, they can significantly tax the GPU.
Complex shaders/materials: Custom shaders or materials with complex calculations can also contribute to the issue.
Networking: Continuous networking activity can drain the battery quickly. In Needle Engine, if you’re using components such as SyncedRoom or SyncedTransform, they could increase the load due to synchronization.
Animation: Active animations, even subtle ones, can keep the GPU/CPU busy.
Overdraw and fill rate: Overlapping transparent objects or a high draw call count can lead to overdraw, which can be costly on mobile GPUs.
Lights and Shadows: Dynamic lights and real-time shadows are heavy on performance. If you have directional lights casting real-time shadows, consider baking the lighting if possible.
To address the battery issue, consider the following:
Performance Profiling: Use developer tools or Needle Engine’s built-in performance statistics (append ?stats to your URL) to identify bottlenecks.
I’ll post the following in response to the bot, in case anyone else sees this in future.
Post processing effects - None
Physics calculations - There are about 20 static checkpoints in a race that are checking an OnTriggerEnter against 6 racers so I cant imagine this is the main factor. However, I have encountered previously reported issues with rigidbodies, and even though the rigidbodies I use are kinematic, perhaps they are somehow contributing, but again, 6 kinematic rigidbodies in a scene isnt excessive.
High-resolution textures - There are some 512mb textures with crunch compression at 50% but the rest are low res textures
Complex shaders/materials - Currently using no custom shaders, instead using the reccommended Unity GLTF PBR shader
Networking - None
Animation: - The bot says “Active animations, even subtle ones, can keep the GPU/CPU busy.” Im hoping Needle doesnt have an issue running about 10 animators at once. They are very basic.
Overdraw and fill rate - Potentially worth looking into. Our scene isnt very complex and has a low enough poly count, however it does consist of quite large chunks.
Lights and Shadows - Nothing in our scene is being lit by a realtime light. We use blob shadows ( a texture), and are in the process of using vertex lighting to fake lighting.
Performance Profiling I didnt realise I could append “?stats” to get further info so I will do that.
Ill look into the bots responses however Im not confident any of the above are the major contributors to our issues.
Both can be controlled from Needle’s side, e.g. limiting the framerate to 30fps and setting a resolution scale factor that counters the high dpi factor of the device somewhat
What does have an effect on performance is using compressed textures and meshes vs. not doing that – by default Needle will etc1s + draco compress everything which saves a factor 4-10x of memory bandwidth and thus also battery
10% battery in a one minute
This sounds pretty much physically impossible and I haven’t seen that, like, ever. Would you be able to share a link (can be in DM) of that project?
Thanks for the response @herbst🌵 . I didn’t realize about the compression so I will change that to use lower resolution power of two textures without crunch compression. I had considered limiting to 30 FPS but haven’t done so for this initial test. I can look at that as well.
Yes I can share a link to you privately for the current version. It drained about 8 percent for me in about 1 minute recently and over 10% in less than 1 race length (90 seconds) for someone else on iPad so I can promise you that it’s happening. I do agree that it’s a bit mental. I’ll share the link with you privately and won’t make any amendments so you can see it in its current state. It would be great if you could try it on mobile rather than PC. I use safari but have had the issue reported on both safari and chrome
One thing I can note is that it looks like very regular memory allocations and freeing, aka a memory leak – JavaScript is pretty good at doing garbage collection but it’s one thing that can be avoided
I can see in a GPU capture that there are realtime shadows in action, and an entire depth pass is rendered (so all objects are rendered twice) – would recommend checking if there’s some realtime light hidden somewhere in the scene, there is a “Light Inspector” window in Unity that may help with that.
For the memory leak, Im not sure what that could be. I know that at regular intervals I do swap textures on a material. I am also accessing a shared material in some parts, but also assumed thats just standard functionality. I do open a web socket actually so perhaps its related to that
I will do a pass on the lighting. Perhaps something got missed. In fact, I think you’ve touched on something here.
I can reduce the overall poly count of the scene. In fact that will be done shortly. I can definitely reduce the draw calls.
I can again definitely reduce the vertex count but good to know it is within an acceptable range
that might be able to help you with your question. Would you like to try this out?
