Scaling Group Does Not Scale Physics

Games
#1

In this topic

http://developer.anscamobile.com/forum/2010/08/02/scaling-physics-bodies-attached-sprites#comment-7344

Evan says “On the other hand, you CAN put all the bodies into a big group and scale the entire world at once. The classic iPhone game “Rolando”, also based on Box2D, is a nice example of this.”

Im finding that this doesnt happen, if I scale a group the collision boundaries stay the same

[code]
local physics = require (“physics”)
physics.start()
physics.setGravity (0,0)
physics.setDrawMode( “hybrid” )

local worldGroup = display.newGroup()
local trackGroup = display.newGroup()
worldGroup:insert( trackGroup )

local track = display.newImage( “trackStraight.png” )
physics.addBody( track, “dynamic”, { density=3.0, friction=0.5, bounce=0.2 } )
trackGroup:insert( track )

worldGroup.x = 10
worldGroup.y = 10
worldGroup.xScale = 0.1
worldGroup.yScale = 0.1
[/code] [import]uid: 5354 topic_id: 2561 reply_id: 302561[/import]

#2

Looking at the Egg Breaker example. Ive set the debug mode to hybrid and scaled the world to 0.5 , 0.5.

It looks like the collisions scale as the game still works but the hybrid vector representations of the collision boundaries do not scale to match. [import]uid: 5354 topic_id: 2561 reply_id: 7345[/import]

#3

Also if you define a shape= as a collision boundary it doesnt rotate the debug drawing with the group.

That is to say if you create an object, define a shape = as its collision boundary, insert that object into a group and then rotate the group. The actual collision boundary rotates but the debug line object doesnt rotate with it.

I think your ‘debug’ and ‘hybrid’ modes need work, they easily stop representing the actual collisions that are happening. [import]uid: 5354 topic_id: 2561 reply_id: 7348[/import]

#4

It also seems when using :applyTorque that the actual rotation and the rotation of the display image its effecting are out of sync by 1/2 when in a group [import]uid: 5354 topic_id: 2561 reply_id: 7351[/import]

#5

Sample of bugs send to Eric and Evan. Hopefully they have enough to debug and correct the issues.

To confirm though the physics all works wonderfully, its just the debug overlay that a little wonky. [import]uid: 5354 topic_id: 2561 reply_id: 7572[/import]

#6

@Matthew Pringle - just adding for the public record what I’ve told several people in email since this came up: this is a known rendering issue in the vector debug mode. We used to have a note in the release notes explaining the limitation, but evidently it did not migrate to our main docs:

NOTE: While the physics debug draw renderer should correctly account for physics objects in nested display groups, it will display misleading results if display groups are rotated or scaled. This will be addressed in a future release.

I’ve now added this note to the bottom of the relevant section: http://developer.anscamobile.com/content/game-edition-box2d-physics-engine#physics.setDrawMode . You are correct that it is display-related: the vectors do not match what the engine is actually doing, in cases where display groups are either rotated or scaled, so the output is visually misleading.

Regarding a fix for the issue, it may sound straightforward, but it’s actually kind of deep. What’s going on is that there are certain graphical transforms happening only in OpenGL itself, with no data representation, so the appropriate transform series to feed back into the vector preview doesn’t actually exist. In other cases (such as position transforms) there is data in the existing display tree that we can read, so that’s why the vectors are reliable in those cases. The solution is to build a new datastructure that records the full tree of display object transforms (without “cheating” and just looking at the actual objects onscreen, since that would defeat the entire purpose of having an independent check).

[import]uid: 3007 topic_id: 2561 reply_id: 11827[/import]