What is the most efficient way to spawn in a lot of cubes, like 10k? [c#]
Ok, so i've been testing to spawn in a lot of cubes, in a grid way(50x50 or 100x100) but the issue is that it freezes the Unity Editor for a long time, when i spawn in a huge amount of cubes. At the moment im using the primitive cubes that Unity comes with, and i spawn them in one time, all of them at the start.
Im wondering is there any better ways to instantiate cubes in a huge amount? Like should i instantiate small chunks until it reaches the goal of amount of tiles i want?
So if im able to fix the first issue, and im able to make a huge grid of cubes in faster way, then im think im gonna have two new issues.
First one is that if i were able to do 200x200 then it would mean 40000 cubes/object to check for in a loop. How would i be able to loop through so many objects, without big performance issues?
Then the other one is the graphical part, where 200x200 cubes would may lag the game, fps wise.
Update: Below is a 75x75 grid of cubes, every tile here is one cube, and all the cubes will be viewed from above, so i've would want to achieve something like this, but cheaper, faster and pleasant for the computer
As i said, i would want to make a grid of cubes. Since im atm working on making a procedual map generator.
But why do they need to be individual cubes? Is there a possibility of seeing all 6 sides of every cube?
Answer by CausticLasagne · Aug 16, 2016 at 06:21 PM
It depends on what you're using them for. I've tried doing this for a minecraft type game, and it does not work.
I used a loop to create the level and it didn't work very well. I have a game in development that uses lots of cubes as a core game mechanic, and I use Occlusion to hide the cubes not visible to the camera.
Spawning lots of cubes with Rigidbodies will fry your computer. if you want to mass spawn cubes, the less components assigned to them, the better. I'd even make them static to lower the memory.
If I knew more about what you're trying to achieve, I can help you more.
Causticlasagne.
I wrote that i want a grid of cubes, so here is more info of the process of creating them.So i start off by making a noise map, then take the noise map and make the properties for the cube, then i instantiate the cube with it's properties. I take the noise map once, and then make a for-loop and generate all the cubes i want.
It takes like 1 second to just create all 100x100 objects alone, but it's the creating the and visualizing the cubes that create lag and freezing the computer.
I've looked at Task $$anonymous$$anager when it freeze and it doesn't consume all CPU or the $$anonymous$$emory
Well either way, even if you want a grid of cubes, and the player is looking at them right? You should only be drawing 3 surfaces at a time. And if you're making a terrain generator out of cubes similar to $$anonymous$$ecraft, you want to cull faces that are not visible to the player. Doug has the right idea. Though I've seen an example where a group of faces are chunked into a single mesh and each mesh is then generated. It's still single cubes, you just need to remove a cube from the mesh. The only issue that is causing the lagg is the rendering of each face on the cube. If you are only drawing 3 faces on each cube + only the faces that are visible, then you'll be able to make more cubes/chunks.
CausticLasagne
So you are making a terrain. Okay. For this you'll need to group some cubes into a mesh, say 8x8 cubes, to form a chunk. This chunk will have it's own collider. On your chunk prefab, you'll need to create a script indexing the cubes that are present and their material id's.... and so on. The tricky part is syncing each chunk so you have a nice even terrain. I'm not personally working on a project like this at the moment, though I can point you in the right direction. Look at this package for info about chunking. Import the project and mess around with some settings.
There is also some fun stuff happening at Volumes of Fun, and they're experimenting with The $$anonymous$$arching Cubes Algorithm, which I'm not sure is up your alley.
Take a look at some of these things to get a hint on which direction to go, but they all use the crap I'm going on about. Be aware that it does require some understanding of mathematics to make a good cube based game, and with marching cubes involved...... That's why I gave up.
I hope I've pointed you in the right direction.
CausticLasagne
Answer by DougMcFarlane · Aug 16, 2016 at 08:09 PM
For simple cubes, creating dynamic vertices and triangles would be the quickest, and require the least resources. It would be faster to render too. You should chunk together multiple cubes into multiple game objects, Minecraft style. Having them all as one model containing every cube may start to push the limits.
Chunking would be your best bet, but testing to find the best chunk size would be needed. A 8 x 8 x 8 cube object sounds like a good start. Chunking would allow for occlusion, so it wouldn't have to draw every cube every frame. If you need each cube to have a collider, you can add multiple cube colliders to the game object to make a larger compound collider.
You could still color each cube differently if you use vertex colors in you shader. You could use arrays to hold each cube's attributes (color, size, visible, etc) and have a routine to regenerate a new chunk if any of the cube data changes.
I had assumed literally the OP wanted individual cubes, each separated by a certain distance. $$anonymous$$nowing you are trying to replicate $$anonymous$$inecraft style graphics, this is a bit different. You would still create vertices and faces per cube, but can eli$$anonymous$$ate any faces not exposed. Especially for cubes that are completely surrounded which would have no faces.
I don't understand what the OP wants exactly. Sure he wants 10k cubes, but what for? Terrain Gen? Shits and giggles? If these cubes are rendered on a camera, then only 3 faces need to be visible, and also the faces that are obscured by other cubes.
If you would check out the update up there, you might understand what type of graphics style im trying to achieve, and i what you wrote, what i've understand i would make a chunk that has it's own created mesh(Procedual ofc) and then somewhat link them up?