Search Results - 双色球和值尾数是8和9的数『1TBH·COM』全球通彩票代理注册2023年3月19日7时59分41秒.H5c2a3.ivhduifoj

Comment on: Topic 'Pain Points in Grasshopper': 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…; Added by David Rutten at 2:11am on August 2, 2014

Event: Moltitudine - Power of the many _ GH advanced workshop: ne – power of the many è un corso advanced level che studia la produzione di effetti complessi a partire dalla modellazione di comportamenti semplici su un insieme strutturato con un numero alto di elementi. Attraverso un approccio generico e scaleless sarà possibile affrontare la tematica generale su più fronti e in una molteplicità di declinazioni possibili. Il corso è rivolto a chi,indipendentemente dal proprio background (urbanistica, architettura, ingegneria, design, arte o altro) già possiede una esperienza di base con Rhinoceros e Grasshopper, e desidera sviluppare aspetti di gestione avanzata del flusso di articolato di informazioni attraverso una strategia guidata basata su esempi pratici e sull’implementazione di un progetto personale sul tema generale del “field behaviour”. Sarà trattato anche l’utilizzo di alcuni plug-ins quali gHowl e WeaverBird. Il numero dei partecipanti è fissato a un massimo di 20 per offrire un tutoraggio proficuo ed una effettiva esperienza di learning ad ogni iscritto. [.] Temi: teoria . complessità, emergence, effetti di campo (field behaviour), sensibilità, efficienza multiperformance tecnica . dati:gestione e manipolazione avanzata del data tree, streaming e visualizzazione; transizione, blending e modulazione delle geometrie; generazione e controllo multiperformance di popolazioni di componenti; attrattori, drivers e tecniche di modulazione avanzate; uso delle mesh con WeaverBird; ottimizzazione con Galapagos [.] Dettagli : Tutors: Alessio Erioli + Andrea Graziano – Co-de-iT Si richiede esperienza di base nella modellazione in Rhino (equivalente a Rhino training Level 1, il Level 2 è gradito – la documentazione per il training è disponibile gratuitamente all’indirizzo: http://download.rhino3d.com/download.asp?id=Rhino4Training&language=it) e nell’uso di Grasshopper (la suddivisione di una superficie NURBS in componenti tramite isotrim è data come base assodata) . luogo: IreCoop – via Vasco De Gama 27 _ Firenze . durata: 25-27 febbraio 2010 – 3 giornate consecutive _ orario 9:00 – 18:00 . costo: professionisti – 450.00 € studenti – 280.00 € . note: scadenza iscrizioni: 20 febbraio 2010 il corso sarà attivato con un numero minimo di 15 iscritti al termine sarà rilasciato un attestato di frequenza gli iscritti dovrano venire muniti dei propri laptop con software installato. una versione free per 30 giorni è disponibile sul sito www.rhino3d.com . contatti: iscrizioni + info alloggi: www.irecooptoscana.it (Cosa offriamo > formazione > altri corsi) info sul corso: info@co-de-it.com…; Added by Alessio Erioli at 11:22am on February 7, 2011

Blog Post: Maze Bowl

From virtuality model to reality for a maze bowl :

After some encouragements in August 2016, I decided in December 2016 to made a real Maze Bowl similar to this one…

Added by Laurent DELRIEU at 3:13pm on December 19, 2016

Topic: Ladybug Photovoltaics components released !: nts for Ladybug too. They are based on PVWatts v1 online calculator, supporting crystalline silicon fixed tilt photovoltaics. You can download them from here, or use the Update Ladbybug component instead. If you take the first option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock"). You can download the example files from here. Video tutorials will follow in the coming period. In the very essence these components help you answer the question: "How much energy can my roof, building facade, solar parking... generate if I would populate them with PV panels"? They allow definition of different types of losses (snow, age, shading...) which may affect your PV system: And can find its optimal tilt and orientation: Or analyse its performance, energy value, consumption, emissions... By Djordje Spasic and Jason Sensibaugh, with invaluable support of Dr. Frank Vignola, Dr. Jason M. Keith, Paul Gilman, Chris Mackey, Mostapha Sadeghipour Roudsari, Niraj Palsule, Joseph Cunningham and Christopher Weiss. Thank you for reading, and hope you will enjoy using the components! EDIT: From march 27 2017, Ladybug Photovoltaics components support thin-film modules as well. References: 1) System losses: PVWatts v5 Manual, Dobos, NREL, 2014 2) Sun postion equations by Michalsky (1988): SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014 edited by Jason Sensibaugh 3) Angle of incidence for fixed arrays: PVWatts Version 1 Technical Reference, Dobos, NREL, 2013 4) Plane-of-Array diffuse irradiance by Perez 1990 algorithm: PVPMC Sandia National Laboratories SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014 5) Sandia PV Array Performance Module Cover: PVWatts Version 1 Technical Reference, Dobos, NREL, 2013 6) Sandia Thermal Model, Module Temperature and Cell Temperature Models: Photovoltaic Array Performance Model, King, Boys, Kratochvill, Sandia National Laboratories, 2004 7) CEC Module Model: Maximum power voltage and Maximum power current from: Exact analytical solutions of the parameters of real solar cells using Lambert W-function, Jain, Kapoor, Solar Energy Materials and Solar Cells, V81 2004, P269–277 8) PVFORM version 3.3 adapted Module and Inverter Models: PVWatts Version 1 Technical Reference, Dobos, NREL, 2013 9) Sunpath diagram shading: Using sun path charts to estimate the effects of shading on PV arrays, Frank Vignola, University of Oregon, 2004 Instruction manual for the Solar Pathfinder, Solar Pathfinder TM, 2008 10) Tilt and orientation factor: Application for Purchased Systems Oregon Department of Energy solmetric.com 11) Photovoltaics performance metrics: Solar PV system performance assessment guideline, Honda, Lechner, Raju, Tolich, Mokri, San Jose state university, 2012 CACHE Modules on Energy in the Curriculum Solar Energy, Keith, Palsule, Mississippi State University Inventory of Carbon & Energy (ICE) Version 2.0, Hammond, Jones, SERT University of Bath, 2011 The Energy Return on Energy Investment (EROI) of Photovoltaics: Methodology and Comparisons with Fossil Fuel Life Cycles, Raugei, Fullana-i-Palmer, Fthenakis, Elsevier Vol 45, Jun 2012 12) Calculating albedo: Metenorm 6 Handbook part II: Theory, Meteotest 2007 13) Magnetic declination: Geomag 0.9.2015, Christopher Weiss…; Added by djordje to Ladybug Tools at 2:04pm on June 15, 2015

Topic: Memory exception in a custom plugin, manipulating Rhino layers: . Things have been working swimmingly in many areas of the plugin, but one particular problem has been tough to solve. I have two components that are trying to read/write to the same memory at the same time, causing Rhino exceptions and crashes. The conflicts appear to be happening between two components -- one is a "Layer Events Listener" that reports essentially what type of layer event just happened. The other is a "Set Layer Visibility" component that toggles the visibility of a list of layers. The code: public class LayerTools_LayerEventsListener : GH_Component { /// <summary> /// Initializes a new instance of the LayerTools_LayerListener class. /// </summary> public LayerTools_LayerEventsListener() : base("Layer Events Listener", "Layer Listener", "Get granular information about the layer events happening in the Rhino document.", "Squirrel", "Layer Tools") { } /// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to listen to layer events in the Rhino document.", GH_ParamAccess.item, false); pManager.AddTextParameter("Exclusions", "E", "Provide a list of exclusions to stop reading specific events (Added, Deleted, Moved, Renamed, Locked, Visibility, Color, Active).", GH_ParamAccess.list); pManager[1].Optional = true; } /// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddBooleanParameter("Initialized", "I", "Whether the listener changed from passive to active.", GH_ParamAccess.item); pManager.AddTextParameter("Document Name", "doc", "Name of the Rhino document that is changing.", GH_ParamAccess.item); pManager.AddTextParameter("Layer Path", "path", "Path of the modifed layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Layer Index", "ID", "Index of the modified layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Sort Index", "SID", "Sort index of the modified layer.", GH_ParamAccess.item); pManager.AddTextParameter("Event Type", "T", "Type of the modification.", GH_ParamAccess.item); pManager.AddBooleanParameter("Added", "A", "If the layer has been added.", GH_ParamAccess.item); pManager.AddBooleanParameter("Deleted", "D", "If the layer has been deleted.", GH_ParamAccess.item); pManager.AddBooleanParameter("Moved", "M", "If the layer has been moved.", GH_ParamAccess.item); pManager.AddBooleanParameter("Renamed", "R", "If the layer has been renamed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Locked", "L", "If the layer locked setting has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Visibility", "V", "If the layer's visibility has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Color", "C", "If the layer's color has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Active", "Act", "If the active layer has changed.", GH_ParamAccess.item); } /// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; List<string> exclusions = new List<string>(); DA.GetData(0, ref active); DA.GetDataList(1, exclusions); RhinoDoc thisDoc = null; bool initialize = false; string dName = null; string activePath = null; int layerIndex = -1; int sortIndex = -1; string eventType = null; bool added = false; bool deleted = false; bool moved = false; bool renamed = false; bool locked = false; bool visibility = false; bool color = false; bool current = false; if (active) { thisDoc = RhinoDoc.ActiveDoc; initialize = (!previouslyActive) ? true : false; RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; RhinoDoc.LayerTableEvent += RhinoDoc_LayerTableEvent; previouslyActive = true; } else { RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; previouslyActive = false; } if (ev != null) { dName = ev.Document.Name; layerIndex = ev.LayerIndex; eventType = ev.EventType.ToString(); if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Current") { // active layer has just been changed current = true; } } if (!exclusions.Contains("Moved")) { if (ev.EventType.ToString() == "Sorted") { // active layer has just been changed moved = true; } } if (!exclusions.Contains("Added")) { if (ev.EventType.ToString() == "Added") { // layer has just been added activePath = ev.NewState.FullPath; added = true; } } if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Deleted") { // layer has just been added deleted = true; } } if (ev.EventType.ToString() == "Modified") { // layer has been modified activePath = ev.NewState.FullPath; //skip sortindex eventType = ev.EventType.ToString(); if (ev.OldState != null && ev.NewState != null) { if (!exclusions.Contains("Locked")) { if (ev.OldState.IsLocked != ev.NewState.IsLocked) locked = true; } if (!exclusions.Contains("Visibility")) { if (ev.OldState.IsVisible != ev.NewState.IsVisible) visibility = true; } if (!exclusions.Contains("Moved")) { if (ev.OldState.ParentLayerId != ev.NewState.ParentLayerId) moved = true; } //if (ev.OldState.SortIndex != ev.NewState.SortIndex) moved = true; if (!exclusions.Contains("Renamed")) { if (ev.OldState.Name != ev.NewState.Name) renamed = true; } if (!exclusions.Contains("Color")) { if (ev.OldState.Color != ev.NewState.Color) color = true; } } } } DA.SetData(0, initialize); DA.SetData(1, dName); DA.SetData(2, activePath); DA.SetData(3, layerIndex); DA.SetData(4, sortIndex); DA.SetData(5, eventType); DA.SetData(6, added); DA.SetData(7, deleted); DA.SetData(8, moved); DA.SetData(9, renamed); DA.SetData(10, locked); DA.SetData(11, visibility); DA.SetData(12, color); DA.SetData(13, current); } static bool previouslyActive = false; Rhino.DocObjects.Tables.LayerTableEventArgs ev = null; void RhinoDoc_LayerTableEvent(object sender, Rhino.DocObjects.Tables.LayerTableEventArgs e) { ev = e;this.ExpireSolution(true); } And for the layer visibility component: public LayerTools_SetActiveLayer() : base("Set Active Layer", "SetActiveLayer", "Set the active layer in the Rhino document.", "Squirrel", "Layer Tools") { } /// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to change the active layer in Rhino.", GH_ParamAccess.item, false); pManager.AddTextParameter("Path", "P", "Full path of the layer to be activated.", GH_ParamAccess.item); } /// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddIntegerParameter("Layer ID", "ID", "Index of layer that has been activated.", GH_ParamAccess.item); pManager.AddBooleanParameter("Status", "St", "True when the layer has been activated.", GH_ParamAccess.item); } /// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; string path = ""; if (!DA.GetData(0, ref active)) return; if (!DA.GetData(1, ref path)) return; int layer_index = -1; bool status = false; if (path != null) { Rhino.RhinoDoc doc = Rhino.RhinoDoc.ActiveDoc; Rhino.DocObjects.Tables.LayerTable layertable = doc.Layers; layer_index = layertable.FindByFullPath(path, true); if (layer_index > 0) { // if exists RhinoDoc.ActiveDoc.Layers.SetCurrentLayerIndex(layer_index, true); status = true; } } DA.SetData(0, layer_index); DA.SetData(1, status); } Now originally I was getting exceptions when changing multiple layers' visibility properties, which would cause the Event Listener to fire and try to read the Visibility property before the memory has been released by the Set Layer Visibility component. That led me to add an "Exceptions" input, that would allow me to disable the reading of Visibility events at the source in the Layer Events listener. That helped me manage about 95% of the crashes I was getting, but I still get strange crashes in other event properties, even when that property shouldn't be affected. For instance, I am getting a crash here on the Name property in the event from the delegate function, even though I am only changing Visibility at any one time: I have a few ideas but they all seem pretty hacky. One is to try to set a flag that is readable by any component in the plugin -- so that the event listener can see if a "set" component is currently running and abort before causing an exception. The other is creating a delay in the event listener, somthing like 200ms, to allow any set components to finish what they are doing before reading the event. Neither seems super ideal. Any ideas? Thanks, Marc …; Added by Marc Syp at 10:45pm on July 5, 2017

Event: Rhino.GetMe Workshop abril 2011 México: de modelación en 3D y aprovechen las ventajas que plantean, como mejorar su proceso de diseño y explorar múltiples alternativas para un proyecto en lapsos de tiempo muy reducidos en comparación de los métodos tradicionales. En consecuencia, los alumnos tendrán la posibilidad de disminuir sus tiempos de trabajo, con resultados iguales o incluso mejores a los que obtenían con anterioridad; mejorar la calidad de sus presentaciones y, lo que es más importante, ampliar la fundamentación de sus proyectos en el aspecto funcional y formal, dependiendo de las características del proyecto. Para lograr estos objetivos, se contemplan dos temarios y un ejercicio práctico. Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, con el objetivo que el alumno pueda continuar aprendiendo con alguno de nuestros siguientes workshops o de manera autodidacta. Además del contenido teórico se incluye un ejercicio práctico, la magnitud del ejercicio y el material que se le destine se definirán con base en el número de asistentes. El workshop tiene una duración de cinco sesiones: Sesión 1 – Temario de Rhinoceros Sesión 2 y 3 – Temario de Grasshopper Sesión 4 y 5 – Ejercicio práctico El horario es de 9 am a 4 pm, con una hora de receso para tomar un refrigerio. No es necesario traer el equipo necesario para trabajar, se cuenta con un equipo para cada persona asi como el material de trabajo para el ejercicio práctico, por lo cual se les recomienda que no traigan portátiles u otro material, únicamente dispositivos de almacenamiento si desean guardar sus trabajos. El costo del evento es de $3,500 estudiantes y $4,000 profesionales. (Para poder tener el descuento de estudiante es necesaria una constancia de la universidad de la que proviene, acreditando que el interesado está cursando algún semestre de la carrera. Personas graduadas que estén cursando una maestría o algún grado superior no reciben el descuento). Para apartar su lugar pueden realizar un depósito de $1,500 y terminar de efectuar el pago antes del 15 de abril si es mediante un depósito bancario o el primer día del evento en efectivo. El evento se realizará en las oficinas de Vegasot, ubicadas en Circuito Cirujanos No. 23-A Cd. Satélite, Naucalpan, Edo. de México 53100 http://www.vegasoft.com.mx Para cualquier duda por favor escriban un correo a luzytextura@gmail.com, por teléfono al 044 55 4381 3302, o en facebook.com/archbernardorivera…; Added by Bernardo Filiberto Rivera López at 4:25pm on February 19, 2011

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: Gismo 0.0.2 Release Notes: , Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address: 2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii: 3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input. 4) 9 new components have been added: "Address To Location" - finds latitude and longitude coordinates for the given address. "XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it. 5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!! Basically just forget about this yellow panel: This panel is not valid anymore, so just use any unit you want. 6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone. The version 0.0.2 can be downloaded from here: https://github.com/stgeorges/gismo/zipball/master And example files from here: https://github.com/stgeorges/gismo/tree/master/examples Any new suggestions, testing and bug reports are welcome!!…; Added by djordje to Gismo at 5:13pm on March 1, 2017

Blog Post: Aether – simple speedy spatial fields for Grasshopper

Added by Daniel Piker at 7:25am on December 16, 2014

Comment on: Topic 'contour possible bug': y anyway ;)) Since 2014 i begun to get back into the construction biz for some dozen main reasons, one of them being the highly increased availability of this kind of software "power", and robotics. first project ended by 1stQ 2015 was focused on the development of a parametric block for construction. (almost sure the first parametric product designed in Uruguay, and probably one of the few first of this kind globally...) Far from being a complicated model. In fact the standard model is extremely simple, key thing is that is fully parametric... dimensions, materials, textures, colors... and so on second key thing is that the main common component of the blocks (an EPS core) is robotically machined... the blocks are the base of a construction system (oriented mainly - though not restricted only - to residential buildings) that - is based on digital models, tendentially to be used in parametric models of buidings - lab tested to prove to be 1.5 times as compression resistant than traditional bricks and blocks. (autoportability up to two stories buildings) - has recently proved (due to size) to be 300% more efficient than the classic and 200% more efficient than steel frame in (our country official figures) check it out here -- https://drive.google.com/file/d/0B1TRxxgF_sEnQnZrTkZGbUx3cmM/view -- - and it's aimed to be mass produced and handled by robots... this project ended on 1H 2016 and i filed 4 patents in the process. 3 of them of mechanical devices designed as extensions for a cnc machine i own and the fourth ( the patent related specifically with the blocks ) included a dozen of innovations (believe me...i have almost 15 yrs in the biz, and are coool stuff...) along the project I've been working with inventor, even knowing in advance it will lack the kind of features I wanted to program many things... (lisp, VB, etc.... all same species of -prehistoric - animals) to leverage the tool to the sky - and far beyond... - but was an alternative valid by that time because it allows the implementation of some form of parametric models, had a local representative and some supposedly skilled guys in the neibourhood.... but life is hard... and none of the latter two rendered me any significant help so I had to take the tour myself... - mind i never regret to do things that others cant - and finish what i start this one was a great project for many figures... and ended with more results than the ones commited to accomplish... ... some more history here .... then because of a customer who brought a ZHA project ! to quote..., I crossed with rhino, and then met GH again to notice to my great joy and pleasure, in what kind of animal it had developed... since money talks I'm investing hard on getting up to the expectations, and beyond as i usually do... and thats how we met.. 2017-2018 it's the time frame to build two robots. first one is a prototype to handle the k-nano blocks in the production process, delivery AND at the construction site ( a "smart crane" we nicknamed...) the other one is the first prototype of robot to assist in the fabrication (smart blocker we called it to be creative ! ;)) then by 2018-2019 i'll be making a "kinda contour crafter" machine to complete the pie :) (you'll be interested on this..) i guess you already know what all this has to do with GH... i already have all the components i can imagine to do almost all i ever wanted to do in relation to this set of projects but in almost a single tool !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! i can design, animate, render, optimize, simulate and even robotic simulate.. so, i have to ask... is there a chance you might be interested in helping us in some projects we are starting on march and june 2017 (8 and no more than 18 months of duration respectively) ? sent you a friend request, for the case you might be interested to continue by e-mail... in any case many thanks for your help and inspiration ! best regards ! long happy marriage, and large figures bank account ! …; Added by franco ferreiro at 1:05pm on February 22, 2017