code from C:\Users\MyName\AppData\Roaming\Grasshopper\ladybug to C:\Users\.MyName\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\ladybugCopying honeybee source code from C:\Users\MyName\AppData\Roaming\Grasshopper\honeybee to C:\Users\MyName\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\honeybeeCopying honeybee userobjects to C:\Users\MyName\AppData\Roaming\Grasshopper\UserObjects\.Runtime error (Exception): `C:\Users\MyName\AppData\Roaming\Grasshopper\userObjects\Honeybee EP context Surfaces.ghuser` and `C:\Users\MyName\AppData\Roaming\Grasshopper\UserObjects\Honeybee EP context Surfaces.ghuser` are the same fileTraceback: line 82, in installHoneybeePlus, "<string>" line 87, in script line 68, in copyfile, "c:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\shutil.py"
Merci beaucoup.
…
50 and reduced the 'cell size' slider to 0.5. When the 'Azimuth' angle is changed to 180 +- 90 (dawn or dusk), the points are widely dispersed, reducing the density and increasing the number of cells in the "sparse grid". Under these conditions, the number of cells was ~2000 and the Profiler time for 'Boundary' went up to a full minute or more each time 'Altitude' or 'Azimuth' was changed.
So I created this code to benchmark some alternatives and found two interesting things:
'Boundary' surface performance (v.1) is not linear. As the number of surfaces goes from 1000 to 2000, the time per surface goes up dramatically.
I tried three alternatives for creating a rectangular surface at a given point that are all substantially faster: v.2, v.3 and v.4. For 2000 points, v.4 is 150 times faster than v.1 !!!
Performance of v.2, v.3 and v.4 are similar and all scale up very well. To benchmark beyond 2000 points, I recommend disabling the VERY SLOW v.1. At 5000 points the 'Pop2D' component takes ~11.3 seconds but v.3 and v.4 take less than one second to generate 5000 surfaces!
See boundary_2015Nov19a.gh attached.
So I replaced the 'Rectangle' and 'Boundary' components in my sun reflection model with v.4 in focus_2015Nov19b.gh (also attached) and the performance is amazing.
I'm sure someone has mentioned this performance issue with 'Boundary' on the forum before but as with many things, I didn't realize what a major obstacle it can be until I discovered this for myself.…
Added by Joseph Oster at 9:16pm on November 19, 2015
grout lines, a tile surface and tile perimeter poly line). I then use that as a Mesh (from Rhino) in the second definition.
2. I can tile out the mesh surface and rotate all the tiles in 90 deg. increments.
To get what I wanted. I took the Mesh and have copied it in series to make a grid. I can then control the dimensions of the grid. X and Y extents. I can also rotate the tiles around their centers.
The spacing of the grid is set from an edge curve of the tile (or mesh). This sets the size of the squares in the grid themselves.
See definition, images and Rhino 4 File, to give the definitions a shot. I have labeled how to use them.
My question -- how can I randomly rotate squares in my grid? I would like the deg of rotation to be random and also which tiles they are.
Also how might I rotate (every other tile) for example? So that I can control the pattern more?
Thoughts?
Thanks!
…
ror when it comes to points on edges of the surface.I guess it is because normal vectors at a few of points are invalid. After all, because of these invalid points, an error message comes out which is saying " Runtime error (PythonException) : Unable to add polyline to document " and it results in no output. Please give me some help if you know how to handle this problem. I post a code below.Thanks in advance.
---------------------------------------------------------------------------------------------
import Rhinoimport rhinoscriptsyntax as rsimport mathimport ghpythonlib.components as gh
output_crvs = []
for pt1 in input_pt :output_pts = []newPt = pt1output_pts.append(newPt)
while len(output_pts) <= 100: newPt = outputpoint(base_srf, newPt, distance_factor) output_pts.append(newPt)
output_crv = rs.AddPolyline(output_pts)output_crvs.append(output_crv)A = output_crvs
def outputpoint(base_srf, input_pt, distance_factor):centre_point = rs.AddPoint(0,0,0)height_point = rs.AddPoint(0,0,10)
zaxis = rs.VectorAdd(centre_point, height_point)
cp_pt = rs.SurfaceClosestPoint(base_srf, input_pt)normal_vector = rs.SurfaceNormal(base_srf, cp_pt)drain_vector = rs.VectorCrossProduct(normal_vector, zaxis)
dvector2 = rs.VectorUnitize(drain_vector)dvector3 = rs.VectorRotate(dvector2, 90, normal_vector)
mpt = gh.DeconstructVector(distance_factor*dvector3)moved_pt = rs.PointAdd(input_pt, mpt)moved_uv = rs.SurfaceClosestPoint(base_srf, moved_pt)output_pt = rs.EvaluateSurface(base_srf, moved_uv[0], moved_uv[1])
return output_pt…
g from a list of 12 items I would find all the combinations taking just 4 at time.
I'd use a Stream gate that takes the indexes of the items and pass them to a list item in order to select just the items of the combination. Doing so I can choose a single combination of index at time to pass to the list item.
In this moment all the data come out from the first gate, all the others are empty.
If I pass these index to the list item it gives me an error (probably because of the data structure).
*long version*
I start from a list of 12 segments, all of them with the starting point in common and the ending point distributed regularly in the space. It's a quite simple starting point.
What I'm trying to achieve is to find all the possible spatial configurations made of 2, 3, 4 segments. I started with 2 segments so I've 12^2=144 possible configurations but just 4 different configurations that can intuitivelly be recognized (60°, 90°, 120°, 180°).
Doing the same with 3 segments generates 12^3=1728 configurations and I don't know how many different ones. With 4 segments I've got 12^4=20736 possible configurations.
As you can imagine many configurations are identical but just with a different orientation so at the end I'll have to parse geometrically the output to delete duplicates (I'll address this later on).
Please could you help me to figure out how to mix these segments in different configurations?
Thank you in advance.…
per bake commands to bake the connected geometry with the corresponding materials.
mxDiff is a simple diffuse material. Only reflectance color for 0° and 90° are exposed.
mxEmit is a basic emitter material. You can set light color, power and efficiacy of the emitter.
mxBasic is the most complex material for now. You can set all the properties of a single layer material including. Use this for transparent materials.
mList is your way if you don't want to create your own materials. This component returns a list of all the materials on the Maxwell scene manager. Make sure this is evaluated after you add your own materials if you want to see them in the list.…
ete" AEC things ... the others could be several steps ahead either by virtue or by momentum.
But Hannes (and others - the pissed-off ones, he he) misunderstood my intentions: I'm not here to measure our ego(s), our @$@% nor to dispute/debate for the obvious. I'm not here for the money (that could be ridiculous) the glory (preposterous), or to perform some cheapo show-off (what for?).
I'm here in case that people can distinguish (and are willing to talk and suggest ways/methods/you name it) the difference between up hauling a windsurf sail and attempting a single forward (that's a loop, he he - the double one is another animal).
By that I mean: ways/methods/whatever that could yield a GH/R combo that could seriously be part of the System as above.
Forget geodomes ... get this (reduced by 95%, every 5th floor combo is shown) and think: what we can do for that matter?
best, Peter …
he new ones start like this:
Imports RhinoImports Rhino.GeometryImports Rhino.Collections
So when I try to run my old code:
Dim vertexList As New List(Of On3dPoint) Dim ribList As New list(Of OnLine) Dim spineList As New list(Of OnLine)
I get these errors:
Error: Type 'On3dPoint' is not defined. (line 93)Error: Type 'OnLine' is not defined. (line 94)Error: Type 'OnLine' is not defined. (line 95)
So this is probably a really easy question. Can I still use the OpenNURBS library or do I need to rewrite using Rhino.Geometry? If so, where is best reference for that?…
Added by Chris Wilkins at 3:32pm on October 15, 2012
i to usb cable and was able to connect Grasshopper with my digital piano realtime through a simple VB.NET component, no need for any other intermediate software. I used this library http://midiservices.codeplex.com/ (but there are several others).
The VB component outputs a list of 88 values that correspond to the intensity of each piano key at the current time (if the pedal is on and a key is depressed the value is halved, if the pedal is off the value is 0).
The rest of the definition is just to do something with this data. It uses these values to display each note as different floating colors that move with the wind (using Kangaroo). The strength of the wind changes as the music dynamics change.
If there are several devices connected you might have to change the line device.Open(0) to another number.
Definition: piano_midi.gh
…