basis).
2. Rhino does not have a proper object display capability (objects per layer per view basis and/or per "collections" per view).
3. TSplines does NOT have any on-the-fly coordinate system definition capability (making "edit" a pointless waste of time). A small example about what this means as regards view navigation matters: imagine "hoovering" along a myriad of 3d objects: if you choose/opt for it: the moment that you touch an element (that could define a vector): this instantly becomes the working plane Z axis (very common capability in top MCAD apps). Not the same as a SpaceNavigator controller mind (far from it).
If these 3 were available > rebuilding anything with TSplines could be a joy (and very fast: about 2 minutes for your mesh)
Get this as well - Load Rhino file first attached in my previous reply (just for fun: not for your case, but we could do an extra WOW MERO spaceframe out of this paranoid M mesh).
BTW: Exo W is "tricky"…
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.…
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. …
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).…
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…
n fact) according a vast variety of "modes" PLUS the required clash detection (ALWAYS via trigonometry). In plain English: outline any collection of Breps and "apply" a truss that is topologically sound (planarization in case of quads etc is an added constrain). PLUS outline/solve what comes "next" after that truss (like the planar glazing "add-on" brackets of yours [ the ones that need redesign, he he], or some roofing/facade skin system [secondary supports, corrugated sheet metal, insulation, final cladding, dogs and cats])
2. Imaging doing this in real life (nothing to do with "abstract" formations of "lines" or "shapes" or whatever). This means primarily adopting a BIM umbrella: in plain English AECOSim, Revit or Allplan (I'm a Bentley man so I use AECOSim + Generative Components). This also means using "in-parallel" a top MCAD app for 1:1 details, FEA/FIM and the vast paraphernalia required for real-life studies destined for real-life projects (made with real-life money by real-life people). My choice: CATIA/Siemens NX.
3. What to send to Microstation (if not using Generative Components, that is) and/or CATIA? In what "state"? To do what exactly? For instance even if you could design this feature driven tensile membrane anchor custom node in Rhino (you can't) it could be 100% useless in CATIA:
4. Imaging masterminding ways to send them nested instance definitions of ... er ... a coordinate system (all what you need). In plain English: since is utterly pointless to send them nested blocks that can't been parametrically controlled (variations/modifications/PLM management/BOM/specs etc etc)... send them simply the "instructions" to place coordinate systems of components that ARE parametrically designed within Microstation and/or CATIA (classic feature driven design approach blah blah). So GH solves topology et all (working on data imported via, say, Excel sheets related with sizes of components etc etc) and sends to Microstation simply this (a myriad of "this" actually):
I do hope that the gist of the "method" (the ONLY way to invite GH to the party) is clear.
best, Peter…
wing2D
Imports System.Reflection
Imports System.Collections
Imports System.Collections.Generic
Imports Microsoft.VisualBasic
Imports RMA.OpenNURBS
Imports RMA.Rhino
Imports Grasshopper.Kernel.Types
Class Grasshopper_Custom_Script
#Region "members"
Private app As MRhinoApp
Private doc As MRhinoDoc
Public P, C As System.Object
#End Region
Sub RunScript(ByVal x_range As OnInterval, ByVal y_range As OnInterval, ByVal attractors As List(Of On3dPoint), ByVal factor As Double)
'''
If (attractors.Count = 0) Then Return
If (factor <= 0.0) Then Return
Dim Rnd As New Random(123456)
Dim failed As Int32 = 0
Dim Pts As New List(Of On3dPoint)
Dim Rad As New List(Of Double)
Dim Crc As New List(Of OnCircle)
Do
If (failed > 100) Then Exit Do
Dim x As Double = x_range.ParameterAt(Rnd.NextDouble())
Dim y As Double = y_range.ParameterAt(Rnd.NextDouble())
Dim pt As New On3dPoint(x, y, 0.0)
If (IsTaken(pt, Pts, Rad)) Then
failed += 1
Continue Do
End If
failed = 0
Dim d As Double
Dim i As Int32 = NearestAttractor(pt, attractors, d)
Dim radius As Double = factor * (Math.Pow(d, 0.8) + 0.5)
Pts.Add(pt)
Rad.Add(radius)
Crc.Add(New OnCircle(pt, radius))
Loop
P = Pts
C = Crc
'''
End Sub
#Region "Additional methods and Type declarations"
#End Region
End Class
Hope you can see an error :)…
nda like a T-Rex).
BTW: The real thing:
(a) accepts different top-bottom nurbs controlled by a variety of ways including attractors etc etc.This is the reason that several components are not "minimized" (this def is a "bit" garrulous I confess, he he).
(b) has clash detection capabilities in order to avoid embarrassing moments when talking with these Germans.
(c) has images of nice looking girls (for inspiration purposes).
(d) has images of MERO cases.
(e) uses about 50% less components.
(f) exports (EXCEL) drilling axis for those Germans.
...
(z) can manage cladding support systems/corrugated sheets/etc without them... this def is 100% academic (see the unfortunate Roissy 2F and a myriad similar cases). Given the opportunity use Foamglas (1 "s") and avoid a myriad of issues.
BTW: this is a classic case about why we desperately need a decent block management at bake time: assume that you want to export something to your favorite AEC app (AECOSim, Revit, Allplan blah blah). By what means can you do it? (other than exporting a myriad of "individual/stand alone" balls/cones/tubes etc etc).
best, Peter
…
ime runs out, of unexplored planets. These masters of gravity risk their lives for the adrenaline, dodging gigantic rocks that could hit their ships crashing into planets and no hope that they can be rescued.
Requires Kangaroo and Human (and in full with Firefly).
Goal of the game
You have four minutes to get six stars and reach the goal. Or die trying.
If a satellite hits you, you will leave fired.
The game has three types of control
1 Using the keyboard (requires Firefly). 2 With an external device such as a smartphone or tablet (requires Firefly and TouchOSC app). 3 Using the mouse, from the grasshopper interface.
Download files
Gh, 3dm, touchosc and textures.
Video
http://www.grasshopper3d.com/video/space-riders…