algorithmic modeling for Rhino
Hay,
I'm working on a definition where if the objects intersect then the physical model will run into issues.
So I'm looking to have the intersecting brep's moved further inward until there is no intersection.
It doesn't have to be all of them moved as when one is clear then the intersection is clear in this case with only 2 objects intersecting each other. But what ever is easier at this point.
My logic is;
If intersection = true
then +1 (unit) move inwards (towards centre) along curve
until intersect = false
I was looking into hoop snake and http://www.grasshopper3d.com/forum/topics/flag-intersection-between... to get the boolean intersect value, but I have not got very far with it.
Current Left
Desired Right
Tags:
Easy ... I'll provide the (usual) thing (painted mat Black) soon (unless some other good Samaritan does this with the politically correct way, he he).
Hell at this point it could be rust brown with multicoloured projectile snot covering it and I'd love it. Not saying that the dark lord is capable of such things.
**Possibly an issue down the line; These are solid difference cut holes in nodes, so if the cut hole moves then ideally the node "arm" should also lengthen to maintain the hole depth. But I was hoping to apply the fix used here to fix issues the 2nd.
Thanks Peter
Lord (of Darkness) he's after black (or mat black or - in an emergency - gloss black).
I'll do it ASAP (including a free of charge bonus).
However:
1. Mode A: "slide" Breps using vectors derived from their corresponding (prox) lines until no intersection event occurs between non of them.
2. Mode B: "slide" ... blah blah until all breps have the same (min) distance between them.
which mode you like?
best, Lord (Of Darkness)
Anyway get this demo and in the next (trad) update we can talk about proper data structures (breps, lines et all). Load Rhino file first.
The free bonus uses J+a+m+e+s for doing the job.
Lord (of Something)
Sweet, the demo looks great!
Mode A & B: Either would be good if only the intersecting breps moved. Leaving the isolated ones in the same position. Its not necessary to have a set distance, but would be no doubt handy at some point.
Mode C? Only solve one intersection at a time, governed by the longest line. So both (of 2) of the intersections don't move but only one until they are both isolated. This would enable one node arm to remain the same length (shortest line) and the other (longest line) would be extended inwards.
In the above example "Brep_Brep_proximity" it would mean that every other brep would move. Although all these lengths are the same, so I don't know how you would determine every other?
Worst case scenarios below:
To get the line per brep would it be looking at the line closest to brep and deriving the vector based on the breps loft direction??
OK, I'll give it a spin but let's make a brake about what these C# things do:
1. The left one ... well it's obvious: finds every min distance from,say, a given letter (J for instance) to all the rest (a,m,e,s). It doesn't work with intersections AT ALL ... thus the presence of holes, cats, dogs (and quite probably one alligator) etc etc means nothing to the method.
2. The right one assumes that your input (breps and lines) is wrong: (phase a) it "corresponds" each brep with the right line and (phase b) creates the right (per brep) vectors for the stepped [step = v.Unitize()] translation. Then (phase c) each brep is moved > using a function exactly the same as the left C# has > distances are sorted and the first is returned from the function (meaning the smallest). If the smallest is > something > thanks > Adios Amigos.
Thus if something = 0.0001 > it's like checking for a non null intersection event.
Now ... if you want all that paranoid stuff to work with the intersecting Breps only > 2 lines of code more > take only the intersecting things and do the magic > leave the others in piece.
Of course for these 2 lines I'll charge you extra (5 cans more of the finest sardines known to mankind)
more soon, Lord (Of Sardines)
Well...this is more tricky than it appears on first sight (as usual)
Not sure that your logic (exclude stand alone breps from the party) could yield a valid solution: for instance it's more than possible when the rest are "slided" along these "guide lines" > intersection (or prox < dMin) events may occur.
Anyway get this and we talk later on (load R file first).
best, Lord of Darkness
Thats still great. Would it be as simple as culling the breps that have intersect value of false to keep them in their original position?
Not simple... more something less hard
Edit* I See What you've done by moving the original breps.
Programmatically nothing is complex ... the complex is the questions about what happens if this or that occurs: for instance a brep shaped like T that when moves away comes into contact with a stand alone "stationary" thingy (but that's easily addressable by including all breps in the recursion whilst only the non stand alone are allowed to move). Anyway ... there's a move all option available just in case.
Notice the substantial difference in speed when the intersection "check" - option - is used (VS the proximity). That's the reason that I've used it in the first place (R is very slow on these ops - and the King of snails is the offset curve on surface: slower than a stationary Harley Davidson).
Such a simple case eh? he he
Couple of quandaries;
Why did you up the loops? *Edit* Ah the flashy ones
and what's the safety net?
Also the data structure for the linelist scares me, on the thought of implementing it on a larger def. Could it just use the existing geometry or would it need new as there's 2 per.
Oh and THANK YOU!
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