Complicated trimmed surface and use of attractor curve on edges

Hi,

I’ve been trying to use a series of three attractor curves on the outline of a trimmed surface to create a sharp dip down then a slow return back to the original surface height on several edges. The attractor curves seem to be working but the surface from points isn’t working from this trimmed surface.

After a bit of research ( Understanding trimmed surfaces, Surface from points - null point in grid ) I have come to realise this is not working because I am working from trimmed surface. I have therefore untrimmed the surface to make the “Surface from points” component work. I am now thinking to trim the surface only after making the attractor curves alteration but I am not acheiving the sharp edges on the boundaries of my final shape in accordance with the sketch saved here:

Would be great to receive a bit of guidance on this from anybody that could help. Here is my initial definition:
Complicated trimmed surfaces - Attractor points and curves.gh (36.6 KB)

Thanks a lot

This doesn’t look complicated at all.


trimmed surface_2023Jun20a.gh (211.8 KB)

If you want a hole in the final surface, just add it to Project.

1 Like

Thanks a lot for sharing this @Joseph_Oster .

I might have explained my problem wrong, sorry for the confusion. Your answer solved part of my problem, I will be working on the untrimmed extent of the surface and then do the cuts I require. Thanks a lot for that.

The difficulty I am facing comes from getting the jaggered edge curve to be consistant to the green outline of the original shape. I was trying to get the jaggered edge marked up in red in the below screen shot to the match the green profile. Is this something that is possible by tweaking my curve attractor portion of the definition? Or from any other alterations to the definition?

My expectation, by adding a custom bezier graph mapper was that the curved surface resulting from the attractor push & pull would match the profile shown by the graph mapper shown bellow.

I’m starting to think it’s just due to the original “devide surface” component not having enough definition in the U and V count to allow for a point to be exactly on the boundary curve?
After increasing the surface devide by double, 100 to 200, in the U & V counts there has been a slight improvement as shown below the red boundary shifted slightly up. To the cost of a lot processing power from my computer, but no where near where I would need it to be. I think I might be going at this in the wrong way…

Is there a way for this altered surface to match the curve by any chance? Or a different way to acheive the inclinations I am looking for through the use of something else than an attractor curve?

I was in a rush earlier and didn’t even look at your attractor code that moves surface points. When I finally did, I was shocked by what I saw :exclamation: Wow, that is complicated indeed - but shouldn’t be.

I made a bunch of changes that get closer to what I expected but still don’t understand yet the effects of your ‘Extent’ (4) and ‘Intensity’ (2) sliders… :question: So this still looks wrong to me.

trimmed surface_2023Jun20b.gh (36.7 KB)

I’m not good with guessing games instead of a clear spec.

The intension for the extent slider is to control the area of influence around the attractor point or curve and the intensity is the amount of displacement in the Z axis.

I was trying to use the attractor curves on the perimeter shown in my first message’s sketch to force the surface to dip down following the profile shown in the graph mapper, and then slowly dip back up.

I drew a sketch to hopefully explain what I was trying to do with this.

I gathered that much from their names. But you used vectors to measure distances to the attractors, which isn’t necessary or optimal. After all, there is only one vector (-Z) required to move each point, so it’s a matter of that vector’s amplitude, eh? Which is some combination of remapped distance from the four attractors. There is no magic in using Graph Mappers (4 of them) but you have to understand their precise effects. Did my changes make any sense?

I followed this path as it was the only one I knew how. I’m looking into your suggestion to evaluate their distance in length rather than through vectors.

It took me some time to understand your cluster “El sort”. It’s allowing for the sorting of surface based on their boundary length, would that be rigth to assume? Unfortunately I have continued a little more on the script since and for the moment I don’t seem to be able to re apply this solution in the amin script I have running. I’ll have to explore that further a little bit later. The other clean ups of the script were very usefull. I had duplicate quite a few components that weren’t needed, thanks a lot for that too.

I’m definetly a little out of my depth with this script, will continue exploring the avenues you suggested in the morning.

Yes, but that’s irrelevant to your algorithm, it’s just one way to get the correct fragment after the surface split.

Perhaps because I don’t understand the effects of your ‘Extent’ and ‘Intensity’ sliders myself, I think maybe you don’t either. This is the same code I posted before with some text panels added to see the effects of your sliders and remapping.

In particular, look at the panel labeled “Four Remapped Distances” on the right. Are these the effects you want? Three zero values out of four indicate that only one of the attractors is having any effect


trimmed surface_2023Jun20bb.gh (40.6 KB)

