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.
…
chandelier where the process of design is perceived within the wide network of new digital technologies.
How:
Two phases will guide the exploration of the small object starting from an empirical moment of design to a more pragmatic construction phase
.A Design The first phase of the workshop is focused on parametric detailing and designing. The aim of the workshop is on generating volumetric non-standard lightweight structures within the constrains of available CNC machinery and material. Automatic unrolling, smart labelling and nesting are some of the things the participant will learn in the context of mass-customization. Rhino in combination with the Grasshopper will be used as a basic platform to develop the designs and prepare the documents for CNC-manufacturing. The design chosen for production and 1:1 assembly will be developed by the participants of the workshop.
.B Construction The second phase will be characterized by the realization of the best design previously selected. A consolidated expertise of Italian manufacture will sustain the building loop of the chandelier, from the production of the final components till the assembly of them. A milling machine is supported not only by a wide variety of different bits but mostly by a strong team of Italian craftsmen.
When:
. From Saturday the 7th of July 2012 till Friday the 13th of July 2012
Where:
. Iablu, via Enrico Mattei 40, 41043 Casinalbo Modena, Italy
Who:
The teaching method will be given by young experts in digital design and further implemented by professional Italian artisans, basic knowledge in the use of Rhinoceros 3D and physical modeling is required:
.A http://www.makeahybrid.org/ Matthijs la Roi .B http://www.iablu.it/ Carlo Maria Morsiani
Why:
The workshop is about the process of design, fabrication, construction, fun and friendship.
$:
The price relating the two periods will be 250 euros per person including :
.16 hours of design method .40 hours of fabrication method .material supply .milling machine time usage .insurance cover
It is important to know that in the expenses are not included the following services :
.night accommodation .food supply .transport .travel .extras
We are contacting all the members in play for the above mentioned list and we can estimate a minimum amount of 300 euros circa per person for European participants, prices for non-European participants are higher. These extra costs are an estimation but we will guarantee full assistance in all the organization parts.
!
Registration must be completed by Friday the 8th of June 2012, followed by a mail of confirmation including the payment procedure and insurance cover, any participant, furthermore must join the workshop with his own computer and software installed. Availability of max 10 participants
If interested write us to : candelabrum2.0@gmail.com Or visit us on : http://candelabrum2.tumblr.com
http://www.facebook.com/Candelabrum2.0…
could represent at least three immaterial substances: his subconscious, the negative mass surrounding the sculpture and a parallel world where material is forbidden.
Has Architects' engagement with virtual space meant a vanishing sensitivity towards material and other immaterial realms?
The AA Rome Visiting School 10 day workshop encourages the observation of material elements and their use in the design of architecture featuring subconscious experiences, spatial voids and virtual communities. Students will investigate modern materials and their digital fabrication by direct experience. They will work with algorithms and sensors able to recognise and respond to human feelings and attitudes. Students will feed novel expressions of void spaces into the Roman tradition featuring examples like the ancient catacombs and the Nolli map. Through augmented reality design the projects will open a window into an digital virtual world.
By the end of the workshop students will unveil their interpretation of the material/immaterial form hidden in the real matter.
Applications
1) You can make an application by completing the online application found under ‘Links and Downloads’ on the AA Visiting School page. If you are not able to make an online application, email visitingschool@aaschool.ac.uk for instructions to pay by bank transfer.
2) Once you complete the online application and make a full payment, you are registered to the programme. A CV or a portfolio is not required.
All participants travelling from abroad are responsible for securing any visa required, and are advised to contact their home embassy early. After payment of fees, the AA School can provide a letter confirming participation in the workshop.
Fees
The AA Visiting School requires a fee of £695 per participant, which includes a £60 Visiting membership fee.
Fees do not include flights or accommodation, but accommodation options can be advised. Students need to bring their own laptops, digital equipment and model making tools. Please ensure this equipment is covered by your own insurance as the AA takes no responsibility for items lost or stolen at the workshop.
Eligibility
The workshop is open to current architecture and design students, phd candidates and young professionals. Software Requirements: basic knowledge of Rhinoceros or other 3D modeling software.
Venue of workshop: Galleria “Come Se”, via dei Bruzi 4, 00185 Roma, Italy
…
del Sacco in Italy. Discover how to extract data from the different level of environmental conditions, than visualize those informations in order to generate an open and resourceful database of the territory.
PROGRAM
NOUMENA & FLONE, in collaboration with FABLAB FROSINONE and FAB LAB BARCELONA presentDATA MATTER | environmental aerial robotics workshop. The course is inspired by the investigation developed along the Sacco river by Carlo Ruggiero, pubblished on"Cattive acque" and the experimental research ran by Michela Ruggiero, co-founder of Fab Lab Frosinone. The course will take place in Frosinone, Italy and will be related to the fields of aerial robotics and data visualization. It will propose a theoretical and experimental framework to develop a database on the area around Valle del Sacco, translating data into visual outputs from the different levels of environmental conditions. During the workshop, participants will have a first hand experience with aerial robotics, mapping and data visualization. The course will focus in several different stages, generating a dynamic and innovative workflow. Main tool of the course will be Flone, a popular open-source drone developed in Spain and already presented in several international events and exhibitions such as Fab10 and MakerFaire. Flone is a co-operative project which explore and envision several applications that translate a basic drone into a multidisciplinary and professional tool. Flone have been already engaged to the field of art and technology, investigating social and professional practices , focusing on topography, energy performance certificates for buildings, environmental strategies of forestation, human rights and aerial photography. During the workshop participants will develop skills of digital fabrication, electronics, programming and data management. Starting from scratch, students will learn all the assembly process of the drone, from laser cutting frame structure to the installations of motors and drivers, followed by coding the electronic boards and fly experience. You will be able to fly and controll the drone by your android smartphone with an application developed by Flone. On site, along the Sacco river, students will use the drone and learn strategies of data recollection, terrain mapping via smart-phones, infrared camera and other environmental sensors installed on the drone. In the final stage of the course, participants will adopt computational techniques ,learning how to organize and visualize data, generate a 3d environment, elaborate informative maps as a resourceful environmental information documents for the recovery of the Sacco river and it’s natural and social context. The fee for the workshop include the ownership of the drone built during the event once the course will be over.
for more info:
http://www.noumenaarch.com/htmle/DRONE/datamatter.html…
Added by Aldo Sollazzo at 3:00am on October 15, 2014
+Grasshopper3D]
www.materialdriven.com/parametricmodulations-ratlab-london
www.rat-lab.org/gvslondon2020
// Level
Basic & Intermediate (Previous parametric design knowledge not obligatory).
// Agenda
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven design strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work. Studio work will be focusing on modulation of geometry and iterative form using Parametric Design methods that will lead to explorations of spatial geometries that can be articulated as architectural constructs or abstract artistic interventions.
// Methodology
Workshop has been structured to teach participants the use of Grasshopper® (Generative modelling plug-in for Rhinoceros 3D) as a generative tool, and ways to integrate it with architectural design process. There will be a focus on parametric modulation of geometry that can lead to a design process that utilizes data to inform geometry and space through use of Grasshopper3D and its associated plug-ins that would be introduced during the 3-day programme.
// Cities & Dates
London, UK: 15th, 16th, 17th January 2020 (Wednesday to Friday)
Anglo Educational Services
(The Montague Room)45 Russell Square, Holborn,
London WC1B 4JP,
United KingdomGoogle Maps: https://goo.gl/maps/YBeBqv7HCZPqSre46
…
rtitions." (http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1)
To continue with my wrapping career, TetRhino (or Tetrino) is a .NET wrapper for the well-known and pretty amazing TetGen mesh tetrahedralization program. It provides one new GH component for discretizing or remeshing objects using TetGen. Basic tetrahedralization functionality is exposed with a few different output types that can be controlled. At the moment, the only control for tetrahedra sizes is the minimum ratio, which is controlled by a slider. This is hardcoded to always be above 1.0-1.1, as it is very easy to generate a LOT of data (and crash)...
The libs are divided again into different modules to allow flexibility and fun with or without Rhino and GH, so have fun. All 4 libs should be placed in a folder (maybe called 'tetgen') in your GH libraries folder. Remember to unblock.
Once again, the libs are provided as-is, with no guarantee of support for now, as I use them internally and do not intend to develop this into a shiny, polished plug-in. If there is enough interest, I can tidy up the code-base and upload it somewhere if someone more savvy than me wants to play.
TetgenGH.gha - Grasshopper assembly which adds the 'Tetrahedralize' component to Mesh -> Triangulation.
TetgenRC.dll - RhinoCommon interface to the Tetgen wrapper.
TetgenSharp.dll - dotNET wrapper for Tetgen.
TetgenWrapper.dll - Actual wrapper for Tetgen.
Obviously, credit where credit is due for this excellent and tiny piece of software:
"The development of TetGen is executed at the Weierstrass Institute for Applied Analysis and Stochastics in the research group of Numerical Mathematics and Scientific Computing." See http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1 for more details about TetGen.
To wrap up, some notes about the inputs:
These are the possible integer Flags (F) values and resultant outputs for the GH component:
0 - Output M yields a closed boundary mesh. Useful for simply remeshing your input mesh.
1 - Output M yields a list of tetra meshes.
2 - Output I yields a DataTree of tetra indices, grouped in lists of 4. Output P yields a list of points to which the tetra indices correspond.
3 - Output I yields a DataTree of edge indices, grouped in lists of 2. Output P yields a list of points to which the edge indices correspond. Useful for lots of things, very easy to create lines from this to plug into K2 or something for some ropey FEA (or not so ropey!) ;)
As this component can potentially create a LOT of data, especially with dense meshes, care should be taken with the MinRatio (R) input. This will try to constrain the tetra to be more or less elongated, which also means that the lower this value gets, the more tetra need to be added to satisfy this constraint. Start with very high values and lower them until satisfactory.
Hopefully shouldn't be an issue, but it's possible that you need the 2015 Microsoft C++ Redistributable.
Happy tetrahedralizing...
UPDATE: The tetgen.zip has been updated with some fixes.
UPDATE2: This is now available on Food4Rhino: http://www.food4rhino.com/app/tetrino
…
Added by Tom Svilans at 1:27am on October 24, 2017
quired)
// Agenda
Parametric Design, in the history of architecture, has defined many rules for current designers and for future practitioners to follow. One of the strongest aspects that are prominent from this style is ‘geometry’. Arguably, there is nothing new about geometry and aesthetics forming the most prominent aspect of any style or era. The language of any style, in the long history of architecture, is visually defined by geometry or shape, beyond the principles that define the core of the style. In the distinguishable style of parametric architecture, geometry has played and is continuing to play an integral role. And with this fairly young style, there are many strings of myths and false notions associated.
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven fabrication strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work, with highlighting agenda of using data into Hands-on fabrication of a parametrically generated design. A strong focus will be made on ‘geometry’ and ‘matter’.
Day 1 Topics / Agenda
Rhinoceros 3D GUI and basic use
Installing Grasshopper & plug-ins
Grasshopper GUI
Basic logic, components, parameters, inputs, numbers, simple geometry, referenced geometry, locally defined geometry, baking, etc.
Lists & Data Tree: management, manipulation, visualization, etc.
Design Experimentations with Geometry & Data
Understanding Data for Manual Fabrication
Day 2 Topics / Agenda
Design Experimentations with Geometry, Form, Matter
Data for effective numbering and strategizing during Manual Fabrication
Collaborative effort for Hands-on ‘making’ process
Analysis & Evaluation of Fabricated Geometry
Documentation
// Tutor(s): Sushant Verma (Architect / Computational Designer / Educator)
…
ppresentazione di modelli per l’architettura ed il design, verso un apprendimento d' alto livello delle tecniche di modellazione parametrica 3D.
Il corso si svolgerà nei seguenti giorni:
Sabato 19/10 dalle 10.00 alle 19.00
Domenica 20/10 dalle 10.00 alle 19.00
Scadenza preiscrizione: 16/10
Contenuti
Durante questo corso, attraverso l' uso di tecniche avanzate di modellazione Nurbs,
si potranno costruire modelli tridimensionali complessi che permetteranno di comprendere le tematiche legate alle forme complesse dell’architettura.
Particolare attenzione verrà data allo studio delle superfici a doppia curvatura, alle superfici rigate e alle superfici sviluppabili, quest’ultime adatte alla creazione di manufatti rivolti alla produzione. Allo studio delle superfici sarà affiancata la logica della loro tassellazione, quindi il passaggio da entità continue ad entità discrete, indagandone il valore attraverso esercitazioni pratiche.
Per comprendere meglio le finalità pratiche della tassellazione verrà adoperata una plug-in integrativa specifica per questo tipo di operazione: Paneling Tools. Le lezioni pratiche saranno arricchite da brevi comunicazioni teoriche utili a perseguire l’obiettivo della costruzione di modelli complessi. Sintesi programma
Costruzione di superfici free-form facilmente editabili attraverso tecniche di sculpting ed una gabbia adeguata di punti di controllo;
Presentazione e spiegazione delle superfici a doppia curvatura, rigate, sviluppabili e loro pannellizzazione attraverso elementi lineari o tasselli piani;
Studio della tassellazione attraverso la plug-in Paneling Tools per lo sviluppo di tasselli tridimensionali complessi;
Modellazione di un'architettura complessa, costruita avvalendosi della anche della tecnica del morphing.
Preparazione della mesh e del file per il rendering.
Alla fine del corso, verrà rilasciato l’attestato di partecipazione ad un corso di Rhinoceros qualificato e certificato dalla casa sviluppatrice McNeel, valido anche per la richiesta di crediti formativi universitari.
Docente del corso
Il corso è tenuto da un docente qualificato, con riconosciuta esperienza universitaria, esperto in disegno e rappresentazione dell' architettura e del design ed istruttore McNeel:
Michele Calvano|_architetto, dottore di ricerca in rappresentazione architettonica specializzato nella modellazione matematica (Nurbs) e modellazione parametrica.
Docente ART (Autorized Rhino Trainer) - [vedi CV]
Info
Per ulteriori informazioni di carattere didattico sono a disposizione i seguenti contatti: Responsabile didattico: arch. Michele Calvano
Info mail: parametricart@gmail.com
cell: 340 3476330
…
o express my gratitude. I've been experimenting with your definitions (and still am), but let me extend my question.
Actually what I'm trying to achieve, is to recreate another project by Andrew Kudless, the spore lamp (I mentioned the Chrysalis at the beginning just because of the animation, which wasn't included in the Spore Lamp presentation).
Basically the spore lamp seems to me to be something like a preliminary study to the Chrysalis III project (I think it's a similar approach).
Andrew stated on his site that he used kangaroo for this project, so the Spore Lamp consists in my opinion either of a relaxed voronoi 3d diagram (b-rep, b-rep intersection) on a sphere which then has been planarized, or more likely it is a sort of relaxed facet dome.
The trick is to:
1. obtain a nicely-balanced voronoish diagram (or facet dome cells)
2. keep each cell/polyline planar (or force them with kangaroo to be planar) in order to move scale and loft them later on.
Here is what I have by now. (files: matsys spore lamp attempt)
That's the closest appearance that I got so far (simple move scale and loft of facet dome cells with the amount of transformations being proportional to the power of the initial cell area: bigger cell = bigger opening etc.) - with no relaxation of the diagram. But it's obviously not the same thing as the matsys design.
Here are some of my attempts of facet dome relaxation, but well, it certainly still not the right approach, and most importantly I don't know how to keep or force the cells to be planar after the relaxation.
1. pulling vertices to a sphere - no anchor points. That obviously doesn't make sense at all, but the relaxation without anchor points gives at the beginning a pattern that is closer to what I am looking for. (files: relaxation 01)
2. pulling vertices to a sphere - two faces of the initial facet dome anchored (files: relaxation 02)
3. pulling vertices to the initial geometry (facet dome) no anchor points (files: relaxation 03)
The cell pattern of the lamp kinda looks like this:
you can find it here: http://www.grasshopper3d.com/forum/topics/kangaroo-0-095-released?g...
Done with Plankton (of course without the "gradient increase" appearance), but in fact not, I took a look at Daniel Parker's Plankton example files, and it's not quite the same thing. Also the cells aren't planar...
The last problem is that during the relaxation attempts that I did, the biggest initial cells became enormous, and it's not like that in the elegant project by Andrew Kudless, that I'd like to achieve.
So to sum up:
Goal no 1: Obtain an elegant voronoi /facet dome cell pattern on a sphere (or an ellipsoid surface, whatever).
Goal no 2: Keep the cells planar in order to be able to loft them later and obtain those pyramidal forms, and assemble easily
Any ideas? Or maybe there's a completely different approach to that?…