re are other ways that might accomplish the same thing.
NOTE: Visualizing slope ranges has been shown by quite a few folks in various ways: (Coloring face by slope using gradient).
http://www.grasshopper3d.com/forum/topics/area-slope-listshttp://www.grasshopper3d.com/forum/topics/color-by-slope
mostly operating off of mesh face normals measured against an absolute z vector, and passing through a gradient component. I was never able to fully understand how the gradient "ranges" corresponded to actual values....
Anyway, here is rough example that I use. I'm sure there is a more effective way, but this worked for us.
The rough idea is something like this:
1 - Get percent slope of each face on mesh, convert to percent
2 - Define consecutive domains, (slope ranges), and use some path manipulation to group faces into thier respective domains
3 - Color the faces/groups
The last bit of the attached definition has a cluster that makes a legend...nothing terribly exciting.
Attached are the definition and an accompanying rhino file that has some notes regarding how slope is calculated, degree vs percent.. it's for reference. All the data is internalized in the GH def.
…
rk for Rhino, this is a first go at a very simple tool to get an idea of how fast different computers are at performing the sort of calculations used in Kangaroo, with the aim of informing those buying or upgrading their machines.
If you could take a couple of minutes to download and run this definition (after closing other running applications), then post here the result and your PC specs, hopefully we can start building a basic picture of what effect different hardware really has on the speed Kangaroo runs.
Most of the information can be found in the System page of Control Panel.
RAM speed can be checked in your BIOS, or with a tool like CPU-Z (note that the reported frequency from this should be doubled to get the actual RAM speed rating - eg if the frequency is 800MHz you should write DDR3-1600. It's confusing I know - see some discussion of this here), or by searching online for the specs of your PC model number.
This definition is purely testing the speed of the internal physics calculation, not display, so graphics-cards are irrelevant.
For now this is just to get a single general measure of overall Kangaroo speed, but it might also be interesting later to run a variety of tests to see how the speed varies with the size and complexity of simulation.
Of course a way of benchmarking general Grasshopper performance would be very nice to have as well, but would involve a lot more variables, and I'd be interested if anyone has ideas about how that could work.
Note - I posted a couple of versions of this earlier with various errors that were causing incorrect results. If you downloaded the earlier KangaMark01.gh or KangaMark02.gh file, please disregard that and any results from it and use the one posted here below:…
cribes a set of machine movements in X, Y and Z (Z being Pen Up and Pen Down) directions. It very closely related to G-code in this way - just slightly more simple than G-code overall.
For tool selection you use the Select Pen - SPx - command, x is the number of the pen you are using. As I'm using a vinyl cutter without a pen/tool changer I just use SP1 in the file header/ini of the cutter.
Without knowing the full spec of your machine it is hard to say for certain BUT all of my experience with CNC machines - of all sizes and spec levels - the actual control files are pretty much the same. Very simple text based HPGL or G-code text files run all motion control - even on things like 7 axis robot arms etc. For plotting I'd expect you'd be able to get a usable HPGL/PLT file without a lot of work - its just a matter of matching the file to what the machine is expecting.
To answer your question about getting the file to the printer its maybe best to explain it this way: there are two parts to this project1/ Create the correctly formatted text/hpgl/plt file ready to send to the printer2/ Send the file to printer
For part 1/ the procedure is:
Select the curves you want to printConvert the curves into a set of pointsFormat these points into HPGL Save this HPGL as a text file
For 2/ we need a way to stream the text file to a printer port
To do this I've used an old dos command line technique that allows allow you to 'copy' a text file to a printer LPT or COM port:
copy /b c:\spool\ini.plt LPT1
Type the above into a DOS command line and it will send a text file called ini.plt to the printer on LPT1 port. As you'll see in my attached code I use os.system calls in my python code to send files when needed.
So your original code was doing some strange things with the conversion from curves to points. Lines/Polylines were OK - with the code just using the line end points. For curves and polycurves the code code was exploding these into segments and then dividing into set of points. However this led to two issues: - curves that started off as closed polycurves would end up being plotted as open curve segments - which is not very good for a cut file and not very smooth for a plot file.- the division of the curves to points was by distance - and if this wasn't an exact division of the length of the curve the end point would not match up with the next line - again not ideal for a cutting file which needs to be a closed curve.
To solve the above I changed to using rs.ConvertCurveToPolyline - with the tolerance set to match the HPGL resolution of 0.025mm - this converts all curves needed to plot to polylines, leaves everything closed and ends points line up perfectly.
I had one other problem with my setup - I ran into a file size/curve number/plotting points upper limit. A small number of curves would cut/plot fine, however at a certain number in one file the print driver would throw an error and the plotter would not even start plotting the file. I could not work out where is the system this limit was being imposed. The current working version of my code is attached - it gets around this file size limit by creating a separate print file for each curve required and sending them to the plotter in sequence. Not as completely tidy as I'd like as it flashes up a cmd window on every loop - but plots/cuts are perfect.
The final 'nice touch' for the project is I've created a custom tool bar button to run the script - all I have to do to cut a file is hit the button on the tool bar, select the curves and hit enter = SO EASY!
I've attached my latest code, a sample HPGL file to plot a rectangle, and a screen shot of setting up the custom toolbar button.
Cheers
DK…
b or a mesh > all finally yielding a triangulated mesh (either via Ball Pivoting or "tuned" via MeshMachine or with some other approach)..
2. Assume that this mesh is "reasonable" with regard the edge sizes et all.
3. What is the best DIY method to do the thing using wood ? Well ... by FORGETTING beams as stand alone entities (using even linear hinges for the connection) and creating STAND ALONE tri "frames" from plywood and then connecting them by bolts.
4. How can we achieve planer pieces that when extruded inwards (+ some other "minor" stuff) could yield these standalone sets of plywood? (+ some decent layouts for cutting the pieces). What about fitting tolerances? What about the fact that we have actually "skin" deployed frames and not a true truss (so what? - it's a small thingy after all).
I give you a hint (he, he) the full solution soon (not sure if I should use a bit of the Dark Side for creating these tri-frames):
Red is non planar, green is planar (height - or rather the "width" of the plywood pieces for the tri-frame - is obviously user controllable):
more soon
…
djust by a graph mapper or something so i can vary the height and size of the twirl in the middle
i essentially want to split the curve on grasshopper like this with points that i can change:
this is because i eventually want to create variations, so i can decrease the middle section, so the variations would look something like this:
i understand that i can generate a line and an arc , but:
1. i can't seem to join them together
2. not sure how to adjust points to give it alternating heights/z axis
3. arc in the middle not oriented the right way!
thank you so much in advanced…
Added by brushstroke at 12:16pm on February 20, 2017
country and in particular London. Point clouds are available online and perhaps there could be a way that they inform the building heights. I have been exploring the following process:
1. the mesh produced with the point clouds. Rather accurate but using the delaunay meshing, the shapes are very rough and dented.
2. I populate the mesh on GH.
3. Using Gismo 2D shapes, I test for point inclusion for each shape and find the highest point. Its height (z) extrudes the 2D shape.
4. The result is very convenient in many cases, though it is not easy to control which shape is extruded to the eighest point as larger polygons could contain smaller ones.
I am still looking for a way to filter more the OSM shape component so that the 2D shapes are strictly buildings.Although the LIDAR files are rather very heavy, perhaps there would be an automated way to query the databases with GISMO.Food for thoughts.
…
But not just any gum tree. The angophora, no less:
Why? Because I like nature, that's why. Every time I see new designs –especially architectural designs– it worries me that the natural environment is being taken over. Not just that, but even the new materials used in all product designs has to come from nature as well [read: mines].
So. People are forgetting that we still need trees and I believe that if someone sees a beautiful [read: established] tree in their architectural plans, they are going to be much more likely to build around it and not cut it down. That alone would no doubt increase the value of the house.
My thinking is that current tree models suck. They look unnatural and I think I know why. They're not random or organic enough. They're not detailed enough. That's basically my 'rationale' for this project. Just look at how different all of these tree trunks are!
So I am not being paid for this project. It's a personal project of mine. I'm just worried about the trunk shape for now — I'll worry about all the leaves... when I get to that.
I am a grasshopper beginner. Please keep that in mind. I am also fairly hopeless at traditional programming, but I find the visual approach of grasshopper much easier to grasp. So unfortunately I have gotten stuck and need some help, even just a clue, as to how to proceed.
That said, here is my current progress:
About a year ago, I started modelling with straight trunks using pipe sections, to see if I could get a very basic "tree" shape. And to see if I could join the segments together. Yes it works but it looks hopeless as you can imagine. Then I stopped for a long while. Now I'm back at it, hoping to improve a lot more.
I have already made one basic vertical nurbs curve with tangents at either end as the main "trunk".
I tried creating two ellipses at each end of the main trunk/curve and lofting between them but it omitted the main curve/rail. So it ended up being an elliptical trunk with straight sides which of course still didn't look right.
Then I divided the first main curve up into a number of segments. I think that is a better approach.
I have taken the parameters of the curve at each segment (probably the tangent, but I am unsure what the exact parameter is) and used that to form a basic angled plane at each segment/division.
I have been able to draw ellipses at each segment and rotate them onto the plane.
I was going to loft it together later on. A Curved loft with elliptical cross-sections looks much better than straight a pipe does, but still looks too unnatural.
I quickly realised that tree trunks are not elliptical, but rather, shaped more like 'kidneys'.
The next step was to create >3 points on each of those planes (spaced fairly evenly around the ellipse so as not to create a really funky/unwanted shape).
Maybe it would be better to model with a triangle or other polygon instead of an ellipse. I haven't got that far yet... because here is where I am getting stuck.
I managed to find a way of getting three roughly 'triangular' points along each that ellipse.
I also managed to create three nurbs cuves in the Z direction which intersected those three points, a bit like three seams down the side of the tree trunk, but couldn't figure out how to loft it all together.
I think it was the wrong approach anyway... I'd rather try to create a bunch of nurbs curves at each of the XY planes so as to get more control of the shape.
What I am trying to do now is create three roughly triangular-spaced points on a basic ellipse through which I can then draw a simple nurbs curve (think like a cross section of the trunk).
I would then like to add some XY-only randomness to the positions of those points. Not Z randomness, otherwise the trunk is going to get messed/kinked up. That's probably very important.
Then I would like to loft those nurbs curvs at each XY plane together forming the basic tree trunk, which also tapers based on some other variable (a non-linear factor, not simply distance from ground plane, perhaps something else?).
I have attached the GH file.
I am also open to suggestions if you have a better way of solving a problem. I would like to retain control over a lot of factor such as number of branches, spacing, average branch length, etc. My main contrsaints are that the entire thing has to be somewhat random and non-linear.
…
curve or locus] of a segment AB, in English. The set of all the points from which a segment, AB, is seen under a fixed given angle.
When you construct l'arc capable —by using compass— you obviously need to find the centre of this arc. This can be easily done in GH in many ways by using some trigonometry (e.g. see previous —great— solutions). Whole circles instead of arcs provide supplementary isoptics —β-isoptic and (180º-β)-isoptic—. Coherent normals let you work in any plane.
Or you could just construct β-isoptics of AB by using tangent at A (or B). I mean [Arc SED] component.
If you want the true β-isoptic —the set of all the points— you should use {+β, -β} degrees (2 sides; 2 solutions; 2 arcs), but slider in [-180, +180] degrees provides full range of signed solutions. Orthoptic is provided by ±90º. Notice that ±180º isoptic is just AB segment itself, and 0º isoptic should be the segment outside AB —(-∞, A] U [B, +∞)—. [Radians] component is avoidable.
More compact versions can be achieved by using [F3] component. You can choose among different expressions the one you like the most as long as performs counter clockwise rotation of vector AB, by 180-β degrees, around A; or equivalent. [Panel] is totally avoidable.
Solutions in XY plane —projection; z = 0—, no matter A or B, are easy too. Just be sure about the curve you want to find the intersection with —Curve; your wall— being contained in XY plane.
A few self-explanatory examples showing features.
1 & 5 1st ver. (Supplementary isoptics) (ArcCapableTrigNormals_def_Bel.png)
2 & 6 2nd ver. (SED) (ArcCapableSED_def_Bel.png)
3 & 7 3rd ver. (SED + F3) (ArcCapableSEDF3_def_Bel.png)
4 & 8 4th ver. (SED + F3, Projection) (ArcCapableSEDProjInt_def_Bel.png)
If you want to be compact, 7 could be your best choice. If you prefer orientation robustness, 5. Etcetera.
I hope these versions will help you to compact/visualize; let me know any feedback.
Calculate where 2 points [A & B] meet at a specific angle is just find the geometrical locus called arco capaz in Spanish, arc capable in French (l'isoptique d'un segment de droite) or isoptic [curve or locus]
of a segment AB, in English. The set of all the points from which a segment,
AB, is seen under a fixed given angle.…
: read below.
1. Using code for the random pts on BrepFace (yours + some holes to spice things a bit). Main reason? Well ... to control the miin distance (critical for engineering purposes). The other one is that you can disable the "even" distribution option and get random points as Fate brings them to us. That said David did a fantastic job on the equivalent native populate component.
2. Then the points are "elevated" (or not) according a user defined Z range. Reason? Well ... Plan B that is (making a tensile membrane system instead of that pessimistic "vault" thingy [ideal for funerals, mind]).
3. Then a user controlled (with regard what mash faces to kill) Delaunay mesh is created. Viruses in the mean time are placed around (you can use any block you like - see BlockManager). C# that does this is independent from the main action (but it doesn't work if the named block specified can't been found). Then the mesh is subdivided further (for obvious reasons). You can switch off this stage (that feeds finally Kangaroo 099). That said increase the N or viruses and spot the response time: this is the only way to do proper business with "identical" objects (same applies for truss members and for any collection of things in fact).
4. Then you double click on the 099 and Daniel does the rest.
BTW: As I said earlier the Anchor picking policy sucks. V2 does this properly.
BTW: Load R file first (and use Named Views).…
sion app (Modo, Z Brush etc) in order to get "as equal" as possible mesh faces.
For instance ... see a W depth truss (tri mesh > meaning that the "out" grid is hexagons) out from a Kangaroo "inflated" mesh:
2. A space frame is NOT a collection of abstract lines ... meaning that clash members detection (via trigonometry and NOT by checking boolean intersections) is far more important than the "concept" it self. If "live" alterations are required for addressing local clash issues ... well ... that's 100% impossible with native components.
See a typical clash detection capability:
3. A truss without proper connectivity Data Trees means nothing in real-life (vertices to edges, vertex to vertex, edges to vertices).
4. Each "standard" truss member (say: sleeves, cones and the likes) should be an instance definition placed in space according appropriate orienting planes. That way you may be able to handle thousands of components that in real-life participate in any truss of a certain size.
All the above are far easier to do with code (V4 is impossible with components).…