I am trying to build up a history of changes that occur to geometries (position of points, over time).
Such changes can be either made by GH or manually by an user over their baked instance (this is currently handled by two definitions used in pair).
One strategy could be to have some data saved globally which is accessible from all the components which have to ‘append’ events as they occur (position of a point instance changes). This needs to write a txt file somewhere on the disk and compare it with what is in GH everytime the solution expires (not really handy).
So, I was looking at this discussion, but I might want to re-consider it as it could not be my case.
Otherwise, data could be stored along with each point, and eventually updated if a change occurs. However, when GH makes changes to the position of a point, this typically is done with any standard GH component (e.g. ‘move’). So, creating a Point_With_History_Goo : GH_Goo<Point_with_History> might(?) not be ideal.
Something tells me that the first approach should be more rigorous, probably due to its ‘global’ nature, but it’s just an idea.
I think you underestimate the complexity of such feature. Not every geometrical object is passed by reference when going downstream. Many objects are copied, especially structs like Point3d, Vector3d or Line objects.
Monitoring each component and saving, does not only create lots of data, it would also be difficult to reinstate later on. What is your actual question? Is feasible? I would rather say no (…at least for average scripters). I don’t even understand what this would be good for, and why normal saving is not an option to you? Can you describe the problem you have?
A while ago I asked if transformations are stored in the data tree. The answer was “NO” data tree is nothing but lists.
If by extracting objects from the data tree you’re also able to extract their transformations from the branch they are on this could be very useful. I don’t see why it should not be feasible. It will be like bundling two or three data trees each carrying different things (eg. one objects, second transformations, third “string notes”)
@TomTom , I was expecting an answer like this one. The ‘local’ option was indeed planned to carry on IDs with the geometries to then reference to them. I am not sure of the persistance of GUID throughout the pipeline - indeed, if they are copied and not referenced, I guess they vary throughout.
The problem: A set of points are distributed along a curve accordingly to some design guidelines. There is some optimisation running under the hood which establish their position. However, to end-user (designers) it should be clear which design guide has been applied where (here the GH-dependent transformation) and if the user wants to change the position (optimisation is not perfect, indeed), the transformation has to be registered too.
@ivelin.peychev , accordingly to what you say, I thought of a ‘quick fix’, which is to stream in parallel with the geometry a JSON (as a string to load and dump at any step in the pipeline a change might occur, and eventually change it). But again, how would you compare it with the previous state? Here, it can be possible to compare it to a JSON (containing all the JSONs streamed for the points) saved to the disk and eventually update the one that changes, but… I don’t find it really efficient, nor clever.
My bet is on “Transformation matrix” you can put that in the JSON.
You have one object, then you have the same object scaled/translated/rotated, the difference between them is the transformation matrix.
If you have point then transformation (move), then you have 2nd point, if you wanna create a line between them. In the data tree (json) the line should bring along the first point and its transformation.
I’m really unsure I understand the complexity of your problem or why it would need a complex solution. This suggestion may be totally useless. But couldn’t you just store that data in the geometry’s key/params attributes?
I think you should just save the parameters of your “optimisation”, and save the change of the user.
Optimization is deterministic. So when feeding in the same parameters you’ll always get the same result.
Saving how the user modifies the output can be done by retrieving the change after the optimization.
This can be done with transformation matrices,yes, however transforming points with them is a bit of a overkill. Just safe the new coordinates…
“Json” is just a data format such as Xml. You could also safe the tform in a simple textfile. 16 numbers plus one identifier. That’s it. Still, this all sounds a bit too generic to give you better answers.
