Search Results - 力曼缺點諮詢:🍟line:sammibaby🍟瘦身鍛煉飲食🏭减肥運動時間幾點合適🚤產後肥胖如何正確减肥⛺池上乡教你如何用桑葉减肥📢澎湖縣飯前吃蘋果瘦身🚺不反彈的瘦身减肥方法👰🏻‍力曼詐騙

Comment on: Topic 'Pain Points in Grasshopper': 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. …; Added by PGirgen at 3:38am on August 3, 2014

Topic: Release Notes - Ladybug 0.0.63 and Honeybee 0.0.60: nd improvements. Many of the new features and components announced in the last release have become stable and have emerged from their WIP section. Additionally, after two years of work, we are happy to announce that we finally have full support of an OpenStudio connection within Honeybee, which has ushered in a whole host of new features, notably the modelling of detailed HVAC systems. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts. LADYBUG 1 - Solar Hot Water Components Out of WIP After much beta-testing, bug-fixing, and general development, all of the Photovoltaic and Solar Hot Water components are now fully out of WIP! The main component is based on a Chengchu Yan's publication. Components have been added to Ladybug thanks to the efforts of Chengchu Yan and Djordje Spasic.. See Djorje’s original release post of the solar hot water components for more information on the components that just made it out of WIP. 2 - New Terrain Shading Mask Released in WIP In addition to Djordje’s prolific addition of renewable energy components, he has also contributed a widely-useful component to generate terrain shading masks, which account for the shading of surrounding mountains/terrain in simulations. While initially added to assist the solar radiation radiation and renewable energy components, the component will undergo development to optimize it for energy and daylight simulations over the next few months. Another new component called Horizon Angles can be used to visualize and export horizon angles. You can test them out now by accessing them in the WIP section. For more information, see Djordje’s release post on the GH forum here. 3 - New Mesh Selector Component After realizing that the Optimal Shade Creator component has applications to a whole range of analyses, it has now been re-branded as the Mesh Selector and has been optimized to work easily with these many analyses. Specifically, the component selects out the portion of a mesh that meets a given threshold. This can be the portion of a shade benefit analysis meeting a certain level of shade desirability, the portion of a radiation study meeting a certain level of fulx, the portion of a daylight analysis meeting a certain lux threshold, and much more! 4 - Solar Adjusted Temperature Now Includes Long Wave Radiation Thanks to a question asked by Aymeric and a number of clarifications made by Djordje Spasic, the Solar Adjusted Temperature component now includes the ability to account for long-wave radiative loss to the sky in addition to it original capability to account for short wave radiation from the sun. As such, the component now includes all capabilities of similar outdoor comfort tools such as RayMan. The addition of this capability is also paralleled by the addition of a new horizontalInfraredRadiation output on the ImportEPW component. See the updated solar adjusted example file hereto see how to use the component properly. 5 - Support for both Log and Power Law Wind Profiles In preparation for the future release of the Butterfly CFD-modelling insect, the Ladybug Wind Profile component now includes the option of either power law or log law wind profiles, which are both used extensively in CFD studies. Thanks goes to Theodoros Galanos for providing the formulas! 6 - New Radiant Asymmetry Comfort Components Prompted by a suggestion from Christian Kongsgaard, Ladybug now includes components to calculate radiant asymmetry discomfort! For examples of how to use the components see this example file for spatial analysis of radiant asymmetry discomfort and this example for temporal analysis. 7 - Pedestrian Wind Comfort Component Released in WIP In preparation for the impending release of the butterfly CFD-modelling insect, Djordje Spasic with assistance from Liam Harrington has contributed a component to evaluate outdoor discomfort and pedestrian safety. The component identifies if certain areas around the building are suitable for sitting, building entrances-exits, window shopping... based on its wind microclimate. Dangerous areas due to high wind speeds are also identified.You can check it out now in the WIP section. HONEYBEE 1 - New HVAC Systems and Full OpenStudio Support After a significant amount of development on the part of the OpenStudio team and two years of effort on the part of LB+HB developers, we (finally!) have full support for an OpenStudio connection within Honeybee. By this, we mean that any energy simulation property that can be assigned to a HBZone will be taken into account in the simulation run by the OpenStudio component. The connection to OpenStudio has brought with it several new capabilities. Most notably, you can now assign full HVAC systems and receive energy results in units of electricity and fuel instead of simple heating and cooling loads. This Honeybee release includes 14 built-in HVAC template systems that can be assigned to the zones, each of which can be customized: 0. Ideal Air Loads 1. PTAC | Residential 2. PTHP | Residential 3. Packaged Single Zone - AC 4. Packaged Single Zone - HP 5. Packaged VAV w/ Reheat 6. Packaged VAV w/ PFP Boxes 7. VAV w/ Reheat 8. VAV w/ PFP Boxes 9. Warm Air Furnace - Gas Fired 10.Warm Air Furnace - Electric 11.Fan Coil Units + DOAS 12.Active Chilled Beams + DOAS 13.Radiant Floors + DOAS 14.VRF + DOAS Systems 1-10 are ASHRAE Baseline systems that represent much of what has been added to building stock over the last few decades while systems 11-14 are systems that are commonly being installed today to reduce energy use. Here is an example file showing how to assign these systems in Honeybee and interpret the results and here is an example showing how to customize the HVAC system specifications to a wide variety of cases. To run the file, you will need to have OpenStudio installed and you can download and install OpenStudio from here. In addition to these template systems within Honeybee, the OpenStudio interface includes hundreds of HVAC components to build your own custom HVAC systems. OpenStudio also has a growing number of user-contributed HVAC system templates that have been integrated into a set of scripts called "Measures" that you can apply to your OpenStudio model within the OpenStudio interface. You can find these system templates by searching for them in the building components library. Here is a good tutorial video on how to apply measures to your model within the OpenStudio interface. Honeybee includes a component that runs these measures from Grasshopper (without having to use the OpenStudio interface), which you can see a demo video of here. However, this component is currently in WIP as OpenStudio team is still tweaking the file structure of measures and it is fairly safe to estimate that, by the next stable release of Honeybee, we will have full support of OpenStudio measures within GH. 2 - Phasing Out IDF Exporter With the connection to OpenStudio now fully established, this release marks the start of a transition away from exporting directly to EnergyPlus and the beginning of Honeybee development that capitalizes on OpenStudio’s development. As such THIS WILL BE THE LAST STABLE RELEASE THAT INCLUDES THE HONEYBEE_RUN ENERGY SIMULATION COMPONENT. The Export to OpenStudio component currently does everything that the Run Energy Simulation component does and, as such, it is intended that all GH definitions using the Run Energy Simulation component should replace it with the OpenStudio component. You can use the same Read EP Result components to import the results from the OpenStudio component and you can also use the same Energy Sim Par/Generate EP Output components to customize the parameters of the simulation. The only effective difference between the two components is that the OpenStudio component enables the modeling of HVAC and exports the HBZones to an .osm file before converting it to an EnergyPlus .idf. For the sake of complete clarity, we should state that OpenStudio is simply an interface for EnergyPlus and, as such, the same calculation engine is under the hood of both the Export to OpenStudio component and the Run Energy Simulation component. At present, you should get matching energy simulation results between the Run Energy Simulation component and a run of the same zones with the OpenStudio component (using an ideal air system HVAC). All of this is to say that you should convert your GH definitions that use the Run Energy Simulation component to have the OpenStudio component and this release is the best time to do it (while the two components are supported equally). Additionally, with this version of Honeybee you will no longer need to install EnergyPlus before using Honeybee and you will only need to install OpenStudio (which includes EnergyPlus in the install). 3 - New Schedule Generation Components Thanks to the efforts of Antonello Di Nunzio, we now have 2 new components that ease the creation of schedule-generation in Honeybee. The new components make use of the native Grasshopper “Gener Pool” component to give a set of sliders for each hour of the day. Additionally, Antonello has included an annual schedule component that contains a dictionary of all holidays of every nearly every nation (phew!). Finally, this annual schedule component can output schedules in the text format recognized by EnergyPlus, which allows them to be written directly into the IDF instead of a separate CSV file. This will significantly reduce the size of files needed to run simulations and can even reduce the number of components on your canvas that are needed to add custom schedules. For more information, see Antonello’s explanatory images here and Antonello's example file here. You can also see a full example file of how to apply the schedules to energy simulations here. 4 - EnergyPlus Lookup Folder, Re-run OSM/IDF, and Read Result Dictionary With the new capabilities of OpenStudio, we have also added a number of components to assist with managing all of the files that you get from the simulation. In particular, Abraham Yezioro has added a Lookup EnergyPlus Folder component that functions very similarly to the Lookup Daylight Folder component. This way, you can run an Energy simulation once and explore the results separately. Furthermore, we have added components to Re-Run OpenStudio .osm files or EnergyPlus .idf files within Grasshopper. These components are particularly useful if you edit these .osm or .idf files outside of Honeybee and want to re-run them to analyze their results in Grasshopper. Lastly, a component has been added to parse the .rdd (or Result Data Dictionary) file that EnergyPlus produces, enabling you to see all of the possible outputs that you can request from a given simulation. 5 - Electric Lighting Components Out of WIP After Sarith Subramaniam’s initial components to model electric lights with Radiance in the last release, we are happy to report that they have been fully tested and are out of WIP. Improvements include support for all types of light fixture geometries and the ability to use the components in a more “Grasshoppery” list-like fashion. See Sarith’s original release post for more information and several example files showing how to use the components can be found here. 1 , 2 , 3 . 6 - Improvements to THERM Components A number of bug fixes and improvements have been made to the THERM components in order to make their application more flexible and smooth. Special thanks is due to Derin Yilmaz , Mel King , Farnaz , Ben (@benmo1) , and Abraham Yezioro for all of the great feedback in the process of improving these components. 7 - HBObject Transform Components After some demand for components that can ease the generation of buildings with modular zone types, two components to transform HBObjects with all of their properties have been added to the 00 | Honeybee section. The components allow you to produce copies of zones that are translated or rotated from the original position. 8 - Comfort Maps Supports PET and Integration of CFD Results Thanks to the addition of the ‘Physiological Equivalent Temperature’ (PET) component by Djordje Spasic in the last stable release, it is now possible to make comfort maps of PET with Honeybee. PET is particularly helpful for evaluating OUTDOOR comfort with detailed wind fields at a high spatial resolution. As such, the new PET recipe has also been optimized for integration with CFD results. The windSpeed_ input can now accept the file path to a .csv file that is organized with 8760 values in each column and a number of columns that correspond to the number of test points. Components to generate this csv from Butterfly CFD results will be coming in later releases. Stay tuned! As always let us know your comments and suggestions. Enjoy!Ladybug Analysis Tools Development Team …; Added by Chris Mackey to Ladybug Tools at 8:39pm on August 11, 2016

