For a script, I need to detect whether I have modified any of the curves I have referenced in the Rhino document.
There appears to be a data item that is added to the GUID in between parenthesis that updates as soon as I move control points of a curve or the endpoints of a line. This thus tells me that the geometry is updated. However, how do I access this piece of information in Grasshopper? And what does the data represent?
Hi @Intuos ,
There may be a much easier way, and I don’t have time at the moment to finish the script but here’s a method of exploiting the _what command and then using text matching to return the number you seek.
This could be done in a single script, hopefully I can update that later.
Graph Space:
Example:
20230816_Get_Object_GUID_Secondary_Number_What_Command_01a.gh (13.5 KB)
Interesting, I’ll take a look, thanks!
What also appears to work is to just compute curve length to see changes (i.e. change of angle for a line in a road network). If I move a spline CV ever so slightly (0,0001mm), I can still detect length changes to the entire curve or the curve network.
Basically the same principle as posted earlier with a datadam set to 0,25s delay and compare values before and after:
True, but this would return true if you just moved the whole curve in the Z direction.
Unless that’s okay?
No it does not, the length remains the same if I move a curve up. The length method does not give me access to which curves changed if I move them around. The GUID data in parenthesis (the hash?), however, does change if you transform curves.
So it is either a length evaluation paired with a midpoint evaluation (which should be rather performant) or a test for the GUID data between parenthesis (which may or may not be reliable).
I see, interesting. Parden the question but is logic being created to try and get around a baking conflict or intended for a specific “only bake if this operation happened” kind of workflow?
I only ask in case there’s a separate baking issue that could be solved easier? I think maybe we looked at this in some separate posts and you had a use case for the custom logic. Just checking if that was the case here as well.
Thanks!
One line of code ?
(three, actually).
private void RunScript(object x, ref object A)
{
i++;
A = i;
}
// <Custom additional code>
private int i = 0;
DetectChanges.gh (4.5 KB)
I have made a street network composed of centrelines and offset the streets based on attribute values. Now, I want to create a procedural fillet by assigning a radius value to the corners where the streets intersect (which is at the discontinuities) To specify the radius of the corners, I plan to bake the discontinuous points so that I can add a radius attribute for the fillet. That way, I get an interactive road network tool.
Here is the proof of concept:
The most difficult part right now is to try to match the baked points with the points in Grasshopper, say I want to move a street. Right now, all my points get reset, because I haven’t worked on this yet.
Will split it off into a separate topic once I get to the matching work.
You’re doing a very similar operation to what I was showing with my doors in a few topics ago where we are both after point in Rhino acting as “control handles” and then user data influencing things locally per “control handle instance”
Currently, if you have those points referenced into GH, change the user data and then move said control points (like a street intersection) does it reset the user data and thus reset your radiuses? Is that your issue?
Or do you mean you have intersection “corners” linked to each intersection “network node” so if you move a network node the intersection “filleted corners” lose their data/don’t move with the network node?
This is a native Grasshopper solution to detect changes to geometry. This script also shows which curve was changed since the last bake. For curves, length, start and endpoints suffice. For Breps, surfaces or blocks, you may want to include attributes for bounding box values, volume and centre of mass.
Leveraging the User Data is an interesting way to go about it. Thanks for sharing!
Just a suggestion but if you are going “native” might as well use a gh boolean data container instead of the Pufferfish inverted bool component. No need to load Pufferfish for that. (Though you may very well be using pufferfish extensively in your larger definition and if that’s the case who cares)
Also added a python script in there that creates a null value for the 2nd part of your script.
Feel free to keep or toss, sharing here in case you find it useful!
Cheers!
20230817_Bake modified curve attributes_MV_Modified_01a.gh (12.0 KB)
Yeah, I’m using Pufferfish extensively for other things anyways, didn’t even notice that the component was a Pufferfish component.
I’ll likely keep sharing any tips or tricks as I come across them (and make a topic for each). There are still several interesting problems left to solve and thinker with.
I certainly appreciate that! And I’ll share anything I find as relevant as well
@michaelvollrath Here’s a way to both detect curve changes and update the User text with the new curve properties.
This is the most compact way I can get the attribute matching and replacing, what you need to do is first filter for the geometry you want to update and then supply the attribute keys that you want to update through your Grasshopper script.
20230822_Bake modified curve attributes.gh (22.2 KB)
As of the release, these methods of detecting changes no longer work the same way as the User Text component no longer synchronises changes. Therefore, I have created an alternative method, see: Detect user text changes to trigger content cache - #3 by Intuos.