adding and removing physics

[jazzarssoul]

Hey Brent I do have a camera system where it’s just the group.x & y following player.x & y

very basic,

and literally everything on the playing field right now to a 10000 x 10000 sized app with about 200 people are all moving and all have physics.

The view in this scenario is limited to 1280 x 720 so max, I would dealing with about 5 - 10 people on the current screen and hope to not allow other objects to be requiring physics at this point as it really lags it down. Also as mentioned I need to incoroporate some form of one eat will spawns 2 more people off screen with hopefully no physics attached at this point until they become on screen items because it would truly lag it out exponentially

Thanks [import]uid: 87730 topic_id: 36384 reply_id: 145130[/import]

[bjsorrentino]

Hi @jazzarssoul,

I still think you can implement some kind of physics sensor solution, BUT you must remember that you can’t shift display groups around independently (in regards to your camera) without breaking the physics collision environment. In other words, you can’t just put a “screen size sensor” locked in place (in one display group) and then have the “camera” move the underlying world around. It will not detect the collisions properly.

You might try to attach the sensor to the player, so it follows it around, and gets the proper collisions when other peeps come into contact with it.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 145215[/import]

[jazzarssoul]

how do you mean can’t just put a “screen size sensor” locked in place?

do you mean if I was to place the physicsBox I’ve created and set that to a constant update to the player.x and y? and not place it in the display group [import]uid: 87730 topic_id: 36384 reply_id: 145265[/import]

[bjsorrentino]

Well basically, the physics engine requires potentially-colliding objects to be in the same “coordinate space”. This is not a new factor, but developers tend to stumble on it because they move an entire display group containing physics objects (to move them all at once), and then they are perplexed why those objects are not colliding with physics objects in other non-moved groups.

How this pertains to your project is that you’re likely moving the entire “world” to simulate the camera. So, if you imagine that you have a stationary “screen sensor” that is positioned in a different display group (not moving with the world), then you won’t get the proper collisions… thus rendering the approach pointless, since it’s that sensor which is supposed to collide with those off-screen objects and “activate” them as they come into range.

What you might be able to do is link this sensor to the PLAYER, either as a secondary body, or using a pivot joint. This way, the sensor would remain in the main group and it should receive the proper collisions. Does this make sense? It’s hard to describe what I’m talking about without actually showing it in action.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 145312[/import]

[jazzarssoul]

Is this what you were getting at?

[lua]
– for the lack of throwing in all the code I’ve devised you will notice the commented sections
– are functions/actions

– created the group & ending as you would

local guy = display.newRect(0, 0, 15,15)
guy.x, guy.y = display.contentWidth/2, display.contentHeight/2

group:insert(guy)

– I have a joystick moving the player
– as you have seen in my above mentioned people creater this is how I’m creating the people
– even attaching physics

– collision event creating other people at random points, spawning on screen would be fine
– I’m not going for complete realism.

– so now what you’re saying is I have to create this physics sensor?

local physicsSensor = display.newRect ( 0, 0, 1280, 720) – 1280 and 720 are screen bounds
– not insert it into the group?

– add physics to the physics sensor for a pivot point to be able to apply?

physics.newJoint (physicsSensor, guy, --etc --etc --etc)???

– and not insert physicsSensor to the group? even though by default if no display objects have been added they get added anyway?

[/lua] [import]uid: 87730 topic_id: 36384 reply_id: 145361[/import]

[bjsorrentino]

Hi @jazzarssoul,
You can definitely remove physics bodies when you need to, and you should, especially if your intention is to create 2000 physics objects as in your example. In fact, creating that many would probably crash and burn, or perform terribly slow at least.

Even better would be a method in which you “recycle” similar objects… but the player never sees it happening. Meaning, you find a way to use a very small set of physics objects and swap them in and out of a “repository” as they enter or exit the screen. I did this in a recent game and it gave me the best performance boost of any others I had attempted.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 144493[/import]

[jazzarssoul]

Hey Brent my situation may need to be described a little more clearly.

I have a certain amount of xp the character needs to work up to, to level up.
To make up for the fact that the higher the xp required the higher amount of people that get eaten needs to respawn.
So per eat of people spawn either 1/2 and to make up for said numbers I was wondering through the spawning method as mentioned is there a way to add and keep physics to the objects on screen + 1/2 the screen width and remove and keep physics away from the objects outside these bounds [import]uid: 87730 topic_id: 36384 reply_id: 144612[/import]

[bjsorrentino]

Hi @jazzarssoul,
Yes, this is basically what I considered, but you’ll have to test it out to see how well it works. Just remember:

1. yes, the sensor is a physics body (sensor). It can be a dynamic object attached to the character using a pivot joint. Its rotation should be fixed using .isFixedRotation = true so it doesn’t go swinging all over if the character rotates.

2. the sensor MUST be in the same group as the character and anything else it might need to collide with (so, all of your other game world characters). It’s the only way to maintain the system receives the proper collision handling.

Brent
[import]uid: 200026 topic_id: 36384 reply_id: 145805[/import]

[bjsorrentino]

