r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
a modélisation paramétrique avec Grasshopper pour Rhinoceros3D ainsi que démontrer plusieurs façons de l’appliquer à votre travail architectural.
Cette formation est conçue comme une expérience augmentée autour de l’architecture paramétrique et elle comprend aussi :
+ Une introduction au design paramétrique par Francesco Cingolani+ Une étude de cas d’un projet de l’agence de l’agence HDA Hugh Dutton Associés+ Acces gratuit 3 journées à l’espace de coworking SUPERBELLEVILLE
INSTRUCTEURS
FRANCESCO CINGOLANI . designer, enseignant en architecture paramétrique, co-fondateur deSUPERBELLEVILLE coworking, collaborateur de l’agence Hugh Dutton Associés. – voir le profil Linked-in
ŞULE ERTÜRK . Architecte diplômée de l’Université Yildiz Teknik à Istanbul, Master en architecture paramétrique, travaille actuellement aux Ateliers Jean Nouvel dans le département 3D. - voir le profil Linked-in
QUENTIN GAUCHER . Architecte DE-HMONP, diplômé de l’ENSA Paris La Villette, intervenant en architecture paramétrique sur divers projets - voir le profil Linked-in
DATES 25 mars 2013 . Annonce de la formation / Début des inscriptions5 avril 2013 . Fin des inscriptions13 – 14 avril 2013 . Formation
HORAIRES Samedi et Dimanche 13 et 14 avril . 10:00 > 13:00 – 14:00 > 19:00Total : 16 heures
TARIF700 € professionnels400 € étudiants
RÈGLEMENT50% est à régler lors de l’inscription (au plus tard le 5 avril)50% au début de la formation.Les règlements s’effectuent par carte bancaire via Paypal ou par virement bancaire.
NOMBRE DE PARTICIPANTSMinimum pour l’activation de la formation : 5Maximum : 7
CONTACTInscriptions et réglements : fr.cingolani@gmail.com . SUPERBELLEVILLE coworkingInformations : quentin.gaucher@gmail.comimmaginoteca.com/grasshopper
EN BONUSLe café italien et les plats faits maison de Claudia offerts aux participants :)…
is to reduce the gaps between built environment and digital technologies seamless integrating design and fabrication. Among the benefits: efficient use of production resources, material-specific design concepts, outcome optimization and durability.
Jointly organized by FabLab Poliba and Polytechnic University of Bari, Self Made Architecture 03 aims to help students to develop new skills and tools on 3D Modeling, Advanced Parametric Modeling, Structural and Daylighting Optimization and Digital Fabrication.
The tools we’ll use:
#Rhinoceros3D #Grasshopper3D #Kangaroo #Ladybug #Honeybee #Cura #BigRepOne
The students will be involved in morning lectures and hands-on workshops during the afternoon with a Do-It-Yourself and Do-It-Together approach. They will be asked to work on group projects and take part of the final phase of a temporary architecture installation.
More info:
Days: 2nd July 2018 to 7th July 2018 Location: Italy > Puglia > Bitonto Language: English Students: 27 International students Credits: 2 ECTS Benefits: Fully Fundend Summer School. Free Application for the Summer School, Free Accommodation with B&B and meals included, Free Enrollment to FabLab Poliba Elegibility criteria: students and graduates of architecture, design and engineering.
Apply: www.poliba.it/didattica/sma03 Deadline: 31st May 2018 at 12:00 (noon) Contacts: info@fablabpoliba.org Scientific Coordinator: Prof. Nicola Parisi…
racting isocurves in Grasshopper in order to use them as more curves. If I could figure out the thorny use of Grasshopper data trees within Daniel Piker's Geometry Wrapper VB script that is used here, it would be considerably faster than having to include each isocurve in a separate field strength lookup.
The way marching cubes and an isosurface work in the code, is to simply find the distance to the closest point on each curve and run the distance to that point through a slow equation to determine field strength there, usually an r^2 operation, and this causes awful bulging where geometry clusters, so I just hacked it to use no math and instead yes/no values based on a fixed radius value, doubling the speed of the script and removing all bulging effects, so it's not really metaballs any more but after MeshMachine relaxes the mesh under tension, the result is similarly smooth. To build up a full 3D spacial field, it simply adds the field values from each curve (or point) together via a loop over all those geometry objects, so there is no big implicit equation created except such summation.
HOW DO I ADD SURFACE ISOFIELD TO THE SCRIPT ITSELF SO I CAN AVOID THE ISOCURVE KLUDGE?
It's not the VB I'm thrown off by but the lack of a real loop where a data tree is used:
I can likely write my own calculate_surface_field function since it just needs to spit out one of two fixed numbers depending on using Rhinocommon to find the distance of the test point (a corner of a marching cube) to the closest point on the surface. But the above loop doesn't cooperate with my attempt to rewrite it as simple loops going through each point, curve, and surface for each test point. I can barely tell what's looping here, as he has stuffed all geometry into one container and then tests for curves. I'd rather just make loops for separate Points, Curves and Surfaces inputs and get rid of the baffling data tree.
The overall canvas is also rudely updating the preview twice, making it much slower than the two big components actually take so solve, as I believe it may be regenerating a display mesh between VB and MeshMachine solutions?
…
mental studies and make it possible to run the analyses faster and more accurately.
Thanks to RADIANCE’s gendaymtx (and the awesomeness of Greg Ward, Ian Ashdown, and the help of Rob Guglielmetti) Ladybug is now using a brand new sky model which makes hourly and real time radiation analysis possible (Watch this video). SunPath is now improved and there are quite a few new components that work with SunPath including shadow mask, ray-tracing (short video), and view from sun (short video).
There are two new components for shading design and shadow studies that are not fully functional but are good enough to be released as a test version (This video shows the shadow study component).
I’m the most excited to introduce and welcome Chris Mackey as the new co-developer of the ‘bug who has developed the Humidity Ratio calculator for Ladybug which you can find under weather data analysis tab. People working with HVAC system design and thermal comfort may find it particularly useful and you can consider this component an initial step towards a Psychrometric chart for Ladybug.
There have also been a few enhancements to the analysis components. The parallel input is working properly now and the analyses are run much faster (here is the proof!). The orientation study is also modified so the legends are normalized and will stay at the same size and in the same location. And there’s much more to be explored when you install the components!
So far I couldn’t find a fast and accurate way to calculate the Vertical Sky Factor but both the viewRose (short video) and the shadow mask components calculate the values of VSF in 2d and 3d which can be used for your studies. I believe there should be a faster way to calculate the VSF based on view analysis.
You can download the new version from the same link and give it a try. I also updated the source code on GitHub and prepared some new examples to get you started. Don’t forget to update your GHPython to the latest release (Thanks Giulio) before updating the Ladybug.
Thanks again for all the support, great suggestions and the kind comments. Please keep the suggestions coming and stay critical to the ‘bug and the results of your studies.
Best,
Mostapha…
e a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative.
I get that. That’s why that 3D shape I’m trying to apply the voronoi to was done in NX. I do wonder where the GUI metaphor GH uses comes from. It reminds me of LabVIEW.
"What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."
Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it.
It’s not the primary components that catalyzed this thought but rather the secondary components. I was toying with a component today (twist from jackalope) that made use of three toggle components. The things they controlled are checkboxes in other apps.
Take a look at this jpg. Ignore differences; I did 'em quickly. GH required 19 components to do what SW did with 4 commands. Note the difference in screen real estate.
As an aside, I really hate SolidWorks (SW). But going forward, I’ll use it as an example because it’s what most people are familiar with.
"[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."
Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.
I agree, and disagree. I believe parametric applies equally to GH AND SW, NX, and so forth, while algorithmic is unique to GH (and GC and Dynamo I think). Thus I understand why you prefer the term. I too tend to not like referring to GH as a parametric modeler for the same reason.
But I think it oversimplifies it to say parametric modelers move the clicks. SW tracks clicks the same way GH does; GH holds that information in geometry components while SW holds it in a feature in the feature tree. In both GH and SW edits to the base geometry will drive a recalculation, but more commonly, it’s an edit to input data, beit equations or just plain numbers, that drive a recalculation.
I understand the difference in these programs. What brought me to GH is that it can create a visual dialog that standard modelers can’t. But as I've grown more comfortable with it I’ve come to realize that the GUI of GH and the GUI of other parametric modelers, while looking completely different, are surprisingly interchangeable. Do not misconstrue that I’m suggesting that GH should replace it’s GUI with SW’s. I’m not. I refrain from suggesting anything specific. I only suggest that you allow yourself to think radically.
This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Given a choice, I'd pick kick-ass algorithmic modeller with no parametrics tacked on.
2. Visual Programming.
I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
I'll admit, this is a bit tough to explain. As I've re-read my own comment, I think it was partly a precursor to the context sensitivity point and touched upon other stated points.
This now touches upon my own ignorance about GH’s target market. Are you moving toward a highly specialized tool for programmers and/or mathematicians, or is the intent to create a tool that most designers can master? If it’s the former, rock on. You’re doing great. If it’s the latter, I’m one of the more technically sophisticated designers I know and I’m lost most of the time when using GH.
GH allows the same freedom as a command line editor. You can do whatever you like, and it’ll work or not. And you won’t know why it works or doesn't until you start becoming a bit of an expert and can actually decipher the gibberish in a panel component. I often feel GH has the ease of use of DOS with a badass video card in front.
Please indulge my bit of storytelling. Early 3D modelers, CATIA, Unigraphics, and Pro-Engineer, were unbelievably difficult to use. Yet no one ever complained. The pain of entry was immense. But once you made it past the pain threshold, the salary you could command was very well worth it. And the fewer the people who knew how to use it, the more money you could demand. So in a sense, their lack of usability was a desirable feature among those who’d figured it out.
Then SolidWorks came along. It could only do a fraction of what the others did, but it was a fraction of the cost, it did most of what you needed, and anyone could figure it out. There was even a manual on how to use it. (Craziness!) Within a few short years, the big three all had to change their names (V5, NX, and Wildfire (now Creo)) and change the way they do things. All are now significantly easier to use.
I can tell that the amount of development time that’s gone into GH is immense and I believe the functionality is genius. I also believe it’s ease of use could be greatly improved.
Having re-read my original comments, I think it sounded a bit snotty. For that I apologize.
3. Context sensitivity.
"There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."
Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?
I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal [...] is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.
You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
You bring up both interesting points and limits to my understanding of coding. I’ve reached the point in my learning of GH where I’m just getting into figuring out the sets tab (and so far I’m not doing too well). I often find myself wondering “Is all of this manual conditioning of the data really necessary? Doesn’t most software perform this kind of stuff invisibly?” I’d love to be right and see it go away, but I could easily be wrong. I’ve been wrong before.
5. Components.
"Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."
I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data.
I kinda like this. It’s a continuation of what you’re currently doing with things like the panel component.
"Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"
It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
6. Integration.
"Why isn't it just live geometry?"
This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry.
"Maybe add more Rhino functionality to GH. GH has no 3D offset."
That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).
On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
You work for McNeel yet you seem to speak of them as a separate entity. Is this to say that there are technical reasons GH can only access things through the Rhino SDK? I’d think you would have complete access to all Rhino API’s. I hope it’s not a fiefdom issue, but it happens.
7. Documentation.
Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.
Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
It begs the question that I have to ask. When is GH1.0 scheduled to launch? And if you need another person to proofread the current draft of new primer.
patrick@girgen.com
I can’t believe wikipedia has an entry for feature creep. And I can’t believe you included it. It made me giggle. Thanks.
8. 2D-ness.
"I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"
I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
I believe it’s been helpful for me to have figured this out. I recently completed a GH course at a local Community College and have done a bunch of online tutorials. The first real project I decided to tackle has turned out to be one of the more difficult things to try. It’s the source of the questions I posted. (Thanks for pointing out that they were posted in the wrong spot. I re-posted to the discussions board.)
I just can't seem to figure out how to turn the voronoi into legitimate geometry. I've seen this exact question posted a few times, but it’s never been successfully answered. What I'm showing here is far more angular than I’m hoping for. The mesh is too fine for weaverbird to have much of an effect. And I haven't cracked re-meshing. Btw, in product design, meshes are to be avoided like the plague. Embracing them remains difficult.
As for offsetsurf, in Rhino, if you do an offsetsurf to a solid body, it executes it on all sides creating another neatly trimmed body thats either larger or smaller than the original. This is how every other app I know of works. GH’s offsetsurf creates a bunch of unjoined faces spaced away from the original brep. A common technique for 3D voronois (Yes, I hit the voronoi overuse easter egg) is to find the center of each cell and scale them by this center. If you think about it, this creates a different distance from the face of the scaled cell to the face of the original cell for every face. As I've mentioned, this project is giving me serious headaches.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
Thank you for taking the time to reply David. Often we feel that posting such things is send it into the empty ether. I’m very glad that this was not the case.
And thank you for all of the work you've put into GH. If you found any of my input overly harsh or ill-mannered, I apologise. It was not my intent. I'm generally not the ranting sort. If I hadn't intended to provide possibly useful input, I wouldn't have written.
Cheers
Patrick Girgen
Ps. Any pointers on how to get a bit further on the above project would be greatly appreciated.
…
ature. By investigating the process of decay across various scales, we will formulate rules of generating decomposition as our design research area. These rules will evolve into design strategies for the creation and fabrication of a large-scale prototype. The design and fabrication process will be informed by the use of robotic fabrication techniques.
The three-week long programme is formulated as a two-phase process. During the two-week initial phase, participants benefit from the unique atmosphere and facilities of AA’s London home. The second phase, lasting for a week, shifts to AA’s woodland site in Hooke Park and revolves around the fabrication and assembly of a full-scale architectural intervention.
Prominent Features of the programme:
• Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
• Facilities: AA Digital Prototyping Lab (DPL) offers laser cutting, CNC milling, and 3d printing facilities. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router, various woodworking power tools, and robotic fabrication.
• Computational skills: The toolset of Summer DLAB includes but is not limited to Rhinoceros, Processing, Grasshopper, and various analysis tools.
• Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies through theoretical sessions and seminars forms one of the major goals of Summer DLAB.
• Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
• Fabrication: According to the specific agenda of each year, a one-to-one scale prototype is fabricated and assembled by design teams.
• Lecture series: Taking advantage of its unique location, London, Summer DLAB creates a vibrant atmosphere with its intense lecture programme.
Eligibility: The workshop is open to architecture and design students and professionals worldwide.
Accreditation: Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications: The AA Visiting School requires a fee of £1964 per participant, which includes a £60 Visiting Membership fee. A deposit of £381 is required when registering with the online form. The deadline for applications is 20 July 2015. No portfolio or CV is required. Online application link:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=325
Return train tickets between London-Hooke Park, accommodation & food in Hooke Park, and materials from Digital Prototyping Lab (DPL) are included in the fees.
Programme Directors:
Elif Erdine (AA Summer DLAB Director): elif.erdine@aaschool.ac.uk
Alexandros Kallegias (AA Summer DLAB Director): alexandros.Kallegias@aaschool.ac.uk
…
ange’ for its 2016 cycle, as a starting point to investigate principles of natural formation processes and interpret them as innovative architectonic spaces. These concepts are carefully interwoven with spatial, performance-based, and structural criteria in order to create full-scale working prototypes.
The three-week long programme is formulated as a two-phase process. During the two-week initial phase, participants benefit from the unique atmosphere and facilities of AA’s London home. The second phase, lasting for a week, shifts to AA’s woodland site in Hooke Park and revolves around the robotic fabrication and assembly of a full-scale architectural intervention.
Prominent Features of the programme:
• Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
• Facilities: AA Digital Prototyping Lab (DPL) offers laser cutting, CNC milling, and 3d printing facilities. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router, various woodworking power tools, and robotic fabrication.
• Computational skills: The toolset of Summer DLAB includes but is not limited to Rhinoceros, Processing, Grasshopper, and various analysis tools.
• Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies through theoretical sessions and seminars forms one of the major goals of Summer DLAB.
• Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
• Robotic Fabrication: According to the specific agenda of each year, scaled working models are produced via advanced digital machining tools, followed by the fabrication of a one-to-one scale prototype with the Kuka KR150 robot.
• Lecture series: Taking advantage of its unique location, London, Summer DLAB creates a vibrant atmosphere with its intense lecture programme.
Eligibility: The workshop is open to architecture and design students and professionals worldwide.
Accreditation: Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications: The AA Visiting School requires a fee of £1900 per participant, which includes a £60 Visiting Membership fee. A deposit of £381 is required when registering with the online form. The deadline for applications is 11 July 2016. No portfolio or CV is required. Online application link:
https://www.aaschool.ac.uk/STUDY/ONLINEAPPLICATION/visitingApplication.php?schoolID=392
Return train tickets between London-Hooke Park, accommodation & food in Hooke Park, and materials from Digital Prototyping Lab (DPL) are included in the fees.
For inquiries, please contact:
elif.erdine@aaschool.ac.uk (Programme Director)
alexandros.kallegias@aaschool.ac.uk (Programme Director)
…
h tubes are redundant so surfaces overlap instead of interpenetrate, so it is not a good system.
Cocoon is the best answer these days unless you can get Exowire/Exoskelton to work. If you want more control over shape, feed your uncapped tubes into Cocoon as meta-surfaces and delete any and all of the inner meshes to just keep the outer single closed one, but this is just duplicate-culled lines used as meta-lines:
Turn down the CS input to 0.005 for this result, from 0.02 used for faster preview. In fact bake the lines and only test Cocoon on a few of them in order to get the result you want before doing the whole thing.
Whole thing at 0.005 cell size takes 5 minutes for Cocoon and 2 minutes for refinement to a smooth and even mesh.
Actually, seems like 0.005 is way too fine, giving a 600MB STL file.
So, 0.01 cell size at less than a minute total:
159MB STL which is still a bit too big for places like Shapeways. Wow. OK then 0.02 cell size, but I have to increase diameter or my two smoothing steps in refine collapse things too much, an in fact I set it to no smoothing, getting more volume and a reasonable 46MB STL file:
Alas, now it's more frail and overly organic rather than mechanical. Increasing diameter just merges it into perforated plates too much. File size is simply an issue with this complexity level, so different 3D printing services will have different file size limits.
Exowire/Exoskeleton would work but your original mesh hasn't been MeshMachine remeshed to be regular, so short segments ruin it. Here is just a corner:
I think that's why more wires fails, at least. Pretty temperamental component.
Switching to MeshMachine is needed, I guess, instead of Cocoon refine, to remesh away so many small triangles along the boring tubes. Crucial for good remeshing was to set Flip to 0 or I failed to get a rough enough mesh.
It's an adaptive mesh so I can retain good detail while roughing out the tubes.
MeshMachine is terribly slow for this whole thing, like 6 minutes, and blows up for this overly rough setting, 20 steps, so less rough, ugh, I'm out of time. I think free Autocad Meshmixer is the way to make a better smaller mesh, after a refined output from Cocoon. MeshMachine is just too slow to tweak and when it blows up, creating massive triangles jutting out, it hangs too when you change settings.
Starting with a Cocoon refined mesh certainly helped Meshmixer. Using triangle budget lets me have full control. Here is 150K triangles instead of 200K:
STL file size down to 40MB. I think Shapeways is 70 or 100MB limit? So it can be even finer. Here is the Cocoon output versus the Meshmixer reduction:
To use Meshmixer, turn on View > Show Wireframe, Command-S to select all and use Edit > Reduce from the palette that appears.
Cocoon can end up making a few inner meshes where things get weird in your uneven original mesh with small holes so fish out the main mesh by adding a List Item node.
The best strategy for Cocoon is indeed to make an overly fine STL so you avoid any need to tweak forever in Grasshopper, but then you can achieve a smaller mesh file size while preserving shape instead of things turning all smearly organic in Grasshopper.…