favreau / bullet

Automatically exported from code.google.com/p/bullet
0 stars 0 forks source link

Scaling compound objects can lead to scene decomposition #444

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create an compound object
2. Scale compund object while simulation runs
3. Objects fall through the floor.

What is the expected output? What do you see instead?

Scaled object should change it's size, but preserve velocity. All compound 
object's parts should remain in their places. Instead they fly away.

What version of the product are you using?

Bullet 2.77, WinXP

Additional information:

In the application I work on the user can use multi touch to scale objects.  
Their physical interactions are simulated by bullet. When user scales the 
compound object it often stops responding and other objects fall through the 
floor. I found that it happens becouse the compound object explodes when 
resized. It's parts fly far away - far enough to lower scene simulation. That's 
why other objects fall. If they are inactive, they fall when touched.

Well, I attach two files. First one contains simple scene before scaling while 
the second one is the dump taken soon after resizing the table. In the wire 
view table's legs can be found far away. These files can easily be viewed with 
AppSerializeDemo demo application available with bullet.

When bullet scales the compound object it has to update group's parts 
transformations. I think that this update leads to applying high velocity 
values to the parts.

Original issue reported on code.google.com by promyc...@gmail.com on 27 Oct 2010 at 2:04

Attachments:

GoogleCodeExporter commented 9 years ago
Well, I see that my diagnosis wasn't absolutely accurate, but that's good. The 
solution was really close and I think I have just found it. There is a method, 
btCompoundShape::setLocalScaling(const btVector3& scaling), in which I changed 
the line

childTrans.setOrigin((childTrans.getOrigin()) * scaling);

to

childTrans.setOrigin((childTrans.getOrigin()) * scaling / m_localScaling);

Without dividing by actual scale each consecutive scaling was cumulative, and 
change from scale 1.5 to 2.0 meant that object's parts were shifted out by 
factor 3.0 instead of 1.(3).

I attach the file to patch the bullet, it passed my tests.

Original comment by promyc...@gmail.com on 28 Oct 2010 at 9:43

Attachments:

GoogleCodeExporter commented 9 years ago
Isn't this the same as issue #374?

Original comment by wombat...@gmail.com on 3 Nov 2010 at 2:37

GoogleCodeExporter commented 9 years ago
Yes, I was looking for but didn't see it before. 

Original comment by promyc...@gmail.com on 3 Nov 2010 at 8:09

GoogleCodeExporter commented 9 years ago
Fixed in latest trunk. The fix breaks the API so we'll add some warning to the 
release notes.

See https://code.google.com/p/bullet/source/detail?r=2658

Thanks for the (old) contribution.

Original comment by erwin.coumans on 10 Sep 2013 at 11:36