UE4 4.6 C++ Project: Package Project Error

drb1992 · January 21, 2015, 10:16pm

A team member and I have been trying to package our project all afternoon. We were getting a few errors, but we have fixed all but 1 error.


[2015.01.21-21.43.32:492]  0]LogUnrealMath:Error: FMatrix::Inverse(), trying to invert a NIL matrix, this results in NaNs! Use Inverse() instead.

We have tried the following.

Restarted PC
Tried to package the game as Shipping and Development
Under Package Settings we checked/unchecked the Full Rebuild option
Removed all uses of FRotator in our CPP code.

Based on our research, we’re not the only ones with this problem, but no one seems to have found/shared a solution yet.

Here is a link](Dropbox - Cook.txt - Simplify your life) to the full log of the failed package.

anonymous_user_4fe9f58b1 · January 21, 2015, 10:52pm

I doubt there’s a silver bullet solution to this. I’d roll up my sleeves, run the cooker with a debugger attached, inspect the asset that’s causing it to happen, see if it’s a content problem or an engine problem.

drb1992 · January 22, 2015, 2:43am

Have any ideas on how I would go about doing that?

anonymous_user_4fe9f58b1 · January 22, 2015, 3:05pm

Behind the scenes, all the cook/package frontend does is issue commandlets. It’s pretty hard to figure out what’s being done and what arguments are being passed just browsing through code, due to the large number of tools interacting with each other. What I generally do is run whatever I want to debug from the frontend, then look at the beginning of the resulting log files for command line arguments. In your case:

Grab the important arguments from that command line and then provide them to UE4 when starting debug. A lot of these arguments are just for controlling output, which doesn’t really matter, so boiled down to the bare essentials:

Set these by right-clicking the UE4 project in your solution and choosing “Properties”. In the Debugging section of the property sheet is the Command Arguments section where you can paste these arguments. If all goes well, this should start the Cook commandlet with the debugger attached and whenever that assert gets hit, you can go up the call stack a bit to have a look at asset data.

Note that it’s entirely possible that the data you want to consult will be optimized out if you’re running in Development. To work around that, you can compile the editor in Debug or, to avoid a full engine recompile, just surround the section of code you want to debug with a #pragma optimize(“”, off) + #pragma optimize(“”, on) pair:



#pragma optimize("", off)

void SomeCookingFunction()
{
	Stuff();
}

#pragma optimize("", on)

Then it all depends on what asset is throwing the assert. I’m venturing from the list of animation assets being cooked in the log that the last one (“Character/Player_Arms/armsBoundAnimated.uasset”) might be the anim blueprint for that skeleton? I haven’t nosed around the internals of anim blueprints much, but hopefully the assert should tell you where the bogus matrix is and that should give you a lead on whether or how it can be fixed.

drb1992 · January 22, 2015, 10:55pm

cmartel;209711:

Behind the scenes, all the cook/package frontend does is issue commandlets. It’s pretty hard to figure out what’s being done and what arguments are being passed just browsing through code, due to the large number of tools interacting with each other. What I generally do is run whatever I want to debug from the frontend, then look at the beginning of the resulting log files for command line arguments. In your case:

Grab the important arguments from that command line and then provide them to UE4 when starting debug. A lot of these arguments are just for controlling output, which doesn’t really matter, so boiled down to the bare essentials:

Set these by right-clicking the UE4 project in your solution and choosing “Properties”. In the Debugging section of the property sheet is the Command Arguments section where you can paste these arguments. If all goes well, this should start the Cook commandlet with the debugger attached and whenever that assert gets hit, you can go up the call stack a bit to have a look at asset data.

Note that it’s entirely possible that the data you want to consult will be optimized out if you’re running in Development. To work around that, you can compile the editor in Debug or, to avoid a full engine recompile, just surround the section of code you want to debug with a #pragma optimize(“”, off) + #pragma optimize(“”, on) pair:
#pragma optimize("", off)

void SomeCookingFunction()
{
	Stuff();
}

#pragma optimize("", on)
Then it all depends on what asset is throwing the assert. I’m venturing from the list of animation assets being cooked in the log that the last one (“Character/Player_Arms/armsBoundAnimated.uasset”) might be the anim blueprint for that skeleton? I haven’t nosed around the internals of anim blueprints much, but hopefully the assert should tell you where the bogus matrix is and that should give you a lead on whether or how it can be fixed.

Thanks a lot. It turned out it was an issue with that animation asset.