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
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.
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
>> 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?
davebollinger, thank you!
I’m an idiot. Should have seen that.
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.
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
>> 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?
davebollinger, thank you!
I’m an idiot. Should have seen that.