and...how to bake meaningful assembly/component type of structures for the rest of the tedious work required > you know what I mean > the ugly part of our business > documentation drawings, BOM, tech etc etc etc.
For instance, let's focus to the planar glazing support items: absolutely no need to make them it via any smart app since they are plenty of them around in the market (unless you are I.M.Pei and you do that exceptional Pyramid wonder thing).
But...the goal is...hmm...to create some kind of "smart" (kinda, he he) solution where components (the "baked" ones, so to speak) are structured in such a way that further work (via conventional CAD apps) is easily managed. To speak in Rhino dialect: nested Blocks and/or nested Refs. Like having components in GH that could manage nested Block/Ref stuff (but I guess that you can do it rather easily via VB).
Back to that ugly truss: It's obvious that this is a nested collection of "repetitions" (should I call them iterations?) : meaning that a void top node owns a module truss that owns 2 supportive sub-trusses that are made by some pipes that own connecting items that own the planar glazing items etc etc etc.
With regard the "own" thing: Imagine a CAD file that is simply a container/place holder of some individual entities (called Models). These Models can be "linked" to others (in a nested parent/child relation). Links can be external of internal. They can be either References or Cells or Shared Cells. This the way that Microstation classifies/handles "entities" (a bit primitive, mind, but nobody's perfect - for the real thing see CATIA/NX).
Back to that ugly truss: Obviously this structure (actually the assembly/component combo related with the given solution) has to be transfered into classic 2d extractions (say: plans, elevations, sections et all). This is done why a weird thing called Dynamic Views/live markers in Microstation (you define Clip planes in 3d space that manage 2d extraction content in something called Drawing Model that controls other weird things called Sheet Models, all these live linked etc etc).
To make things more spicy...these 2d extractions can been viewed as master detail directives: from where 1:1 classic details are made (that is: you apply more Dynamic Views and live markers and life goes on - red pepper extra strong Russian vodka is a must when you do that type of work).
This is where Rhino is out of his depth (but to be fair: it's not designed for this type of work) and also this is where Microstation has no competition at least for AEC purposes (but to be fair: it is designed for this type of work).
Of course Autodesk...well expect soon the Gen Comp equivalent for Revit...a fact that complicates things (for Bentley) a bit given the Revit mania in the AEC world.
Moral: intelligence is good but it's only the tip of the iceberg. …
igned by this software may be terrible, this is how the future is being shaped, so an understanding of the technology is important.
http://bimandintegrateddesign.com/2014/10/24/googles-bim-busting-app-for-design-and-construction/
https://vimeo.com/107291814
-Projects are due May 8th at the WAAC Final Gallery (I think at 5:30 PM). You will have your board(s) pinned up and your physical model complete underneath. The location is still being worked out, so I will let you know when I know. After the physical submission, a digital submission is required as well. There should be at minimum -
A board with the discussed drawings and images below, named LastName_FirstName_FinalProject.pdf
A photo of your physical model (if not included on the board), named
LastName_FirstName_FinalModel.pdf.
These should be posted on the dropbox sometime before the last day of the semester. Your project will not be graded if you do not physically submit on May 8th and digitally submit sometime before the semester is over.
-Project brief is below
Project Brief: Up until now, you have been using grasshopper to develop, analyze, and fabricate architectural ideas in a very controlled format. The final project is a chance to combine this knowledge with your own design intent and aspirations. The project will use specific deliverables to spur growth, but also allow for you, the designer, to do what you please within the following boundaries.
Requirements:
# open project# must be a design project # story of what you are designing and why you are using grasshopper - specific design intent# must have physical scale model # must have 24” x 36” board - made in Adobe InDesign or Photoshop # grasshopper definition image # 1 artistic rendering - any format - with scale figures # 5 iterations of your project must be presented # 1 diagram to visually describe your project # text describing project # process drawings - photos/sketches/models/other iterations# this is the bare minimum - to have an excellent project, one must go above and beyond these requirements# talk to me if you have out of the box ideas of presenting/ teams / etc...
That is all, there are no assignments due this week, just keep working on those projects. I am available for help during the week, just email or post in the forum. USE THE GRASSHOPPER FORUM IF YOU ARE STUCK. There are many people on here that are way smarter than I that can help you.
See you all next week!…
logic in the script body. Now it works OK. Feeding all the right data required to Kangaroo is entirely trivial.
Happens now : create some "filters" about if a given cone is a classic one (suspended from a triad of high points == make triads of cables etc etc) or an inverted one (pulled from the ground == do something about that, anyway). This means find some interactive way to alter the cones data tree on a per branch basis (a slider access branches > the offset is altered > cone "type" > ...).
Just checked the P thing : it's all clear now (DeBrep).
That said I work in a smoke build on some MCAD app that does the following : when you hoover over a tool ... the underlying method is exposed and ... you can find what is where in nanoseconds.
Anders: I've looked at the Brep.Trim before posting this ... but .. well I can't get the gist of it (anyway the split loop did the job).
... If the Cutter is closed, then a connected component of the Brep that does not intersect the cutter is kept if and only if it is contained in the inside of cutter....
…
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
reaky thing consisting from triangulated "modules" (i.e an assembly out of this, this and that) where the exterior edges ARE always under tension (= SS 304/316 cables OR nylon) and the interior ones MAY be under compression ( = steel, aluminum, wood, carbon) OR ... some of them ...may be under tension. Bastardized T trusses deviate a bit from theory ... but who cares? (not me anyway). T trusses have many variants (but as the greatest ever said: Less is More).
2. Large scale T for AEC is the art of pointless since it costs around the GNP of Nigeria. Here's some indicative components from a module of a multi adjustable TX system costing (the module) ~ the price of my Panigale (Google that):
The above is mailed to a friend who has MIT (yes, that MIT: the top dog) on sight ... therefor he needs some appropriate "credentials", he he.
3. The distance that separates the above with the demo TDT node provided is around 666.666 miles - but we don't care: we are after Art not some testimony to vanity.
4. On purpose I've used a smallish ring to give you a clear indication upon the constrain numero uno in truss design: CLASH matters.
5. You'll need:
(a) A decision related with the tensioners (classic Norseman + SS cables or nylon machined thingies?).
(b) A machinist who can do elementary stuff (like the adapters) and can weld this to that (the "ring" for instance). His abilities must be 1 in a scale of 100. If the fella has a computer (not a CRAY) and he knows what 3dPDF is (hmm) ... well ... use that way to communicate with him PRIOR designing anything: He must agree on the parts BEFORE the whole is attempted (as a design in GH or in some other app).
(c) A carpenter with a wood lathe for the obvious. BTW: BEFORE doing any TDT attempt > ask the carpenter about the available wood strut sizes. Against popular belief DO NOT varnish the wood (use exterior alkyd/oil stains from some top maker like the notorious US company PPG).
http://www.ppgpaints.com/products/paints-stains-data-sheets
(d) Good quality cigars (and espresso) plus some classic music (ZZTop, PFloyd, Cure, Stones, U2 etc etc) during the assembly.
(e) Faith to the Dark Side (see my avatar).
May the Force (the dark option) be with you.…
r graphics get saved as 24x24 pixel images before they are put into the grasshopper application, which means the icons look like crap when you zoom in. This is the aforementioned problem that needs to be addressed in GH2. There have historically been two approaches to this issue:
Provide pixel images with several sizes.
Render vector graphics directly.
Option 1 is common for apps that do not have variable levels of zoom, such as Windows Explorer. When explorer shows file icons it either shows them in 16x16, 32x32, 48x48, 96x96, or these days, various HUGE sizes. As a result *.ico files allow you put in different images for all these target sizes. Since Grasshopper has variable zoom levels, this is not an ideal solution. Also, it requires a lot more work per icon.
Option 2 is becoming more and more popular as increased graphics speed now allows for the real-time rendering of vector graphics. Yet, you still need a renderer that knows how to draw vector geometry crisply at low sizes. All vector renderers I know just interpolate the geometry linearly and if a line happens to end up 'between pixels' it's just fuzzy.
I don't have hard and fast rules for the icons, but I try to adhere to at least these:
Keep a border of 2 pixels free around the icon content. So basically only use the inner 20x20 pixels rather than the 24x24 you're allowed. This is needed because the drop shadow needs to go there.
Only draw silhouette edges around shapes, not inner creases. Typically a 1-pixel line will do. I prefer to use a dark version of the fill colour rather than black for edges.
Loose curves can be drawn in 1 or 2 pixel thicknesses, depending on how important the curve is.
Try to avoid text in your icons (not always possible).
Stick to 1 colour family per icon, preferably per icon family. You can add highlights with another colour if you must, but too many hues make an icon hard to read (for the example the [Voronoi] icon, it has red, green and blue and it's a bit of a mess, on the other hand [Colour Wheel] has the full spectrum and seems to work quite well...).
Very roughly speaking, if there's both black and red geometry in an icon, it means the red is component input and the black is component output.
Drop shadows are pixel effects, applied to the 24x24 image. They have a blurring radius of 2 pixels, a horizontal offset of 1 pixel to the right, a vertical offset of 1 pixel to the bottom and they are 65% black.
When you use high contrast shapes (for example black edges on a light background) the anti-aliasing provided by vector renderers such as Xara or Illustrator won't be enough to make it look smooth. I'd recommend avoiding high contrast if at all possible, but if not possible then draw a 1-pixel line around the dark bits in 95% transparent black. This effectively extends the anti-aliasing range from 1.5 to 2.5 pixels and it helps make things looks smoother.
--
David Rutten
david@mcneel.com…
th Yalda's issue here.
The impetus for this related project is that there are thousands of weather file stations in the world that are producing publicly-available hourly data but have either not been running long enough to generate EPW files, have a few hours where there are gaps in the data, or are not keeping detailed radiation records that are required to produce EPW files. A full map of these weather stations (and links to order/download their data) can be found on the National Climatic Data Center (NCDC) website here:
http://gis.ncdc.noaa.gov/map/viewer/#app=cdo&cfg=cdo&theme=hourly&layers=1&node=gi
I have been working on a component that can take the hourly data downloaded from the map database above and produce an actual-year EPW file for any station on the map if you have a base EPW file for a nearby location. The main reason why I need the base EPW file is that many of these stations are not recording detailed radiation data with a pyranometer but they are often keeping detailed records of sky conditions like cloud cover and visibility (especially if they are airport weather stations). By finding the correlation between these sky conditions and radiation in the initial base EPW file, I have been hoping that I can a pretty decent estimate of radiation for the weather station that is only recording sky conditions. So far, the results look really promising but I really should quantify the percent error of this method before distributing it widely. I followed this method to create an actual-year weather file for Paris in the deadly 2003 European heat wave as you see here:
http://www.payette.com/post/2963956-perspective-international-climate-summit
Given the opportunity to test this for another case, Yalda, I have produced an actual-year EPW file of 2015 for what I think is your site (assuming that the ARDAL you are referring to is the Ardal in Iran and not the one in Norway or India).
For some reason, the peak temperatures in the NCDC records of Ardal are coming much earlier in the day than the nearby Esfahan. I am positive that this is something reflected in the NCDC and the WMO's records.
You can find the EPW file attached along with the GH file that I used to generate it and the 2015 text file that I downloaded from the map database (Shahr Kord). The the base EPW file that I used is from the US DoE database (Esfahan).
I am planning to release this component for connecting to the NCDC database with Dragonfly (the new insect that I have been working on to extend the capabilities of LB+HB). If any of you test out this workflow or have any feedback, please send it to me or post here.
-Chris…
tly light vehicles such as bicycles and variations thereof. Although frame design is mostly of a structural nature, there are a number of elements that interact mechanically. Also, as you may be aware, bicycle and high grade tubing is not of constant section so shelling method in FEA is out of the question, but even so, because the joint needs to be modeled very accurately, that means different geometry and properties for welded area, heat affected area and base material; like so a simpler FEA package may not suffice.
I don't know karamba extensively, rather superficially, actually, but I'm under the impression it mostly deals with beam analysis. Pls correct me if I am under the wrong impression. I must say it would be very nice to have a complete FEA package inside GH really!!
Typical workflow for me would be to model everything in Solidworks, and then export to Ansys Mechanical. Although Ansys needs to read every input and naturally remesh back again, integration within Solidworks, Catia, Inventor, Creo, Solidthinking... and the sort, works reasonably well.
Now, I don't remember Ansys having a Rhinoceros plugin so that you could bridge the 2 together, but maybe I should go check again.
3) Great work with that fractal tree. It's nice to know it is a possibility at least. I have tried Apophysis and others, but to my knowledge there's not an application that could deliver 3D fractal designs in a way that you could further manipulate with conventional modelling techniques, maybe apply textures and render, or export to CAM, 3D printing... etc.
P.S.: I have tried all the apps mentioned above and then some more. All of them have serious limitations when it comes to parametric design. For complex models they crash plenty upon rebuilding... a number of time consuming errors appear, and general work flow isn't very efficient for purely parametric work. Speaking for myself, I'd rather spend the time on a definition that enables me to have full control and then generate a new result within seconds, than model everything very quickly and then taking a long time with each new result.
(Thanks for the replies and sorry for the long text, you asked to elaborate).…
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. …