godot: Sprite3D and AnimatedSprite3D is rendering very slow

I tried so much variations with/without shading with gdScript, nativeScript (Nim) and different import settings without luck. One archer walk animation, with 8 frame costs 14 fps (reduced to 46fps) . It slows to 19-20fps when I exported it to android also. I’m adding screen shots from my computer with GeForce 940MX screen card (I can play Anno 1404 without any lag with this screen card).

I have only one archer on the screen, and I scripted with nim (very fast programming language). I supposed in this example I made the fastest things I can do. If not please share my mistake.

Version: Godot 3.0 System: Linux Manjaro (ArchLinux derive) Frame rate drops too much (14fps for only one node). I expect it to work with 60fps.

Screen shots: animation code import-settings screen1

I have only one scene as Archer and I’m using a sprite image only. Nothing more.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 7
  • Comments: 22 (15 by maintainers)

Commits related to this issue

Most upvoted comments

Fixed by #39867 in the 3.2 branch.

It’s not fixed in master yet though, so keeping this issue open. A different fix will be used there.

+8
akien-mga on Jul 6, 2020

I’m going to just replace the backend of the Sprite3D with a proper mesh instead of using ImmediateGeometry.

+6
clayjohn on Jun 26, 2020

I can only draw about 100 Sprite3D before i drop below 100fps, but i can draw almost 1000 QuadMesh.

+6
fossegutten on Mar 9, 2020

@clayjohn What about AnimatedSprite3D? It’s surely possible to emulate its functionality using a MeshInstance + QuadMesh, but it sounds tedious to set up.

+6
Calinou on Feb 17, 2020

Does Sprite3D need a refactor? Surely an object that simple should not be so slow to render.

+4
semirix on Feb 17, 2020

This was resolved for master by https://github.com/godotengine/godot/pull/50014, closing.

To confirm this, I benchmarked 3.x against master to compare the current rendering performance of 900 Sprite3Ds in a blank scene (no lights, fallback environment).

Benchmark

OS: Fedora 34 CPU: Intel Core i7-6700K GPU: GeForce GTX 1080 Resolution: 2560×1440 Godot versions: 3.x a05aefb74, master fe6c65a1a

Testing projects:

master - Vulkan Clustered

Project FPS: 1198 (0.8 mspf)
Project FPS: 1195 (0.8 mspf)
Project FPS: 1198 (0.8 mspf)
Project FPS: 1198 (0.8 mspf)
Project FPS: 1199 (0.8 mspf)

master - Vulkan Mobile

Runs faster than Vulkan Clustered thanks to its lower base cost. However, its performance will fall behind compared to Vulkan Clustered in a more complex scene with many lights.

Project FPS: 1380 (0.7 mspf)
Project FPS: 1376 (0.7 mspf)
Project FPS: 1380 (0.7 mspf)
Project FPS: 1379 (0.7 mspf)
Project FPS: 1349 (0.7 mspf)

3.x - GLES3

Project FPS: 1691 (0.5 mspf)
Project FPS: 1704 (0.5 mspf)
Project FPS: 1667 (0.5 mspf)
Project FPS: 1690 (0.5 mspf)
Project FPS: 1689 (0.5 mspf)

3.x - GLES2

Despite the GLES2 renderer’s lowest base cost (out of all the renderers tested here), this is by far the slowest result.

Project FPS: 546 (1.8 mspf)
Project FPS: 548 (1.8 mspf)
Project FPS: 550 (1.8 mspf)
Project FPS: 548 (1.8 mspf)
Project FPS: 550 (1.8 mspf)
+3
Calinou on Nov 3, 2021

@semirix it should probably just be removed and made into a thin shell for a billboarded quad.

+3
clayjohn on Jun 26, 2020

PR is up now! Please test it if you are having performance issues with Sprite3D!

#39867

+2
clayjohn on Jun 27, 2020

See my comment above yours: https://github.com/godotengine/godot/issues/20855#issuecomment-654278054

+1
akien-mga on Apr 28, 2021
Read more comments on GitHub
← godot: Some usages of `class_name` can produce cyclic errors unexpectedly
godot: Static func causes class to not get resolved on run →