No i am just took a random vector from the stream to determine the position and scales for the transforms, but as the error is showing the box extent was calculated properly whereas the sphereradius were not. None of them ended up being NaN or infinite but the sphereradius only, and that was inf (infinite) to my readings. Thanks for the heads up anyways, i will take extra care to not fell into this problem of NaNs, however i believe it does not apply to this case at the moment. Or maybe it is?
It would be nice to understand how comes that the box extend can be calculated properly but not a sphere radius, and under what circumstances?
Is there a reason you are testing with numbers as large as -27134358891693078478848.0? If you won’t end up needing to support numbers this big when you finish testing whatever you’re testing, you may want to constrain the random numbers you’re generating to a more reasonable range. If you are setting the object’s position or scale to values as large as -27134358891693078478848.0, then you are likely going to run into some issues with infinite numbers that are calculated using its position or scale (such as its bounds).
The calculations for the sphere radius probably involves using the distance formula, which involves squaring each dimension of the bounds. Imagine how big a number -27134358891693078478848.0 squared is! I did the math and it’s 7.3 x 10^44. The maximum representable float is only 3.4 × 10^38, so that’s probably why you’re getting infinity for the sphere radius.
It’s actually very strange why it is showing that big number. I am only using a unit vector multiplied with a relatively small number, which i use to determine random locations and scale. I wasn’t sure why it is showing this number, but i was hoping that maybe it was a bug in the logging to show this wild number, because it was not expected to pop up.
There is a chance that at this point, we can talk about pointer issues that presented invalid transformations maybe. I was unable to reproduce this issue since then. My computer seem to be in ideal condition.
However silly the problem might be, your answer i can accept as the reason for the infinite number, however i still can’t see any explanation for the wild large number just showing up for no reason.
Thank you for answering this question. I will open a new issue once i can have a reproduction for the invalid transform, or the reason for the wild number.
I am received this error and crash when updating a HISM component. My class (fast hism comp) just extends it to make it easy for me to use in blueprints, but nothing fancy actually.
Ensure condition failed: !Primitive->Bounds.BoxExtent.ContainsNaN() && !Primitive->Bounds.Origin.ContainsNaN() && !FMath::IsNaN(Primitive->Bounds.SphereRadius) && FMath::IsFinite(Primitive->Bounds.SphereRadius) [File:q:\ue4\Engine\Source\Runtime\Renderer\Private\RendererScene.cpp] [Line: 752]
Nans found on Bounds for Primitive FastHISM: Origin X=477.632 Y=3.815 Z=-27134358891693078478848.000, BoxExtent X=2097.008 Y=279.157 Z=27397170951547911143424.000, SphereRadius inf
As the error states, the bounds are invalid, and i suppose it is actually the SphereRadius which is for some reason have became infinite. I did not set anything on the mesh i use in the hism component, but it seems like the calculus for determining the sphere radius could end up with infinite radius? Why is that?
I cannot seem to reproduce the glitch after many attempts, but i would like to avoid this to happen randomly, because it leads to the crash in engine since the assertion. I would rather force the sphereradius to be not infinite, but how should i do that?
Typically when I have gotten this error before, it has been because I was setting either the position, rotation, or scale of the object to some vector / rotation that had NaN in it. Check every place in your code where you affect the object’s transform and make sure you aren’t accidentally setting any part of it to NaN anywhere.
