The text conversion that GH does is used to represent the object in a human-understandable way, not to define the state of the object in string type, so you are not getting the state of the object in text but a representation. Even for simple types like point or vector that GH can create them from text you lose some information in decimals since the conversion to string is designed to be a human-friendly representation so its may ignore some decimals.
On the other hand, if you look at the text representation in GH of a plane, the format used is point and normal, and so you can’t recover the original plane as you have 360 degrees of freedom to place the other axes.
You have to make your own format and conversion method.
I used to save plane information of a block as key/value data. My first approach was to save the whole string output but I ended up deconstructing the plane info into origin, X, Y and Z vectors and save those as individual values.
@Dani_Abalde Thanks for the explanation. That makes total sense actually that it doesn’t sufficiently describe a plane. I will create my own format, probably just going straight for a transformation matrix.
@andheum cool idea to convert to json format. Took me a while to figure out JSwan and that you have to zoom in to add an input. I have not seen that in any other plugin - maybe you could add a small gif of that in food4rhino. You only show the deserializing part, but not the serializing.
@Joseph_Oster thanks for the super quick way of doing it. I will add some IDs and make sure it’s all in one line per plane for a text file. Right now it would just flatten everything into lines, so you would have 3 lines per plane. So to better simulate what will happen you would have to flatten the text output and then reconstruct from there. But I will do that part.
I just disabled it, but it seems just as slow. A lot of things you don’t realise are slow until you really crank the numbers. I will post a separate issue as to why ScaleNU is so much slower than Scale (factor 20x). Understanding these things is the first step in working around it.
Here is a version that includes the original data tree paths as IDs, flattens the “text file” (yellow group), then reconstructs the original data tree. The bottlenecks here are Construct Plane(17.5 secs.) and Replace Paths(6.3 secs.).
@Joseph_Oster I noticed the same actually, in most cases of very slow components with lots of data it is because of the type conversion. Thanks for verifying this on your end as well. Such a shame that it is that slow and kind of not understandable. I use the same kind of datasets in other tools like vvvv and if you convert from string to number there it barely makes a dent in the 60fps it normally runs at.
@Dani_Abalde wait, I am confused now. That is what Andrew shows in his screenshot though!? I want to convert the JSON string into an object again of datatype plane.
So I just gave it a go with actually writing and then reading a JSON file and it doesn’t seem to want to work.
In the documentation it says you can just plug a path to a .json file into the deserializer. But it always says “no valid JSON properties found”, even though the file literally just contains the same output as what the serializer outputs.
So from what I gather the Deserialise compontent of jSwan just splits the JSON data into its groups, but does no data type conversion the way the serializer does!? Just trying to wrap my head around what jSwan does and does not do.
JSwan supports a file path as input — it will read it in. The problem is that you’re not writing a valid json file — you’re writing a bunch of individually valid JSON files into one file (without grouping them). This is valid:
but this is not:
To remedy this, right click the “planes” input to your Construct JSON component and set it to “list access” instead of “item access” so that it will produce a single valid JSON from your list.