A couple of static mesh assets in our project triggered an ensure when trying to render them, more specifically:
`FDistanceFieldSceneData::UpdateDistanceFieldObjectBuffers(…
…
const FDFVector3 WorldPosition(PrimAndInst.Origin + FVector(PrimAndInst.WorldBoundsRelativeToOrigin.GetCenter())); //this WorldBounds box has min and max = NaN
FMatrix44f LocalToRelativeWorld = FDFMatrix::MakeToRelativeWorldMatrix(WorldPosition.High, PrimAndInst.GetLocalToWorld()).M;
FMatrix44f RelativeWorldToLocal = FMatrix44f(LocalToRelativeWorld.InverseFast()); //trying to inverse the matrix with NaN components`
The WorldBoundsRelativeToOrigin of this PrimAndInst is invalid - every field is NaN.
I’m not sure if it’s created during importing the static mesh asset or when setting up the scene, but the same issue happens when trying to open the asset in the editor (as the viewport is trying to render it).
Is there a way to check for this issue without drawing the static mesh on a scene? I’m wring a validator for static meshes, derived from
UEditorValidatorBaseand want to check for those type of issues there.
I’d also greatly appreciate info on why this can happen and how to prevent that.
Hi there,
This issue appears to be the same as the one reported [Content removed] However, it looks like there wasn’t a good reproduction for this, and so the case didn’t get very far. Would you be able to provide a reproduction project containing one of the meshes that exhibits this issue? The best way to create this would probably be to migrate (right click -> asset actions -> migrate) the affected mesh asset from your project into a blank one.
You should be able to call StaticMesh->GetRenderData()->Bounds.ContainsNaN(), to check if a mesh’s bounds contain NaNs or not.
Building the editor in Debug mode will also enable a bunch of extra NaN diagnostics, which should hopefully tell you where these NaNs are actually coming from. These will get output to the log by default, but you can also set the CVar EnsureOnNaNFail to 1 to trigger an ensure instead. It would be good to be able to get a call stack of where the NaN diagnostic ensure fails, to help track down this issue.
Regards,
Lance Chaney
Hi, thanks for the reply. I’m still waiting on a decision if the mesh can be shared, since the question is public.
Thanks, let me know what you decide and if you need any more help with the validation. From the previous linked case, it appears that something might be going wrong on import that is causing this, and a re-import seemed to fix the issue. You can probably track down assets with issues fairly easily by validating UStaticMesh assets
StaticMesh->GetBounds()
StaticMesh->GetRenderData()->Bounds()
for bad values (NaN, very small, or extremely large)
Regards,
Lance Chaney