Physic culling ?

[evanspro]

Hey there !

I’m trying to optimize the physics performance of my game. It works fine on iOS (it could be better though), but on Android… well… it does not.

Just so you know : my game is not a tile based game. I have a lot of physics bodies (~ 300…) but I’d say that most of them (around 80%) are just static bodies. There are around a hundred of physic bodies in each level (of course, it depends on each level).

So, I tried to deactivate all the physical bodies that are offscreen by setting “isBodyActive” as false.

Today, I’ve done something like that :

1. I create an array where I’ve listed all the physical bodies

2. In an enterFrame listener, I read the array and see if the coordinates are off or on screen.

It does work (bodyActive is set to false), but it doesn’t seem to change anything : my game is still slow. My guess is having an enterFrame listener checking all the bodies one by one is just… too much to handle.

So, to avoid having an enterFrame listener and getting x and y, I was thinking about doing this :

1. One rectangular box, corresponding to the “on screen” zone, set as a physical body, then set as a sensor.

2. Adding a collision listener to that box : everytime it touches any other body, the body is activated, otherwise it’s deactivated.

So here are my questions :

- Is using “isBodyActive” effectively efficiant ?

- Is there any better way to deal with offscreen physical bodies ?

BONUS QUESTION : What is better ? Using several different physical bodies, or instead, using one multi-element physic body ?

[undecode]

Hi Evan, i don’t know about your first question, but have you tried assigning physical bodies just to the relevant items? Do you have to have 300 items at the same time, all with physics added? Even if 80% are static?

[bjsorrentino]

Hi @evanspro,

Another question would be, can you combine multiple physics objects into one? ~300 objects is a considerable amount, so if you can reduce that amount by combining smaller objects into multi-element bodies or similar, that would boost performance.

An even better approach (if possible) would be to “swap” offscreen physics bodies with bodies that are about to come on screen. For example, if you have “50 coins in the entire level” but only 10 might be on the screen at once, you could create just 10 coins (not 50), then as they go offscreen, you place them into some kind of offscreen “queue”. Then, as they are about to come back on screen, you pull them out of the queue and place them in their new location. I did this kind of queue setup with one of my games, and while it took a fair amount more up-front coding effort and management functions, it made the performance stellar fast.

Brent

[evanspro]

Hi !

@undecode :

Yes, “unfortunately”, I did assign physical bodies just to relevant items. For now, I actually managed to reduce this number by changing and simplifying some of my heaviest level.

@Brent :

Like I said, I managed to reduce the number of physical object by fusionning some bodies into multi-element bodies. But I wasn’t sure it would actually improve performance (at this point, it’s kinda hard for me to see if it’s actually better or if it’s just some kind of placebo effect).

And for what you’re suggesting, I’d love to know how you would handle the “queue” system : are you checking all the bodies on “enterFrame” or by using a timer ? Because at first, I made an enterFrame listener checking coordinates. Like I said, it did work, but it was too expansive to be really effective (I’m trying to run my game at 60 fps)…

[bjsorrentino]

Hi @evanspro,

While you could check the offscreen objects by Runtime or timer-based position checks, in my game I actually used the physics engine for this purpose. I simply created one big rectangular vector object which was the size of the entire screen (actually a bit larger, just to be safe), and set that as a physics sensor object. Then, I made its collision listener only check the “ended” phase… so, when any valid game object exited the bounds of that object, it would trigger the collision listener. That means that the object was effectively “off screen” because the rectangle covered the entire screen.

In the collision event, I would take the object that just left the bounds of the rectangle, move it far offscreen somewhere (like x/y -10000,-10000) so that it would not risk appearing anywhere “in the world”, make it physically inactive, and add its object reference to my queue of available objects. Then, when my game needed to put the same type of object back into the world (say a “coin” object), I would check the queue for that type of object, pull it out of the queue, and place it back in the world, once again making it physically active. Note that when it entered the bounds of the sensor rectangle, it would not trigger a collision event because I never detected the “began” phase… so it didn’t matter when it entered the screen, only when it exited the screen.

Hope that helps clarify things,

Brent

[evanspro]

Hey @Brent,

Funny ! This is exactly what I started doing : using a physical body to activate or deactivates other items. But I didn’t go through the whole thing because I wasn’t convinced it would be enough to improve performance. 

Also, I was starting doing it with the “began” event phase instead of using the “ended” event.

And I didn’t even think about deactivating “coins” (or whatever physical bonus exist in my game) : this will, for sure, change a lot. I’m gonna do it and see how it works !

Thanks again, it helps a lot !

[bjsorrentino]

Hi @evanspro,

