, and it was only devised for triangular faces:
I could track all my edge labels (via the neighboring cell discussion) but from that info (the pesky tree) I needed unique face pairs to output a single crease angle.
Now (with your scripted component) I have the crease angles. All the 3D text is temporary for trouble shooting. This is 3 faces from a dodecaheadron:
So now I have the remaining hurdle as to whether the proper crease angle is the GH angle or the GH reflex angle.
The funny thing with the "pesky tree" is the meaning of the pattern doesn't become apparent until it's more complicated than the simpler excerpt from above.
I think I could make the scripted component a little cleaner if I use some nested loops instead of your search and remove method, but that may take me a while.
But it all the fun comes from this guy:
…
...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
…
ed many inverted normals, holes, bad edges, intersecting mesh faces etc and couldn't really find a good fix for all the issues.
3. I imported the file again and tried the mesh offset to thicken it just by 1mm. It gets a reasonable result but still has errors where the offset creates intersecting mesh faces. The result looks better than the Rhino offset mesh and looks like it might actually stand on a table. It was a 53Mb STL file!
Unfortunately I do not have the Objet software on my laptop otherwise I would have tried to prep it for 3d printing but I have a feeling any slicing software will struggle to process this mesh and it would be quite an expensive risk to try and print it as is.
You might be able to take the thickened mesh and cut away at the problem areas, then manually tidy up the holes created but this would be a long, manual process.
I also tried a 2mm offset but this was less successful... I think what is really needed is a sort of intelligent offset whereby in areas where the offset creates intersecting mesh geometry, the offset is smoothed off in the intersecting areas. Sorry... no idea how you could do this.
Do you want me to upload the 53Mb STL somewhere? Can I upload it to your dropbox?
Do you want me to upload the 53Mb STL somewhere? Can I upload it to your dropbox?…
Added by martyn hogg at 2:41pm on November 24, 2014
ngy (as stand alone product). But on the other hand it's widely used and is the "standard" seed for cultivating the new generations. With this in mind I rate it ... er ... hmm... higher than Generative Components. Because GC (and the ParaSolids 3d kernel that derives from Siemens/NX) may be mighty (if we forget this, this and that, he he) but is almost totally inaccessible: requires several years of training and then ... yes ... it can eat GH for breakfast as regards AEC matters (but this IS NOT the point, nor it means that GH is "worst").
The analogy is: GH is like my FireBlade (homogenous, easy) and GC is like my Panigale (lethal if not treated properly). On the other hand Honda cells 100 times more Blades than Ducati Panigales.
2. This cultivation thingy is/was NEVER understood by Bentely Systems (I had some very nasty Skype sessions on that matter, he he).A critical mistake that one, but then again Bentley doesn't like going to bed with individuals and ... maybe ... they are in the right path (a bit hilly, he he).
3. Dynamo on the other hand ... well I'm a Bentley Systems man so "by default" I dislike AutoDesk products and/or bought ones (TSplines excluded). But humor apart ... I dislike Revit for a vast variety of reasons the primary being the approach for effective parallel/team work. AECOSim on the other hand is brilliant on that matter. But Revit is dangerously close to become the BIM standard (which means - by default - that's the wrong thing).
4. Thus ... are R/GH in danger for playing a role in real-life AEC? Well ... if there was not the cultivation thing ... maybe.
In conclusion: In Planet Zorg this is the way to do AEC stuff: GH (scripts only) + GH add ons (if required) + GC (works only with scripts anyway) + AECOSim + you name it + CATIA/NX + you name it.
Moral: A classic Alice in the wonderland case that one: i.e. an amoral one, he he
take care, Jack the Ripper…
. and the bad habits die last as they say. This means that ... well ... the adaptation to more realistic (and meaningful) things later on ...
3. I can easily provide some solution (ultra expensive in real-life) to do what you want but this would be carried over solely via C# code (NOT good for you especially when this would/could be used in some sort of Thesis). To make a very long story short the "curvy" parts is highly recommended being tubes ... and the "liquid" nodes required ... well ...that's another animal UNLESS one could accept an Academic over simplification by using balls of a slightly bigger R than the adjacent tube "struts" (whilst the "iso curves" [per BrepFace] would use an even smaller R and inserting crudely into the Brep Edge "main" curves). But since actually we are talking about a secondary random "lattice" per BrepFace the "iso curves" are actually stuff made via the Surface.ShortPath Method (not sure if this exists as GH component) using random points where their number is proportionally to a given BrepFace area (freaky stuff, trust me). This yields a "uniform" random secondary "lattice" in accordance to the whole "random"/liquid appearance of the T-Splne Brep.
The above a bit naive approach (obviously out of question in real life) can yield a solid thingy if we unite all the parts and bits (Rhino takes ages to do that if we are talking big numbers of Breps) ... thus some 3d printing is doable.
In other words we do a MERO "approximation" by hoping that no German guru reads this thread, he he.
We can provide a Frankenstein type of "pro" connectivity as well: since a Brep is actually kinda a Mesh (with regard connectivity of vertices, edges, faces et all) making the connectivity trees required is not a big deal (GH has the Brep Topology thingy as well).
But the whole solution could be a black box to you: if this what you want?…
was not all there myself. Overall the night wasn't that productive so I wanted to apologize, I will do a better job in the future.
Attached to this message is the Assignment sheet for the upcoming week. Please post the picture of the models before 7:00 PM Monday 2/16.
Here is a link to the completed script from last night, as well as the Rhino file and presentation pdf.
https://www.dropbox.com/sh/3g6fnue93dk8iub/AAB88CNVCtC64cmz_ENLlojQa?dl=0
A few notes:
- I added two separate tags to the end of the script. One set is for the 3D model of your form, locating where the pieces originally come from. The second set is for the flattened out sections, which can be etched on your pieces to actually locate them when they are physically created. Play around a bit in the script and try to understand what is going on between the different parts.
-Baking: We went over baking in last weeks class. You right click on the component you want in the physical realm and select bake. Rhino will then ask you to select a layer to place the items on. I would suggest having two layers, one will be for cutting and one will be for etching (when you bake the tags(optional)). Once the pieces are in Rhino, you can use the Make2d command and export to AutoCad where you can laser cut (if you are unsure about this process, Google it as there are numerous tutorials).
-I would recommend using chipboard as it is the cheapest and most readily available, but don't let me chain your creativity if you come up with another material.
I look forward to seeing your guys models. See you Monday!
…
pavilion) and from that i want to fabricate it using some paper or card bored .
for modeling the pavilion i used a simple kangaroo based algorithm to generate the desired form using mesh 3d plane faces . there was no problem with this part and i was able to get the mesh from geometry out put . then i wanted to use that output mesh to panelize it and then adding tabs and the nesting and cutting to get the parts. but the problem was every tutorial i looked up were using surfaces to panelize and nest so this was the first problem to convert the mesh into a surface and then panelazing and nesting . i tried using the mesh2nurbs but it didn't work out for me . (because i needed a single surface not some poly surfaces) . (attachment | input mesh )
so i started from the beginning and tried using a surface as an input for kangaroo and thus getting a surface as an output so i did that and tried to create a surface by the Surface from points component . and the result was not good the surface was kinda messed up and the the reason was the points were not ordered well i guess . so this was another problem for me . (attachment | input surface)(picture below)
so basically i have a few main questions :
1. is there a tutorial or any topic or book or somthing that explains from 0 to 100 from design to fabrication (as an example a pavilion) ?
2. can i use the mesh to panelize and nest and then fabricate ? and are there any tips or tricks to it ?
3. is the starting from surface for me a good idea or not ?
i am extremely sorry for talking this much and i'm grateful for the time you spent on reading this .
best wishes ; Babak.
…
actually can perform using a dedicated software:
in 3D:
https://www.facebook.com/francescopiasentini/videos/523532707845171/
in 2D:
https://vimeo.com/189618609
The output of Modal Analysis (at a given frequency) is a list of point (x,y,z), each of them has the three coordinates and the maximum displacement in the direction normal to the surface (that's not flat)
Point number x y zmax1 24,007565 337,876028 -0,6545572 -28,0404705 337,947773 0,7760153 57,141457 316,757768 -0,8413914 18,667466 314,814543 -0,235288
My idea is:
-import stl surfaces of the object (violin)
-import Modal Analysis data
-deform stl (or Nurbs) surfaces using something like a customized CageEdit
-animate this deformation from zero to maximum displacement
-give a color to deformation (or first-second derivative of the interpoled deformation curves)
My wish is to have closed surfaces at any steps, and to create "natural" deformation shapes.
I just tried to import MA data. I was trying to create an array of circles with given x,y,z and radius, I could not figure how to separate information of position and radius when importing the file:
file content:
0,1,0; 5;2,1,3; 2;5,2,6; 4;
thanks for yout attention.
Looking forward to hear you soon!
Francesco
…
, National University of Singapore.
An introduction workshop for Rhinoceros 3D and Grasshopper Generative Modeling for Rhino for architectural practices. Workshop goal is to provide basic functional understanding of both Rhinoceros 3D and Grasshopper, to enable participants to build own definitions, and understands existing definitions.
Grasshopper is a Work-in-Progress. Features and procedures are added/changed often. If you are bringing your own laptop, please update to Rhino version 4 service release 8 and Grasshopper version 0.8.0004 which will be use in the workshop.
If you are not sure of your current update, please email to Agnes (agnes.tan@mcneel.com) for assistance.
Speaker: Agnes Tan agnes.tan@mcneel.com
Contact Person: Pinglei ping_lei@nus.edu.sg
Campus map: http://www.nus.edu.sg/campusmap/
Seats Limited.
Registration fee: S$250.00 each person
Mode of payment: Cash or Cash cheque
*Please note exhibition and workshop venues are in different locations.
…
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.
…