Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[UE4]Spine & Runtime Mesh Component performance

InsomniaRide

Hello guys,

I recently had a performance issue on an Unreal project with the SpinePlugin.

I saw there were 2 similar posts regarding this:
http://esotericsoftware.com/forum/UE4-Performance-problem-example-project-current-branch-9482
http://esotericsoftware.com/forum/UE4-Performance-issue-after-CreateMeshSection-change-9479?p=42955&hilit=CreateMeshSection#p42955

I managed to find the cause of the problem, it was because of the collision generation for the mesh sections. I disabled this and not it works fine but I just wanted to give some more information on the issue.
On my part, at least, it was caused because of high disk usage. I attached a screenshot of the files open while the plugin was running. It seems that the Runtime Mesh Component writes a lot of files in the DDC on each update (you can check the screenshot below).
I have 2 machines I am working on, a PC with an SSD and a laptop with a hard drive. On the PC the issue is not noticeable, but the DDC cache constantly increases while a spine animation is running.

Is this because of the Runtime Mesh Component or because of the way the Spine Plugin is using it?

Thanks,
Andrei

InsomniaRide

Mario

This is because of the Runtime Mesh Component. It seems UE4s physics system is actually at fault though. I have not found a work around to not have these files generated to the DCC yet. I guess we could disable collision mesh generation by default for the time being. As I found, the files are not generated at runtime once you cook the final app.

jzela

Checking in on this because I have the same problem. Am wondering if there is an open issue for it that I can track to see if any progress is made. Our project uses the collision mesh for hit detection, but it saps ₅₀ fps on dev machines where the DDC is not on a SSD.

Thanks!

Mario

Here you go [UE4] Generation of huge infinite number of File in DerivedDataCache · #1041

MBLucid

This is a tad more dangerous than a perf hit...

I stumbled upon this post, after finding 6.5 million files had been generated by this bug. My computer was lagging, and my SSD was having some serious issues. Windows wouldn’t even boot proper half the time, the C drive working at 100% as though hung. It took 6 hours to delete all the files... a defrag and system repair later, and I seem to be in working shape again.

The only work around I’ve found is to disable all collision on the spine component, relying on other components/traces for collision purposes.

Mario

Sorry for that. I've disabled collision by default now.

Mantic

By any chance would this affect touch/input on spine objects in UE4? I'm assuming so since it uses the collision system to detect UI interaction. I just realized no touch was happening on the spine skeleton renderer and stumbled on this post. It seems to add up. I'm running spine 3.7-beta-cpp from github.

Does this happen to be related to the issue where "Set Flip X" is no longer present on the Spine Skeleton Animation object? or is that an intentional design?

Thanks!

Mario

flipX and collision are not related to each other. Instead of flipX/flipY you can now use scaleX/scaleY which is a lot more flexible.

Regarding the collision problem we've contacted Epic and are awaiting a response on how to solve the issue of a gazillion PhysX files being generated when enabling collision mesh construction on a ProceduralMeshComponent. For the time being, I'm afraid you'll have to use a separate collision shape for your skeletons.

Mantic

Ah, gotcha. With 3.6, I didn't realize there was a flipx, so I did some negative scaling to invert the graphic. I must have been doing something wrong, because UE4 complained about having to re-calculate the collision objects on the inverted mesh. Since collision is up in the air at the moment, I'm guessing that it's a moot point until its been resolved.

Thanks!