Overflow in AABB - Debug vs Release builds

filmdude
Posts: 5
Joined: Wed Apr 28, 2010 5:41 pm

Overflow in AABB - Debug vs Release builds

Post by filmdude »

Hello,

I have been working with compound objects built using convex hulls generated from point clouds. The method Im using appears to work great. Bullet eats up what ever I through at it without issue. However, it only works well with the Bullet Debug libraries. As soon as I switch to the Release libraries, I get the following:

Overflow in AABB, object removed from simulation
If you can reproduce this, please email bugs@continuousphysics.com
Please include above information, your Platform, version of OS.
Thanks.


Failure is completely random. I ran my sim multiple times and sometimes it works, while other times it does not. No changes between runs.

I checked the AABB bounding box and sure enough its infinity. I doubled checked all my data being passed in and all seems well. I assume I must be doing everything right as it works so well using the debug libs.

Ive been messing with the release build settings and haven't really gotten anywhere. Any ideas on what compile flags to turn on or off? Or perhaps there's something else to check?

Tested on Vista64 and XP32.

Thanks for your help.
filmdude
Posts: 5
Joined: Wed Apr 28, 2010 5:41 pm

Re: Overflow in AABB - Debug vs Release builds

Post by filmdude »

Ive been able to isolate the issue a bit more.

If I create a single object compound shape, the issue disappears and all works well. The problem occurs only when more than one of my point cloud hull objects is used in a compound shape. Interestingly, the single object compound shapes begin to fail if there is a multi object compound shape in the same sim. Now what kind of weirdness is that?

Thinking that perhaps this is a memory alignment issue, Ive used btAlignedObjectArray on just about everything now. Failure remains completely random, but seems to have improved to about a 50% success rate.

Debug builds continue to have a 100% success rate and run perfectly.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Overflow in AABB - Debug vs Release builds

Post by Erwin Coumans »

Most likely there is some un-initialized value that you pass to Bullet, that happens to get values that don't cause issues in debug mode (0xcdcdcdcd instead of 0 etc)

Can you try to create a .bullet file in release mode just before running the stepSimulation (that makes things fail), and attach it to this forum topic so we can look at it?
See here for instructions: http://bulletphysics.org/mediawiki-1.5. ... ialization
Thanks,
Erwin
filmdude
Posts: 5
Joined: Wed Apr 28, 2010 5:41 pm

Re: Overflow in AABB - Debug vs Release builds

Post by filmdude »

It wouldnt suprise me if I left something unitialized. Ill double check everything I pass in to bullet now.

Please find the bullet file attached. Thanks for your help.
You do not have the required permissions to view the files attached to this post.
filmdude
Posts: 5
Joined: Wed Apr 28, 2010 5:41 pm

Re: Overflow in AABB - Debug vs Release builds

Post by filmdude »

More information on overflow problem.

After rechecking all input values, I switched back to Vista64 to test further. On this platform success for compound objects in release is 0% with no issues in debug mode.

I believe I've been able to rule out that this issue is caused by using point clouds for hull creation. I can create 100s of them on the fly with out issue in either release or debug.
filmdude
Posts: 5
Joined: Wed Apr 28, 2010 5:41 pm

Re: Overflow in AABB - Debug vs Release builds

Post by filmdude »

ISSUE RESOLVED

Checked out a fresh copy of bullet from the repos, recompiled everything, and now it works. I guess something got corrupted on my end. With an error like this, I should have tried this first. What a dope.
mrice
Posts: 1
Joined: Thu Oct 07, 2010 3:06 am

Re: Overflow in AABB - Debug vs Release builds

Post by mrice »

I see the same issue, using 2.77 on linux.
The problem comes from using a btTransform after it has been given to btCompoundShape::calculatePrincipalAxisTransform()
It looks like the matrix is incrementally scaled for each child shape.