algorithmic modeling for Rhino
Well, there's a variety of ways to equalize things with K1/2 ... but your issue is NOT that:
Are you trying to handle/manage/modify individual points (as anchors) on a per point basis ... and then run K?
If so this is only achievable via code.
See for instance this def attached: last step before passing control to C# (and kiss goodbye to all GH related Components).
... in your code, the same thing happens...
Indeed ... but this is the version - as I said - WITHOUT the C# that does this. It's the 99.99999% of cases shown in this Noble Forum: modify ALL points (or anything else in fact) that fall into some criteria at once (either with the random Z method exposed, or via attractors or via any other "global" modification mode). The fact that, say, the Z is different in the method used is totally irrelevant: still you modify ALL of them at once by preparing a list of Z (random) values and then ... blah, blah.
Forget all that: Imagine a classic grid of points (sampled in a single dimension Tree: x counts the branches and y counts the items): can you modify individually the Z on some points on a per point basis? (picking this or that point that DOES not comply to any "global" sampling method) and/or sample some of them (also in a per point basis) into some other collection and do whatever you want. Obviously when you reopen the definition the chosen "state" of points should be as it was at saving time.
This very simple (BTW: the core of all engineering matters) thingy is doable only via code I'm afraid.
I'll post here soon a small demo.
Here's a simple visual demo (points with modified Z ... are ... replaced with "buildings" for clarity):
Create a grid of extruded rectangles whilst at creation time (and/or at some later time) you modify individually the height ...er ... just because you choose a particular value. No rules, no attractors ... just some height value picked. It's the same sort of problem with your points (and a zillion of other cases).
Easy? or "impossible"?
And before switching to C# to do it properly (with a variety of checks for the initial "grid + modified points to Kangaroo" case), here's a demo on that "individual" control using components (too many ... all that would being replaced just by one "thing", he he).
The acyclic nature of GH dictates using Anemone (I like it much more that the other thing, he he).
Do this collection of breps "on the fly":
BTW: For equalizing (so to speak) you can try the 2 options provided ... (switchable) but have in mind that since we don't have something to "pull" against ... any equalize attempt would deform the all overall mesh:
For instance going from this state:
In general I would say that the "edge equalization" is a compromise between spring settings VS equalize settings. The fact that points are random makes - potentially - "areas" of no possible solution like this one where 2 random anchors ... just happened to be neighbors in the grid ... meaning no movement at all ... meaning a quite long "edge" (anchor to anchor):
The obvious solution: individually modify these 2 (and/or others) in order to allow more grid points in between ... meaning some "equal" modules more.
BTW: try these (a bit "abstract") as well in order to get the gist of that "equal" (or "relax" or whatever) thingy.
Spot the critical requirement to "follow" something in order to avoid chaotic "deformation(s)". This means (in this case) that a second K (taking the first mesh as "guide" to pull against blah blah) is not a very extreme approach.
BTW: Of course ... there's always Plan Z: post process (AFTER K, that is) the mesh via MeshMachine (don't forget the "steady" bits, he he).
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by