0
\$\begingroup\$
var key = thisKv.Key;
                foreach (var thisValue in thisKv.Value)
                {
                    GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
                    cube.transform.parent = emptygameobject.transform;
                    var renderer = cube.GetComponent<MeshRenderer>();
                    renderer.material = textMaterial;
                    cube.transform.position = new Vector3(-thisValue.Y, 0, thisValue.X);
                }

thisKv.Value Value contain over 700000 And then when it's creating the cubes:

GameObject cube = GameObject.CreatePrimitive(PrimitiveType.Cube);

And make the loop very fast my memory usage of the pc get to 91% and more and i need to shut down the unity editor.

Is there any other way to handle so much cubes ?

\$\endgroup\$
  • 2
    \$\begingroup\$ Question 1) Why do you need so many cubes? What game function do they serve? There might be more efficient ways to serve that function. Question 2) Why a key-value structure for something so huge that you appear to be iterating non-randomly anyway? \$\endgroup\$ – DMGregory Oct 7 '17 at 0:51
  • 3
    \$\begingroup\$ You're trying to make a voxel landscape (like Minecraft) but you're trying to treat each block as its own entity, which is not needed. Blocks should just be a compact data structure from which you build a surface mesh. \$\endgroup\$ – Draco18s Oct 7 '17 at 3:55
  • \$\begingroup\$ There is a reason Minecraft doesn't use a stock game engine. The game is doing something very unusual. Stock game engines aren't optimized for that. \$\endgroup\$ – Philipp Nov 12 '17 at 11:21
1
\$\begingroup\$

You should definitely not create a separate entity for each block in the terrain. Entities have a huge overhead in terms of memory. Instead, use something more compact, like a bunch of bytes, shorts or integers (depending on how many types of blocks you have, you could also use a struct if you need to keep some additional data) in a multi dimensional array (or a single dimensional one if you really need to save memory).

So, you'd basically have chunk objects, each containing an array of values. From here you can go in 2 different directions.

  • If the chunks don't change that much, then you should generate a single mesh out of the cubes where you remove the invisible faces and you only need to update this mesh if the blocks change.
  • If the chunks change frequently, then you should use instancing to render the cubes. This way you don't need to change a mesh every time the blocks change. You should try to avoid rendering invisible cubes and possibly faces, but the latter one wouldn't help too much over the former if the terrain's mostly solid.

If you did all that, but you still hit the memory cap (I doubt it though), then try a different method instead. Create a 3d texture containing the terrain information and render it using a geometry shader. This way you only use the VRAM instead of the RAM, but it's going to be slower to update the terrain.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.