koobas.hobune.stream
Instantiating thousands on start (loading custom levels)
Is there any alternative to having to instantiate every object when "loading" a user made level? Having to instantiate a lot, especially on mobile causes the game to get slower and slower. So is there any way to do this? how does unity load its scene without slowing the game down (after it loaded)
Are you loading the objects on courotines? If so, and still feeling the lag, have you considered a loading bar?
Doesnt matter if coroutines , if you instantiate a lot, every time you instantiate the game becomes slower , as the Instantiating takes up more and more memory, so loading bars wont help
What I meant is, for example. To create a coroutine that instantes a number of objects at a time, and waits for a moment, then does it again, until all objects are in the scene. If your problem is that having all your objects in the scene is too laggy, then that means your objects are consu$$anonymous$$g too much data for the actions you are attempting.
Other than your own customized optimizations, your best bet really is Object Pooling.
https://unity3d.com/learn/tutorials/topics/scripting/object-pooling
The basic idea being that you create these hundreds of objects on awake, and reuse and recycle them depending on your needs.
Object pooling every single possible prefab a user may put in the scene is worse than instantiating like 100 objects at start, because we are talking about a level editor not commonly used projectiles. Having like 10 available objects for like 100 prefabs would mean having 1000 objects in the scene rather than instantiating just 100
Hello PixelSpartan, I like the name. Now to business, you say:
"if you instantiate a lot, every time you instantiate the game becomes slower , as the Instantiating takes up more and more memory".
However, that should not really be the case, and just to be sure let's make sure we are on the same page.
For starters, are you experiencing poor frame rate or the fact that loading is simply taking too long? Instantiating objects may cause an obvious hiccup in gameplay, especially on mobile, but once the object is instantiated it should not be the case that the game remains running slow due to memory. However, could it be that you are having FPS issues (for example bringing in 1000 objects and then trying to draw the vast majority of them without proper batching)?
If you are having issues with long loading times, as stated by RobAnthem you, could use a coroutine to help load additional objects after the scene transition. For example, loading the main pieces of a scene behind a loading screen for a few seconds, and then getting the player in the game while continuing to load objects via coroutines after they are in and playing. With this approach your player might see some popping in of the new objects, and depending on how many objects it may still slow your game too much, but it is a solution that works for some people.
On the other hand, if the game remains slow, I suspect you may have an FPS issue. Take a look at your set pass calls and if you see them up over a couple hundred and are targeting low end mobile, this may be your issue. The first step here would be to look into static/dynamic batching. Another possibility is that you are using shaders that are too performance intensive on mobile, which could also severely degrade your FPS. Lastly, depending on what these objects are doing, it could be possible that you are generating a lot of garbage via scripts. The constant garbage collection could also degrade performance, and you can take a look at profiling on device to see which areas to best optimize.
In general, having a lot of objects in memory SHOULD NOT cause your game to be slow. I have been a part of mobile games with several thousands of objects in them and pushing the memory limits, while still maintaining a solid FPS on older mobile devices (iPad2, iPhone4, Samsung Galaxy Tablets, etc) by following those rules outlined above.
Well i guess using up memory when creating many objects is expected and cant be avoided
This is correct, but typically the objects themselves are very small and having thousands of them, even on mobile, is not a concern. However, depending on the assets these objects use (textures, audio clips, animation, etc), that is typically where the memory begins to bloat out and cause out of memory and crashing issues.
Im talking about instantiating a lot of objects and then the framerate remaining low. And the more levels you load over time the game goes slower and slower
And i try as much to batch everything so its not that and i dont really care about load time
My guess is that the more objects you make the more memory it takes up, so it lags as it struggles to find memory to run well
Probably bad GC, maybe i can try GC.Collect(); and see if it helps
GC.Collect() is highly advised against unless you have very good reasons, I don't see much that would end up in the GC from the instantiations, because the objects should all be loaded into the stack, and have no reason to be in the heap unless destroyed.
GC issues would come down to your own custom code, not those instantiations. If the poor framerate was due to constant GC collections, you could verify this by profiling, or even disabling all the scripts you can and see if it helps.
I would really take a look at the set pass calls if experiencing constant low FPS, as it is typically the #1 mobile issue. I would highly advise to profile on device, as right away you will be able to see what is wrong.
You are correct in that the more objects you create, especially if they are complex objects, it will require more memory. However, this will not typically cause your game to have poor framerate, ins$$anonymous$$d what will happen (in the case of iOS) is that you will get a "$$anonymous$$emory Pressure" warning from the OS and then eventually your game will crash as it runs out of memory.