Topic: Curves in GhPython in Grasshopper: command to select the curves, but I'm not able to control the resultant form afterwards in Grasshopper to create Pframes or array a geometry on the surface. My script: import rhinoscriptsyntax as rs import Rhino import scriptcontext as sc sc.doc = Rhino.RhinoDoc.ActiveDoc class TanLines: def __init__(self, _curve, _numOfDivs): self.curve = _curve; self.numOfDivs = _numOfDivs def tanPoints(self,strength): #print("check") doms = rs.CurveDomain(self.curve) minDom = doms[0] maxDom = doms[1] ptList = [] tanPtList = [] for i in range (0, self.numOfDivs + 1): param = (maxDom-minDom)/self.numOfDivs * i tan = rs.CurveTangent(self.curve, param) tan = rs.VectorScale(tan, strength) pt = rs.EvaluateCurve(self.curve, param) rs.AddPoint(tan) rs.AddPoint(pt) tanPt = rs.VectorAdd(tan, pt) rs.AddLine(pt, tanPt) ptList.append(pt) tanPtList.append(tanPt) return [ptList, tanPtList] curve01 = rs.GetObject("pick curve 1", 4) curve02 = rs.GetObject("pick curve 2", 4) curve03 = rs.GetObject("pick curve 3", 4) 　 obj01 = TanLines(curve01,50) data01 = obj01.tanPoints(-0.1) obj02 = TanLines(curve02,50) data02 = obj02.tanPoints(-0.1) obj03 = TanLines(curve03,50) data03 = obj03.tanPoints(-0.1) 　 ptList01 = data01[0] #point list of first line ptList02 = data01[1] #tan points of first line ptList03 = data02[0] ptList04 = data02[1] ptList05 = data03[0] ptList06 = data03[1] 　 count = 0 crvList = [] #establish list of curves 　 for i in ptList01: pointsForCurve = [ ptList01[count], ptList02[count], ptList03[count], ptList04[count], ptList05[count], ptList06[count] ] crv=rs.AddArc3Pt(ptList01[count], ptList06[count], ptList04[count]) crvList.append(crv) count += 1 Surface = rs.AddLoftSrf (crvList) sc.doc = ghdoc A = Surface B = crvList C = [curve01, curve03] - Any help would be much appreciated. Thank you.…; Added by Francis McCloskey at 8:13am on December 15, 2014

