Optimizing Grid Asset Size

  • May 30, 2017 at 05:24 #20874

    Hi, my game requires me to bake and store 256 grids as assets to be loaded in at runtime. Right now the grid assets alone make up about 10 GB of the project. I have made them 64×64 grids with cell size 4, which is about as big as I can afford making them, but this didn’t seem to help reduce file size from being 128×128 w/ cell size 2.
    What can I do to minimize the amount of space taken up by my grid assets? I would experiment myself, but there are so many of them that it is very time consuming to bake them.
    Thank you!

    May 30, 2017 at 13:29 #20879

    My guess would be that you use height maps for height navigation. If your terrain is uneven, that takes up a ton of space compared to anything else, even if you use the quad tree storage mode.

    So if you can afford a little extra cpu load you can save a ton of memory by setting the height navigation to raycasting (Navigation Settings Component).

    July 17, 2017 at 12:57 #21413
    Kirill Pervushyn

    Hello guys.

    We are making semi-procedural strategy game. Worlds are going to be quite big.

    1) How much space will take pre-baked grids for 50 2x2km worlds? Cell size can be rather big for strategy, but if it still will take 10 GB, we’d rather think of baking grids at player’s computer.

    2) Is there a way to move grid with a chunk of mesh/terrain at player’s computer? I know you tested this and rejected, but maybe there is hidden class for this?
    If so we could bake 30-50 grids for small chunks and shuffle them. Although… this would require portals to be assigned, and this can only be done in design time, right?

    3) We’ve noticed strange thing:
    – 2048*2048 terrain with Y*Y cells of size S takes about 80 seconds to bake
    – 512*512 terrain with Y*Y cells of size S/2 takes 8 seconds to bake
    Same amount of cells on the same terrain takes different time to bake if we scale down both terrain and cell sizes.
    You basically say: make your game 10 times smaller, and your grids will bake faster (and maybe their initialization and volume on HDD will go down as well).
    Can you comment this point?
    Cause we actually are at the prototype phase, where we can actually make 10 times smaller game. If Unity will have some inaccuracies with physics, I think, we can handle them (this a strategy – no precise physics needed).
    But I expect that something is wrong here – most likely I misinterpretated something.

    4) If we replace terrain with mesh (much less polygons) it doesn’t seem to fasten baking. Is that so?
    We conducted to few tests to be sure.

    Thanks in advance.

    August 1, 2017 at 13:31 #21588


    1. I can’t tell you that as it depends on settings, height diversity etc., so you will have to test it yourself.

    2. I don’t quite understand your question, but portals can be created/activated at run time.

    3. The only thing that will impact baked grid size given the same amount of cells, is the height map granularity. So if you keep a default granularity of 0.1 while doubling your cell size the result is that the baked data gets bigger.

    4. Grid generation is based on raycasts, not voxelization like a Nav Mesh, so the complexity of the mesh has no impact.

You must be logged in to reply to this topic.