hi, everyone. iv recently come across an issue where i havent been able to spawn actors quickly enough in my project.
essentially when i initialize my project, i need to spawn an unknown amount of actors (between 500 to 5000, or in rare cases up to 20,000), so i cant bake them into the level.
Alot of them will be off screen to help with performance, but the player can teleport anywhere, so they all need to be created as quickly as possible (ideally less than a second for 20,000).
the actors that im spawning are extremely simple overall, just needing a material, mesh, hit box, and being movable, so i dont need any of the other stuff that comes with an actor, like physics. this means a stripped down alternative to an actor could work as well.
something else that could work is just to have the hit box, then use some actors from an actor pool and spawn them around the player at the locations of the hit boxes. theres almost never going to be more than a thousand on screen at any given time so i can bake all those into the level, but the hit boxes will need to be spawned at runtime.
another idea thats even more out there, is to preallocate the memory in C++ which can be done all in one chunk, then fill the memory quickly with actor memory using memcpy and a for loop because the actors are all going to be the same size memory wise. no idea if this is possible, so the more experanced people, let me know if this is doable.
There’s no real fast way of spawning actors - if most of them are just Static Meshes - you can create instances.
I’ve just built a system that makes that kind of thing easy - you build up actors into reusable blueprints, then you can assimilate them into single actors - it takes care of things like instancing them too - and it has options for spawning from the construction script:
The fastest thing you can do - is create one instance of objects you’re wanting and then move them to where you are with a trigger - moving is much faster - that’s something else it can do.
They are all basically static meshes (altho they have different static meshes/materials applied and a couple of variable values applied at runtime), so i can instance them all from a single actor? it wouldent be much extra work for me to move the instance around if thats the case.
Yes you can instance them all from a single actor - you make instances from each of the different meshes/material sets you have (or rdBPtools can do that automatically)
Another option (just trying to be fair) is if you’re using UE5 - there is an experimental Plugin called “Light Weight Instances” which can also do it, but requires a bit more work to set up.
hmm. i tried making an instance but no dice. still quite slow.
3.07 seconds for an actor
3.01 seconds for actor instance.
on the other hand a pawn was quite a bit faster, at only 2.3 seconds. ill see if i can use a pawn for my use case. i wonder if there’s an even more cut down actor tho… hmm
ah i see. thank you.
yeah this is indeed a method that could possibly work. it would just be extremely complex to retrofit my current system to work with it if i went this route.
i was hoping to get distinct (but very cheap) actors out of so i could work with them individually.
Alter them using SetCustomDataValue on the mesh instead of using different materials or changing parameters, if you use only one material it would be much more efficient when you have many instances.
If they are all the same, and the player never sees more than 1000 at a time, then you don’t need more than 1000. Just play around with their location /and visibility/ to create the illusion that there are more than 1000. You can bake them in the level to avoid spawning them at runtime. Why would the hitboxes need to be spawned at runtime? When you move the actor, its hitbox component moves with it (provided it’s movable).
as for why they all need to spawn at the same time, its because the user may want to access all of them at once (all 20,000 for example), so im not totally sure how i could fake it
answer is instanced static mesh component (or hierarchical one)
for collision, you can use the get instances overlapping box to get the overlap data. i was able to spawn about 50,000 meshes in a quarter of a second, so very performant.
you can also view them all at once with no loss of performance as well.
probably the largest detriment is actually managing the sudo actor data attached to them. no physics as well, but that was sorta a given.
