I care first about Frustum Culling, but question actual for Occlusion Culling too.
As I see Lua is too slow for this operations and Defold SDK have no instruments to make it using cpp. I try to understand how to optimize game that have big world and camera with pssability to zoom.
Culling is definitely on the roadmap. I am composing a roadmap for optimisation and graphics functionality in general, but this is not quite complete yet. Culling is high on the agenda though, so it should be supported in a not too distant future.
Culling in Lua is not advisable unless there are few objects and GPU overdraw is the primary problem.
Yes, i understand it.
That’s the reason why I try to find some decision/best practices.
Recently I began to help a one team to finish the quite big farm game on Defold. And culling is one of the issue.
I hope this task have big enough priority in roadmap.
Thank you.
Old topic, but is there any issue to vote and track? Were there any ideas on how to implement this? Or what was the story? 
Frustum Culling is now at 4th place in most voted issues on Github, but it will jump to TOP 3, because Defold is already added to Steam, right? I hope, you will take this into account @britzl and @JCash wink wink 
If there is anything our community can help, let us know 
I’ve created a new (smaller) ticket for the sole purpose of frustum culling of renderables.
The previous ticket became an overarching topic which will consist of meny smaller tickets (like this one):
(And this ticket is actively being worked on!)
The frustum culling has now landed in in the dev branch (the alpha version), and you can now test it out in your render script (enabled by default in the default.render_script)
If you have a custom render script, you need to pass in a frustum matrix to the render.draw()calls: documentation
Currently, the only component supporting culling is the sprite component.
We’ll add support for them, one by one in order to ship the feature as soon as possible.
Next up is the mesh component.
Link to the alpha version
I want to point out the significance of this new feature. This will have a huuge impact on game with large levels with many off-screen objects. Either in that there will be a reduction in draw calls or in the amount of data sent to the GPU.
I’m guessing that the improvement will be quite significant in a game such as Fates of Ort by @Alex_8BitSkull for instance. Alex, if you have time please give this alpha a try!
o7
I’ll report back as soon as possible!
Positive results!
Sprite.CreateVertexData: 1.83ms to 0.87ms (0.37ms plus 0.28ms and 0.22ms for frustum culling)
Draw calls: 139 to 34
Vertex data: 2.2Mb to 334kb
I kind of just focused on testing the feature as soon as possible, so just glossed over the work that’s gone into making it happen. Thanks for the hard work @Mathias_Westerdahl, I think I speak for a lot of us because it’s been such a highly requested feature!
It will be very useful in Fates of Ort, and in my future games too.
Defold just gets better!
It works great! (look at the “draw calls” value)
Is there a way to check the availability of frustum culling in the engine to support both render.draw() calls (new and old) in our render script during the feature testing period in the alpha-beta-stable releases?
Good to hear!
Perhaps sys.get_engine_info().version == “1.3.1” would work for this?
Will culling also work for GUI nodes?
Perhaps later, but it is definitely not a priority at the moment.
OK! I implemented the engine version check to support new/old render.draw calls. I will remove it after the stable release of 1.3.1.