Comment on: Topic 'Everything you need to know about Display and View Menus in Grasshopper': ing Low Quality High Quality Document Quality Custom Quality Edit Custom Quality These same options are also available from the Canvas Toolbar on the right hand side, with one exception: this is the only location [GH 0.9.0075] where you can find the Bump Preview Toggle. The ability for the user to choose the standard of preview mesh quality was introduced in GH version 0.9.0005. Referenced Rhino Document Objects: Disable Meshing as the name suggest this switches the meshing off for all Grasshopper Objects in the Rhino Document. It does not completely turn the Grasshopper Preview off as the Edges of Surfaces and other curve objects remain visible. Low Quality is the default within Grasshopper as ultra-fast preview mesh settings are more suitable when having to update lots of objects in realtime. They also cause the most concern when people first see the difference between the surfaces represented by Grasshopper and those in Rhino, note the Sphere in the image below If High Quality is of more importance then this can be selected to show a truer representation of the geometry in the Rhino Viewport. When Document Quality is selected Grasshopper will reference which ever setting is selected in the Tools>Options>Document Properties>Mesh Settings Panel Jagged & Faster Smooth & Slower Custom Custom Quality is available to any one wishing to have more control over the representation of Grasshopper objects in the Rhino Viewport. Whether it is extremely low for speed or extremely high for clarity. The first time you toggle this the Edit Custom Quality window will pop up. Edit Custom Quality window displays the various options available to you to alter in order to achieve your desired results. similar to Rhino if a setting is set to 0 then it will be ignored. Bump Preview is a solution to the problem of seeing Grasshopper objects and Rhino Referenced objects occupying the same space. Without Bump Preview toggled the Rhino object will almost always take precedence over the Grasshopper preview. Compare the difference between the image below where Bump Preview has been switched off and any of the previews above to see that the thick, black Rhino lines are visible as opposed to the thin, red Grasshopper lines. Bump Preview achieves giving Grasshopper objects priority by bringing the them closer to the camera. If you were able to view the same seen from the side then this would be what you would see: As a result Bump Preview does comes with its own undesirable artifacts that might lead you to suppress it. In the image below you can see the line that should be hidden behind the Shaded cube is visible for a short length before it passes through the Rhino Object. *** Warning *** If you wish to use any other Preview Point Flavour (see below) other than Cross you must deactivate Bump Preview as there is a bug in the display pipeline.…; Added by Danny Boyes at 4:42am on June 19, 2014

