rquitectura y el diseño, tanto como plataforma de comprobación de ideas como de producción directa de objetos finales. Los participantes serán introducidos en el uso de softwares de modelado 2d y 3d para la generación de geometrías que serán posteriormente mecanizadas in situ en una máquina de control numérico CNC de 3 ejes.
Para este workshop, proponemos un ejercicio de eficiencia en el diseño y optimización de la producción. Apoyándonos en las nuevas herramientas digitales, los participantes crearán una estructura que sea capaz de soportar su propio peso (como por ejemplo una silla, un banco, etc…). Se pretende fabricar una estructura ligera compuesta por un único material y montada sin el uso de herrajes o componentes externos.
Más informaciones aquí: http://www.mediodesign.com/?p=2141
…
it within the same smart umbrella? Or put it differently: is it worthy to exploit/consider/evaluate GH methods and development orientations that could "approximate" Utopia?
Let's split the case into segments:
The parametric part thing (although critical) is complex and rather beyond the scope of GH. Affects Rhino far more than GH. That said Microstation has 3 levels for doing this (but forget Microstation and/or Gen Comp).
So for a start we can focus in GH acting as a "composer" in 3D place of all the required (hopefully real) parts for the job. Parts must be nested AND readable as such by an external AEC app.
I'll post here (soon I do hope) all the parts that are required for assembling this. I mean individual static "blocks" that we assume (wrongly) that remain static: I mean we presuppose that the whole GH geometry is fixed (thus this is really a smart sketch of some sort) and no further changes are on schedule (that MAY affect parts).
That said I prefer an incomplete Utopia (one thing that "does" it all, or it thinks that does it) than a myriad of individual apps that take input one from the other and promise the Holly Grail (and/or delivering it). The core reason that I use Microstation as my basic platform is exactly that (obviously with a certain price to pay: bugs, shortcomings, wrong concepts in places etc etc etc).
Best, Peter
…
b, then tried again, but I still have no luck. So what I did is I modeled the building again in Rhino and reduced the curves then I imported the geometry into GH and used the HoneyBee zone by surfaces component , but I noticed that after I grabbed the new components I get a "NULL" if I plug a panel to the final zone. Finally I decided to model a very simple box and grab all its surfaces to create a zone , and to my surprise I still get "NULL" Am I doing something wrong ? here are what I did to create this one zone box
1- modeled a 3d box in Rhino
2- Exploded it
3- In grasshopper I created HB-surfaces ( Floor, Ceiling, 4 individual walls and added I glazing by ratio to one of the walls)
Here is an image, also I attached the file, the box components are grouped with an orange background. Now I'm convinced that I have a bug or something because it can't get easier than creating a zone from a simple box and yet I get a "NULL" message.
…
iew mode:
instead of the fabrication mode (individual Breps ready for 3d printing - minus "some" little details with regard their effortless connection > this is what V3 does):
2. GH does not (AFAIK) include the mesh.Offset capability (used a little C# for that).
3. I promise to translate the test C# used into native components ... if the result is what you are after (you never know, he he).
4. Rounding (fillet) the thickened panel lips (around the hole and with regard perimeter panels) is doable but only via code: AFAIK GH does not include the Surface.CreateRollingBallFillet method (something that does fillets, that is - forget it for the moment). In fact ... there's a complex way to do it without that method ... but is not for the moment (next week you'll be 100% more experienced, he he).…
that greatly facilitates "impossible" tasks of the past).
Anyway..
1. Graft means get a List and make a Tree thus the sweep has profiles (as items in tree branches, i.e. Lists) VS rails as ... er ... we need to match apples to apples here: for each branch that has profiles get a branch with a single item (the rail).
2. In general without fully understanding the way that GH manages "nested" collections (DataTrees) is utterly frustrating to attempt anything. Spend some time on that matter. Some fellas would advise you to learn "on the way". I would strongly advise the opposite: first understand what a piston is and then design a machine.
3. Rules et all ... well you can do some stuff via components but the things that I have in mind require code not because is far more "efficient" in complex data structures (a matter of personal preference that one) but mostly for controlling items in collections on a per item basis (don't ask what this means, he he) tracking history, using hierarchies of instance definitions (blocks), controlling sliders, controlling events ... and many other ultra freaky things.
4. Coding is the next step towards the Holly Grail. Requires serious commitment, time and guarantees frustration, agony, and pain until ... you arrive into a point where all things appear "easy" (kinda like attempting a double forward in windsurfing: easy provided that there's "some" scars around). …
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…
, HVAC, blah blah).
BIM is NOT a parametric process at least having in mind graphical editors the likes of GH (or stuff the likes of Generative Components): it's a holistic data management approach. Some concepts used in BIM apps (for instance in AECOSim etc) the likes of "walls"/"openings" etc are "parametric" in the sense that allow auto perforation of this with that. On the other hand AECOSim is feature driven (since Microstation works in that "mode" as well) ... a thing that complex things even more with regard what is actually "parametric" and what not.
BIM is as good as the meta data structure is (especially the spec related aspect - Goggle MasterFormat and the likes). BIM AEC apps are notoriously incapable to work (without a lot of lines of code) with proper RDBMS. On the other hand Bentley Systems ProjectWise ... well ... but that's another animal (by no means a topic for the inexperienced).
In descending order or importance a contemporary AEC practice should use:
1. A general information "controller" like ProjectWise (who said/did what/when/why).
2. A Specs (say CSI - not the TV soap opera) management app.
3. Several Meta data RDBMS.
4. A BIM suite of apps.
5. Optionally some parametric thingy.
PS: For AEC ... when inviting the parametric thingy to the party you have only 2 options:
ProjectWise + AECOSim + Generative Ciomponents (my choice).
?? + Revit + Dynamo.
…
would actually be to parametrize the dome itself. Otherwise, turning the 3D lines into a sorted list of grouped points is going to be a huge mess, and we are not even sure if the CAD model would have some kind of internal order to start with...
2.- Anyway, if you want to do it the 'hard' way (choosing each point independently, totally not recommended...), you should first find the 'base panel' to perform sun angle calculations, and then modify the top geometry proportionally to this angle:
3.- If you'd rather instead work with opening variables holes on it, the procedure would be very similar, but instead of modifying the geometry, drawing the circle and the resulting surface:
See files attached.
Good luck!…
icosecond laser. In their wisdom the manufacturers of the laser have paired a cutting edge laser with an ancient CNC. The machine requires straight cut lines only (it doesn't handle curves) so these have to be converted from the original design, for which I'm using Grasshopper. Also, it requires multiple passes at a slight offset each time in order to ablate the silver successfully, generated again using Grasshopper.
So far so good. The machine controller is very picky about the format of Gcode it accepts, and it will only accept Gcode. So I am currently exporting the Grasshopper processed design as a dxf and running it through a dxf2gcode converter. This must then be manually processed (I use vi!) to change x references to c, y references to d and remove any references to z. Precision must be to 3 decimal places.
Silkworm is of course ideal for creating Gcode but is pretty specifically written for 3D printing I think? How configurable would it be with the config file to produce what I've described above, even if it's raw gcode which could then be wrapped manually with a header and footer? I'm thinking you'd have to rewrite portions of the module which is of course a bit pointless for such a specific task. Thought I'd ask anyway!
Cheers,
Simon
…