Target Parameter Copy&Paste

[georglobe]

In Grasshopper it seems that it is not possible to internalize Targets in a Target-parameter and copy it to another document.
Might need a little tweaking with the override Read/Write methods?

Is there a chance this will be addressed in future releases?

[visose]

Hi, the problem is more related to how to deal with the properties of a target that are reference types and where the same property value, like a tool, can be referenced by multiple targets. In part is a general problem with serializing an object graph that is not a simple tree structure, but there are other issues like how to handle geometry indirectly referenced from the Rhino document.

For example, you have a list of targets, they all reference the same tool, this tool references a mesh that is referenced from a Rhino document.
The most naive way to handle this could be, for each target, it internalizes the tool, which internalizes the referenced mesh. This causes each target to have a unique duplicate of the tool with a duplicate of the mesh. Not very efficient, and if you change the tool of one of the targets, the others will not change, so the behavior is also different than before internalizing.

[visose]

The best solution might be to not allow to internalize individual Targets, but to change the Toolpath type so that its not just a list of Targets, but serializes/deserializes this object graph properly.

[georglobe]

I like the idea of having Toolpaths grouping the targets by Tool (ordered) , which in turn would make it easier to serialize and have more structure/overview.

For single targets I agree, that it is too much data to store every time.

Another thing - why serialize the Tool assigned to a Target?
As long as robots is installed the Tools and Robotslibraries are defined, a reference to the name of the Tool might be sufficient as we can, on de-serialization, load the tool once it occurs and store it in memory then apply it to all the next Targets that contain the same Toolname.

The same thing for referenced Rhino geometry - as native GH handles it - reference by Guid and if its found its there, if not - not

I might have time next week to have a look at the Toolpaths and Targets to further understand the issue completely and will try to implement some serialization.

ps. I might just use Robots wrong or not to its full extent :)

[visose]

having Toolpaths grouping the targets by Tool (ordered)

Besides the tool there are other attributes like Frame, Speed, etc, that can be shared among targets, so you can't exclusively group targets by one attribute. Also the same tool could be assigned to different targets in non-sequential order.

why serialize the Tool assigned to a Target?

If you don't serialize it, on deserialization the tool would either be null or changed to the default tool which would not be what a user expect.

What you mention about storing the name (or some other reference like a Guid) so that on deserialization it can figure out how to reconstruct the object graph is what I proposed above with the Toolpath serialization, but this cannot be done by only serializing individual Target objects.

[visose]

To explain better the last point, serializing individual targets to include only the reference's id would only work if it is expected that it will be deserialized in a context where those references are available.
This specially won't work if you internalize a target and copy it to a different Grasshopper document.
But it would also not work on the same document (what you have in mind), since references are added to targets through wires connected between components. Even if in the same Grasshopper canvas there is a component outputing a tool, an internalized target will not know that this tool exists if no wire is going from the tool to the target in some way.