You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Minor feature request: the constructors for btCapsuleShape, btCapsuleShapeX and btCapsuleShapeZ should assert when negative values are passed in for radius and/or height.
Background: we're currently in the process of porting a last-gen video game to current-gen platforms. The game originally ran via Havok physics, but we've made the decision to switch to Bullet physics for a number of reasons. Recently, we noticed that the collisions between the player and some random enemies in the game didn't work, and there seemed to be very little consistency to this (some kinds of enemies would never work, whereas others would work sometimes and not other times). After some experimentation, I also noticed that this bug occured when using a btAxisSweep3 broadphase, but not when using a btDbvtBroadphase.
It took me around two days to find the root cause of the issue, but it turned out that we accidentally instantiated some of the capsules for our characters with negative heights, which messed up the broadphase due to unexpected AABBs. This happened because the game's assets provide their capsule properties as radius and end points (since that's what Havok used) rather than radius and height. We just used a simple subtraction to calculate the height needed for Bullet, which turned out to be erroneous because the layout of these end points is not always consistent, therefore leading to negative values sometimes with our old method.
Of course once we found the error in our code, it was reasonably simple to fix, but adding some asserts on negative radius/height arguements to the capsule shape constructors would probably be a good idea and could help future users not falling into the same trap. Alternatively (or addtionally), some asserts could probably be added to the btAxisSweep3 implementation whereever the AABBs are used (since this could catch even more incorrectly initialized shapes).
(I would make a pull request for this myself, but I'm currently not at home, so I at least wanted to create an issue for it)
This discussion was converted from issue #2599 on April 26, 2021 03:55.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Minor feature request: the constructors for btCapsuleShape, btCapsuleShapeX and btCapsuleShapeZ should assert when negative values are passed in for radius and/or height.
Background: we're currently in the process of porting a last-gen video game to current-gen platforms. The game originally ran via Havok physics, but we've made the decision to switch to Bullet physics for a number of reasons. Recently, we noticed that the collisions between the player and some random enemies in the game didn't work, and there seemed to be very little consistency to this (some kinds of enemies would never work, whereas others would work sometimes and not other times). After some experimentation, I also noticed that this bug occured when using a btAxisSweep3 broadphase, but not when using a btDbvtBroadphase.
It took me around two days to find the root cause of the issue, but it turned out that we accidentally instantiated some of the capsules for our characters with negative heights, which messed up the broadphase due to unexpected AABBs. This happened because the game's assets provide their capsule properties as radius and end points (since that's what Havok used) rather than radius and height. We just used a simple subtraction to calculate the height needed for Bullet, which turned out to be erroneous because the layout of these end points is not always consistent, therefore leading to negative values sometimes with our old method.
Of course once we found the error in our code, it was reasonably simple to fix, but adding some asserts on negative radius/height arguements to the capsule shape constructors would probably be a good idea and could help future users not falling into the same trap. Alternatively (or addtionally), some asserts could probably be added to the btAxisSweep3 implementation whereever the AABBs are used (since this could catch even more incorrectly initialized shapes).
(I would make a pull request for this myself, but I'm currently not at home, so I at least wanted to create an issue for it)
Beta Was this translation helpful? Give feedback.
All reactions