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…
ey provide all the means to what I try to achieve.
What I need is to get a fast (as possible) evaluation of passive heat/solar gain from a certain facade. I know my building can cool to a certain degree (lets say 80 W/m2 - now lets forget other internal gains) and I want to be sure my facade is not letting excessive amounts of heat into the room/building. Normally I would make a full blown simulation to count my overheating hours and thereby evaluate my facade. To speed up the process, the idea is just to evaluate overheating hours in a faster way. So what I am thinking is that excessive amounts may estimated by counting high intensity irradiation patches in a critical sky-component or whatever such thing would be called that surpasses my sensible cooling load. My hope is that any facade visible to the sky-patches would very similar to the number of overheating hours if properly calibrated to a simulated model. However I have no idea right now, if this can be done.
Why do this? Speed, convenience, whole building thermal analyses.
@Chris and @Abraham The critical sky-component is made with LBs radiance component radiation and filtering the beam-components with highest effects from a yearly epw-file.
@Chris Conductive heat gains are also important especially if the facade is badly insulated, so the next step is to filter the outdoor temperature parallel with that critical sky-component and then do a static heat transfer analysis and combine that with the effect from direct sun influence. Again, no idea if it works.
Hope it makes sense. I a little embarrassed I drew you into this little experiment. This was not at all the point of the discussion. But now we are into it I like to know what you think. If it works its kinda neat, at least i think it is.
/K…
rld.wolfram.com/EnnepersMinimalSurface.html
when i type the equations for z,y,z it says a syntax error so i obviously do not understand how to construct an expression. (screen capture attached)
Any help/explanation of using this function would be greatly appreciated
thanks so much
Capture.JPG…
on 2: I think the reason to draw a fitness landscape is to highlight graphically the presence of local minima, even in a simple optimisation problem. In architectural terms, this means getting an idea of how many sub-optimal solutions there are in a problem, which helps while exploring conceptual design proposals.
Have a look at this very basic example (which I published with two colleagues on "Shell Structures for Architecture", chapter 18): a shell footbridge (24m x 4m footprint), which is generated by two parabolic section curves (the two apex heights are the two design variables). The maximum displacement of the structure under gravity load and self-weight is the objective function. Simple example, but several local minima and interesting shell forms (image below).
@AB,
The expression used by David in the Number of Samples Input is a simple “x+1”. By grafting the Divide Curve Output, he got 81*81 lenghts (6,561 values). You have to make sure that number is divisible by the no. of samples. The second expression used for the Length output is only a scaling factor (my guess), to control the height of the fitness landscape drawing.
Cheers…
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.…
precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.
2. AEC Projects are made by teams. Period.
3. Teams are organized with some sort of hierarchy. Period.
4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)
5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).
6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).
7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ... etc etc).
8. Efficiency is above all (even above tax-free cash).
9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.
10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).
If you combine all the above you'll have the answer (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.
PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).
best, Peter (Prince of Cynics)
…