I currently have a system in which i can create a spline for meshes to follow (It will need to be possible for multiple different meshes to be mixed in, so i can’t easily use an InstancedStaticMeshComponent) and i feel like creating and destroying static mesh components for each mesh is a huge bottleneck. Is there any way to simply call something like DrawMesh() to draw a mesh from a specified static mesh, at a certain world position and rotation?
Hey @LunarSnail!
A little trick I like to use: if they’re reused often, spawn them on load, put them in an array, and stack them somewhere the player won’t ever see. Especially if they’re something you need a lot of, and fast when they’re needed.
Spawning takes an absolute ton of resources compared to a simple “Set Location”. And when it’s done, instead of despawning it, you can move it back to your pool location.
I’ve used it before on a game with about 100 projectiles spawned onto the screen at the same time- each with their own trajectory and Niagara effects- and I went from a 40 frame drop to a .5 frame drop with this.
Now, if this spline is being created on the fly and the game is told to render 1000+ static meshes over and over without reusing objects… Yeah, that’s going to bottleneck you.
I guess what we need to know is more context to give you a for-sure helping hand?
Ah, yeah. Sorry for not providing much context!
I’m making a factory game, in which i’ll need many items (referred to as meshes above) to be spawned so they can be transported. The amount of meshes i’ll need is never constant, so I’m not sure if pooling is an option. I can calculate the amount of items that could fit on a spline - if it was fully filled - but pooling those would mean spawning a bunch of unnecessary objects.
EDIT: This is ofcourse only for the visual part of the factory, so all of this optimization in relation to this is only needed when said items are visible.
Oh, man, then the pooling option would actually work out great!
What that does is it sacrifices processing up front, in order to prioritize processing optimization later. If your factory churns things in and out, despawning and spawning is a huge hit to optimization. When they hit the end of the line (go into a bucket, enter another stage of production, etc.) you can re-pool them. Destroying is costly, too.
The beauty of a pool is you can reduce or grow it as needed.
If
Array < 5
SpawnActor and add to array, delay, loop back to <5 check to check again.
You could also work it backwards.
Because the thing is if you grow the amount of static meshes in the pool and shrink it as needed, you don’t have to take the hit of spawning and destroying over and over, only as needed. The pools will grow as the factory does.
And it’s better to have 100 static meshes getting moved around than getting spawned and despawned. We’re talking an exponential difference in processing power.
So, if I understand this correctly, I should be spawning just as many static mesh components as would humanly be possible in the current camera view at all times, and shrinking or growing depending on how much the camera can see?
Sounds like a C++ challenge, but not an impossible one for sure.
EDIT: Just re-read, is spawning exactly as many as needed for all transporters in the world what you meant, or what I described here?
Not depending on how much the camera can see- that would be taken care of by occlusion culling. Let them exist normally.
However many the factory could have spawned at one time. Heck, if you shut off one production facility, you could let the products pool up and delete them once the pool starts getting too large, as well.
The point is to have the array grow with the factory, and shrink if necessary.
Say you have an iron ingot maker with 10 spots on the spline. You spawn them in, 1…2…3…4… to ten. Then they reach the end of the line and go into a receptacle. Spawn them to 15 just to be safe. The ones falling in the receptacle get added to a pool that STARTED with 0 but now has 5.
So after 15 have been spawned, you just recycle the meshes over and over and over.
So if the facility produces 100 iron bars a minute, with 10 on the conveyor maximum, you go from 100 spawns and destructs per minute down to 15 EVER, until that line is extended. Maybe you could base the amount of objects needed to be kept on length of spline.
Then if you built a second iron bar making facility, you’d just grow the size of the “Iron Bar SM” array as needed, say another 10, and have them both pull from that array.
So, split the pool by itemtype/mesh, grow the pool as more are produced + some extra (they will be recycled once they reach the end of the spline), and keep doing that for every machine/spline?
(Ofcourse, once it notices that some pool items are just not getting used, it will clear those out of the pool)
You get it, for the most part!
The only thing I’d add is that you don’t HAVE to have one pool per machine/spline!
If they are producing the same item, you can double up on the same pool- just increase the size of the array.
So say you had:
Iron mine.
Iron mine.
Iron mine.
Smelter.
Smelter.
You’d have TArray (Iron Ore) With a size of 35, and a TArray (Iron Bar) size 25.
Or- EVEN BETTER-
Get Array LENGTH, if <= 0, spawn Static Mesh.
Else, get Array Index (Length-1), set static mesh to start position, set visibility-> True, attach to conveyor, Remove from Array.
Then at the end:
Get Array LENGTH, if >= 6, Destroy Component/actor/however you have it.
Else, set visibility → False, set static mesh to pool position, and add to array.
After thinking about it even more, i got the following idea:
What if I created an Instanced Static Mesh Component for every item type, and stored these globally (in the gamestate or something). I can then access them and add / remove meshes from them as needed. (these mesh components would always exist in the world)
EDIT: If this still creates performance issues, i can always still pool them inside of the instanced static mesh, with the methods described above
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.