UProceduralMeshComponent UpdateCollision Degrading performance over time

Aylaylay · October 6, 2015, 2:23pm

When playing in editor, updating collision for a UProceduralMeshComponent will take longer and longer to complete each time it’s updated, the time it takes to complete also stays the same when stopping and starting the game, it only goes back to normal when the editor is restarted. This doesn’t seem to be a problem in packaged builds, just play in editor.

This seems to be a problem in the physics cooking code, updating the visual mesh works perfectly.

Here’s a comparison of a packaged build and PIE.

Packaged build:

PIE:

Packaged build will stay at the same fps when updating the mesh but PIE will quickly drop to a low fps.

anonymous_user_2b03d27c · October 6, 2015, 5:12pm

Hey Mykei-

Could you post the setup for your procedural mesh component? I would like to test this issue on my machine and want to make sure that I’m following the same steps that you used.

Cheers

Aylaylay · October 6, 2015, 6:02pm

I made a minimal test actor that degrades performance over time.

100 quads updated every frame with 4 mesh sections (this wouldn’t normally happen in a real game but it replicates the bug) I’m not sure if it happens with just 1 mesh section or it takes a much longer time for performance to degrade, I’ll run it for a while to test.

gist.github.com

https://gist.github.com/aylaylay/b2182166f310b59132ae

TestActor.cpp

// Fill out your copyright notice in the Description page of Project Settings.

#include "Core/Interior.h"
#include "TestActor.h"

ATestActor::ATestActor()
{
	PrimaryActorTick.bCanEverTick = true;

	Mesh = CreateDefaultSubobject<UProceduralMeshComponent>(TEXT("ProceduralMeshComponent"));

This file has been truncated. show original

TestActor.h

// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "GameFramework/Actor.h"
#include "ProceduralMeshComponent.h"
#include "TestActor.generated.h"

UCLASS()
class INTERIOR_API ATestActor : public AActor

This file has been truncated. show original

Confirmed that performance still degrades over time with 1 mesh section, it just takes much longer.

Aylaylay · October 7, 2015, 1:03am

I ran the profiler and found that UBodySetup::CreatePhysicsMeshes() is taking the most time

Aylaylay · October 7, 2015, 2:50am

I’ve narrowed it down to
GetDerivedDataCacheRef().GetSynchronous(DerivedPhysXData, OutData);
Replaced it with
DerivedPhysXData->Build(OutData);

That completely fixes the performance issues in PIE.

Aylaylay · October 7, 2015, 5:41pm

The fix is in engine code, I’ll request to have it included.

anonymous_user_2b03d27c · October 7, 2015, 5:33pm

Hey Mykei-

I’m glad to hear that you were able to find a solution for the issue. Was the fix you found inside your own code or the engine code? If you made the change you mentioned to source code you may want to consider entering a pull request to have your fix included into the engine. You can find instructions on how to do this directly on GitHub: https://github.com/

Cheers

dupe_Ori_Cohen · October 13, 2015, 1:28pm

Hi,

In this case the DDC is getting thrashed with new data every frame. I think the right approach is to allow users to tag a bodysetup as requiring runtime cooking. This would be a bool that you would set to true when doing runtime cooking on a component.

Because of backwards comparability we can’t use this flag to determine which assets are not using runtime cooking, but we could issue a warning so that any asset which is cooked at runtime without the flag would be known by the user. This would allow us to make the behavior more strict over time.
Of course if the flag is set you’d never check the DDC.

If you are willing to make this change I’d be glad to integrate it!

Either way thanks for bringing this up it’s a definite issue.