Happy to help! Like I said, this entire approach caries with it more up-front effort, in building the queue system. However, it will drastically improve performance… consider if you had a total of 300 “coins” in a level, but at any one time, perhaps a maximum of 20 would appear on the screen. Building a queue system allows you to eliminate a whopping 280 physics objects from the world, and that should make the game run as smooth as melted butter.

Another note: in my game, I was able to determine in advance the number of any particular object that may be on screen at once. However, if that isn’t possible for your game, consider populating the queue with a certain “expected” number, but then, if a time comes where the game checks the queue and there isn’t one of those items available, feel free to spontaneously generate/create that item and then, when it eventually goes offscreen, it can be added to the queue just like the items you originally put in there.

Brent

[undecode]

Hi Evan, i don’t know about your first question, but have you tried assigning physical bodies just to the relevant items? Do you have to have 300 items at the same time, all with physics added? Even if 80% are static?

[bjsorrentino]

Hi @evanspro,

Another question would be, can you combine multiple physics objects into one? ~300 objects is a considerable amount, so if you can reduce that amount by combining smaller objects into multi-element bodies or similar, that would boost performance.

An even better approach (if possible) would be to “swap” offscreen physics bodies with bodies that are about to come on screen. For example, if you have “50 coins in the entire level” but only 10 might be on the screen at once, you could create just 10 coins (not 50), then as they go offscreen, you place them into some kind of offscreen “queue”. Then, as they are about to come back on screen, you pull them out of the queue and place them in their new location. I did this kind of queue setup with one of my games, and while it took a fair amount more up-front coding effort and management functions, it made the performance stellar fast.

Brent

[evanspro]

Hi !

@undecode :

Yes, “unfortunately”, I did assign physical bodies just to relevant items. For now, I actually managed to reduce this number by changing and simplifying some of my heaviest level.

@Brent :

Like I said, I managed to reduce the number of physical object by fusionning some bodies into multi-element bodies. But I wasn’t sure it would actually improve performance (at this point, it’s kinda hard for me to see if it’s actually better or if it’s just some kind of placebo effect).

And for what you’re suggesting, I’d love to know how you would handle the “queue” system : are you checking all the bodies on “enterFrame” or by using a timer ? Because at first, I made an enterFrame listener checking coordinates. Like I said, it did work, but it was too expansive to be really effective (I’m trying to run my game at 60 fps)…

[bjsorrentino]

Hi @evanspro,

While you could check the offscreen objects by Runtime or timer-based position checks, in my game I actually used the physics engine for this purpose. I simply created one big rectangular vector object which was the size of the entire screen (actually a bit larger, just to be safe), and set that as a physics sensor object. Then, I made its collision listener only check the “ended” phase… so, when any valid game object exited the bounds of that object, it would trigger the collision listener. That means that the object was effectively “off screen” because the rectangle covered the entire screen.

In the collision event, I would take the object that just left the bounds of the rectangle, move it far offscreen somewhere (like x/y -10000,-10000) so that it would not risk appearing anywhere “in the world”, make it physically inactive, and add its object reference to my queue of available objects. Then, when my game needed to put the same type of object back into the world (say a “coin” object), I would check the queue for that type of object, pull it out of the queue, and place it back in the world, once again making it physically active. Note that when it entered the bounds of the sensor rectangle, it would not trigger a collision event because I never detected the “began” phase… so it didn’t matter when it entered the screen, only when it exited the screen.

Hope that helps clarify things,

Brent

[evanspro]

Hey @Brent,

Funny ! This is exactly what I started doing : using a physical body to activate or deactivates other items. But I didn’t go through the whole thing because I wasn’t convinced it would be enough to improve performance. 

Also, I was starting doing it with the “began” event phase instead of using the “ended” event.

And I didn’t even think about deactivating “coins” (or whatever physical bonus exist in my game) : this will, for sure, change a lot. I’m gonna do it and see how it works !

Thanks again, it helps a lot !

[bjsorrentino]

Hi @evanspro,

Happy to help! Like I said, this entire approach caries with it more up-front effort, in building the queue system. However, it will drastically improve performance… consider if you had a total of 300 “coins” in a level, but at any one time, perhaps a maximum of 20 would appear on the screen. Building a queue system allows you to eliminate a whopping 280 physics objects from the world, and that should make the game run as smooth as melted butter.

Another note: in my game, I was able to determine in advance the number of any particular object that may be on screen at once. However, if that isn’t possible for your game, consider populating the queue with a certain “expected” number, but then, if a time comes where the game checks the queue and there isn’t one of those items available, feel free to spontaneously generate/create that item and then, when it eventually goes offscreen, it can be added to the queue just like the items you originally put in there.

Brent