physics scaling one more time...

Physics
#1

Hi All,

As usual, I’m experiencing extremely weird behaviour in my app:)

It looks like setLinearVelocity interferes with an objects contentWidth while scaling of the object IS NOT altered.

The same goes for applyImpulse. It even seems like the physics engine itself fcks with my objects contentSize, even without doing anything physically. The impact seems to be bigger the more ‘dynamics’ there are.

I am aware that rescaling an object without removing it from the physics context won’t work and I don’t do it.

What I do is scale the objects in advance, calculate the physics shape according to the desired scale and then add the stuff to the physics engine and then join it.

I am sorry for not having the time isolating the problem. I couldn’t reproduce it with a single object.

Is there a known problem regarding this regarding contentSize and physics?

kind regard, Johannes

#2

I know this looks like my own fault, but this enterframe listener:

    local function report()
        print(time(), car.wheel[1].xScale, car.wheel[2].xScale, car.wheel[1].contentWidth, car.wheel[2].contentWidth )
    end

reports:

1241412 ms    0.80000001192093    0.80000001192093    128    128
1241421 ms    0.80000001192093    0.80000001192093    129    128
1241436 ms    0.80000001192093    0.80000001192093    130    129
1241452 ms    0.80000001192093    0.80000001192093    131    129
1241468 ms    0.80000001192093    0.80000001192093    131    130
1241484 ms    0.80000001192093    0.80000001192093    132    130
1241500 ms    0.80000001192093    0.80000001192093    132    131
1241516 ms    0.80000001192093    0.80000001192093    133    131
1241532 ms    0.80000001192093    0.80000001192093    134    132
1241548 ms    0.80000001192093    0.80000001192093    134    132
1241564 ms    0.80000001192093    0.80000001192093    135    133
1241581 ms    0.80000001192093    0.80000001192093    135    133
1241596 ms    0.80000001192093    0.80000001192093    136    134
1241613 ms    0.80000001192093    0.80000001192093    137    134
1241628 ms    0.80000001192093    0.80000001192093    137    135
1241645 ms    0.80000001192093    0.80000001192093    138    135
1241660 ms    0.80000001192093    0.80000001192093    138    136
1241676 ms    0.80000001192093    0.80000001192093    139    136
1241692 ms    0.80000001192093    0.80000001192093    139    137
1241708 ms    0.80000001192093    0.80000001192093    140    137
1241724 ms    0.80000001192093    0.80000001192093    140    138

As you see, contentWidth changes over time while the scaling factor doesn’t.

Shouldn’t  contentWidth == width* xScale always be true?

This happens even if the above listener is the only thing happening after physics init. As mentioned the impact on the difference is even greater if I actually add more dynamics by setting a velocity or applying an impulse.

#3

Hi @Johannes,

How are you manipulating (scaling/resizing) this object? In a transition? In a repeating timer? In another Runtime listener? In a touch-drag listener?

Brent

#4

>> Shouldn’t  contentWidth == width* xScale always be true?

Not if the object is rotated (and it seems likely a “wheel” might be)

Your wheels would seem to be sprite-based (128x128), and printout dimensions would seem about right for ~5° rotation .  Your application of forces is probably just rotating the object, not scaling it, so your just seeing the size of the rotated bounding box.  (and the apparent non-linear “jiggle” is likely from a variety of other forces/joints also acting upon it)  Might help if you also printed out .rotation?

#5

davebollinger, thank you!

I’m an idiot. Should have seen that.

#6

I know this looks like my own fault, but this enterframe listener:

    local function report()
        print(time(), car.wheel[1].xScale, car.wheel[2].xScale, car.wheel[1].contentWidth, car.wheel[2].contentWidth )
    end

reports:

1241412 ms    0.80000001192093    0.80000001192093    128    128
1241421 ms    0.80000001192093    0.80000001192093    129    128
1241436 ms    0.80000001192093    0.80000001192093    130    129
1241452 ms    0.80000001192093    0.80000001192093    131    129
1241468 ms    0.80000001192093    0.80000001192093    131    130
1241484 ms    0.80000001192093    0.80000001192093    132    130
1241500 ms    0.80000001192093    0.80000001192093    132    131
1241516 ms    0.80000001192093    0.80000001192093    133    131
1241532 ms    0.80000001192093    0.80000001192093    134    132
1241548 ms    0.80000001192093    0.80000001192093    134    132
1241564 ms    0.80000001192093    0.80000001192093    135    133
1241581 ms    0.80000001192093    0.80000001192093    135    133
1241596 ms    0.80000001192093    0.80000001192093    136    134
1241613 ms    0.80000001192093    0.80000001192093    137    134
1241628 ms    0.80000001192093    0.80000001192093    137    135
1241645 ms    0.80000001192093    0.80000001192093    138    135
1241660 ms    0.80000001192093    0.80000001192093    138    136
1241676 ms    0.80000001192093    0.80000001192093    139    136
1241692 ms    0.80000001192093    0.80000001192093    139    137
1241708 ms    0.80000001192093    0.80000001192093    140    137
1241724 ms    0.80000001192093    0.80000001192093    140    138

As you see, contentWidth changes over time while the scaling factor doesn’t.

Shouldn’t  contentWidth == width* xScale always be true?

This happens even if the above listener is the only thing happening after physics init. As mentioned the impact on the difference is even greater if I actually add more dynamics by setting a velocity or applying an impulse.

#7

Hi @Johannes,

How are you manipulating (scaling/resizing) this object? In a transition? In a repeating timer? In another Runtime listener? In a touch-drag listener?

Brent

#8

>> Shouldn’t  contentWidth == width* xScale always be true?

Not if the object is rotated (and it seems likely a “wheel” might be)

Your wheels would seem to be sprite-based (128x128), and printout dimensions would seem about right for ~5° rotation .  Your application of forces is probably just rotating the object, not scaling it, so your just seeing the size of the rotated bounding box.  (and the apparent non-linear “jiggle” is likely from a variety of other forces/joints also acting upon it)  Might help if you also printed out .rotation?

#9

davebollinger, thank you!

I’m an idiot. Should have seen that.