koobas.hobune.stream
Instantiate problem for game editor
God day.
I have a big problem with the instantiate frame drop. I'm working on a game editor in which the player can place as many objects as he want on a 2D grid. The problem is, after placing 50 or more objects, the frame rate begins to drop. So far as I understood, that drop is caused through the Instantiating of objects.
On the internet, I found a solution with an object pool, but the problem is, that I have a huge grid with 256 x 256 placing points, so that the player could place up to 65536 individual objects. When I consider that there are many different objects which can be placed, I would need an object pool, that contains 65536 x (placeable object count) objects at the start.
I already tested it with placing 65536 objects inside the unity editor. Thanks to dynamic batching, the framerate is stable.
My question at you is: Is there a way to add objects to the grid without frame drop and without overloading the RAM at the start?
That's a lot of objects you are allowing players to create, what's the idea behind this game/application?
You might find there is another way to do what you want that avoids this problem.
Well that whole project is a maze game, in which you can create your own maze with predefined parts. Perhaps 256x256 is to big, but the problem is actually not the size, but that the framerate drops after only 50 placed object...
I'm actually trying with a object pool, but only with one object. This object gets edited (Replace mesh, meshrenderer and collision object) and then placed. I hope that that works better...
Hopefully that will help!
As an alternative, how about letting the player 'draw' the maze they want rather than placing the objects themselves? so effectively let them draw lines that would represent a wall.
Then once it has finished you could have a 'Build!' button and it will build it (maybe behind some loading screen or something).
Is the frame rate drop due to the amount of objects on the screen or does it happen only when you instantiate each object? i.e. frame drops for a few seconds and then returns to normal.
The problem here is the same. The objects gets added at runtime, so it makes no different why and when they are added. Only exception, when you add them directly at the start of the game.
So far as I understood, the problem is only caused through adding objects during playtime. The adding process does something with the ram, that causes a longtime lag.
Smal update from me... After I tried many different ways to place objects during the game, I did not find anything.
What I have tried: - Instantiate empties at start() and give them all needed components, so that I later can easy replace the components of those empties. (To reserve ram space and prevent heavy ram management) - Instantiate finished objects to replace they'r mesh and components with the needed objects (same reason as above) - Directly place objects without object pool
All those ways didn't work, always I had the same behavior. After the first few placed objects, the cpu time starts to decrease, after ± 50 objects, the cpu time is at 0.2ms (before ±10.5ms)... It stays there for ever. If this is really a problem with the ram access from unity, then it i a bug. I have no other explanation. Short time drops can be possible, because of ram access, but not that long.
If somebody has an idea, what could be the problem, please post it, else I will send a bug report.
Greetings Chillersanim
A technique used in world editors is pretty similar to the way Google Maps works: you only store in memory the objects currently visible.
So imagine you want to scale your application to 1,024x1,024 = 1,048,576 objects. There's no way Unity (or other engine for that matter) will be able to handle that amount of objects.
The tricky partt is when you start at the zoom out level, because you need to show an overview of the map. For this you should store a low-resolution image of the map, generated either on loading time, or when you save the map back to disk.
There's no way an user can edit the map while at the zoom out level. Check for example Curiosity, which deals with billions of objects, and don't let you edit them at the zoom out level, only when you zoom in.
When you zoom in, what you need to do is serialize and destroy the objects not currently visible, so you can load them back later from disk. Pretty similar to the way any modern carthographic map viewer works.
Thanks, for bigger mazes would that be a possibility. But it isn't exactly the solution to my problem, because I've my problems with the instantiating of objects. The amount didn't affect the fps, I already tested it.
