Turn off physics for a collection?


My game consists of one “main” gameplay screen but multiple menu screens. I’m using collection proxies for the menu screens, but I recently encountered this error:

ERROR:PHYSICS: Physics world buffer full, world could not be created.

This was a good warning for me, because I don’t need physics on any of those menu screens and I’m hoping if I disable it on those screens it will increase performance. Is there a way to disable a collection (or world) from using the physics engine?

1 Like


No, there is no way to disable physics on individual collections. It would only have a very marginal impact on performance anyway. You’d save some runtime memory but that’s about it. Are you having performance issues?

1 Like


I am having minor performance issues switching collections, but you’ve already addressed them in this thread. I’ve tried loading async which has helped, but I’m still noticing variable load times in collections. In other words, sometimes it’s almost seamless (100-200ms between switching), but sometimes it takes 2000-4000ms which is very noticeable to a user. Thanks for your help anyway!



Is it always the same sequence of events that results in 2000 vs 200ms or is it totally random? In the case where it takes 2000ms it could be because none of the resources required are loaded, while in the 200ms case it could be that some of the resources have already been loaded since they perhaps were in use by another collection.



It seems pretty random. I’ve changed my code so that once it’s loaded it’s cached and renabled, so obviously that’s faster, but on first-time app load, some collections’ initial load is very fast, while other times it seems to take a few seconds.

Perhaps there’s a profiling tool that can help me track down what’s causing the slowdown?



Is this on a mobile device or on your local machine? If it’s on your local machine then what OS are you using? Perhaps there’s some disk issues or an over-zealous anti-virus?



@therondevelopment If you use the web profiler, then you can capture several frames, and you’ll see the spikes in frame time. From there you should be able to pin point more exactly what system is causing this.



Can this be used with a production app, or only in development mode? I.e. can I use this for an iPhone running a test flight version of my app from the app store?



The webprofiler is available in bundles where the release checkbox hasn’t been ticked (and yes you can have such a build in production if you want to).



I also bumped into this limit, which causes this crash:

When I upped the limit, I noticed this message:

It would be nice with a “no physics” flag for each collection.

1 Like


Yeah a crash is not very user friendly.



We have a fix for this in the Defold 1.2.168 BETA

Yes, we’ve discussed this and have it in our backlog.

1 Like