Comment on: Topic 'unfolding a surface extracted from Revit': urface that there are not enough control points to match well, but these seem fine. Just be aware of using enough spans and tweaking the flexibility to get within-tolerance edge matching so your final assembly doesn't leak in the rain. Now how do I unwrap that flat? It may have slight compound two or more directional curvature that may freak out normal commands, but what's the standard command for this in Grasshopper or Rhino? Indeed the Rhino command Unroll is uncooperative, won't even try! "At least one surface you are trying to unroll is not developable because it is doubly curved. If you want to unroll it anyway, try using the Smash command or adjust the relative tolerance on the UnrollSrf command line. Unrolling doubly curved surfaces will produce inaccurate results." And Smash...just asks for *curves* on surface to unroll, well let's do the border ones, those being the only ones...and it's very slow... ...well, your scale is so off the charts at a quarter million units out in space and 5K wide objects that normal Rhino tolerance is utterly tiny so I can even join extracted border lines playing around...so I will scale down by 1000X first. That broke my Grasshopper Patch trimming...so...I must turn my flexibility to 100...and it still fails since I forgot to also translate away from 500K units away from the origin...so with 1/1000th scale *at* the origin, my patch is working again. Now Rhino Smash gives a terrible result that can't even be rendered with shading so I must select it to even see it: So...I reset my tolerance to much finer in the Rhino settings: Now I can Smash away: Alas, Grasshopper hasn't got a Smash, so...we search and find a script: http://www.grasshopper3d.com/forum/topics/smash-command-from-rhino?... However, that gives an invalid brep output that can't be re-trimmed, and again I find in side the script a tolerance setting of 0.01 but we are in centimeters so that's silly, I'll edit it to 0.001 and now it works: Now Grasshopper, I notice, hasn't been fully joining my mesh edge curves, even though upon baking, Rhino does it just fine. OK, I just have to right click toggle the Preserve Curve Direction option for join and it works so now I can split my unrolled surface with my original border curve manually to thus simplify the unrolling, I guess: But the result is not accurate enough, after I manually move them together and rotate in Z to the same angle: The longest edge length is also off by about 0.1%, but that's OK. Some strangeness is going on with double curvature, even slight, that throws off the result. That's some start of a possible solution though. The Rhino Smash command gives the same result. Ah, the problem is that my patch strategy is giving a *severely* doubly curved surface you just can't see after trimming and that's causing massive distortions as Rhino tries to also flatten the outside crap: The original patch has an everyday right edge above, but the left edge is stretched much longer than that due to the weird curvature that is not the fault of the mesh edges but of the way patch works! That's some ideas anyway. Because patch is fairly well behaved despite the crazy curvature, manually constructing a flat target surface with straight edges the same lengths as the patch surface might work better. I'm not sure how though. Serious trigonometry I'm afraid. …; Added by Nik Willmore at 9:41pm on March 8, 2016

