ración de 150 horas divididas en cuatro módulos, arrancando el 22 de Marzo del 2011 y terminando la segunda semana de Junio con sesiones los Martes y Jueves de 18:00 a 22:00hrs y algunos Sábados de 10:00 a 14:00hrs.
El tema central del diplomado es el uso integral de la herramienta digital en el proceso de diseño a partir de la base teórica del fenómeno de la emergencia (entendida como la obtención de resultados complejos a partir de la interacción de elementos simples con reglas de bajo nivel de sofisticación).
El desarrollo del programa se concentra en la aplicación práctica de las reflexiones teóricas generadas mediante el uso de herramientas digitales generativas, principalmente Grasshopper (plug-in de modelado parametrico para Rhinoceros).
Contaremos con la presencia de dos colaboradores internacionales: EL primero será un miembro de LaN (Live Architecture Network) que impartirá un curso sobre programación avanzada en Grasshopper enfocandolo a la realización de un objeto construido, haciendo énfasis en la transición entre lo virtual, lo análogo y lo físico. El segundo es Jalal el Ali, maestro en arquitectura por la Architectural Association, líder de la Unidad de Geometría Generativa de Buro Happold y actual líder de proyecto en Zaha Hadid Architects, quien dará un curso intensivo enfocado al uso de la herramienta digital y la producción digital, enseñando procesos que ha aplicado en la empresa donde trabaja. Jalal pronunciará también una conferencia magistral.
Es un programa promueve el uso de nuevas tecnologías y la integración de procesos de producción desde la concepción del diseño, aplicando los conocimientos teóricos en un objeto físico usando el laboratorio de fabricación de la Universidad Iberoamericana.
…
me work I was doing on DP on GH. Here are my conclusions:
- As Rhino is not a constraint-based modeller, assembly design without plugins(RhinoWorks or else) is just not possible. So as long as constraints will not be present in rhino... no constraints, no AEC.
- The list management that GH offers is 10 000 time more efficient and user friendly. So a good point would be to link all the list management tools with GH-like interface. In fact, for all operations that are not concerning assembly (wireframe generation for example), GH is way ahead in terms of speed IF you're not dealing with geodesic curves or parallels on surface, eventually boolean operations, that are really a weakness of Rhino in terms of precision and stability. You can also do amazing synchronised attributes datatrees quite easily in GH, that you can then synchronise via Excel with a massive product based on Catia without problem. It can easily save you a few days of work.
- Rhino does not handle pre-computation of the geometry without loading effectively that geometry, so you will not be able today to work on a product bigger than 2Gb (maybe 3) in rhino in any way, even on rhino v5 64 with 16Gb of Ram. With the constraint stuff, I really think it is the second bad point about rhino.
- As Jon said, I think Rhino has to be understood as a sketch-oriented application for the construction (this is not pejorative, that's what I personnaly prefere) in a sense that its usefulness is to allow research of design possibilities, that you can of course link afterwards with what you want, but too much basic options are missing to rhino to be really viable for AEC. I personnaly don't want to see geometrical sets to appear in rhino, it is absolutely useless considering grasshopper evolution towards clusters for exemple.
After that, in purely technical terms I would say that:
1) Possible, partially already working --> Clusters (waiting for updates)/nested definitions + SQL for attributes management on several working definitions.
2) --> I think there are two ideas here: a) exporting some dead geometry in an arborescence of files (can be done quite easily with LocalCode but it will remain dead. You can also create a definition based on dead geometry and update this geometry using the geometry cache. Of course if this geometry is automatically exported via LocalCode from a precedent definition, when you update the upper definitions then the modification is repercuted on all your model. Personnaly I think it is best not to do it in rhino. b) otherwise, it is just synchronisation of public attributes attached to existing parts/products, as I described previously.
3) Geometry Cache. You can also auto-loop you file using loading/unloading input geometry of your desifnition with LocalCode and some VB.
But maybe I am wrong on some points of course.
Best,
Thibault.
…
ng in Grasshopper?
As a general recommendation for developers in Grasshopper who are writing a part of their library which is performance-sensitive (please note: often the performance sensitive part is very limited) is to write it in C#, or maybe even C, or maybe even assembly :). Of course, the closer to the machine you will be, the easier it will be to harness all minimal optimizations. However, there is always a compromise between "getting things done" and "making them best" and this boundary is not very easy to catch, right?
If you want to have significant speed improvements for numerical calculations, I would at least recommend developing with C# in a compiled component using Visual Studio or SharpDevelop. The reason is: in order to provide the line number of possible errors, Grasshopper compiles C# scripts in debug mode! They will be much less optimized than what is possible even with today's technology. This does not preclude keeping the project open-source, if that is one of your goals.
Regarding the actual list:
1) Yes, the implied loop will probably be slower than just a simple for loop. This is because Grasshopper code has to keep track of more things than the ones you could be considering with your knowledge of of your very-special case. However, a factor of 10 is simply not acceptable and is likely a symptom of something else. In fact, I think I remember fixing a bug around that in Rhino WIP. However, it appears to be still slower also there. I've added a bugtracking item here.
2) If you are able to do all casts that are involved, and do them as Grasshopper does, please write that code that way. For example, if you supply a curve to an input with number hint, Grasshopper computes the length of the curve. There will have to be an "if" that checks if the input is a curve somewhere (or some similar construct). This aid for designers is what slows down the hint input.
3) Grasshopper has to keep side effects at bay. For example, components B and C are both connected to outputs of A. If you edit data in component B, and that data came from A you of course expect that data to be unchanged in C. This means that, for even lists of numbers, Grasshopper has to perform a deep copy of the output for each input. Otherwise, what happens if B sorts the list and C finds the index of the smallest number? This could be improved if GH components had some way of flagging themselves as non-data-mutating (constant). The fact that, by supplying special types, Grasshopper has no way of performing copies will likely speed things up. But be aware of possibly very annoying side effects creeping in if data is not immutable. Another option is performing the copy "optimally", just where you need it, because you know where your data is used. This is not information that is available to GH at present.
Does this help?
Thanks again for your input,
Giulio--Giulio Piacentinofor Robert McNeel & Associatesgiulio@mcneel.com…
input orientation of the objects. I can see that you've already done this with Vec2pt. Doing it with a sun vector is a little easier, because you are working with one vector, not a bunch of different vectors. you probably know a lot of this already, but I wanted to write a comment that is helpful to anyone coming across the discussion, because it is a common design task.
To orient a bunch objects towards a sun vector:
1. you need a vector to represent the sun's rays. You can either use an existing definition from the web (definitely look at Ted Ngai's amazing work on this), or just make a single adjustable vector as a stand in. I've often simply made a vector using azimuth and altitude angles as inputs, since those are common ways of describing the location of the sun, and makes it easy to look up a sun angle and put it in to your definition.
2. assuming you have some vector to represent the sun's rays, make a plane that is perpendicular to this vector. But Why, Precisely?, you're already familiar with some of the quirks of making a plane perpendicular to a vector, just keep those quirks in mind.
3. next, create reference planes for your panels. If your panels are flat (i.e. planar) this is really simple, just make a list of their planes, using whatever you like (check planarity, evaluate surface, whatever). If your panels are not planar, then you need to decide on a plane you can make from each one that you would like to use as a reference plane. plane from 3 points might be a good method here.
4.take your single plane that is perpendicular to your single sun vector, and place it at the origins of all of your reference planes. Now you have a sun-oriented plane for each panel.
5. Using the orient component, input your reference planes as the reference planes, and input your sun-oriented planes as the target planes, and input your panels as the geometry to transform. You should now have a bunch of panels oriented to the sun vector.
6. In this method, I've assumed that you want your panels perpendicular to a solar vector, to face the vector, but if you want a different relationship to the sun vector, you just need to change the relationship of that single first sun-oriented plane to whatever relationship you would like to make.
One thing to think of when designing for sun angles is just that at any given point in time, for any given point on the earth's surface, the rays of the sun are basically parallel. the angle of these rays changes over time, but at any other time, the rays are still parallel to each other, and can therefore be described by a single vector for each moment in time.…
diseño computacional.
La Visiting School digitalMed 2014, promovida por Medaarch y Emwesoft Sevilla S.L.N.E, se celebrará en la ciudad de Sevilla, y tendrá como tema central la Smart City y el estudio de la interacción entre las personas y su entorno a través de objetos, dispositivos e infraestructuras.
Fecha limite de inscripción: 16/01/2014
info@emwesoft.com
OBJECTIVOS Adquirir la capacidad de gestionar flujos de datos en los que las ciudades están sumergidas, para insertar proyectos que sean útiles, contextualizados, poco invasivos y aptos a establecer un intercambio de informaciones con los usuarios.
El objetivo final es redactar un catálogo de proyectos que puedan formar parte de un contexto urbano y puedan delinear el perfil de las ciudades en las que viviremos en el futuro próximo.
METODOLOGÍA Metodología basada en el aprendizaje activo, en la puesta en práctica de métodos activos que estimulan y facilitan el intercambio de experiencias y puntos de vista entre el alumnado: Buscando la participación del alumno, planteando todas las cuestiones que considere necesarias a la hora de aclarar conceptos.
Fomentando el debate y la colaboración entre los participantes.
Dando respuesta a las dudas planteadas.
La metodología será presencial, lo cual permite un mayor acercamiento entre profesor y alumno, y en consecuencia una mayor asimilación de los conceptos.
PROGRAMA Los primeros días del taller serán dedicados a establecer definiciones comunes que nos permitan trabajar a partir de significados compartidos. En esta fase se tratarán temáticas que recurren a menudo en la práctica arquitectónica contemporánea, es decir el diseño computacional, la fabricación digital y los data driven. Los alumnos tendrán la posibilidad de aprender a usar software para el diseño paramétrico, como Rhinoceros y el plug-in Grasshopper, a través del conocimiento de dichos software, el alumno conseguirá competencias teóricas y técnicas, para un enfoque al diseño computacional.
PROFESORADO La formación será impartida por profesionales con amplio conocimiento y experiencia en el ámbito. Los tutores serán los arquitectos Amleto Picerno Ceraso y Francesca Viglione.
DURACIÓN TOTAL DEL TALLER
40 horas
QUIÉN PUEDE PARTICIPAR?
. Funcionarios con una actitud proactiva hacia la construcción de ciudades inteligentes;
. Académicos y estudiantes en áreas relacionadas con el desarrollo de proyectos y soluciones tecnológicas para ciudades digitales y ciudades inteligentes;
. Arquitectos;
. Ingenieros;
. Diseñadores;
. Profesionales de las tecnologías de información y con relación a el área de tecnología.
REQUISITOS BÁSICOS
- Conocimiento básico de Rhinoceros
- Inglés medio
*Disponibilidad de un intérprete español.
PRECIO y Tarifa especial
El cuesto del taller es de 500€.
También hay facilitacióno en caso de Inscripciones de grupo: para cada grupo formado por 5 inscriptos, que paguen en un única solución, el costo total será de 4 miembros y no 5 (una persona gratis)
DONDE
Emwesoft Sevilla S.L.N.E C/ Monte Carmelo 21, 41011 – Sevilla (España)
Teléfono: +34 (955) 224 524
Email: info@emwesoft.com
Internet: www.emwesoft.com …
o está dirigido a estudiantes de arquitectura y diseño de interiores, recién titulados y profesionales interesados en el software o que necesiten conocer las herramientas básicas de las que dispone el programa en los diferentes ámbitos y cómo enfocarlas a arquitectura.
Descripción:El contenido del curso enseñará a utilizar el programa de diseño Rhinoceros 3D aplicando su metodología de trabajo en el campo de la arquitectura, básandose además de la creación de pequeños elementos paramétricos para controlar el diseño y acabar renderizando las geometrías 3d con V-Ray para Rhino.
El curso consta de 3 módulos de 12h de duración cada uno (que pueden realizarse juntos o por separado) en los cuales se profundizará en herramientas de Rhino, Grasshopper y V-Ray a medida que se realizan casos prácticos sobre proyectos arquitectónicos.Se pretende establecer un sistema de trabajo eficiente desde el inicio del modelado hasta la posterior creación de imágenes para documentación del proyecto.
Módulo Rhinoceros Arquitectura:• Conceptos básicos e interfaz de usuario Rhino• Introducción al sistema cartesiano en Rhino• Clases de complejidad de geometría• Importación/exportación de archivos compatibles• Topología NURBS• Trabajo con Sólidos• Estrategias básicas de Superficies• Introducción a Superficies Avanzadas
Módulo Grasshopper:• Conceptos básicos e interfaz de usuario Grasshopper• Introducción a parámetros base y componentes• Matemáticas y trigonometría como herramientas de diseño• Matemáticas aplicadas a creación de Geometría• Introducción a listas simples• Análisis de Superficies y Curvas• Dominios de Superficies y Curvas• Panelado de superficies• Manejo de listas y componentes relacionados• Modificación de panelados en función de atractores• Exportación/Importación de información a Grasshopper
Módulo V-Ray para Rhinoceros:• Conceptos básicos e interfaz de usuario V-Ray• Vistas guardadas• Materiales V-Ray• Materiales, creación y edición• Iluminación (Global Illumination, Sunlight, Lights)• Cámara Física vs Cámara default• Canales de Render• Postprocesado básico de canales
Detalles:Instructores: Alba Armengol Gasull y Oriol Carrasco (SMD Arquitectes)Idioma: CastellanoHorario: 22 JULIO al 26 JULIO 2013 // 10.00 – 14.00 / 16.00 – 20.00Organizadores: SMDLugar: SMD lab, c/Lepant 242 Local 11, 08013 Barcelona (map)
Software:Rhinoceros 5Grasshopper 0.9.00.56V-Ray 1.5 for RhinoAdobe Photoshop CS5Links de versiones de evaluación de los Softwares serán facilitadas a todos los asistentes. Se usará unica y exclusivamente la versión de Rhino para PC. Se ruega a los participantes traer su propio ordenador portátil.
Registro:Modalidad de precio reducido por tres módulos 275€Posibilidad de realizar módulos por separado 99€…
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…
.
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
…
ll geometry.
The difference with programs like Inventor is that they are made for production, regardless of the fabrication method. I won't go into detail about that, and instead focus on the modeling process.
In this little model, the starting point actually is a bit obvious, the foundation.
The only contents in the 3dm file are 27 lines. These indicate the location of each footing, and the direction of the tilt of each column. Everything else is defined in GH with the use of numbers as input parameters.
Needless to say, instead of those lines you could obviously generate lines and control the number of columns and panels, hence establish their layout, with any algorithmic or non-algorithmic criteria you please. That marks a major difference between GH and Inventor.
You can generate geometry with Inventor via scripting/customization (beyond iLogic), with transient graphics for visual feedback similar to GH's red-default previews. However Inventor's modeling functions are not set to input and output data trees. I won't go into detail on that, but suffice to say that the data tree associativity of GH was for me the first major difference I noticed. I've used other apps with node diagram interfaces like digital fusion for non-linear video editing since the late 90's, so the canvas did not call my attention when I first started using GH.
Anyways, here's a screen capture of the foundational lines:
In the first group of components, the centerlines of the rear columns are modeled:
And the locations in elevation for connection points are set. Those elevations were just numbers I copied from Excel, but you can obviously control that any way you please. I was just trying to model this quickly.
The same was done for the rear columns:
The above, believe it or not, took me the first 5 hours to get.
Here's a screen capture of what the model and definition looked like after 4 hours, not much:
If you're interested, next post I can get into the sketching part you mentioned, which is a bit cumbersome with GH, but not really.
I wouldn't say that using GH to do this little model was cumbersome, it just needed some thinking at the beginning. You do similar initial thinking when working with a feature-based modeler.…
Added by Santiago Diaz at 12:44am on February 24, 2011