-
|
I have an Infinix NOTE 50 Pro phone, and I conducted tests on it using "many foxes." The results showed that even without any foxes, the frame rate only reached 20, and regardless of the number of foxes, the CPU usage remained relatively low. Could this be due to certain features not being enabled? These are the enabled features. "android-native-activity",
"gltf_animation",
"bevy_light",
"ui_bevy_render",
"sysinfo_plugin",
"bevy_gltf",
"scene",
"tonemapping_luts",
"zstd_rust",
"multi_threaded",
"default_font",
"bevy_dev_tools" |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
Maybe an obvious question, but did you compile with release optimizations? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I compiled it with release cargo ndk -t arm64-v8a -o android/app/src/main/jniLibs build --profile release |
Beta Was this translation helpful? Give feedback.
-
|
I used tracy_profiler to check the runtime situation and found that even when only one Plane is being rendered, RenderExtractApp still takes a significant amount of time. |
Beta Was this translation helpful? Give feedback.
-
|
After multiple tests, it was found that the performance bottleneck lies in Plane3d. The larger the Plane, the lower the frame rate. This might be due to my phone not supporting GPU preprocessing. |
Beta Was this translation helpful? Give feedback.
-
|
It turned out there was no issue with the code; it was simply that the GPU was relatively slow. By default, StandardMaterial was used, which is a PBR-based material and inherently computationally heavy. When the Plane3d area becomes large, the fragment shader calculations slow down significantly. After switching to a custom simple Material, the problem was resolved. |
Beta Was this translation helpful? Give feedback.
It turned out there was no issue with the code; it was simply that the GPU was relatively slow. By default, StandardMaterial was used, which is a PBR-based material and inherently computationally heavy. When the Plane3d area becomes large, the fragment shader calculations slow down significantly. After switching to a custom simple Material, the problem was resolved.