Hi @jazzarssoul,
Certainly this should be possible. You might also consider a screen “region” which is an invisible sensor object. Objects that move outside that region are either made inactive or the physics body removed. Objects that move inside the bounds are reactivated. Ultimately, the implementation is up to you… but the scenario sounds feasible, absolutely.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 144766[/import]

[jazzarssoul]

I had imagined this particular scenario would be the case in which there is an object region that follows the movement of the player and triggering physics as it goes but I however have tried this strategy and failed miserably…

So I kinda ditched the effort and hoped there was an easier way. Is there a way you can provide me with an example or start me in the right direction Brent? [import]uid: 87730 topic_id: 36384 reply_id: 144775[/import]

[bjsorrentino]

Have you implemented some kind of “camera” movement? Meaning, the entire world is moving and all of the offscreen objects are entering/exiting the “viewport” at different times? If so this becomes a bit more complex, but should be solvable. If the “camera” is moving around a world, does the character stay centered in the screen or push the scrolling around as it reaches near the screen edges?

Or, do the offscreen objects move independently of each other, moving about at different speeds and velocities or something? And then the screen “sensor” I described could be locked in place?

Brent [import]uid: 200026 topic_id: 36384 reply_id: 144974[/import]

[jazzarssoul]

Hey Brent I do have a camera system where it’s just the group.x & y following player.x & y

very basic,

and literally everything on the playing field right now to a 10000 x 10000 sized app with about 200 people are all moving and all have physics.

The view in this scenario is limited to 1280 x 720 so max, I would dealing with about 5 - 10 people on the current screen and hope to not allow other objects to be requiring physics at this point as it really lags it down. Also as mentioned I need to incoroporate some form of one eat will spawns 2 more people off screen with hopefully no physics attached at this point until they become on screen items because it would truly lag it out exponentially

Thanks [import]uid: 87730 topic_id: 36384 reply_id: 145130[/import]

[bjsorrentino]

Hi @jazzarssoul,

I still think you can implement some kind of physics sensor solution, BUT you must remember that you can’t shift display groups around independently (in regards to your camera) without breaking the physics collision environment. In other words, you can’t just put a “screen size sensor” locked in place (in one display group) and then have the “camera” move the underlying world around. It will not detect the collisions properly.

You might try to attach the sensor to the player, so it follows it around, and gets the proper collisions when other peeps come into contact with it.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 145215[/import]

[jazzarssoul]

how do you mean can’t just put a “screen size sensor” locked in place?

do you mean if I was to place the physicsBox I’ve created and set that to a constant update to the player.x and y? and not place it in the display group [import]uid: 87730 topic_id: 36384 reply_id: 145265[/import]

[bjsorrentino]

Well basically, the physics engine requires potentially-colliding objects to be in the same “coordinate space”. This is not a new factor, but developers tend to stumble on it because they move an entire display group containing physics objects (to move them all at once), and then they are perplexed why those objects are not colliding with physics objects in other non-moved groups.

How this pertains to your project is that you’re likely moving the entire “world” to simulate the camera. So, if you imagine that you have a stationary “screen sensor” that is positioned in a different display group (not moving with the world), then you won’t get the proper collisions… thus rendering the approach pointless, since it’s that sensor which is supposed to collide with those off-screen objects and “activate” them as they come into range.

What you might be able to do is link this sensor to the PLAYER, either as a secondary body, or using a pivot joint. This way, the sensor would remain in the main group and it should receive the proper collisions. Does this make sense? It’s hard to describe what I’m talking about without actually showing it in action.

Brent [import]uid: 200026 topic_id: 36384 reply_id: 145312[/import]

[jazzarssoul]

Is this what you were getting at?

[lua]
– for the lack of throwing in all the code I’ve devised you will notice the commented sections
– are functions/actions

– created the group & ending as you would

local guy = display.newRect(0, 0, 15,15)
guy.x, guy.y = display.contentWidth/2, display.contentHeight/2

group:insert(guy)

– I have a joystick moving the player
– as you have seen in my above mentioned people creater this is how I’m creating the people
– even attaching physics

– collision event creating other people at random points, spawning on screen would be fine
– I’m not going for complete realism.

– so now what you’re saying is I have to create this physics sensor?

local physicsSensor = display.newRect ( 0, 0, 1280, 720) – 1280 and 720 are screen bounds
– not insert it into the group?

– add physics to the physics sensor for a pivot point to be able to apply?

physics.newJoint (physicsSensor, guy, --etc --etc --etc)???

– and not insert physicsSensor to the group? even though by default if no display objects have been added they get added anyway?

[/lua] [import]uid: 87730 topic_id: 36384 reply_id: 145361[/import]

[bjsorrentino]

Hi @jazzarssoul,
Yes, this is basically what I considered, but you’ll have to test it out to see how well it works. Just remember:

1. yes, the sensor is a physics body (sensor). It can be a dynamic object attached to the character using a pivot joint. Its rotation should be fixed using .isFixedRotation = true so it doesn’t go swinging all over if the character rotates.

2. the sensor MUST be in the same group as the character and anything else it might need to collide with (so, all of your other game world characters). It’s the only way to maintain the system receives the proper collision handling.

Brent
[import]uid: 200026 topic_id: 36384 reply_id: 145805[/import]