Topic: Grasshopper 0.8.0005 available for download: e here, which you can use in case you have problems downloading or running exe files. There are several known issues that have not yet been fixed, among these are the Cluster Data Output Layout discrepancies and the lack of flatten and graft state icons on several objects such as Gradients. Here's a list of changes since 0.8.0004, and you can see the full update history using the 'Version History' entry in the Grasshopper help menu. Additions: 1500+ Lolcats! The deep-down-display-plumbing has been rewritten. The Grasshopper canvas is now drawn on the screen in a completely different fashion, be on the lookout for weird behaviour and novel crashes. Added customizable display threshold to profiler widget. Added a Reverse option on all parameters in addition to Flatten and Graft. Added constant info to the PathMapper mask dialog. Added 'Copy Content' and 'Copy Data Only' menu items to the text panel. Improved add-on icon placement on the banner. Rewrote Colour Picker control from scratch. Rewrote Number Slider control from scratch. Added a new Digit Scroller control to replace all standard windows numeric up/down controls. Added a new Digit Scroller control as a special object. Added a new data type for groups of geometric objects. Added Create Group component (Transform tab). Added Destroy Group component (Transform tab). Added Merge Group component (Transform tab). Added Split Group component (Transform tab). Added a Transform Matrix type and parameter. Added Compound Transform component (Transform tab). Added Split Transform component (Transform tab). Added generic Transform component (Transform tab). Added Transform Matrix display object (Transform tab). All Transform components now output Transformation data. All Transform components geometry inputs are now optional. Double clicking on the trackbar portion of a slider now pops up an input textbox. Added a Settings browser window (File menu). Note that this is not supposed to be a true Settings interface. Solution states can now be deleted as well as created. Changes to solution states are now recorded in the undo stack. When toolbar icon panels are fully collapsed, they are now wide enough to read the panel name. Added FilletCurve component for individual fillets. Sliders with expressions now show the processed value. Added a Value List object to the Params.Special panel. Added System.Linq and System.Xml.Linq namespaces to the VB/C# references. The Image Sampler can now save the image data in the ghx file. Added an image gallery object (Params.Special tab, dropdown portion only). Fixes: Fixed a problem with the popup search box not showing up sometimes. Floating parameter icons now center themselves in the space left over by the state tags. 'Export Hi-Res' menu item is now disabled if no document is loaded. Fixed a problem with tooltips on the Grasshopper banner assembly icons. Parameter flatten settings were not recorded in the undo-stack, this is fixed. Parameter graft settings were not recorded in the undo-stack, this is fixed. Fixed a bug with Curve|Line intersection and degenerate curve boundingboxes. Fixed a bug in the Shatter Curve component (thank you to]) Scribble drags were not recorded by Undo, this is fixed. Scribble property changes were not recorded by Undo, this is fixed. Some general notes about the new stuff: The Group data type basically allows you to bundle together geometry during transforms. It's a lot like Blocks in Rhino (except there are no reduced memory benefits). Groups will work with Transform components but not with most other Geometry components. The Transform data type is for geeks only. Rhino internally uses a 4x4 matrix to transform geometry. Unless you understand what all the numbers in the matrix mean, this is probably of no use to you. There were a lot of problems in the past with the particular flavour of GDI blitting I used. Compared to the number of times a Grasshopper canvas was redrawn in the world at large this was still a very rare event which made it difficult to catch. Hopefully the new system will not suffer from these old problems, but be aware there may be new problems as well as performance hits. If you find something odd, please let me know. All windows numeric up-down controls have been replaced with a custom digit scroller control. This is only the first stab at getting it right. If you have constructive criticism please do not hesitate to post it. Storing images inside the ghx document is now possible both via the Image Sampler and the Image Gallery objects. Note that images are currently always stored as 32-bit-per-pixel png files, even if you supply them as downgraded jpegs. This means that the file-size might explode if you decide to store embedded images. A pre-release version of this build was posted on the Grasshopper VB/C# forum a few days ago, since there are quite a lot of SDK breakages. If you find some of your additional GHA libraries fail to load, please post a screen-shot of the error either here or on the VB/C# forum. Enjoy, David -- David Rutten david@mcneel.com Poprad, Slovakia…; Added by David Rutten at 8:14am on February 28, 2011

