This might be caused by something #include’ing <cmath> header, which #undef’s all normal math.h macros, including isfinite(). Unreal Engine doesn’t include this header itself (but some third party libraries do) and hence the issue may not be reproed directly.
While the proper fix is perhaps using PxIsfinite() method in PhysX headers, the short term fix is to make sure that neither you (nor libraries you use) include cmath (or re-include math.h before #include’ing PhysX headers).
#Thank You RCL!
Dear RCL,
Thank you very much for answering this even though it does actually extend beyond the domain of stock UE4 code, I was including some extra math headers in my plugin that you’ve now explained were conflicting with the PhysXIncludes
Thank you again RCL!
#
Rama
You are welcome! 
Wow! Epic are really themselves in this issue! Not resolving, not answering since 2015, not acting responsibly. Well, what did we expect…
The solution (graceful one, not involving modifications inside PxUnixIntrinsics.h and working in UE4.16.3):
Go to the file, where you include your PhysX headers (#include “ThirdParty/PhysX/PhysX_whatever_version/Include/your_px_header.h”). Just above the include statements add next code:
#if PLATFORM_ANDROID
#include <cmath>
static bool EpicShouldFixThis(float v) {
return std::isfinite(v);
}
static bool EpicShouldFixThis(double v) {
return std::isfinite(v);
}
#define isfinite(x) EpicShouldFixThis(x)
#endif
Then, immediately after the include lines of your PhysX headers add next lines:
#if PLATFORM_ANDROID
#undef isfinite
#endif
That’s it. This should work.
The long and boring explanation (omit this, if you are not interested in the reasons for the issue):
You see, there are several libraries containing isfinite(), since it is a very basic function verifying “finiteness” of the number. Now, one could include it like that for example: extern “C” { bool isfinite(); }. This means “Use native C function”. Or like that: #include <math> and then use std::isfinite(whatever). Apparently Android SDK uses only first example, and PhysX expects the second. So, trivial assumption could be that the only thing needed is to include cmath. But no. Maybe Android SDK cuts it off somewhere, i don’t know. But including will not work. However, if you will not use the #undef after the includes in my fix above, your packaging will crush on multiple definition of isfinite (curses!). That’s the reason i complain about Epic! They are actually including it somewhere! It’s only about #include order. And even if there is no good way to reorder it, my fix should be implemented on their side. All i actually do, is temporarily appointing isfinite calls to std::isfinite, like PhysX wants it. I would even dare to say, that it’s Epic’s responsibility to manage PhysX versions, and make some include adapter governed by macros, and not just throw upon the developer to include the latest PhysX every time they will again secretly decide to jump up a version.
If you want an answer verified in UE4.16.3, got to my answer below.
Thanks for the explanation.
With all due respect, you must have missed the other replies and workarounds given back in 2015 (including my own back in March 2015). PxUnixIntrinsics.h has also been changed since then.
The problem obviously does not affect the stock UE4 - otherwise we would not be able to compile UE4Game for Android as part of the release. If you were affected by the problem, it might be unique to your #include situation (e.g. are you using extra libs that we don’t? or different NDK than what 4.16.3 shipped against?). If you believe that your case is common, I suggest including the repro steps so Android folks on our side could repro and find a solution.
Thank you for the nice words. Sorry to annoy, but it was quite late at night when i posted this. I was a little out of focus, and missed, that “<” sign should be posted as " & lt" , so the libraries i included were cut out of the text. Fixed this, so now the answer is correct. Sorry for inconvenience.
Thank you for the answer! Actually, that’s the first time my bitter comment was actually related by staff! Yay! With your permission i will answer gradually:
“With all due respect, you must have missed the other replies and workarounds given back in 2015 (including my own back in March 2015).” - Do you mean “make sure that neither you (nor libraries you use) include cmath (or re-include math.h before #include’ing PhysX headers)” ? How is this workaround permanently valid? Problems are:
a) If game designer uses any plugin, he actually has no way to know, nor manage includes of the plugin. This means, that plugins may be mutually exclusive with PhysX. Does that sound as a valid infrastructure?
b) “or re-include math.h” - didn’t work for me. And imho it’s hardly a valid solution to make someone juggle with include hierarchy, part of which he neither knows about, nor it resides on his side of the code, and generally may be altered under the hood by the whims (legitimate and logical as they may be) of other parties.
“The problem obviously does not affect the stock UE4” - well, my complain is, that it exactly does. Unless you consider using PhysX as non-stock of course. Correct me if i am wrong, but we are suggested to use it roguishly, as third party, instead of through the engine. Although the engine supposedly uses this library itself. Hence my suggestion about exposing some adapter to PhysX as part of engine API, to avoid exactly the situation we are at now. Please note, that this issue arose after i integrated new, PhysX utilizing feature on the machine, that underwent format and full system and Unreal re-install just before that. And that’s a machine dedicated for UE development.
Out of characters, so continuing in the comment below…
The reproduction steps are fairly simple:
i) Make a whatever project
ii) Add this to some header:
#include “PhysicsPublic.h”
#include “PhysXPublic.h”
#include “PhysXIncludes.h”
#include “ThirdParty/PhysX/PhysX_3.4/Include/geometry/PxTriangleMesh.h”
#include “ThirdParty/PhysX/PhysX_3.4/Include/geometry/PxSimpleTriangleMesh.h”
#include “ThirdParty/PhysX/PxShared/include/foundation/PxVec3.h”
iii) …
iiii) Profit!
Taken from St.Rama and St.vebski tutorials:
P.S.
Please don’t take this personally. I sincerely believe, that every staff member out there wants to help. And i am really grateful for your answer. But we all work under corporal supervision, which tends to be rather immoral.
I am working with UE for around half-a-year already. What i (subjectively) see is, that the general tendency is as follows:
No valid, up-to-date API documentation. The online documentation is at most javadocs without any comments, that don’t explain what particular API actually does. And at worst just plain wrong. I found more solutions out of source code reading. And as good of a way as it may be, it’s gratuitously time-consuming, don’t you agree?
No manuals. It may take up to few weeks to find the manual, written by the great guys like i mentioned above, and it will be for the outdated UE version. So, no manual worked for me straight. I had to patch it to work. And it is the best of cases.
Out of characters, so continuing in the comment below…
No forum responsiveness from Epic staff since 2015. That’s a general tendency! Before 2016 every question has Epic staff attention, but API in the answers is outdated. After 2016 the staff attention became scarce and very selective. I (subjectively) noticed, that question is answered only if there is a quick, simple directive. None of my questions or questions i was interested in were ever commented. Not even by “Pal, the solution is out there, in some manual. Just keep trying, you will eventually find”. Very frustrating is to search for some API, without even knowing if it exists.
No backwards compatibility. By definition (!!!). So, most of the awesome answers given before 2016 - 2017 are not valid today. At least at the fields i was interested in. But they are still present in the forums, which is very misleading.
No valid examples. The examples Epic provides do not match any manuals, especially not the online Epic YouTube channel explanations (well, most of them). The samples utilize a very specific happy path, that is not usable for most people i encountered.
Generally, it seems, that instead of putting their effort in improving and de-bugging their products, or providing user support, Epic, as a Corporation, is more interested in sueing 14-year olds for hacks in FREE TO PLAY games, that they EVEN DIDN’T DEVELOP. We here call it Activision of a brain. A pity, that Epic tends to turn this way.
Maybe I did something wrong, but this workaround didn’t work for me. Although this one worked.
In file “…\UE_4.18\Engine\Source\ThirdParty\PhysX\PxShared\include\foudnation\unix\PxUnixIntrinsics.h”
I have changed that call by
//! \brief platform-specific finiteness check (not INF or NAN)
PX_CUDA_CALLABLE PX_FORCE_INLINE bool isFinite(float a)
{
return !!FMath::IsFinite(a);
}
//! \brief platform-specific finiteness check (not INF or NAN)
PX_CUDA_CALLABLE PX_FORCE_INLINE bool isFinite(double a)
{
return !!FMath::IsFinite(a);
}
and compilation passed.
Really? D@mn. Contact me by mail felix@anzu.io and i will try to help. Changing the code of PhysX files is a bad practice, since Epic can suddenly decide to go up a version, and it will cause you to repeat this workaround. Moreover, if someone checks out your project, or you are developing a plugin, it’s wrong to cause other people to repeat all of your workarounds. This inflates troubleshooting exponentially.
FilAl’s fixed worked for me today on 4.21. Thanks!