- Edited
[UE4] Performance problem, example project, current branch
I already made a post about this in the runtime section, but now I realized that this happens even if you take the current branch example UE4 project, copy the spine-c folder where it goes, generate visual studio files and then rebuild from visual studio. You get this kind of performance: (both tests in the same machine. I only have one though so I havent been able to check in other hardware):
Now if you delete the "true" part in the file spine-runtimes-3.6\spine-runtimes-3.6\spine-ue4\Plugins\SpinePlugin\Source\SpinePlugin\PrivateSpineSkeletonRendererComponent.cpp
void USpineSkeletonRendererComponent::Flush (int &Idx, TArray<FVector> &Vertices, TArray<int32> &Indices, TArray<FVector2D> &Uvs, TArray<FColor> &Colors, TArray<FVector>& Colors2, UMaterialInstanceDynamic* Material) {
if (Vertices.Num() == 0) return;
SetMaterial(Idx, Material);
TArray<FRuntimeMeshVertexTripleUV> verts;
for (int32 i = 0; i < Vertices.Num(); i++) {
verts.Add(FRuntimeMeshVertexTripleUV(Vertices[i], FVector(), FVector(), Colors[i], Uvs[i], FVector2D(Colors2[i].X, Colors2[i].Y), FVector2D(Colors2[i].Z, 0)));
}
CreateMeshSection(Idx, verts, Indices, true);
// CreateMeshSection(Idx, Vertices, Indices, TArray<FVector>(), Uvs, darkRG, Colors, TArray<FRuntimeMeshTangent>(), false);
Vertices.SetNum(0);
Indices.SetNum(0);
Uvs.SetNum(0);
Colors.SetNum(0);
Colors2.SetNum(0);
Idx++;
}
You get, this kind of performance:
I realize this probably has more to do with the CreateMeshSection() function (which I think is an UnrealEngine defined function), but as a default setting for the plugin it doesn't feel right that the tick function takes like 10 times more time and has a lot of spikes (which is the same thing that happened to my project after updating before reverting the "true" part). Of course it might be that it can't be replicated on other hardware or it's something specific to my machine but still think is worth pointing out.
Thanks for reading and for any replies I might get.
Hm, we changed this just recently, so ray hit tests work as expected at runtime. This is actually part of a 3rd party plugin we use (RuntimeMeshComponent) to generate meshes on the fly (which is necessary to implement all of Spine's functionality). Sadly, the build in dynamic mesh component doesn't allow us to do all the things we need, so we switched to that. The true flag is responsible for creating collision meshes. This should be fast.
I'll investigate. Best case we can make this faster and keep it as a default, worst case, we make it a switch! Thanks for bringing it to our attention! Here's an issue you can follow [ue4] Collision mesh generation hogs performance · #1026
I've tried to reproduce this in 4.17 and 4.18, but the timings seem ok.
https://i.imgur.com/FfUQewP.png
I assume you used the example project as is without modifications? What are the specs of your development machine? What OS version are you running?
Hi, thanks for the quick replies. I tried updating the faulty projects and it still happened to me, even in 4.18. But I redownloaded the new version from scratch and got this:
Which seems very similar to your image and pretty good. I'm still seeing some improvement without it but much less pronounced (and there doesnt seem to be any spikes):
So it's ok now. Maybe there was something wrong with the way I installed it last time, or I accidentally grabbed the wrong branch or something (even though I thought I made sure I didn't). So, sorry for that. I'm gonna try updating my project and see if everything is fine. Just for completeness I post answer to your questions below.
Thanks for the answers.
I did use the example project just as downloaded without any changes. All I did was copy-paste the spine-c folder to the specified location, then regenerate visual studio project files and then rebuild in VS 2015 community.
Going by the "system information" in control panel, my machine specs are:
Windows 10 Pro
Processor: Intel(R) Core(TM) i7-4790 CPU @ 3.60 GHz 3.60GHz
RAM: 16.0 GB
System type: 64-bit Operating System, x64-based processor.
and my Graphics Card is an
ASUS DUAL-GTX1070-O8G
this one:
https://www.amazon.com/GeForce-Dual-fan-Gaming-Graphics-DUAL-GTX1070-O8G/dp/B01JHQSZ40/ref=sr_1_1?ie=UTF8&qid=1509393140&sr=8-1&keywords=asus+dual-gtx1070-o8g&dpID=51xWIIzYafL&preST=SY300_QL70&dpSrc=srch
Thanks for the update, and glad it works as intended. I'm a bit uneasy that these discrepancies can pop up out of the blue without us being able to track down the cause. Your setup is largely similar to mine, including VS version, UE version etc.
One idea I have: is this a PC or laptop? If it is a laptop, then energy saving features (CPU throteling) could be responsible for what you saw.
Sorry for the late response, I updated my project and it's working fine now so I forgot to check the forum :p .
It's a PC. The only thing I can add (that probably is not gonna be much help) is that for some reason, both in the fresh project that's working fine, and in my personal project right after I updated it, the first time I opened the UE Editor after rebuilding in VS, performance still had spikes and was overall slow, but if closed and then reopened for a second time performance got regular and nice as in the images and then it was all ok. I haven't rebuild my project since (and I'm away from my PC) so I don't know if this happens every time. As I'm not the most computer savvy guy and no one else seems to be having problems I figure is probably just something on my end (like maybe my PC, or maybe I need to check my UE4 global settings, if those exist, or VS settings, as I have sometimes changed stuff I don't really understand as a leap of faith while reading tutorials to get stuff working in my game ).
If a manage to reproduce it with rebuilding, I'll try to see if some of the Unreal Engine 4 profiling commands give more detailed information so I can see exactly what's going on and let you know.
Anyway, thanks for the quick and thorough attention. As for right now it's all working really well :party: .
At least we got it documented here for other people who may run into it. Hope we can get more data points.