Topic: NBBJ releases Human UI -- now available for download: . Today we have gone live, and the plugin is available on Food4Rhino. You will find an installer package, sample files, and a demo video on getting started: http://www.food4rhino.com/project/human-ui Visit the Bitbucket Repo and poke around in the code: https://bitbucket.org/andheum/humanui Check out today's coverage in Architect Magazine: http://www.architectmagazine.com/technology/nbbj-releases-human-ui-to-bring-parametric-modeling-to-the-masses_o Finally join our group and ask any questions or post any comments here: http://www.grasshopper3d.com/group/human-ui See below for detailed description! ---------------------------------- Human UI Primary Development by: Lead Developer: Andrew Heumann / andheum / @andrewheumann Product Manager: Marc Syp / marcsyp / @mpsyp Contributing Developer: Nate Holland / nateholland / @_NateHolland Gone are the days of faking a user interface by laying out sliders and text panels and hiding wires on the Grasshopper canvas. Human UI interfaces are entirely separate from the Grasshopper canvas and leverage the power of Windows Presentation Foundation (WPF), a graphical subsystem for rendering user interfaces in the Windows environment. OLD NEW In other words: Human UI makes your GH definition feel like a Windows app. Create tabbed views, dynamic sliders, pulldown menus, checkboxes, and even 3D viewports and web browsers that look great and make sense to anyone--including designers and clients with no understanding of Grasshopper. Human UI has been in development at NBBJ for over a year, as part of a larger NBBJ Design Computation initiative to deliver our tools internally as Products -- with fully automated installation, managed dependencies, analytics, documentation, and “magical” user experience. Human UI has been a huge component of the user experience part of this puzzle, and we are excited to share it with the larger Grasshopper community so that others can benefit from it and contribute to its development. The initial release of Human UI is accompanied by a few simple examples to get you started, but we have developed sophisticated user interfaces with these tools at NBBJ and will slowly be rolling out more advanced examples. We also look forward to opening up the development to the community and seeing what new features and paradigms we can add. Download the plugin at Food4Rhino and get started building Custom UIs for Grasshopper right away! We are happy to answer any questions or field discussion in the dedicated Grasshopper Group. Please join us! Join the Grasshopper Group http://www.grasshopper3d.com/group/human-ui Download the plugin + sample files http://www.food4rhino.com/project/human-ui Visit the Bitbucket Repo https://bitbucket.org/andheum/humanui We look forward to seeing where this project takes you, please share your projects made with Human UI! Sincerely, Design Computation Leadership Team, NBBJ …; Added by NBBJ Architects at 11:18am on February 2, 2016

Comment on: Topic 'Geometry and Generic deserialization bug.': the command history dump... Cheers, --Mitch ================================== Command: GrasshopperObjects to reference:Objects to reference. Press Enter when done:GH_Structure deserialization begun{ (The local structure contains interfaces, not classes.) Deserializing at branch index 0, path: {0} Tracking down local type: Grasshopper.Kernel.Types.GH_PointConstructing Goo-Table{ Parsing assembly: Grasshopper, Version=1.0.0.20, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Arc Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Boolean Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Box Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Brep Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Circle Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Colour Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_ComplexNumber Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Curve Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Field Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_GeometricGooWrapper Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_GeometryGroup Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Guid Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Integer Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Interval Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Interval2D Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Line Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Material Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Matrix Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Mesh Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_MeshFace Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_MeshingParameters Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Number Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_ObjectWrapper Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Plane Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Point Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Rectangle Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_String Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_StructurePath Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Surface Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Time Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Transform Found IGH_Goo implementation: Grasshopper.Kernel.Types.GH_Vector Parsing assembly: CurveComponents, Version=1.0.4597.40619, Culture=neutral, PublicKeyToken=null Parsing assembly: FieldComponents, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null Parsing assembly: GalapagosComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Parsing assembly: GhPython, Version=0.5.1.0, Culture=neutral, PublicKeyToken=null Parsing assembly: GH_Kangaroo, Version=0.66.0.0, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: Kangaroo.NodeClass.KSpring Found IGH_Goo implementation: Kangaroo.NodeClass.KSpring2 Found IGH_Goo implementation: Kangaroo.NodeClass.KPlaw Found IGH_Goo implementation: Kangaroo.NodeClass.KUForce Found IGH_Goo implementation: Kangaroo.NodeClass.KBend Found IGH_Goo implementation: Kangaroo.NodeClass.KAlign Found IGH_Goo implementation: Kangaroo.NodeClass.KPressure Found IGH_Goo implementation: Kangaroo.NodeClass.KAnchorSpring Found IGH_Goo implementation: Kangaroo.NodeClass.KEqualSums Found IGH_Goo implementation: Kangaroo.NodeClass.KHinge Found IGH_Goo implementation: Kangaroo.NodeClass.KWind Found IGH_Goo implementation: Kangaroo.NodeClass.KHydro Found IGH_Goo implementation: Kangaroo.NodeClass.KShear Found IGH_Goo implementation: Kangaroo.NodeClass.KVortex Found IGH_Goo implementation: Kangaroo.NodeClass.KPlanar Found IGH_Goo implementation: Kangaroo.NodeClass.KConic Found IGH_Goo implementation: Kangaroo.NodeClass.K4Equalize Found IGH_Goo implementation: Kangaroo.NodeClass.KLapSmooth Found IGH_Goo implementation: Kangaroo.NodeClass.KLevelSet Found IGH_Goo implementation: Kangaroo.NodeClass.KDevelop Found IGH_Goo implementation: Kangaroo.NodeClass.KEqualizeN Found IGH_Goo implementation: Kangaroo.NodeClass.KPullToSurf Found IGH_Goo implementation: Kangaroo.NodeClass.KPullToMesh Found IGH_Goo implementation: Kangaroo.NodeClass.KCollideSurf Found IGH_Goo implementation: Kangaroo.NodeClass.KCollideMesh Found IGH_Goo implementation: Kangaroo.NodeClass.KReMesh Found IGH_Goo implementation: Kangaroo.NodeClass.KPullCurve Found IGH_Goo implementation: Kangaroo.NodeClass.KRocket Found IGH_Goo implementation: Kangaroo.NodeClass.KPointParticle Found IGH_Goo implementation: Kangaroo.NodeClass.KAnchorXYZ Found IGH_Goo implementation: Kangaroo.Options.KOptions Parsing assembly: LegacyScriptComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Parsing assembly: MathComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: MathComponents.ExpressionComponents.VariantType Parsing assembly: MeshEdit, Version=1.0.9.0, Culture=neutral, PublicKeyToken=null Parsing assembly: ScriptComponents, Version=1.0.4597.40617, Culture=neutral, PublicKeyToken=null Parsing assembly: SurfaceComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: SurfaceComponents.SurfaceComponents.LoftOptions Found IGH_Goo implementation: SurfaceComponents.MeshComponents.GH_MeshPoint Parsing assembly: XformComponents, Version=1.0.4597.40618, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: SquishyXMorphs.GH_TwistedBox Parsing assembly: TriangulationComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Parsing assembly: VectorComponents, Version=1.0.4597.31226, Culture=neutral, PublicKeyToken=null Found IGH_Goo implementation: VectorComponents.PointComponents.CoordinateMaskType Parsing assembly: WeaverBird.Gh.CommonSdk, Version=0.5.20.0, Culture=neutral, PublicKeyToken=null}Search for type: Grasshopper.Kernel.Types.GH_Point{ Found matching type} Local type found: GH_Point Valid instance added to branch: Referenced Point Tracking down local type: Grasshopper.Kernel.Types.GH_Point} Local type found: GH_Point Valid instance added to branch: Referenced Point Tracking down local type: Grasshopper.Kernel.Types.GH_Point} Local type found: GH_Point Valid instance added to branch: Referenced Point Tracking down local type: Grasshopper.Kernel.Types.GH_CurveSearch for type: Grasshopper.Kernel.Types.GH_Curve{ Found matching type} Local type found: GH_Curve Valid instance added to branch: Null Curve Tracking down local type: Grasshopper.Kernel.Types.GH_BrepSearch for type: Grasshopper.Kernel.Types.GH_Brep{ Found matching type} Local type found: GH_Brep Valid instance added to branch: Referenced Brep Tracking down local type: Grasshopper.Kernel.Types.GH_Brep} Local type found: GH_Brep Valid instance added to branch: Referenced Brep Tracking down local type: Grasshopper.Kernel.Types.GH_Brep} Local type found: GH_Brep Valid instance added to branch: Referenced Brep Tracking down local type: Grasshopper.Kernel.Types.GH_Curve} Local type found: GH_Curve Valid instance added to branch: Null Curve}…; Added by Mitch Heynick at 3:15am on September 21, 2012

