algorithmic modeling for Rhino
Hi everyone,
(images and files attached)I've been going crazy over this for an entire day without any luck. Hoping someone can help me to figure it out. I have two sets of points, 'from' and 'to'. I have the 'from' connecting to their closest 'to' based on the component setup in the file (it's a simplification of a larger file but this is how it's set up). I have lines going from each 'from' to each 'to' based on this setup.
No problems there.
But each 'to' destination has a total "capacity" of 'from' connections. At first, these connections ignored this capacity and so there are many more connections than there are supposed to be.
I want to cull those extra connections after the closest point action, and then use that newly culled point list to connect to the 'line' component. The end result should be a set of connections where the total capacity of each 'to' point is not exceeded.
I've gotten to the stage where I can find how many 'to' connections are made, but I cannot figure out for the life of me how to cull the excess points. Any help would be greatly appreciated, hopefully the file makes clear where I have not, I've tried to make the file as clean as possible.
Tags:
Hmm...
1. We have a fromPtsLlist, a toPtsList, a toCapacityList and a rule : each from to closest to.
2. So far they are all clear: the thing that I don't get is the attempts that the x from tries to connect to the (closest) to: since the closest rule is steady ... it means that you have multiple lines from-to ????
Hi Peter! Yes, I will have multiple lines which I'll use for different things later on. As you can see they overlap in this simple layout and cannot be seen, but they need to be there and will be visually represented later on.
Also, with the 'random' component in there, though the closest rule is steady, the numbers of multiple individual connections to each 'from' will vary and that's something I need to keep as well.
OK, I'll do it (the Dark Side way, he he) as follows (DT: DataTree):
1. We have a fromPtsDT, a toPtsDT, a LineDT and a rule : each from to the closest to. A C# will generate user controllable amounts of random from/to points (option (a) :"evenly" spaced, (b) "as they come") within a rectangle3d. The same C# will create random attempts/capacity values (or not ... if user provides the related data).
2. First dimension for each DT is the given point.
3. Second dimension in fromPtsDT (index 0) is the attempts allowed: {i;0}.
4. Second dimension in toPtsDT (index 0) is the capacity: {i;0}.
5. Second dimension in toPtsDT (index 1) is the connection events counter: {i;1}.
6. First dimension in LineDT is the first dimension fromPtsDT.
7. Second dimension in LineDT is the Lines.
8. Karma is stored in KarmaDT.
Hi Peter, sounds great! I'm always amazed at your work. But I do admit to having to see it in GH to understand it fully~
Hi Peter, one more thing I want to add is that the 'from' and 'to' points will be fixed locations. But at any given time maybe all of them will be included in the calculation, or maybe just a portion of them. Also, the 'from' and 'to' line quantities may change based on other external factors.
So the randomness that I have in my current file is related to the individual choices within each 'from' point as to where each of its lines connect to the 'to' points. That is to say, I don't plan that each 'from' point will only choose to connect to its closest 'to' points. That's the use of the 'random' component setup right now.
Well ... (understand it fully: it's very simple actually (kinda) ... but it's SOLELY in C#).
Point "modes":
1. IF you provide your DT (from, to) the C# will obey and work with these (NOTE: expects to find for a given branch i: {i;0} = the point, {i;1} = the attempts/capacity respectively).
2. IF you don't the C# creates demo DT's and plays ball with these (in 2 "modes" as I said : "evenly" spaced ... or not). You'll see why this is quite handy for testing the whole concept if the number of from/to points is big.
Connection "modes":
3. Based on your latest reply the from-to-connect rule has by now 2 modes: (a) connect to the closest (b) connect to a randomly selected one.
PS: If I get the gist of what you are after (Note: I can recall the other case of yours as well) ... I strongly recommend to attack these things via code: I mean ... well ... this is kinda "simple" ... but what about the next cases that may be far more complex, may require a myriad of "modes"/checks/what-ifs etc etc etc.
more soon
Hi Peter! Yes, what you stated is exactly right. Haha, any chance you can offer a coding class? You're right, I do want to start learning via your programming methods. Seems like they tip Grasshopper over the edge to allow almost infinite flexibility. Such potential was made clear to me in that file you sent me before.
Wow that image looks great. I can't wait to try it out.
Hmm ... I say (shown the demo pts mode: C# does it all, no user input):
1. Iterate ONCE across the whole fromPts collection and find the closest (from the toPts collection) - NOTE: in this "closest" mode the attempts are pointless: for more than obvious reasons. Capacity has some(?) meaning(?) mind ... I mean for you, he he):
BTW: Using the fastest (at least known to me) method to find the closest thingy (tested against up to 1M pts > pants on fire fast > job finished > in less than ... er ... 1234,78 hours > how cool is that?, he he):
2. Iterate ONCE across the whole fromPts collection and find a random one (from the toPts collection) - NOTE: in this "random" mode attempts they actually(?) have some(?) meaning(?) ... I mean for you, he he:
BTW: I wonder: why I have a feeling that the whole thing is kinda a trip into the rabbit hole?
Moral: I'm working on it.
Hi Peter, it's cool to see this process as it's happening~ I'll let you know the meaning behind this. The 'from' points are residential neighborhoods. The 'to' points are workplaces. The number of connections from the 'from' points corresponds to the commuter population within each neighborhood. The 'capacity' of the 'to' points corresponds to the number of jobs they have available~~ And each 'from' and 'to' point has the potential to change both its location and its population based on factors outside of this file. Haha there's your rabbit hole!
1234,78 hours... just... wow :P
Well ... I've guessed the scope (based on your previous case)
1. At this present phase you could do this via components as well (but personally I find 100 times easier to handle data management stuff directly via code). However ... if I guess correctly > there's other things that (I suspect) you have in mind > ...
2. Already this becomes paranoid (a bit) : I've changed the branch logic for the linesDT (since in "closest" mode we are talking about "star" like topology). Now the linesDT follows the toDT branch (main dimension) enumeration.
Using DataTree<object> for from/toDT's (since Points and integers coexist):
For toDT point at {0;0} that has {0;1} capacity (2 as captured) the lineDT puts the 2 lines found at {0;0} and the others (over capacity) to {0;1}. For the next toDT point {1;0} that has {1;1} capacity (4 as captured) ... no {1;1} branch exists since the amount of lines found is less than the toPoint capacity... blah blah.
Interesting stuff (for freaks, he he) I must say.
PS: due to a typo 1234,78 hours is actually 123,478 milliseconds (but who's counting? , he he).
Haha yes I figured that you did guess that. I need to learn to code : /
I already had a system set up to try to accomplish this with components... I felt I was so close... but 5 hours after that I figured that I tried everything I knew how to try.
So it sounds like you've accomplished the 'over-capacity' problem that I was originally going to put off due to its complexity. I do appreciate that. Yes I find this terribly interesting.
I've been watching the original Star Wars movies again by the way :P
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