koobas.hobune.stream
Quickest most efficient way of instantiating a large amount of GameObjects
I'm looking for suggestions for the quickest and most efficient way of instantiating GameObjects at runtime, I'm procedurally generating a terrain on which I'm casting thousands of rays to the surface to check each hit position meets the spawning requirements ( can this be done more efficiently, baring in mind my terrain is spherical )
On each cast I establish whether the ground meets requirements ( in this case I check that the nearest hit vertex is coloured red ) and then instantiate my GameObject.
Currently this process causes the frame rate to drop to ~2FPS for a few frames, can this be done more efficiently?
In my specific case would I be better off iterating the verts on my terrain than leveraging the physics engine?
if you are doing a procedural terrain, instantiating is inherently slow as it takes an entire frame, it has to add lots of new details to memory every time etc. It's much faster to have many copies of your base procedural object somewhere miles out of range, and move it into place and change objects when you need them. so if you did a flat terrain, you would be going slower by instantiating every part, then by having say 144 chunks in the game and some of them marked in view and some of them as movable,
Also, the size of the mesh seems to have a disproportional impact on the slowdown, any meshes like 16x16/32x32 run really fast.
Also you should be looking at using yield as much as possible, you shouldn't use recalculate normals, you should do the normals based on invisible points just next to your vertices and then get their crossproduct if you can figure out which way they point etc. Like that it looks a lot better and you have more control over the normals calculation timing.
You can look around on the unity forums for a function queueing script, a task list queueing script, and yield command is very useful also,
for calculating the shape of your terrain, you can do that in between frames at different times from the mesh editing code , and you can do some simple processing on a different thread if the procedural code is simple or maybe even using arrays to read.
another problem you will find is Colliders, they take a long time and you should ideally only generator Collider for meshes that you are next to.
disable any scripts on terrain objects that use an update function, or just disable and enable scripts from the master script control as much as possible to keep it light and to lighten the memory.
That's about as many tweaks as I know for doing fast procedural terrain.
@ZoomDomain really appreciate that information, although I think my question wasn't worded very well, I've actually managed to generate the terrain fairly quickly, what I'm struggling with is tree and foliage instantiation. Would you still recommend having the objects preloaded and available "off screen"? I was also interested in the the separate thread idea, were you recommending arrays to managed by a different thread?
@ZoomDomain That method of calculating the normals was very interesting please could you also expand on it. How would you go about creating those "invisible points" would using the vertex positions and just offsetting them work?
