Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 359 Game & application design
- 317 Plugins
- 70 User experience
- 75 Marketplace
- 293 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 674 Bugs and issues
- 195 Introduce yourself
- 242 Announcements
- 106 Forum talk
- 405 Relax cafe
Large slowdown in 3D instancing in 2024 3dbase library
PaulH
Member
I've noticed a dramatic slowdown in some 3D processing between version 2024.2 and 2024.6.1, and still present in the latest version. One of my apps uses a few thousand instances of 3D primitive shapes to build fishing flies. Up to 2024.2 a fairly complicated fly could load almost instantly, in 0.3 seconds. I only see that slowdown with models with large numbers of instances. When I include the 3dbase library from 2024.6.1 or newer that time goes from 0.3 seconds to 5.93 seconds. Here's an video showing the change: 
Once the instances are defined, the frame rate is fine. I haven't tried profiling it, but it seems like updateInstances or something similar may be involved.
It's not a major problem for me as I can continue to use the older 3D library, but I thought I should report this.
Once the instances are defined, the frame rate is fine. I haven't tried profiling it, but it seems like updateInstances or something similar may be involved.
It's not a major problem for me as I can continue to use the older 3D library, but I thought I should report this.
Comments
I am not sure what changes would have made it slower, can you take the time to profile both versions (with Gideros Studio profiler) and share the results ?
Likes: MoKaLux
In 3DShapes.lua setInstanceCount() now calls updateInstances(). My code changes the number of instances thousands of times, 5,152 in this case, as it builds them dynamically, and can't set the matrix for each new instance unless it is within the number of instances indicated by the most recent call to setInstanceCount. This code then calls updateInstances() only once per mesh when its done defining them all, 8 times in this case, taking only 5 ms. By adding updateInstances() to setInstanceCount() it's now doing updateInstances() 5,152 times, and that's taking 5,360 ms.
Commenting out the added call to updateInstances in setInstanceCount eliminates the slowdown.
It seems to me to be more appropriate to have the calling code call updateInstances when it's done with any changes to the number of them. If there's a good reason to have setInstanceCount call updateInstances every time by default, I'd like an optional parameter that would skip that.
Likes: MoKaLux
Perhaps the best thing to do is to delay actual Mesh:setInstanceCount and Shader update into the updateInstances() call, making the setInstanceCount an almost no op call by itself.
Likes: MoKaLux
Likes: MoKaLux, PaulH