Hello,
I wanted to know if it is possible to move physical objects according to a chosen path.
To explain, I take as an example the color switch game where obstacles move in particular paths and at variable speeds.
Is there a way to rebuild something like with corona physical bodies?
I attached a photo and a video
https://www.youtube.com/watch?v=1C2trS1_n2I
Watch videos at about (0:32)
Yes, but do NOT try to move physics bodies by setting their .x and .y values - this will only end in pain.
When you want to change the position of physics bodies in Corona’s physics engine (Box2D) you should attach a Touch Joint to the body. This is a joint which, rather than connecting two bodies together, simply defines a point on your body which you can move - and the body will move with it.
The trick here is that creating the touch joint anywhere but the very centre of the object’s mass will cause it to rotate.
The other trick is that touch joints have (just as many joints do) a certain amount of elasticity, so you need to play around with the values.
Once you have touch joints sorted out, you can use them to trace a path around the screen and the attached body will follow that path - at the point it’s connected to the joint.
Thanks so much!
I had not thought about using the touch joints in this way.
So in theory can I use a transaction at a joint so that the body follows it?
This is right?
Hi @maximo97,
Touch joints aren’t really an “object” so you can’t transition them directly as normal objects. Instead, you need to set (or transition) the touch joint’s target , which essentially tells the body which it’s attached to “move to this point”. Is that what you’re seeking, or do I not fully understand the question?
Brent
Hi @Brent Sorrentino
That’s what I meant.
I did a simple test. The result is more or less what I want but I do not know if the code is optimized.
Could you give me an opinion?
local physics = require("physics") physics.start() physics.setDrawMode( "hybrid" ) --debug hybrid normal local bodiesGroup = display.newGroup() -- Create physical objects local shape = display.newRect( bodiesGroup, 0, 0, 60, 60 ) shape:setFillColor( 1, 0.2, 0.4 ) physics.addBody( shape, "dynamic", { bounce=0 } ) shape.x, shape.y = display.contentCenterX, 300 touchPoint = display.newCircle( bodiesGroup, 0, 0, 15 ) touchPoint:setFillColor( 1,0,0.2 ) touchPoint.alpha = 0 shape:toBack() touchPoint:toBack() -- Create joint joint = physics.newJoint( "touch", shape, shape.x, shape.y ) joint.maxForce = 1000 joint.frequency = 0.8 joint.dampingRatio = 1 --temp obj for joint local tmp = display.newCircle( bodiesGroup, shape.x, shape.y, 20 ) tmp.isVisible = false transition.to(tmp, {time = 2000, x = display.contentCenterX+100}) transition.to(tmp, {delay = 2000, time = 2000, y = 200}) transition.to(tmp, {delay = 4000, time = 2000, x = display.contentCenterX-100}) transition.to(tmp, {delay = 6000, time = 2000, y = 300}) --Function to follow the object from the joint function mima() joint:setTarget( tmp.x, tmp.y ) end Runtime:addEventListener( "enterFrame", mima )Hi @maximo97,
That basically looks fine, yes. If you have gravity on (meaning, not zero-gravity) you should probably make the body “kinematic” type so that it’s not subject to gravitational pull.
May I ask, will the objects you’re planning to move be involved in various physical collisions with other physical objects where physical force responses will occur? Meaning, like objects bouncing off others or bumping into things and transmitting forces around?
The reason I ask is, it’s actually legally possible to just move physical objects directly via transitions or x/y updates. It’s just not recommended unless you know what you’re doing to account for other aspects, which is why @horacebury wisely cautioned you against doing so (it often does end in pain, as the developer gets in over their head and doesn’t know why).
Typically, the best approach is to control physical objects by “physical means,” meaning the application of velocity, force, impulses, touch joints, etc. However in some cases… IF you know what you’re doing with physics… you can just move them around manually or with transitions.
Brent
Thank you @Brent Sorrentino.
As you said these moving objects come into contact with others.
The basic idea is that the main object should avoid touching the moving object because a bounce occurs in the contact. The fact is that I would like to apply particular movements to the moving object for that I spoke of swich color as an example.
I had also thought of moving static objects only with transition. Probably now that you know what I must do you can tell me which is the best way?
Some of what I’m referring to is described in the following guide, so please read that first and tell me if it applies to your intended situation:
https://docs.coronalabs.com/guide/physics/limitations/index.html#movement
The basic concept is, you shouldn’t have both “transition/x/y movement” competing with “physical movement” since they are unrelated forces which will fight for control of the object. You can combine both, but you need to take very careful steps to avoid problems, which is why it’s generally not recommended.
Brent
I read the guide is made of evidence.
The best way seems the code I posted…
Moving static objects directly creates problems in some cases
the source of trouble with moving dynamic objects directly, is that it is like “teleporting” them instantaneously, so the physics engine doesn’t get a chance to evaluate that movement and intermediate positions for collision detection and response. if the delta movement is small enough you can sometimes get away with it, but that’s typically the exception rather than the rule.
touch joints are like a zero-length rubber-band attached between the body and the specified location. they work “best” when the location doesn’t change super-often (like every frame) so that physics has a chance to integrate the “elastic” over a couple frames at least. they WILL work with an ever-changing location, they just won’t be as “stable” as if they had more time to operate. only testing and tweaking will determine if they’ll work as desired in a given circumstance.
a weld joint can also be used. weld joints are “in theory” rigid joints that “lock” one body’s position relative to another. in practice, weld joints are a bit flexible, because other constraints like collision response may out-prioritize them. so, in practice, they can be used a bit like a rubber-band joint too, sort of like a stronger touch joint. the setup is to create an invisible kinematic sensor body (let’s call it the “carriage”) to which your real body is attached via a weld joint. you may now directly move the carriage, which will attempt to “drag” the body along via its weld joint. unlike directly moving (aka teleporting) the primary body, physics DOES get to see this motion (in fact, physics causes the motion, via the weld joint), so it can do all the proper things like collision detection/response. but,… a weld joint might be too rigid in some circumstances, where the touch joint would be preferred.
Thanks a lot very useful. @davebollinger
I will make good use of your counsels.
I did the tests and actually the weld joint works well in some circumstances
Yes, but do NOT try to move physics bodies by setting their .x and .y values - this will only end in pain.
When you want to change the position of physics bodies in Corona’s physics engine (Box2D) you should attach a Touch Joint to the body. This is a joint which, rather than connecting two bodies together, simply defines a point on your body which you can move - and the body will move with it.
The trick here is that creating the touch joint anywhere but the very centre of the object’s mass will cause it to rotate.
The other trick is that touch joints have (just as many joints do) a certain amount of elasticity, so you need to play around with the values.
Once you have touch joints sorted out, you can use them to trace a path around the screen and the attached body will follow that path - at the point it’s connected to the joint.
Thanks so much!
I had not thought about using the touch joints in this way.
So in theory can I use a transaction at a joint so that the body follows it?
This is right?
Hi @maximo97,
Touch joints aren’t really an “object” so you can’t transition them directly as normal objects. Instead, you need to set (or transition) the touch joint’s target , which essentially tells the body which it’s attached to “move to this point”. Is that what you’re seeking, or do I not fully understand the question?
Brent
Hi @Brent Sorrentino
That’s what I meant.
I did a simple test. The result is more or less what I want but I do not know if the code is optimized.
Could you give me an opinion?
local physics = require("physics") physics.start() physics.setDrawMode( "hybrid" ) --debug hybrid normal local bodiesGroup = display.newGroup() -- Create physical objects local shape = display.newRect( bodiesGroup, 0, 0, 60, 60 ) shape:setFillColor( 1, 0.2, 0.4 ) physics.addBody( shape, "dynamic", { bounce=0 } ) shape.x, shape.y = display.contentCenterX, 300 touchPoint = display.newCircle( bodiesGroup, 0, 0, 15 ) touchPoint:setFillColor( 1,0,0.2 ) touchPoint.alpha = 0 shape:toBack() touchPoint:toBack() -- Create joint joint = physics.newJoint( "touch", shape, shape.x, shape.y ) joint.maxForce = 1000 joint.frequency = 0.8 joint.dampingRatio = 1 --temp obj for joint local tmp = display.newCircle( bodiesGroup, shape.x, shape.y, 20 ) tmp.isVisible = false transition.to(tmp, {time = 2000, x = display.contentCenterX+100}) transition.to(tmp, {delay = 2000, time = 2000, y = 200}) transition.to(tmp, {delay = 4000, time = 2000, x = display.contentCenterX-100}) transition.to(tmp, {delay = 6000, time = 2000, y = 300}) --Function to follow the object from the joint function mima() joint:setTarget( tmp.x, tmp.y ) end Runtime:addEventListener( "enterFrame", mima )Hi @maximo97,
That basically looks fine, yes. If you have gravity on (meaning, not zero-gravity) you should probably make the body “kinematic” type so that it’s not subject to gravitational pull.
May I ask, will the objects you’re planning to move be involved in various physical collisions with other physical objects where physical force responses will occur? Meaning, like objects bouncing off others or bumping into things and transmitting forces around?
The reason I ask is, it’s actually legally possible to just move physical objects directly via transitions or x/y updates. It’s just not recommended unless you know what you’re doing to account for other aspects, which is why @horacebury wisely cautioned you against doing so (it often does end in pain, as the developer gets in over their head and doesn’t know why).
Typically, the best approach is to control physical objects by “physical means,” meaning the application of velocity, force, impulses, touch joints, etc. However in some cases… IF you know what you’re doing with physics… you can just move them around manually or with transitions.
Brent
Thank you @Brent Sorrentino.
As you said these moving objects come into contact with others.
The basic idea is that the main object should avoid touching the moving object because a bounce occurs in the contact. The fact is that I would like to apply particular movements to the moving object for that I spoke of swich color as an example.
I had also thought of moving static objects only with transition. Probably now that you know what I must do you can tell me which is the best way?
Some of what I’m referring to is described in the following guide, so please read that first and tell me if it applies to your intended situation:
https://docs.coronalabs.com/guide/physics/limitations/index.html#movement
The basic concept is, you shouldn’t have both “transition/x/y movement” competing with “physical movement” since they are unrelated forces which will fight for control of the object. You can combine both, but you need to take very careful steps to avoid problems, which is why it’s generally not recommended.
Brent
I read the guide is made of evidence.
The best way seems the code I posted…
Moving static objects directly creates problems in some cases
the source of trouble with moving dynamic objects directly, is that it is like “teleporting” them instantaneously, so the physics engine doesn’t get a chance to evaluate that movement and intermediate positions for collision detection and response. if the delta movement is small enough you can sometimes get away with it, but that’s typically the exception rather than the rule.
touch joints are like a zero-length rubber-band attached between the body and the specified location. they work “best” when the location doesn’t change super-often (like every frame) so that physics has a chance to integrate the “elastic” over a couple frames at least. they WILL work with an ever-changing location, they just won’t be as “stable” as if they had more time to operate. only testing and tweaking will determine if they’ll work as desired in a given circumstance.
a weld joint can also be used. weld joints are “in theory” rigid joints that “lock” one body’s position relative to another. in practice, weld joints are a bit flexible, because other constraints like collision response may out-prioritize them. so, in practice, they can be used a bit like a rubber-band joint too, sort of like a stronger touch joint. the setup is to create an invisible kinematic sensor body (let’s call it the “carriage”) to which your real body is attached via a weld joint. you may now directly move the carriage, which will attempt to “drag” the body along via its weld joint. unlike directly moving (aka teleporting) the primary body, physics DOES get to see this motion (in fact, physics causes the motion, via the weld joint), so it can do all the proper things like collision detection/response. but,… a weld joint might be too rigid in some circumstances, where the touch joint would be preferred.