P.S. One more metric… the text panel labeled “Non-zero Attractors” shows the number of non-zero values (0 to 4) for each point. The ‘counts’ panel (green group, lower right) shows the number of points that have 1, 2 or 3 non-zero attractor values. None have four! Only 24 points have three, 1137 points have two and all the remaining points have either one or none. Interesting, eh?


trimmed surface_2023Jun20bbb.gh (39.9 KB)

From here:

Thanks a lot for your response, that seams really clear.

As you said previously, the script is far too complicated as it stands. I’m currently in the process of altering the amounts of attractor curves and especially the perimeter ones to make the script a lot simpler and will have a look at you definition improvements you suggested at the same time to tidy up the whole script.

Thanks again for your time.

It’s taken me a bit of time to digest your info.

This information does look extremely messy. There are 10200 values that represent all my surface points. In my mind the 0 represent the points not affected by any of the attractor resulting in no movement of the points in teh Z axis. The four remmaped distances is actually revealing the compounding element I was trying to solve earlier. Does that mean that if two remapped effect are affecting the same point it means it gets moved down even further? Lets say for one single point in the list I have 0,0,2,3 then when pluged back into the vector move component the point will move 5m in the Z axis? That is the effect I do not want in the definition. I’m trying to avoid the coumpounding of the effects and avoid the apex shown in the screenshot below. If I manage to sort this list of four remapped distance that might resolve my issue?

The point of this definition would be to move away from the tedious task of using “network surfaces from curves” commande in rhino to build the below curved surface. I was trying to get the script to use a series of attractor curves mimicing the location of the beams holding up this surface.

Having a script to control the shape of the surface would help us test faster different inclinations and positions of dips for these inflexions of the surface.

Yes. It could be written so that only the closest attractor distance is used. Or it could be written so that attractor influence is attenuated (reduced) by distance so the closest attractor has more influence than a distant attractor.

1 Like

Thanks! I’ve been trying to integrate a cull pattern into the definition based on your first suggestion:

I’ve been trying that one as it sounds more like what I was trying to acheive. I’ve been trying for the last few days without success. Still trying at the moment…

Here are a few search results that might be helpful? Look at all the replies in each thread, not just these.

1 Like

Thanks for the reference to past questions.This is all starting to unlock slowly.

1 - As you suggested I removed the vector based move and resulted to distance out of the Closest point component instead, Seams to still be doing the same thing and looks simpler.

2 - By using some of your past definition you shared, I managed to isolate the two attractor effects on each individual point. But then I can only cull the stronger effect on one branch of my list and therefore cannot plug it back into my move. How would I be able to use that part of the definition to get rid of all the stronger values applied to each point and plug it back into the move component back at the top of the definition?

Overlapping of Z strengths.gh (23.4 KB)

I still see multiple Z vectors that are added together instead of only one Z vector whose amplitude is determined by remapped distance values. I don’t seem to be able to help you, sorry.

P.S. My eyes glazed over when I first looked at your latest code, but I looked again. I believe you need help with more than the group in your image.

You are still dividing each attractor curve and using Closest Point (in a cloud) to determine distance, though I’ve said before that Curve Closest Point (Crv CP) is better suited to this task. All of your code and parameter values are identical for both attractor curves (perhaps only temporary?), meaning that what you have now could be written like this:


Overlapping Z strengths_2023Jun28a.gh (15.3 KB)

I don’t understand why you don’t understand what I’ve been saying all along? Multiple attractors are usually not complicated, provided the goals and code are clear and simple.

My knowledge of grasshopper is only as good as the information, tips and tricks I gather from the ressources I find online to teach myself.

If I didn’t do what you’ve been saying all along is that I could not understand it yet. I am gratful for the time you took to make the script more efficient and elegant. Althought what I have been trying to solve still is a mistery to me. I can notice from your latest definition that the area at the cross between the two curve is still adding up the forces of each curve to push the surface down even further.

I know now that my shortfall lies in my knowledge of data tree management and understand it is considered like basic knowledge from the community so I’m currently trying to remedy that shortfall. It is only a hurdle I need to overcome.

This version uses the Max remapped value of two attractors instead of adding them together. Needs refactor to handle more than two!


Overlapping Z strengths_2023Jun29a.gh (16.2 KB)

P.S. Replaced Max with Sort (white group) to handle more than two attractors.


Overlapping Z strengths_2023Jun29b.gh (14.9 KB)

2 Likes

This unflattens the Bnd (Bounds) input so untangles the “Extent of effect” sliders and makes it feasible to have separate ‘Depth’ values for each attractor (blue group).


Overlapping Z strengths_2023Jun30a.gh (18.0 KB)

3 Likes