e in Euclidean space then the distance metric can be discontinuous:
Discontinuous means that a tiny change in input may result in a large change in output. Observe the image above, we start measuring euclidean distances from point A. At first the process appears to be continuous. We measure at distance b and we get point B. We increase the distance slightly to c and we get point C, which is very close to point B. We increase the distance slightly again to d, but now suddenly we're in a completely different location. This jumping behaviour can mean that certain questions (such as: "how do I divide this curve into 4 points, all equally far apart?") do not have an answer. It could be possible for 3 and 5, but not 4.
Another problem is that there may be multiple solutions. In the image above the point D isn't the only point that is d units away from A and coincident with the curve. There may be any number of those points depending on the shape of the curve, the location of A and the value of d. And of course once you have two (or more) solutions, you can have two (or more) answers. Then each of those solutions may yet again have more than one outcome for the next point in the chain and before you know it the question you asked has 35295 different answers and good luck trying to find one you like.
Now of course sometimes it is possible to answer your question unambiguously. I made a solution that uses Galapagos. It's pretty slow, and it'll get slower the more segments you want:
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:26am on September 9, 2013
rid that works on the left and/or right edge of the components, so that it's easier to align them (similarly to the align functions that show up when multiple objects are selected)
Overall, I think we'd just need a basic grid for alignment, so whatever is easy/quick to implement might be good enough.
4) great, I didn't know about aliases - that pretty much answers my question.
Related to this, when I press F4 and search for a component, if the mouse/pen pointer is above the list, when I press enter Grasshopper will insert the component under the pointer, and not the one I have found with the keyboard. Am I missing something? In case could it be fixed?
As a side note, at the moment the keyboard focus is always on the Rhino Command Line. Would it be possible to optionally change the focus when the Grasshopper window is active so that we can insert new components just by typing, without pressing F4 or doubleclicking? I just find myself constantly using the keyboard to insert components, so that'd be a very nice timesaving.
5) Your idea would be great to manage complex panels and I think would be very nice to have.
However I was thinking of a different workflow, that could be useful - for instance - when working with several objects in Rhino that are referenced in Grasshopper as basis to create more complex objects.
For example: I have three different surfaces that are used to create framed grille elements. It would make sense to select these surfaces in Rhino and access to a panel that shows the element properties (for example frame dimensions, type of grille, etc.) - similarly to the property panel in Rhino.
Additionally, If I need to create a new grille element from another Rhino surface, I could just duplicate the RPC component along with the definition without the need of manually publishing all the parameters to a new RPC group. I hope this makes sense.
I understand this may not be an "urgent" feature, however I find that working with RPCs is very pleasant so I'd really like to see this feature expanded in some way :-)
6) Just perfect :-)
Thanks again David!
Marco
…
r planet Utopia?
2. In what sort of animal these "shaders" are to be used? Meaning that designing a "Viz" control for 2345,67 mini-membranes is one thing and doing it for your house is a totally different challenge. In plain English: it's more than possible to hit the Wall if lot's and lot's of items are invited to the party (you bring the girls and I'll provide the Vodka).
3. Do you like the idea of completely separating (on a spatial basis) input/viz control (what is on display and on what level of "detail") from the core logic (i.e. components). Pros: obvious, Cons: obvious.
4. Is this def planned as a "constant" evolution thing? Meaning that using, say, the mapper isn't the best idea if your input goes from {a;b;c} to {a;b;c;d;g;...;z}.
5. Have you any - even academic - plans (see 1) to walk the walk up to the end?. Meaning talking to Birdair/Taiyo Kogyo etc etc ( http://www.birdair.br.com/ ). If yes be prepared because these fellas work a bit differently as regards potential collaboration and feedback at design phase.
BTW: the thing that would change the world as you know it:
http://www.birdair.br.com/tensileArchitecture/tensotherm.aspx
best, Peter
…
rder to deal with the contents of the MERO structure (like glass, panels, polycarbonate). That is what the C# does already.
3. Vectors (a la "Umbrella" sticks) in order to place correctly your MERO nodes (the "hexagon" brackets - so to speak). That is what the big C# (the one that I've send to you some time ago) does already.
4. Calculations (lengths, angles) for each node against the other related nodes and the points derived from dividing the MERO square "tubes". For a given node these points are variable (from 2 [when in the "bounds" of mesh] to 6 ["typical" middle point, so to speak].
5. Demo block instances in order to see first hand what GH can actually do (that's WOW stuff: you slide a slider and "several" real-life components are placed in 3d space in real-time, he he).
6. Node connectivity data for the obvious (assembling the MERO on site).
7. Some assembly "simulation" capability (we do this today and this tomorrow ...)
So forget the single carrot (plenty carrots for you soon) for a while and answer to the most critical question: Based on what you've displayed to me (Skype) what is your policy against the MERO node itself?
I mean: we don't deal with a classic MERO ball type here (meaning variable drilling axis per ball). Meaning that the "hexagon" bracket (if I may use the term) IS VARIABLE. Meaning: you need a "module" that can being adapted against "every" possible (logical) angle value? (and compose the bracket?) Or you gonna fabricate the "brackets" on a per node basis?
And what if we had a planar glazing system? (same principle, more expensive, 100 times more WOW).
BTW: The best man in the world to do "similar things" with "hinged" custom aluminum systems (like doing the blue facade that you've displayed to me with some semi structural/structural system) he's a very close friend of mine. He's based in Dubai UAE.…
ts (other than Kangaroo - if required). Anyway notify if you want some taste of them (but they are a bit "chaotic" : too many parameters etc etc ...). Warning: Almost all are written with MCAD apps in mind: GH is used SOLELY as a graphical editor/topology solver and just makes the simplest instance definitions possible in order to send them (via STEP) to some MCAD (Frank G uses CATIA/Digital Project as you may probably know, CATIA is my favorite toy as well) for actually designing the components and composing the whole.
2. "Equality" in modules (panels/glass/lexan) it's not an issue (other than aesthetics). I mean cost wise since modules are prepared via CNC these days. I wouldn't suggest to waste your time with "equality" puzzles and completely ignoring the big picture (real-life) that is FAR and AWAY from aesthetics. I mean: assume that I of someone else or Daniel can "equalize" things (up to a point): Is this sufficient for designing a similar real-life solution? In plain English: don't get occupied by the tree and ignore the forest.
3. As regards the frame in most of cases some MERO type of modular system is used: either a "flat" dome-like arrangement or a classic spaceframe or a hybrid system [push: tubes, pull: cables]. Hybrids are the most WOW (and costly) for obvious reasons. When properly done (and combined with a planar glazing system) THIS is the star of the show.
4. As regards the skin we use either "hinged" custom stuctural/semi structural aluminum extrusions (they can adapt to different dihedrals up to a point) or classic custom planar SS16L systems that also can adapt to dihedrals. A custom planar glazing solution is hideously expensive, mind (say: 1K Euros per m2).
5. Smart Glass tech (changes light transmission properties under the application of voltage) is gradually penetrating the market especially in future bespoke designs.
So in a nutshell: these are "pro" territory - if I may use the term, thus I don't expect to find ANY similar "turn-key" solution in the very same sense that you can't find a tensile membrane turn-key solution.
Meaning that practices that can do it ... er ... they keep the cookies for themselves. …
rder in which these polylines are drawn is not important (correct me if this is not the case).
2. We explode the polylines. This outputs all the line segments and all the endpoints (both groups with duplicates inside them). So we have 204 lines (including duplicates) and 246 points (including duplicates). We flatten both outputs in order to get 2 simple lists.
3. We use [dupPt] to remove all duplicates from the points list. So we get a list of all the nodes with each node contained one time, so we have 108 points.
3a. We can use [pointList] to display the index of each node on screen.
4. For each line segment we find the 2 endpoints and put them together in a list. So we have 204 lists with 2 points each. (We graft the list of lines so that the endpoints of each one will be in a different branch/list)
5. We use [closestPoint] and so for each endpoint we get the index number of the corresponding node. So we have 204 lists with 2 indices each.
6. We get each couple of indices and join them as text with a comma separator. (We flatten the data so that we have a single list with 204 texts)
7. BUT some of these 204 texts are duplicates (because they originate from duplicate lines), so we use [cSet] which returns the unique values from a list. So we end up with a list of 180 texts (one for each unique line). Instead of using [cSet] you could also eliminate duplicate lines using kangaroo's [dupLn] (which is the equivalent of [dupPt] but for lines) before step 4.
Hope it is more clear like this. I am not sure I understand what you mean by "But they are not connected in the order to form the tessellation.". If you still have problems with the definition please explain this a little better.
cheers, Nikos
…
ts (NOT meshes) using my (still WIP) BallPivot thingy (still highly temperamental despite wast quantities of Vodka consumed - in the Name Of Science, what else?):
Watch this Forum for the forthcoming mother of all threads : Get Points > Do Something.
On the other hand (real-life):
1. A truss without connectivity is nothing.
2. A truss without clash defection is nothing.
3. A truss without instance definition(s) is more than nothing.
4. A truss without (rather very complex that one, mind) roof/envelope stuff is nothing + pointless.
5. Mesh from points without a 1000% working ball pivot thingy is like 3rd marriage.
And as you'll discover this Monday ... well ... "some" things would be MIA from the definition.
Other than that:
For Chap, David, Angel and anyone else interested on these freaky things (get points do something, that is).
Do you people think that this (mode: dense [yellow stuff] ) has any meaning?
VS that (mode: hex):
I mean for the truss itself not the roofing paraphernalia. Notice that in this handsome hex mode we've already achieved max rigidity since we deal with tetrahedral stuff.
PS: My aunt Drusilla finds the dense mode ... utterly pointless (and a bit disgusting).
That's friends is the 1M question.
…
truss right?
2. Trusses are NOT made via lines ... they are made by real-life components like balls, rods and other mysterious (and maybe ominous, he he) paraphernalia.Good news for you: lot's of C# stuff around me that do that (but they are not exactly "entry-level").
3. PRIOR talking to ANY FEA/FIM thingy you need to address clash situations: I mean IF a given node is doable or not (because lines they don't rise clash issues ... but rods/struts/tubes/cones do). Good news for you: lot's of C# stuff around me that do that (but they are not exactly "entry-level").
4. Then you have to use some real-life (or at least some "realistic") components like the ones found in, say, a classic MERO "ball" system (and especially the adapter cones between the balls and the tubes). Or at least "some" of them that outline a "realistic" truss.Good news for you: see above.
5. Then you could validate the whole structure AND the parts VS structural loads: I mean there's absolutely no meaning "doing the whole" without taking into account the load bearing capability of the parts. For instance, say, what happens if the geometry (i.e. the topology) is "capable" but a given bolt is weak? That sort of stuff.
6. Now ... this is Academic ... but following the "abstract" way (I don't care about bolts because I'm a student)... this could teach you the entirely wrong way to use FEA/FIM for validating any structural ability of ... anything. And besides FEA/FIM is used for making the damn thing in the real-world ... and that involves (unfortunately) "some" bolts and nuts.
I can arrange a (rather long) Skype session for a demo of all the above ... but first I strongly advise to post here a finished thing (in terms of 3d component geometry) ... and THEN we can examine the whole strategy: what to export, how and especially what could be an "interactive" (both ways) protocol/strategy in order to give the green light for that truss.
BTW: Kangaroo is a physics engine and as such it's used as an abstract "shape" finder. I have no idea what Karamba does ... but always have in mind: BIM things ... are BIM things (meaning that without a serious BIM umbrella ... don't go out when it rains).…
gns. There were a few issues with your case. I will try to list them, hoping that this can also be helpful to you but also other users in the forum.
1. The Rhino model contained a lot of open polysurfaces. This is a big enemy of meshing and CFD. The way meshing works is that every single open area, that can be reached from your locationInMesh with a polyline, will be included in meshing. Some of your lanscape volumes were open. I have rectified this in the .gh file attached and now they should be ok to mesh.
2. It is strongly suggested to rotate the geometry and not the incoming wind when creating the wind tunnel. This might as well have been the reason for meshing awkwardly, although can't be sure. I have rotated the geometry by 45 degrees to allow your original wind to have a Y+ direction.
3. I could see a decomposition component in your case study although I cannot be sure if this could be the reason of your problems. It was not connected to anything, but perhaps it might have been the culprit for the paralle issues you were having. I have disabled the component so the case would run in single processor, but you can freely enable it and your case will be run in parallel (4 cores).
4. Your post-processing surfaces have large parts inside the building volumes and under the landscape (if included). You will probably get some issues with visualizing some probes, although this will not affect your study in any way. I recommend to only pass probes that you know to be sure will be inside the mesh to OF.
5. If you decide to include the landscape (I have it disabled in the attached .gh file) I strongly recommend to allow for more cells than 2m. 10m would be a good start imo for this case.
6. I did not check, as it will not make your case break, but your grading was a bit imbalanced at first glance. Try and keep some balance, especially in the X-direction, and make sure to visualize the blockMesh and make sure you achieved what you had in mind.
I did not actually run the case btw, I leave that to you. I believe it will run without problems, although I cannot be sure it will not diverge (this is something that is very educational for you to deal with).
Good luck!
Theodore.…
he grouping of the sliders on the remote control panel.
4. Separate viewport(look at picture)
5. Cluster editor new wish
My version grasshopper 0.8.0004
Best Regards,Valentin
Kiev, Ukraine
…