make quad mesh usable with Kangaroo and with limited inputs parameters in order to simulate funicular structures like "Vaulted Willow" or "Pleated Inflation" from Marc Fornes and the Verymany.
Here is a first attempt script.
As inputs there are :
Lines_in, just lines, no duplicates, on XY plane could have Z values, but the algorithm works on a , on XY plane could have Z values, but the algorithm works on a flat representation.
Tolerance is used to glue lines when points are closer than tolerance
Width is the half width of the “roads” going through the network
Angle is the shape of the ends of the roads, 0° means flat end, 180° a totally rounded end
Deviation is the shift generating spikes or enabling to generate pleated geometry
N_u is the number of subdivision along the “roads”, image above with 3 subdivisions on the roads
N_u is the number of subdivision across the “roads”
Zbool if false everything is flat, if true the mesh is in 3d, best with angle = 180° or -180°
For the outputs there is the topology of the network (like Sandbox)
As outputs geometry are put on datatree, each branch represent a path on the road, above 3 paths, which are brep output.
Adding a diagonal there are now 4 paths so 4 branches
The mesh M goes with F which are fixed points, anchor in Kangaroo.
U and V are lines in datatree, there will be used as spring in Kangaroo, U above
This script could be used to draw sort of roads, like in here https://codequotidien.wordpress.com/2013/03/22/hemfunction/
But the primary purpose is to do that.
…
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
…
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)
…
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)
…
cells was determined by a network of tubules that he termed the cytoskeleton
(the name comes from Cyto- meaning cell or hollow vessel)
This is another wireframe thickening tool, intended for 3d printing use.
In contrast to exoskeleton (which works on general line networks), this works exclusively on lines which form the edges of meshes. The additional connectivity information present in this case makes it possible to produce an output with all quads, and moreover, a quad mesh with all even valence vertices.
Because it works on a Plankton mesh, the input can be made of ngons. We can also input a triangular mesh, apply the dual operation, and then thicken the edges of the resulting polygon mesh. This works well in combination with the remeshing script I posted here, for getting approximately equal edge lengths. This can be used to quickly turn any closed mesh into a lightweight hexagonal (mostly - with a few pentagons and heptagons for curvature) frame structure.
The even valence quad mesh property of the resulting thickened mesh means we can also use the mesh direction-sorting and directional-subdivision tools from Kangaroo (described here).
When combined with Weaverbird's Catmull-Clark subdivision, this allows us to smooth the mesh, while also having control over how much 'webbing' occurs at the nodes:
from left to right we see:
2 levels of Catmull-Clark with no directional subdivision
1 level of directional subD, then 2 Catmull-Clark
2 levels of directional subD, then 2 Catmull-Clark
One could even combine the resulting surfaces with all sorts of relaxation, or developable strip unrolling...
The code is there for you to read, so feel free to experiment and make adjustments to it. Hopefully it is fairly self explanatory.
Please feel free to ask any questions or suggest improvements, or just show off anything you create using this.
and yes - because the input and output are both meshes, you can apply it recursively!
This script references version 0.3.0 of Plankton, which you can download here:
https://github.com/Dan-Piker/Plankton/releases/tag/v0.3.0
…
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…
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.
…
ttern with many panels is an assembly. an assembly is made of parts. The cardinal thing is that Rhino does not export a mesh in these formats but only surfaces or solids..and then one must remesh them in Abaqus.. I'm trying to export the mesh itself.
here are the supported file formats as Abaqus describes them:
Abaqus/CAE reads and writes geometry data stored in the following formats:
3D XML (file_name.3dxml)
3D XML is an XML-based format developed by Dassault Systèmes for encoding three-dimensional images and data. The format is open and extendable, allowing three-dimensional graphics to be easily shared and integrated into existing applications and processes. 3D XML files can be many times smaller than typical model database files. The 3D XML Player from Dassault Systèmes is required to view 3D XML files or to integrate them into business applications. You can also view 3D XML files in CATIA V5.
You can export viewport data from Abaqus/CAE in 3D XML or compressed 3D XML format. For more information, see “Exporting viewport data to a 3D XML-format file,” Section 10.9.5. You cannot import 3D XML into Abaqus/CAE.
Abaqus/Standard and Abaqus/Explicit input files
Abaqus/CAE generates an input file when you submit a job for analysis. You can import input files into Abaqus/CAE. Abaqus/CAE translates the keywords and data lines in the imported input file into a new model; however, a limited set of Abaqus/Standard and Abaqus/Explicit keywords is supported, as described in “Importing a model from an Abaqus/Standard or an Abaqus/Explicit input file,” Section 10.5.1. For more information on creating and submitting jobs, see “Basic steps for analyzing a model,” Section 18.2.1.
ACIS (file_name.sat)
ACIS is a library of solid modeling functions developed by Spatial, and most CAD products can generate ACIS-format parts. You can import ACIS-format parts, and you can export parts or the assembly in ACIS format. In addition, you can import and export sketches in ACIS format. For more information, see “Importing parts from an ACIS-format file,” Section 10.7.4; “Importing sketches,” Section 10.7.1; and “Exporting geometry and model data,” Section 10.9.
AutoCAD (file_name.dxf)
Two-dimensional profiles stored in AutoCAD (.dxf) files can be imported as stand-alone sketches. However, Abaqus/CAE supports only a limited number of AutoCAD entities, and you should use this format only if no other formats are available. For more information and details on the AutoCAD entities supported by Abaqus/CAE, see “Importing sketches,” Section 10.7.1.
CATIA V4 (file_name.model, file_name.catdata, or file_name.exp)
CATIA is a CAD/CAM/CAE software package marketed by IBM and Dassault Systèmes. You can import CATIA-format parts. You can also import an entire CATIA V4 assembly into the Abaqus/CAE assembly, or you can choose to import only selected part instances. For more information, see “Importing a part from a CATIA V4- or V5-format file,” Section 10.7.5; and “Importing an assembly from a CATIA V4-format file,” Section 10.7.13. You cannot export parts from Abaqus/CAE in CATIA format.
CATIA V5 Elysium Neutral File or Elysium Neutral Assembly File (file_name.enf_abq or .eaf_abq)
A translator plug-in is available for CATIA V5 that will generate a geometry file using the Elysium Neutral File (.enf) format or the Elysium Neutral Assembly File (.eaf) format. You can use Elysium Neutral Files to import CATIA V5 parts. In addition, you can use Elysium Neutral Files or Elysium Neutral Assembly Files to import an entire CATIA V5 assembly into the Abaqus/CAE assembly, or you can choose to import only selected part instances. For more information, see “Importing a part from an Elysium Neutral file,” Section 10.7.6, and “Importing an assembly from an Elysium Neutral file,” Section 10.7.14. You cannot export parts or assemblies from Abaqus/CAE in Elysium Neutral File or Elysium Neutral Assembly File format.
CATIA V5 parts and assemblies (file_name.CATPart or .CATProduct)
With the optional CATIA V5 Associative Interface add-on feature for Abaqus/CAE, you can import CATIA V5-format parts and assemblies. For more information, see “Importing a part from a CATIA V4- or V5-format file,” Section 10.7.5. You cannot export parts from Abaqus/CAE in CATIA V5 format.
I-DEAS Elysium Neutral File or Elysium Neutral Assembly File (file_name.enf_abq or .eaf_abq)
Abaqus provides a translator plug-in for I-DEAS that will generate a geometry file using the Elysium Neutral File (.enf) format or the Elysium Neutral Assembly File (.eaf) format. You can use Elysium Neutral Files to import I-DEAS parts. In addition, you can use Elysium Neutral Files or Elysium Neutral Assembly Files to import an entire I-DEAS assembly into the Abaqus/CAE assembly, or you can choose to import only selected part instances. For more information, see “Importing a part from an Elysium Neutral file,” Section 10.7.6, and “Importing an assembly from an Elysium Neutral file,” Section 10.7.14. You cannot export parts or assemblies from Abaqus/CAE in Elysium Neutral File or Elysium Neutral Assembly File format.
IGES (file_name.igs or .iges)
The Initial Graphics Exchange Specification (IGES) is a neutral data format designed for graphics exchange between computer-aided design (CAD) systems.
You can import IGES-format parts, and you can export parts in IGES format. In addition, you can import and export sketches in IGES format. For more information, see “Importing a part from an IGES-format file,” Section 10.7.7;“Importing sketches,” Section 10.7.1; and “Exporting geometry and model data,” Section 10.9.
The IGES-format allows for many interpretations, and most of the parts that you import into Abaqus/CAE using IGES-format will need to be repaired before you can use them. Thus, it is recommended that you try to use another format, if possible.
Output database (output_database_ name.odb)
An output database contains the data generated during an Abaqus/Standard or Abaqus/Explicit analysis. You can import parts from an output database in the form of orphan meshes. An orphan mesh part contains no feature information and is extracted from the output database as a collection of nodes, elements, surfaces, and sets. If the output database contains multiple part instances, you can select the part instances to import. Abaqus/CAE imports each part instance as a separate orphan mesh part. You can import either the undeformed or the deformed shape. If you import the deformed shape, you can specify the step and the frame from which to import.
To verify the quality of the orphan mesh, you can display the orphan mesh part in the Mesh module and select MeshVerify from the main menu bar. In addition, you can use the Mesh module to change the element type assigned to the mesh and to edit the original mesh definition. For more information, see “Importing a part from an output database,” Section 10.7.12; “What can I do with the Edit Mesh toolset?,” Section 46.1; and “Assigning Abaqus element types,” Section 17.5.
You can also import a model from an output database. The model that is imported will contain orphan mesh parts representing each of the undeformed part instances in the output database along with an orphan mesh representation of the undeformed assembly. The model will also contain any sets, surfaces, materials, section definitions, and beam profiles that were defined in the output database. For more information, see “Importing a model from an output database,” Section 10.5.2.
Parasolid (file_name.x_t, file_name.x_b, file_name.xmt_txt, or file_name.xmt_bin)
Parasolid is a library of solid modeling functions developed by UGS. A variety of CAD products can generate Parasolid-format parts, such as NX, SolidWorks, Solid Edge, FEMAP, and MSC.Patran. You can import Parasolid-format parts. You can also import an entire Parasolid assembly into the Abaqus/CAE assembly, or you can choose to import only selected part instances. For more information, see “Importing a part from a Parasolid-format file,” Section 10.7.9; and “Importing an assembly from a Parasolid-format file,” Section 10.7.15. You cannot export parts or assemblies from Abaqus/CAE in Parasolid format.
Pro/ENGINEER Elysium Neutral File or Elysium Neutral Assembly File (file_name.enf_abq or .eaf_abq)
Abaqus provides a translator plug-in for Pro/ENGINEER that will generate a geometry file using the Elysium Neutral File (.enf) format or the Elysium Neutral Assembly File (.eaf) format. You can use Elysium Neutral Files to import Pro/ENGINEER parts. In addition, you can use Elysium Neutral Files or Elysium Neutral Assembly Files to import an entire Pro/ENGINEER assembly into the Abaqus/CAE assembly, or you can choose to import only selected part instances from the assembly. For more information, see “Importing a part from an Elysium Neutral file,” Section 10.7.6, and “Importing an assembly from an Elysium Neutral file,” Section 10.7.14. You cannot export parts or assemblies from Abaqus/CAE in Elysium Neutral File or Elysium Neutral Assembly File format.
STEP (file_name.stp or .step)
The STandard for the Exchange of Product model data (STEP ISO 10303–1) is designed as a high-level replacement for IGES that attempts to overcome some of the shortcomings of IGES. The STEP AP203 standard is designed to provide a computer-interpretable representation of a mechanical product throughout its life cycle, independent of any particular system.
You can import STEP-format parts, and you can export parts in STEP format. In addition, you can import and export sketches in STEP format. For more information, see “Importing a part from a STEP-format file,” Section 10.7.10; and“Exporting geometry and model data,” Section 10.9.
STEP-format parts are similar to IGES-format parts in that most of the parts that you import into Abaqus/CAE using STEP-format will need to be repaired before you can use them. Thus, it is recommended that you try to use another format, if possible.
VDA-FS (file_name.vda)
The Verband der Automobilindustrie Flachën Schnittstelle (VDA-FS) surface data format is a geometry standard developed by the German automotive industry. Both VDA-FS and IGES files contain a mathematical representation of the part in an ASCII format; however, the VDA-FS standard concentrates on geometry information. Additional information covered by the IGES standard, such as dimensions, text, and colors, is not stored in a VDA-FS file.
You can import VDA-FS-format parts, and you can export parts in VDA-FS format. For more information, see “Importing a part from a VDA-FS-format file,” Section 10.7.11; and “Exporting geometry and model data,” Section 10.9.
VDA-FS format parts are similar to IGES-format parts in that most of the parts that you import into Abaqus/CAE using VDA-FS format will need to be repaired before you can use them. Thus, it is recommended that you try to use another format, if possible.
VRML (file_name.wrl)
Virtual Reality Modeling Language (VRML) is the ISO standard for displaying three-dimensional images in a web browser or a stand-alone VRML client. It is an open, platform-independent, vector-based, three-dimensional modeling language that encodes computer-generated graphics to allow them to be shared easily across a network. VRML-format files can be many times smaller than typical model database files. A special plug-in viewer, such as Cortona or Cosmo, is required to view VRML files.
You can export viewport data from Abaqus/CAE in VRML format or compressed VRML format. For more information, see “Exporting viewport data to a VRML-format file,” Section 10.9.4.
…