I have a Grasshopper file, running on shapediver, that imports a Partfile and places spheres on its surface. The number of spheres I place depends on the model.
My intention was to allow the user to manipulate these spheres by dragging them individually. However, since all the spheres are created using one component, they are selectable as a group rather than individually. Additionally, because I don’t know in advance how many spheres there will be, I can’t use a Python script to copy a single sphere object multiple times, as this would violate the Shapediver Rules (as stated in the documentation: https://help.shapediver.com/doc/forbidden-grasshopper-functionalities). (right?)
I tried using the “Disjoint Mesh” component, but the behavior was indifferent to the output without this component.
Are there any clever ways to enable individual selection and manipulation of the spheres, or would it be wiser to omit this functionality?
(I am using the Rhino7 Backend)
In order to use a single component but keep geometries separated in the viewer API, the ideal way is to using name attributes to influence the scene tree, as described here.
The different nodes in the scene tree can then be accessed individually. We will soon add a more detailed and comprehensive example of the use case you are mentioning, I will post it here when it is ready.
Now I have the feeling that I already started the wrong way.
Since the points are created by some Grasshopper component, won’t the user input have no impact at all because the position is immediately reset to the original position?
Do I need to implement those handles in a different way?
Thanks!
To allow for an interaction, I think I have to use the in- and output blocks.
Is that right? → How do you render the points then?
I’ve seen that I can define the size of a sphere, which will be rendered around a point - but then I would need to inject the points from the UI, and not from the Grasshopper-file, because else the points wouldn’t be moved when dragged, right?
In the codepen / gh file you referenced above, it is set up in the following way:
The definition has a text input containing a list of point locations.
The definition has a geometry output for sphere display, which are kept separate for the API so that each sphere can be selected and dragged individually.
Using the API (this example uses v2 but the setup will be similar in v3), you can make the spheres draggable. When you drag the spheres, events give you information about the point where dragging started and ended. Using the location of the sphere at the end of the dragging operation, you can then send a new value for the text input containing the list of point locations, including the new location for the sphere that was dragged. The model then recomputes and automatically updates the positions of spheres to match the new configuration.
I will discuss with the team how to adapt the example you posted to v3 of the viewer, in order to provide a full updated use case.
