na cubierta o una estructura sigue en pie; presentar el router cnc en el evento depende del ejercicio práctico, para mayores informes no duden en escribir a luzyextura@gmail.com o a las oficinas de Bishon en Querétaro
_______________________________________________________
Workshop de arquitectura paramétrica mediante procesos digitales.
El temario incluye aspectos básicos y medios del modelado en Rhino, tanto de dibujo como de objetos en 3D, y las funciones de Grasshopper como una herramienta para el diseño paramétrico.
Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, también comprenderán todas las herramientas básicas y el estilo de trabajo.
Además del contenido teórico se incluye un ejercicio práctico, que consiste en la producción de un modelo 3D, abarcando desde las ideas generadoras, el diseño, dibujo de piezas para su fabricación y construcción final.
El workshop tiene dos semanas de duración, con un horario de 8 am a 3 pm, el costo para estudiantes es de $4590, para la comunidad en general $4900. 35% descuento antes del 22 de julio
Informes bishion@mail.com, luzytextura@gmail.com.
Teléfono en Querétaro 4422 75 2863
Teléfono en la Ciudad de México 04455 4381 3302…
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
essarily architectural. As you can guess from the tone of my previous response, I finished with school and had a hard time finding a job that focused on the technologies I delt with all through undergrad and grad. During grad school I was working with ASGvis (the makers of V-Ray) so I got exposed to the software side of things both on the support/management side and the development side. Now I'm off on my own doing development projects like RhinoHair, a few others, and some custom plugins for clients. Not necessarily what I thought I'd be doing after grad school, but I'm certainly enjoying it more than the "standard" practice of architecture.
I definitely understand "creating" a program. I did both my undergrad and grad at Catholic U here in DC, and although there was some ground work laid in regards to fabrication, I was one of only two or three students spearheading a lot of the scripting/GH/parametric stuff and some of the topics that go along with them (algorithmic design, adaptive systems, advanced geometry). One thing that was incredibly helpful for me was to pair up with the most advanced and forward thinking professor(s) that you can and take their studios, electives, and/or help out with their research. I was lucky enough to pair with a professor who had been at MIT and really encouraged me to explore my interests and sharpen my technicial skills.
It might also be a good idea to stick your head in some other departments, probably the math and engineering ones, or even biology and economics if there are some forward thinking professors. Talk to some people and get a different perspective on things. When I went to the ACADIA conference in 2008 it really opened my eyes to some of the potential influence from those different arenas.
Fabrication wise, I'd really try to focus more on milling (3 axis is fairly standard, 5 axis if you can get access) than 3d printing. Printing is a lot of fun, but ultimately we're not printing buildings (yet), so some of the milling processes will be much more valuble. If your school doesn't have those kind of facilities on campus (either in the Arch dept or engineering or something), then contact a local fabricator and see if you can work together somehow or someway. You'd be surprised and how many fabricators are interested in talking to architects.…
Added by Damien Alomar at 3:13pm on February 8, 2010
...hmm... points across the facade edges are not included (or may be some) and thus the whole thing is the art of pointless.
2. See the 1a unfinished part ... that defines internal boundaries for that purpose - then you need to create points across the edges, random reduce them and merging the list with the other points...blah blah.
3. That way each facade could yield structural members that touch the edges (where the biggest HEB/columns are expected to be). Obviously nodes are shared between facades with a common edge - the best logical approach for obvious real-life reasons.
4. The whole approach is stupid : here we need some Hoop snake "loop" control (that could take into account the critical connection angle constrain) in order to achieve a "progressive" deployment of the diagonal members in order to satisfy structural requirements and ... hmm...aesthetics. Free espresso for everyone is an added bonus.
5. Bottom to top design mentality is urgently required here: mastermind some 3d conceptual arrangement of nodes keeping in mind ... well...just 345,67 different real-life factors (but you could combine insulation and fireproofing if you use my favorite material: Foamglas - name with with one "s"). That way you can define the critical deployment planes : i.e. diagonal rigidity members, some facade aluminum system and floor main perimeter I-Beams MUST be in different planes.
I'll be back with a more stupid version of that thing.
may the Force ...blah blah
…
ncluded 3) using a freaky thing that "makes" Planes in order to do ramps (spot the Vodka option = Mobius + antigraviity OFF).
Don't touch the freaky things: for the moment just go and play with this palatable portion (GH components, nothing to fear he he):
depending on choice in gates: Paranoid (Mobius "shifted in Z")
sane (using corrected Planes):
not so sane:
What we have learned so far? Well ramps (and most of other things) ... it's about Planes (coordinate systems) you know.
Again: this is for fun/demo ONLY. I'll prepare a dedicated def for your case soon.
have fun, be brave
…
he past Architecture was the art of sketching: some "idea" with pencils/crayons + vellum paper (or with some computer) > then "others" trying to make this happen. This in general is known as top-to-bottom approach. Naive and dangerous (for the reputation/reception/acceptance of Architects/Architecture) to the max.
2. These days we work both ways: whilst some work on some "idea" (called it: "assembly") others (in sync mode) resolve the bits and nuts of that "idea" - up to 1:1 level of detail (called it "components"). This is the bottom-to-top approach. Make this your way: NEVER proceed in something whist's not EVERY bit of that something is well addressed (with at least 3-5 ways).
3. The emergence of parametric (GH, Generative Components, Dynamo) in AEC (an approach well known in MCAD word many years ago, mind) made things ... worst: the tremendous topology exploitation capabilities blinded people's mind and they are completely sucked up by the forest forgetting/by passing the critical fact that there's no forest without trees.
4. That's expected: is in the human nature to follow/admire the blink/glam and omit/skip the humble. It's the easy way you know, he he.
5. The tremendous growth of countries the likes of UAE/China/Russia made AEC things ... even worst: lot's of cash available > make us some encomium to Vanity, forget Modesty. You can replace "Vanity" with "New Frontiers" ... if you like fooling yourself.
Some Academics are not capable to understand all that: if they could they would potentially operate in the field (where the pink color is rarely used) and not in fishbowl(s). Some Academics believe that an "idea" is the 99% of the whole whilst actually is less than 1%. But on the other hand anyone can do Architecture (even Architects, he he).
That said (Vanity crisis) you want some other "component" options for this case of yours? (starting with "some" dollars more and ending with the mortgage the house/sell wife+kids option).
take care (and kill them all)…
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…
e "amusing") - but all the intelligence is lost + the assembly hierarchy is lost + my dog is MIA as well.
2. This relates ONLY with some members of a given XFrame (meaning that you need a zillion things [or some "abstract" ones] for a relatively "large" scale tensegrity truss).
Meaning: instance definitions ... or Armageddon.
Meaning: some "adjustments" in a given definition having in mind similar systems (Plan B: abandon ship).
3. The fact that the 4 (ex single "tube") members are NOT planar (while ones in the previous example) AND their angles are variable as well (blue in the previous example) makes things hideously complex: we need ways to achieve levels of freedom AND some rigidity: the other way is to machine custom MERO type of stuff (balls, that is) that could host the adapters (but this means 1 zillion DIFFERENT balls). So in this variant shown the angles are managed by a "fixing" ring and rigidity by double tube [MERO type] members. Cables shown are classic Norseman stuff (Plan B: abandon ship).
4. So it's not a mystery why nobody uses that type of nonsense stuff for real-life AEC projects (other than smallish decorative things with a very limited load bearing capacity).
5. All that ... BEFORE the ultra complex system that supports the roof.
STEP mailed but ... well ... what about doing some nice tensile membrane? I have a zillion "simple" defs that do that sort of stuff.
best, Lord of Darkness (ex SardineLand Lord)…
posted rather testifies that. Randomness is the virtue here NOT equality. BTW: forget completely "optimization" of the mount points et all.
2. The thing in pic is airy (quality Numero Uno on that type of stuff, especially for things with no real load bearing capability) meaning minimum profiles ... meaning FORGET wood. Use aluminum tubes (rather cheaper than wood) as follows: screw the Captain Hook "node" in some kind of machined tube end (a humble massif cylinder that is screwed or clued [Araldide 2 part Epoxy] to the tube AND machined with threads for the hook).
NOTE: I could make a simple tube "adjustment" system that could allow you to build that on-the-fly WITHOUT any GH/K or anything: just start connecting variable length tubes ... er ... hmm ... randomly. This is the recommended way to do it anyway: we can't emulate art with software and even if we could: it's the art of pointless.
3. Additionally the whole conceptual aesthetics BEG for some kind of metal instead of wood. The fact that wood is aplenty in Russia doesn't justify killing trees (for any scope), anyway.
4. Using rings to "attach" the hooks ... well that could yield a highly unstable structure for more than obvious reasons. I could provide to you dozens of highly sophisticated bespoke solutions on that matter ... but they are unsuitable for this DIY occasion: I must think on a zero basis on that puzzle - allow me some time to propose the best "adapter" (easy, cheap, stable and allowing some liberties).
5. A Connectivity tree (see for instance Sandbox) can resolve with easy the equal axis worry of yours (thus: FORGET equality, just buy a hack-saw [ aluminum is very easy to "cut", he he]).
All in all: I like that a lot. I'll post soon some examples related with the all overall approach (including the node, he he). You don't need Kangaroo for that (and dare I say no structural analysis IF the structure to be is "similar" in size with the one pictured).
more soon, best, Lord of Darkness…
d the Pts from 1 to the List 2 of reduced Points.
4. Sort the List VS the curve (or use some smart way to properly "insert" Pts from 1 to Pts from 2).
public List<Point3d> SortPointsAlongCurve(List<Point3d> points_list, Curve sorting_curve) { points_list.Sort((point1, point2) => { double point1_t = 0; double point2_t = 0; sorting_curve.ClosestPoint(point1, out point1_t); sorting_curve.ClosestPoint(point2, out point2_t); return point2_t.CompareTo(point1_t); }); return points_list; }
or
public List<Point3d> SortPointsAlongCurve2(List<Point3d> pList, Curve curve) { List<Point3d> pSorted = new List<Point3d>(); List<Point3d> pClosest = new List<Point3d>(); for(int i = 0; i < pList.Count;i++){ double t; curve.ClosestPoint(pList[i], out t); pClosest.Add(curve.PointAt(t)); } Point3d pPrev = pClosest[0]; Rhino.Collections.Point3dList points = new Rhino.Collections.Point3dList(pClosest.Skip(1).ToList()); for(int i = 1; i < pClosest.Count;i++){ pSorted.Add(pPrev); int ind = points.ClosestIndex(pPrev); Point3d pNext = points[ind]; points.RemoveAt(ind); pPrev = pNext; if(i == pClosest.Count - 1) pSorted.Add(pPrev); } return pSorted; }
5. Do some Polyline or Nurbs .…