Topic: Preview geometry from custom class: nfinite loop). Here’s what I’m doing: The custom class I derive from GH_Goo<object> and I make it inherit from IGH_PreviewObject. I override IsPreviewCapable, ClippingBox, Hidden, DrawViewportWires and I create some PreviewArgs from some lines created by the class, as shown in the code below. In my component I then call DrawViewportWires and pass the PreviewArgs I created in the class. Is that the right thing to do? public class CustomClass : GH_Goo<object>, IGH_PreviewObject { //GH_Goo stuff //Custom Class stuff bool IGH_PreviewObject.IsPreviewCapable { get { return true; } } private BoundingBox boundingBox; private BoundingBox BoundingBox { get { List<Point3d> ptsPreview = new List<Point3d>(); //add points to list foreach (Point3d pt in pts) { ptsPreview.Add(pt); } boundingBox = new BoundingBox(ptsPreview); return boundingBox; } } BoundingBox IGH_PreviewObject.ClippingBox { get { return BoundingBox; } } bool IGH_PreviewObject.Hidden { get { return false; } set { //… } } void IGH_PreviewObject.DrawViewportWires(IGH_PreviewArgs ArgsWires) { //base.DrawViewportWires(ArgsWires); -what’s base with GH_Goo<object>? ArgsWires.Display.DrawLines(PreviewLines, Color.Red); } void IGH_PreviewObject.DrawViewportMeshes(IGH_PreviewArgs ArgsMeshes) { //base.DrawViewportWires(ArgsMeshes); -what’s base with GH_Goo<object>? } public IGH_PreviewArgs ArgsWires { get { ArgsWires.Display.DrawLines(PreviewLines, ArgsWires.WireColour); return ArgsWires; } } private List<Line> previewLines; public List<Line> PreviewLines { get { previewLines = new List<Line>(); foreach (Line l in lines) { previewLines.Add(l); } return previewLines; } } } In the component which uses the class, I then call CustomClass cl = new CustomClass(); DrawViewportWires(cl.Args); I’ve also tried cl.DrawViewportWires(cl.ArgsWires); but I get the same error. Also, I’ve tried putting all of the IGH_PreviewObject stuff into the component and collecting the “previewLines” in SolveInstance, which didn’t cause Grasshopper to freeze, but didn’t display anything either. Any help/pointers in the right direction would be greatly appreciated! Thanks, Daniel …; Added by Daniel Gebreiter at 4:59am on April 1, 2012

Topic: Which Scripting Language should I learn? C#, VB.Net, or Python?: /www.grasshopper3d.com/forum/topics/vb-vs-c-vs-python http://www.grasshopper3d.com/forum/topics/which-programming-language-should-i-focus-on-vb-or-python VB.Net and C# VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order: Performance - VB.Net and C# scripts tend to execute faster because they are "Just-in-time" compiled as opposed to interpreted. Autocomplete - both VB.Net and C# have rich autocomplete functionality in their respective script editor components - significantly more so than the python editor. This can be helpful for beginners since you can "hunt" for methods and properties by just typing a "." after an object name and looking at the list of available methods/properties. Native Component development - If you eventually want to develop GHA assemblies/plug-ins for grasshopper, as of Rhino 5 you will have to use one of these two languages. However, there are plans to introduce python-based plugins in Rhino 6. Even so, the resources around plug-in development are very rich in the C# and VB.Net environments (with c# seeming to be the more popular of the two). "Strong Typing" - VB.net to some degree, and C# especially, are less "forgiving" languages than python - they require you to know about the data type of the objects you're operating on. This can sometimes result in more verbose code - as you explicitly convert from type to type - but it also promotes good programming practice and helps make errors more understandable. .Net ecosystem - using a .Net language means you have access to the thousands of libraries publicly available, and the process of referencing these libraries and making use of them is comparatively straightforward relative to python. More on this in the following section. Resources/Support - At least as of 2012, VB and C# turned up more results on this forum than python, and I think you'll find slightly more expert-level coders in those languages able to help you here. Which one between the two? C# or VB.Net? - Personally, I greatly prefer C# - I find it to be cleaner and clearer to use. I also have some programming background in C++/Java/Processing so I found the "C family" approach to be more familiar. As David and Damian point out in some of the posts linked above, C# is more popular than either python or VB.net in the rest of the coding world. However, if you are learning without any prior programming experience you may find VB.net to be a bit easier to learn. Python Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable. Syntax - Python is beautiful to read and write. Its syntax is very clear and free of extraneous punctuation (for example the ";" line endings in c#). It has many very nice language features that make common tasks more concise, like its loop syntax, list comprehensions, list "map" and "filter." Multiple ways to talk to Rhino/Grasshopper - Python enables two general approaches to interacting with the Rhino/Grasshopper environment: RhinoCommon and RhinoScriptSyntax. If you have prior experience with Rhinoscript, you may find RhinoScriptSyntax to be preferable - it adapts many of the methods you're familiar with to the python language, and simplifies some tasks. A word of caution though - working with Rhinoscriptsyntax can introduce a performance hit relative to RhinoCommon operations. C# and VB.net by contrast can only work with RhinoCommon. "Goodies" - The Python environment in Grasshopper has some "special features" that the other languages lack. In particular, the "GHPythonLib" library enables the ability to call most Grasshopper components from within your code, and the ability to easily enable parallel processing to improve performance. (A word of caution though - these two features do not seem to "play well" with each other, there may be bugs causing memory leaks that result in increasingly worse performance with each execution). Cross-Platform - Unlike C#/VB.net, Python can be used natively in Rhino for Windows and Rhino for Mac. Direct scripting in Rhino - You can also use Python directly in the Rhino environment without the need for Grasshopper if you desire, using the Rhino Python editor. IronPython / Ecosystem issues - one frustration / potential downside to working with Python for Rhino/GH is that though there is a vast, amazing ecosystem of external libraries for Python, getting these to install/work properly in the Rhino/GH environment can be a real pain - largely because the language is actually "IronPython," a version of python designed to work closely with the .Net ecosystem. Many popular libraries like numpy and scipy are very challenging to get working in Rhino/GH. Scripting in other programs - Especially in the AEC industry, Python is a popular scripting language for other applications. Tools like Revit, Dynamo, Blender, and ArcGIS all offer their own Python scripting interface - so learning Python in Rhino/GH can give you a leg up in eventually scripting in these other programs. Python's Stock is Rising - there are currently a number of efforts to improve the "status" of python within the Rhino/GH ecosystem. The python editor in Rhino 6 has a number of improvements, not least of which is the ability to "compile" add-ons for Grasshopper written in python. I'm sure Giulio can speak to other upcoming improvements. I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both. I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there. …; Added by Andrew Heumann at 12:38am on March 28, 2016