koobas.hobune.stream
400 Scriptable objects per 1 datastructure = overkill. Halp plz
Hello everyone!
I have a kd-tree datastructure.
The leaf nodes are used to store items. Items hold: a vector position and 4 references to other similar items.
Kd-tree nodes are also referencing each other (parent-child relationship).
To keep those references, each node of my tree is a scriptable object and gets saved as an asset onto the disk.
The items the leaf nodes hold are also scriptable objects and are also saved as assets.
However, just to store 50 items like that, I need to create ~200 tree nodes (200 scriptable objects).
This comes down to about 400KB of size just for the tree. But I need to store information about 50 000 items, which would rocket up to Gigabytes of data.
So, creating a scriptable object to store information in 2 fields and keep a few references seems an overkill. 1 scriptable object =2-3kb of data.
.
..Please save me, what are my alternatives?
Is any one node of the tree referenced from more than one spot of the tree? If not, then you don't need true references which unity implements with scriptable objects. Simple classes marked as [Serializable] will do. Their serialization is embedded "in place". Sorry if the question is stupid, I'm not very familiar with kd trees.
yep, every node holds a link to the parent node. The child node can have it's own children, which requires references as well :( Sort of like Linked List, but every element holds references to 2 elements at once, not 1 like a List does
if you are interested about learning trees, you can check out my tutorial https://www.youtube.com/watch?v=TwZH-aoSzJk
No, my question was not whether one node references many, but whether any one node is referenced from more than one non-parent. That's almost exactly the reverse. But you've got your question answered anyway by @Baste. He replied exactly with what I've been trying to clarify but was faster:)
@IgorAherne Here is another thing to keep in $$anonymous$$d if you go for Unity's serialisation:
http://answers.unity3d.com/questions/434489/unitys-serialization-seems-to-have-a-maximum-depth.html
Since you don't have anything more in your objects than a reference to the parent I don't think you actually need to necessarily define them as scriptable objects. So long as you keep track of the parent and the Vector3 you're good right? I think you could use a tree if you create an index that accounts for which 'branch' on the tree the Vector3 resides like this:
And then you can get the parent just by using modulus on the index:
private int GetParent(int child)
{
int numDigits = child.ToString().Length;
return child % (int)Mathf.Pow(10, numDigits - 1);
}
With this method you could store it all either in one dictionary with an int key (or long if you have a lot of children) and Vector3 values or split up the Vector3 into floats and create 4 arrays of fixed length, using corresponding indices to match up the values. Tough problem no matter how you go about it, good luck!
Thank you! This has turned me in the direction of storing all the information in dictionaries. This wouldn't be a problem with SerializationCallBackReciever.
The thing is, the tree is built once, - no insertion / delition is intended. So after its built, I can just traverse it and flush all data into a single dictionary. Values of such dictionary could be simple serializable classes (holding Vector3s and ids of other nodes in the same dictionary).
Because nodes also contain items which are also referencing other items, this might come down to several dictionaries with IDs everywhere. :D
I could then manipulate the ids to access the correct values in both dictionaries.
Thank you
Why does the nodes have to be scriptable objects?
You could implement the nodes as serializeable classes (or structs), and simply keep them in an array - ordered or unordered - in your tree scriptable object. Arrays of serializeable objects can be serialized, and that should seriously cut down on your disk space usage.
You could also store this information in your own format. Unity has a great built-in system for serializing stuff directly, without you having to write any code, but if you write your own format to read/write this data to files, you could cut the neccessary amount of data in the files by a lot. It'll take a bit of time, but might be worth it if you're storing very large amounts of information.
Yep, currently thinking about binary serializer. The problem is that all the nodes have to hold references to each other, so xml serializer won't work. They also hold references to items. Items in tern also hold references between each other
Thank you for the answer!
