physics object does not match pre-scaled display object (ZoomIn/ZoomOut for a physics game not possible)

Physics
#1

created a bug for this one

Documentation states " You can scale the object up or down and rotate it but the Physics engine still sees the object as it was before the changes.".  However this example code demonstrates that the physics boundary is not matching the pre-scaled object

-- Version 2013.1178 (2013.8.2) local physics = require( "physics" ) physics.start() physics.setGravity(0, 1) physics.setDrawMode( "hybrid" ) -- SETUP OBJECTS local crate1 = display.newImage( "crate.png" ) crate1.x = 220; crate1.y = 100 crate1.myName = "first crate" local crate2 = display.newImage( "crate.png" ) crate2.x = 180; crate2.y = 300 crate2.myName = "second crate" crate2.rotation = 45 crate2:scale(2,2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- \<\<==== SCALING BEFORE PHYSIC OBJECT CREATED -- ENABLE PHYSICS timer.performWithDelay(500,&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;function(event) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;physics.addBody( crate1, { density=3.0, friction=0.5, bounce=0.3 } ) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;physics.addBody( crate2, "static", { density=3.0, friction=0.5, bounce=0.3 } )&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;end ) &nbsp;
#2

@Corona - Help. Noting the below from the old guide doco it indicates we can not ROTATE physics objects. Is this true?

Question: How can I build a game that requires the player object to be rotated as it moves? Do I have to forego using physics on the player object then as a means to detect collisions with it?

When you turn a display object into a physics object, the Physics engine owns the object and has its own rules about the object. Physics assumes the reference point of the object is the center of the object so object:setReferencePoint() may change the reference point from Corona’s Display Object point of view but not for the Physics engine. This affects collisions and how other physics bodies interact.

The same applies for scaling and rotating the object. You can scale the object up or down and rotate it but the Physics engine still sees the object as it was before the changes.

You can see how the Physics engine view the object with physics.setDrawMode(“debug”).

#3

@Corona - Help. Noting the below from the old guide doco it indicates we can not ROTATE physics objects. Is this true?

Question: How can I build a game that requires the player object to be rotated as it moves? Do I have to forego using physics on the player object then as a means to detect collisions with it?

When you turn a display object into a physics object, the Physics engine owns the object and has its own rules about the object. Physics assumes the reference point of the object is the center of the object so object:setReferencePoint() may change the reference point from Corona’s Display Object point of view but not for the Physics engine. This affects collisions and how other physics bodies interact.

The same applies for scaling and rotating the object. You can scale the object up or down and rotate it but the Physics engine still sees the object as it was before the changes.

You can see how the Physics engine view the object with physics.setDrawMode(“debug”).

#4

lodged as Case 25345

#5

Any work-arounds in the meantime to allow use of one image (a sprite) that I want to make into a physics object, but it needs to be various scaled sizes?   I don’t want to have to develop multiple different sizes of the same image in Photoshop, upload to Spritehelpers etc etc if possible…

#6

PS.  Another use case this impacts is the ability to have a game level itself (consisting of hierarchy of groups effectively) that you want to be able to give the user an ability to determine how “zoomed in” to the level they want to be when they play it.  

If I understand things correctly the ability to Zoom In / Zoom Out on a game (with Physics) is prevented due to this.

#7

There is a long standing Corona bug, going back years, where if you zoom in or out in hybrid or debug mode the visual representation of the physics objects shapes don’t scale correctly.  But the underlying physics simulation is actually working correctly.  So you can have a game that zooms in and out on the simulation, but if you are trying to view the collision objects while testing/developing you will have a very difficult time seeing what is actually colliding or not.  

#8

thanks HardBoiledIndustries - confusing stuff :slight_smile:  

You haven’t come across a work around for visualizing the physics areas I don’t suppose?  Can you retrieve the actual physics body true co-ordinates from a physics display object and then have your own routine to draw a non-physics display object to show it?  

#9

You could have a test mode disable the zoom camera while enabling hybrid mode so you see all the physics shapes in their “normal”, un-zoomed state.  They will be true visual representations at that point.  If the zoomed camera is vital to your testing then you might have to do what you suggest and create your own display objects to stand in for the physics shapes.

#10

ok thanks - it seems you’re confident that zooming still works properly then - I guess you can display your own objects then on the assumption things scale correctly, as you’d be calculating what you thought the scaled physics area would be (assuming here there’s no way to ask corona for this)…ummm so doesn’t that mean Corona labs could do the same then and fix the visualization display?  

#11

Hi Greg,

I think your main questions were:

  1. Can you rotate a physics object? Absolutely yes… the older docs were vague/misleading on that specific point. I have fixed that, and I plan to update the collision guide considerably as soon as I get past some pressing tasks.

  2. You can scale up (or down) the entire physics world, and it will work. You just can’t scale individual bodies independently of the world and expect the collision bounds to work. That being said, it would probably be fairly easy to write a little scaling algorithm that would work on any given shape, and output the new coordinates. I did something like that just this past weekend for flipping physics shapes (and flipping is, in effect, scaling negatively across an axis). This took me about 30 minutes and it works nicely on all physics shapes… so, it could likely be enhanced to scale bodies up and down and dynamically apply a body based on the “scaled coordinate points”.

Take care,

Brent

#12

ok thanks Brent - and whilst you’re there can you confirm the Corona visualization debug aspect for physics - is what we were saying true in terms of this no currently working for scaled physics?   (i.e. physics.setDrawMode( “hybrid” ))  

Any work arounds you could suggest beyond HardBoiledIndustries re debugging physics in a scaled game?

#13

Hi Greg,

When scaling the game, you will need to contend with debug tracings that don’t quite match. I believe the engineers investigated fixing this, but it was placed at lower priority than several other things. So, for now, you’ll need to debug the best you can.

Take care,

Brent

#14

lodged as Case 25345

#15

Any work-arounds in the meantime to allow use of one image (a sprite) that I want to make into a physics object, but it needs to be various scaled sizes?   I don’t want to have to develop multiple different sizes of the same image in Photoshop, upload to Spritehelpers etc etc if possible…

#16

PS.  Another use case this impacts is the ability to have a game level itself (consisting of hierarchy of groups effectively) that you want to be able to give the user an ability to determine how “zoomed in” to the level they want to be when they play it.  

If I understand things correctly the ability to Zoom In / Zoom Out on a game (with Physics) is prevented due to this.

#17

There is a long standing Corona bug, going back years, where if you zoom in or out in hybrid or debug mode the visual representation of the physics objects shapes don’t scale correctly.  But the underlying physics simulation is actually working correctly.  So you can have a game that zooms in and out on the simulation, but if you are trying to view the collision objects while testing/developing you will have a very difficult time seeing what is actually colliding or not.  

#18

thanks HardBoiledIndustries - confusing stuff :slight_smile:  

You haven’t come across a work around for visualizing the physics areas I don’t suppose?  Can you retrieve the actual physics body true co-ordinates from a physics display object and then have your own routine to draw a non-physics display object to show it?  

#19

You could have a test mode disable the zoom camera while enabling hybrid mode so you see all the physics shapes in their “normal”, un-zoomed state.  They will be true visual representations at that point.  If the zoomed camera is vital to your testing then you might have to do what you suggest and create your own display objects to stand in for the physics shapes.

#20

ok thanks - it seems you’re confident that zooming still works properly then - I guess you can display your own objects then on the assumption things scale correctly, as you’d be calculating what you thought the scaled physics area would be (assuming here there’s no way to ask corona for this)…ummm so doesn’t that mean Corona labs could do the same then and fix the visualization display?