Scaling Collision Object when Game Object is scaled (DEF-521)


Sadly, no. Those other (required) tasks haven’t been prioritized during the year.
But I feel hopeful we’ll pick those up at the beginning of next year. (But again, cannot promise an ETA yet)



Having used Box2D a bit more directly through Löve2D, I have a better appreciation for why this “issue” exists — It’s simply the way Box2D works. It is not a bug, in Defold or anything else. Box2D does not allow you to change existing shapes, only to create and destroy them. I assume this is a performance optimization, so any “fix” will cause at least some performance hit.

The real bug I see is that the editor does not respect this. So your game objects can look one way in the editor but completely different in the actual, running game. There have been a few reports for this: here, here, and here.



Just started playing around with Defold and faced this issue, when I scale a GameObject with attached CollisionObject, in the Editor both sprite and CO look scaled correctly, but when I run the game then CO appears scaled incorrectly. I can rescale collision object manually so it will fit GO size, but again, now in the Editor CO looks messed, but at least it’s ok in the game.

Please, make it at least consistent, broken in both places, or fixed in both. Thanks!



The original ticket (DEF-521) is about scaling the game object at runtime.

Your issue seems different. Afaik, the scaling of game objects at edit time will be represented ok in the engine.

Can you give us a repro case to test with? E.g. zip up a small test project and share it here. (Exclude the build folder and any hidden folders)

1 Like


I had this same problem last week. Here’s a short video and test project to demonstrate the issue (the checkerboard pattern is scaled x 4): (3.3 KB)



I’m sure box2d doesn’t allow any shape scaling on runtime.But you or the game engine could have some workaround here.



We’re bumping this into our next sprint (in one week). We’ve worked on this on and off in the past and have code that is working, but it’s not a perfect solution that we want to release yet, and as you say box2d doesn’t allow this but we can solve it in the engine. We now feel that we need to deal with this old feature request once and for all. We’ll keep you posted.



Is this closeley related enough to be included in the next sprint also? (Hoping)!



Any updates on this?

I have an object which is non-uniformly scaled at run-time, so I can’t use the scaling at factory creation workaround.



It’s a task that we wish to pick up soon.
It’s been in our sprint a couple of times, but it has been out-prioritized by other more pressing things.



I also look forward to finding a solution to this problem :hugs:

1 Like


+1 for this


Defold 1.2.152 has been released

A little bit of a status update:

We’re wrapping up the 1.2.150 release now (for Monday). It will contain the synchronous raycast btw!

For 1.2.151 we plan to finish the Facebook upgrade and a bunch of other things (flipbook animation cursors!).

Aaaaaand then for 1.2.152 we plan to do a physics focused sprint where we’ll expose more physics settings and work on things such as physics shape scaling and running the physics simulation in a separate thread.



Woooow! :smiley: All those features seems to be kind of a small revolution :smiley: Waiting for cursors, ofc! :smiley: So with physics in other thread we would be possible to create even more collisionobjects without carrying too much about performance, yep? :smiley: If it comes to exposing physics setting, actually there is only damping of a collision object actually changeable, so I think exposing more of the settings to change could allow us to perform a lot of dynamic things. Or do you mean adding even more settings??

1 Like


You should always care about performance :slight_smile: The main idea with this is to get a much more consistent physics simulation where each physics step is of equal size. The problem right now is that if the game lags for one reason or another the physics will suffer since the dt varies so much.

Well for starters it’s really weird that Gravity is hardcoded into game.project from start. It should be possible to change at run-time. There are probably a lot of other properties that can be read and maybe in some cases also manipulated at run-time.

Oh, and we’d like to release the first version of the physics joints system!



Why didn’t you manage to solve the problem in the new version? :persevere: Defold 1.2.156 has been released

1 Like


Because we finished the work on joints instead. And we added support for programmatically changing the gravity.

Solving physics scaling is next on our list though. But it is dependent on another engine change where we need to make it cheaper to know when a transform hierarchy has changed. We really don’t want to poll for scale changes every frame but rather have a system where we have some kind of dirty flag or similar.



I guess recreating physics bodies each frame is not the best route. Maybe add a message or a call to reapply scaling? So the developer chooses when to update.



I am really looking forward to this fix! It has been a pain for a really long time.

1 Like


Any updates on this? This is very useful feature

1 Like