Decal & Emitter Pool Being Purged At Same Time, How Raise Limit

Development Programming & Scripting C++
, , , ,
1

Dear Friends At Epic,

I am simultaneously using decals and particle systems to show footprints

and periodically during game time, after around 200 or so of each type,

they ALL just suddenly disappear!! ( new ones as well as ones that are currently fading)

This is disastrous for my game mechanic of having long lasting footprints!

#Preventing the Purge?

How do I raise the limit or prevent this sudden purge from occurring?

Rama

#Background Info

I am using GameplayStatics SpawnEmitter and SpawnDecal

I am using the Location versions at the moment

this is not PIE

this is independent game instance

I am setting lifespan for decals to 0

and particle systems have a life span of about 20 seconds

#They All Disappear Together All At Once

2

#Texture Pool Size

In Config/DefaultEngine.ini

I tried this

[TextureStreaming]
NeverStreamOutTextures=False
MinTextureResidentMipCount=7
PoolSize=10000 ;160
MemoryMargin=20
MinEvictSize=10
MinFudgeFactor=1
LoadMapTimeLimit=20.0
LightmapStreamingFactor=0.2
ShadowmapStreamingFactor=0.2
MaxLightmapRadius=2000.0
AllowStreamingLightmaps=True
UseDynamicStreaming=True
BoostPlayerTextures=3.0

behavior did not change

3

#Permanent Object Pool

I tried this

[Core.System]
MaxObjectsNotConsideredByGC=0
SizeOfPermanentObjectPool=10240  ;0

Behavior did not change

4

#Please Help Epic

I"m stuck on this,

I cant make a long trail of footprints as a game mechanic

because of the periodic complete and instant purging of all decals and pscs

Rama

5

#Solution Workaround, Spawn ADecalActor Directly

I decided to just spawn the decal actors myself

and now they stay!

Still looking for feedback on this issue though

#Sample Code For Others

ADecalActor* NewDecal = UMyCore::Spawn(GetWorld(),NewFootStep.Location,NewFootStep.Rotation);
if(!NewDecal) return;
NewDecal->Decal->SetDecalMaterial(NewFootStep.MatInst);
NewDecal->SetActorRelativeScale3D(NewFootStep.DecalSize);

#.h

you need to add this

//Decal Class
#include "EngineDecalClasses.h"
6

Most likely the reason they all poof at once is Garbage Collection. There is no emitter pool or decal pool that the created components are placed in so there is no reference to hold them in memory. To verify this is/was the case you could force garbage collection with the console command “obj gc” and see if you see the poofing behavior.

As with all things GC the solution is to make sure you have a reference to the created components. The reason why your decal actor approach works is now that you have an Actor it is a member of the level and so garbage collection won’t touch it. Of course using an Actor is somewhat more heavy weight as you have an actor wrapping the component, so it would be more ideal to have only the component.

Perhaps a single footstep manager actor that keeps the list of footstep emitters and decals might be the way to go.

7

Hmm, that is a very helpful info Marc!

But I was storing references to the decals, inside of an array of USTRUCTS,

and each USTRUCT had a reference to its respective DecalComponent.

the DecalComponent was a UPROPERTY()…*

So I was bascially using a footstep manager originally, but perhaps my structure was too indirect?

it was basically (part pseudo code)

some .h

USTRUCT()
struct FootStepStruct
{
   UPROPERTY()
   DecalComponent* DecalPtr;
}

:slight_smile:

in the actor class .h:

TArray Footsteps;

.cpp

//when spawining a footprint:
FootStepStruct NewStep;
NewStep.DecalPtr = UGameplayStatic::SpawnDecal....

Footsteps.Add(NewStep);

so I will have to do further tests.

But thanks as always!

Rama

8

#Tarray UPROPERTY()

you know…

I made all of the struct decal pointers UPROPERTY()

but I dont think I made the TArray of USTRUCTS into a UPROPERTY() !

So I will consider this as resolved, though I had to move on to actor implementation for other reasons, mainly self-management of fading out.

But thanks once again Marc!

#Marc the Hero!

#:heart:

Rama