eople use different methods and components was the way that I learnt most of what I know (and it might solve parts of other's problems)! It's always apparent from forum posts that everything is work in progress.
The "divide curve" components gives you tangents (T) to the curve at the points you've made. You want the perpendicular (right angle) to the curve, so need to rotate this vector around point on the curve (P) by 90 degrees or Pi/2 Radians .
It seems you're finding your lengths as required, but then passing them through a unit Y vector - so they are only ever going to move in the Y direction. You need to use an "Amplitude" component with the perpendicular vectors from above and the lengths you've calculated.
Before sweeping you'll need to properly align the rectangles such that they are also perpendicular to the curve.
…
Added by Joe Allberry at 10:33am on August 4, 2015
se the final panels that you want to rotate, or is this file just an example? Do you also have panels in other facades (in other planes)? Is the positioning of the panels random? Is it completely random, or are there some rules? Are the dimensions of the panels fixed or can they change, and how?
2. If I understand correctly, you want to have 2 different rotations, right?
2a. The first rotation is around the edge of the panel that lies on the facade and you want it to be between 0 and 90 degrees, right? How is the angle for each panel defined? Based on the sun's beams direction and, if yes, how exactly?
2b. The second rotation is around the X axis, on the right point of each panel (which is fixed on the facade) and you want the angle of rotation to be specified based on an attractor point, right? Is there a minimum and maximum angle or do the panels always align with the attractor point?
For a better understanding of these questions, see the attached definition (open it together with your 3dm file). Here the first rotation is the same for all panels and is controlled by a slider (until you explain how you want to define the angles). The second rotation doesn't have any constrains, so the panels always "look" at the attractor. But, as you can expect, strange thing happen this way: Panels hit into each other, rotate until their solar side is looking downwards, etc.
Still, I believe, if you answer the above questions we will get somewhere.
Cheers,
Nikos…
Added by nikos tzar at 5:42am on September 24, 2015
s. Now ... I want from you to do the proper combo of columns for the job: I want a dynamic solution worth the name not some stupid columns going vertically. Use the tree regions in order to avoid distorting the glass modular floor. Say like this:
The truss must engulf the trees. Killing a tree is a crime (even touching it should be a crime). How to do it? Same for the rotating fins. Assembling the truss must take provision of the branches (if they are fragile).
Plaza must being divided as follows: a perimeter ring (critical) separates the glass floor panels from the ugly buildings AND the tree regions. Fine grey pebbles are OK for that. Then the panels deploy in the remaining region. Panels must be all the same: 90*90cm. Solve this "arrangement" with GH. Measure the drainage slopes and calculate the Buzon pedestals with GH (how far we need to adjust them: critical for ordering).
Cover the existing pavement with a 5cm thick layer of black pebbles (bonus: hide the cables for the led arrays and the rings [no WiFi required]). Create variations of these arrays in GH.
Create something for servicing the whole thing.
Greenhouse effect can raise the temperature below the glass flooring (BTW: panels are at 1-2 cm distance [Buson spacers] each other [rain + escaping gases]).
…
ese seem to have one issue which I need to be addressed for my application.
The grids which are produced using the methods on here follow the surface and tend to be equally spaced in two dimensions. What I need is to create a grid which keeps the distance between the path lines equal whether the angle between the lines is 90 of 45 degrees. At the moment the grids act a bit like contours on an OS map but they bunch up in the lower parts of the curves and spread out in higher parts.
Below is a picture of what I produce via grasshopper so far but using a grid formula from elsewhere on the forums along with Rhino to connect up the paths. In this example they seem equally spaced but they differ by anywhere between 0.755mm and 0.785mm which if scaled up would be a problem.
Any Ideas how to help me split the surface up equally in all dimensions, meaning that if I were to sweep the tool path with a circle radius of half the distance between the lines/rails, there would be no gap between the beads/filaments?
I appreciate any help or advice hugely.
Philip
…
width of the other letter
find the intersecting shape with Solid Intersection
re-orient final shape
This process sometimes breaks when a letter has one or more "holes" in it (eg: B, O, R). When this happens, the Solid Intersection component experiences an error and says "Boolean intersection set is empty". I don't know what that means.
I have tried the quick-fixes of flattening and grafting to no avail.
Could somebody shed some light on this issue?
I have internalized the letters into the attached GH def, but am also attaching the illustrator file that I'm using.…
e any affect, but that's way too slow if 90% of the GH program is initialization and creation of source geometry to then simply alter a bit or array here and there. When I use Python directly to change output values that I plug into former slider inputs, again no new solution is triggered at all so I'd have to recalculate the entire Grasshopper program which is simply not how Grasshopper normally works. How do I actually emulate a human changing a slider value one slider at a time in a way that makes Grasshopper behave normally so that only downstream flow is affected in an efficient way?
An related example would be if you have several separate programs in a Grasshopper page and you wanted to only change one of them without triggering full recalculation of them all.
At this point it's almost like a Windows mouse scripting utility is needed but if I need to do combinatorial combinations of all possible slider values, that seems quite thorny too unless I set up a pre-arranged array of values that could then simply be incremented "manually" followed by a right click to bake and then typing commands into Rhino to save to a file. UGH. That would be quite difficult to pull off since I need to control file names, but it's what I seem to need.
I'm using Python since it avoids thorny Grasshopper schemes and it allows me to access Rhino to save baked objects files.…
ving a copy of the surface in the original position. Second, and more frustrating, not all of the surfaces orient properly. A few lay flat but then rotate 90 degrees horizontally.
Any help or insights would be greatly appreciated!
Images and files are below.
grasshopper screenshot 1gh%20problem%20part%201.png
grasshopper screenshot 2gh%20problem%20part%202.png
grasshopper file slat%20wall%20C2.gh…
n account of the position of the sun and weather cannot be expressed in terms of a single set of luminous intensity values (which is what IES files do).
With regards to your example files, I agree with Chris. The primary reason for the low illuminance levels is that the light bounces are getting lost in the tube. Have you checked with the manufacturer/distributor if the location of the IES file should be inside the tube and not flush with the ceiling? Physically modelling such tubes in lighting software like Radiance (which is what HB uses) or AGI32 is a fairly expensive proposition. This is one of the reasons why manufacturers provide photometric data for such devices (however simplistic that data might be).
The candelamultiplier increases or decreases the luminous intensity values. So it will have a direct impact on the calculation. The primary reason for having that input was to enable users to do some testing with different lamp types and environmental factors such as dirt depreciation. You need not change them for your simulation. Assuming that the IES file is inside the tube, in order to make this calculation work inside HB you'd have to crank up the calculation settings to a very high level (start with -ab 10 -ad 4096).
Finally, due to shortcomings in the annual simulation software (Daysim), IES files will not work directly work with annual calculations. However, there is a fairly easy workaround for that issue. In case you are planning to run annual calculations with IES files, please let us know here.
Sarith…
ing illuminance and limiting exposure (lux hours). Hours with direct solar irradiance are likely to exceed the limiting illuminance thresholds, which range from (200 to 50 lux as per Table 3.4 in CIE 157:2004). It makes sense to consider direct illuminance (an ab=0 simulation in Honeybee) separately from a normal illuminance calculation.
Assuming that the museum exhibits have low to high responsivity to light, an ideal solution would minimize direct sunlight. For daylight from the sky and reflected light, it might be enough to keep the illuminance levels below the recommended thresholds and then sum up lux-hours.
Daysim, the annual daylighting engine used by Honeybee and DIVA, is not very accurate for direct-sun calculations. You will get more accurate results if you run your analysis with Radiance directly.
Instead of considering the horizontal illuminance grids, one can create grids that correspond to the dimensions of the exhibit and then average those values. I think single points, as shown in your gh file might not suffice. Calculating lux-hours is by far the simplest part of such a simulation. It will only require averaging these points, extracting them into an array and then summing up that array.…
eñadores, y creativos interesados en el aprendizaje de metodos avanzados de generación y racionalización de geometría compleja, y su implementación en distintas etapas del proceso de diseño.
Se abordaran los conceptos básicos para hacer frente a diversas problemas de diseño a través de la implementación de una serie de plataformas computacionales con el objetivo de construir un flujo de trabajo que permita optimizar proyectos de diversa escala y explorar esquemas geometricos complejos de manera rápida y eficiente.A lo largo del 6 dias trabajaremos con la plataforma de Modelado 3d Rhinoceros, el entorno de programación visual de Grasshopper y el motor de Renderizado de Vray.Estudiantes: $4,500.00Profesionistas: $5,500.00info+inscripciones:workshop@complexgeometry.com[044] 33 3956 9209[044] 33 1410 8975[044] 81 1916 8657
…