Hey All, I have a simple BP set up where I’m loading in a static mesh cube every .01 seconds. This ends up creating a “trail” of cubes behind my character (around 3,000 or so). I’ve set a life span on the cubes so that after 15 seconds, they destroy themselves. The intent is to hide the cubes when playing in game to create a collision “ribbon” behind my character. The issue is, once the cubes start to destroy themselves, I get a massive drop in performance (20-30 frame drop). I’m assuming the issue is the number of draw calls and the fact that UE is trying to spawn in and destroy thousands of boxes at once. Does anyone have any suggestions? Here’s a video showing the issue;
First of all, consider using a timer for the spawning. Not sure if it’ll make any difference in performance, but it’s much cleaner and easier to disable for any reason (not just game over).
Second, if it’s collision you’re worried about, why not use an actor that only has a box collision component? You can add the graphical representation (the trail) any other way. Using a particle effect, or an instanced static mesh component would be a much better idea.
Hi, currently the blue trail is a particle effect. I tried creating a blueprint actor that only has a collision box component but when I get the same performance loss when it starts to destroy each collision box.
Thank you for the screenshots! Unfortunately, after setting up my ISM and Character BP exactly how you have it, nothing spawns behind my character! Do you see anything that I did wrong in the video below? Thanks!
Also you do not need to position the Child Actor Component in player relative space (-140). The instance location is dictated by that x100 forward vector (-100uus behind the player’s location).
Besides that, the comp lives in the world space (absolute) so it will actually stay in the middle of the world all the time. it will not move with bike anyway, which is a good thing.
Now, depending on how it goes, it might be cheaper to move the instances away - somewhere where the player cannot see them, rather than remove them. Keep track of them and only remove them when the player is occupied with something else - staring at a menu, for example. In case this causes a spike.
Omg not sure how I missed that. Thank you. I’m getting a strange issue where the items are spawning but not rotating behind my character like yours is. I’m not sure why.
Since there’s only 1 skeletal mesh, this should be safe-ish. If you add more skeletal meshes to this actor, this may need changing.
Instead of the Actor’s Forward vector, we’ll use the Skeletal Mesh’s Right vector (we’re inheriting from the character, little we can do - that’s how it’s set up so we’ll roll with that). That’s the element that rotates, so this should work but is totally untested…
One way or another, this surely is cool but there may be better ways ;D On the other hand, if you manage to leverage / justify thousands of those instance hanging around for some other cool effect…
The game looks neat!
scaling boxes (tricky to set up and manage, verticality complicates things)
spline mesh components (you could have bendy trails, conforming to traversal path when jumping off ledges; updating a lot of SMCs every frame is costly. Perhaps we only need to update the last one that is disappearing, though. Quite a bit of flexibility.)
procedural mesh (complicated compared to other methods, fiddly, upfront time investment)
instanced static meshes (lotsa granular control over looks and behaviour, easy to manage). Not sure how much will the GPU like the indexing changing since 0 is removed often. Can be resolved by batch removal.
Thanks again. One more question and hopefully it’s the last . When you are setting your skeletal mesh variable in the BP, how do you get it to connect to the getworldlocation, getforwardvector, and getrightvector nodes? Mine says it’s not compatible.
P.s. I did try the spline mesh components method and had the light trail following, but I couldn’t figure out to to enable collision on the spline mesh or subtract spline points to allow the trail to disappear. So I resorted to creating a ribbon particle for my trail and dropping cubes behind for collision
As in the Answer Hub post - if you make the spline mesh an Actor that is kept alive by the Child Actor Component - the collision will work. It’s not actually a problem with collision per se, it’s a feature of the Movement Component. It only accounts for the root of the actor it’s moving - the capsule. It will ignore other bits that are attached to the root and the spline was attached. There’s probably a hackaround for this, like changing the owner and such.
But if you ensure the spline is not a part of the moving character, the collision will / should work.
If you tried to add Instanced Static Meshes you’re using now the way you tried it with the Spline, the character wouldn’t collide against them. Same rule applies.
. When you are setting your skeletal mesh variable in the BP, how do you get it to connect to the getworldlocation, getforwardvector, and getrightvector nodes? Mine says it’s not compatible.
