koobas.hobune.stream
How do I save/restore a procedurally generated mesh in runtime in Unity 5?
I am writing a game in which I need to procedurally generate a mesh. The AssetDatabase class is available to me if this mesh is generated in the Editor and save it into the assets folder, but the meshes I am working with are specific to a specific game instance, and would be stored in the user's save game directory. How do I save the generated mesh? I don't need to save the mesh in any exchangeable format, just something Unity can read/write.
According to most posts, I'd create some kind of serializer but has Unity 5 introduced any new capabilities?
The easiest is most reliable way is to not serialize the mesh itself, but rather the data that is used be the mesh generating algorithm to generate it. This could be, for example, a 2-dimensional int array for a tile-based mesh. The array is flattened so it can be serialized, and then serialized and saved to a file. To load it, the file is loaded, deserialized, and then the array is made multidimensional again and the resulting 2-dimensional array is then used by then mesh generator to create teh mesh anew.
Here's one possible asset to save and load data:
ah, so that the saved meshes are in an alternate format and aren't coupled to a mesh format that has the potential to change as Unity evolves.
Yes. As long as the data that is serialized can be read by the mesh genereration script, it can be sued with any Unity version.
As in THIS article the trick is to create a serializable mesh class that holds all mesh parts into serializable values and as it's System.Serializable it can be serialized and written to a binary file using a BinaryFormatter.
This article you've linked has several serious problems. First of all it does not cache any of the $$anonymous$$eshs vertex attribute arrays. This will creates tons of garbage. Just to put that into perspective: If the $$anonymous$$esh has 1000 vertices, just the vertices loop alone will allocate 3000 times the vertices array. Since the array contains 1000 Vector3 values (1000 3 4 bytes == 12000 bytes). You will have 1000 times 12$$anonymous$$B. That's 12$$anonymous$$B of garbage. The two uv array loops will do the same each. The normals loop is even worse since it's 4000 times the array so 16$$anonymous$$B
Another thing is it doesn't process all mesh vertex attributes. There are in total 9 vertex attributes: boneWeights, colors, normals, tangents, uv, uv2, uv3, uv4 and vertices but the code only saves 5 of them
In addition to completely restore a $$anonymous$$esh you may want to not read the triangles array but read the individual submeshes if the mesh has submeshes (sub$$anonymous$$eshCount). Otherwise you will loose the material assignment to the individual submeshes. If it's a skinned mesh you also need to store the "bindposes" matrix array.
Finally it's better to store the vertex colors as Color32. This reduces the space for the colors by a factor of 4 (1x Color has 16bytes, 1x Color32 has 4bytes)
Note that the garbage generation grows O(n²) the way he does this. So while you generate 12$$anonymous$$B for 1000 vertices you will generate 1.2GB for an array with 10000 vertices. At 65$$anonymous$$ vertices the vertices array alone will generate 150GB+ of garbage.
Even all those allocated arrays go out of scope / extent the next loop iteration it's very possible that the GC can't cope with the pressure and you get an OutOf$$anonymous$$emory exception. Even if you don't it would run extremely slow.
