-
Notifications
You must be signed in to change notification settings - Fork 814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raycasts may fail after moving a lot of objects #550
Comments
I'll investigate ASAP. |
Merci! (Oh... I remember browsing your Coder Corner with great interest in the early 2000s!) |
I haven't been able to reproduce this so far. Are you doing anything out of the ordinary for this to happen? I did various tests like in the attached video, with a lot of objects moving around, and a test raycast against a particular object. The blue lines visualize the AABB tree for the scene, and it's rebuilt approximately every 100 frames. The test raycast never misses the test object, even though it's moving quite fast so any missed "refit" operation on the BVH should be exposed by this. I suppose you don't have an easy repro for me to look at? Github550.mp4 |
Hi Pierre, I attached a modified version of the Hello World snippet that will eventually reproduce the issue if you let it run. Just put a breakpoint on line 217 and it will stop when a ray cast fails. I also added this:
You can see that the new world's bounding box corresponds to the previous position of the objects and not to the new position that was set in the previous frame. Note that I used static rigid bodies because that's what was used (sorry, I forgot to specify it). In the original project, the objects are never moved except when a specific event occurs and all the objects are moved somewhere else. |
Ok, for PhysX 4 you will need to modify the code in 2 places:
Add the last part with BUILD_LAST_FRAME there:
And that should fix the bug. The bug happened because BUILD_LAST_FRAME was added a long time after the initial code was written, and we forgot to update these two lines. It went undetected until now (including in my own repro attempt above) because the scene tree contains N objects per leaf node. So the last tested AABB is not actually the AABB around just one moved object, it's the AABB around a group of spatially close objects. As long as the group's bounds still enclose the previous position of the moved object, the bug doesn't appear. It only appears if you teleport everything far away from the previous positions, as in your repro. Thanks for that one, it was not an obvious bug. |
Thanks to you! And yeah, it wasn't an easy one! It took me almost two weeks to get a proper repro and eventually isolate the cause. |
Two weeks is not bad. According to the Perforce history, this bug has been introduced at some point between 2013 and 2014 (I couldn't find exactly when). And nobody ever noticed. So, congratulations :) |
Will take this into Unity :-) |
About this issue because in some places buildStep doesn't commit right away void SceneQueryManager::sceneQueryBuildStep(PruningIndex::Enum index)
{
PX_PROFILE_ZONE("SceneQuery.sceneQueryBuildStep", mScene.getContextId());
if (mPrunerExt[index].pruner() && mPrunerExt[index].type() == PxPruningStructureType::eDYNAMIC_AABB_TREE)
{
const bool buildFinished = static_cast<AABBPruner*>(mPrunerExt[index].pruner())->buildStep(false);
if(buildFinished)
{
mPrunerNeedsUpdating = true;
}
}
} |
@PierreTerdiman Reference francis-page example,add the code to the sceneDesc Settings:
This problem still exists. because in buildStep,BUILD_FINISHED state not commit right away
|
Hi,
I've been investigating a low occurence bug where raycasts fail after moving a lot of objects around. I think I finally found what is causing it. When switching to the new AABBTree in AABBPruner::commit when a refit happened in the previous frame, the new AABBTree will contain outdated data. What happens:
In the frame where AABBPruner state is BUILD_LAST_FRAME:
In the next frame, where AABBPruner state is BUILD_FINISHED:
I tried to skip the BUILD_LAST_FRAME step and it seems to fix my issue. It's probably not the right fix as that step must have a reason to be.
The text was updated successfully, but these errors were encountered: