Send Feedback
Defines enumerated values for all implemented corner styles in curve offsets.
Namespace: Rhino.GeometryAssembly: RhinoCommon (in RhinoCommon.dll) Version: 5.1.30000.12 (5.0.20693.0)
Syntax
C#
public enum CurveOffsetCornerStyle
Visual Basic
Public Enumeration CurveOffsetCornerStyle
Members
Member name
Value
Description
None
0
The dafault value.
Sharp
1
Offsets and extends curves with a straight line until they intersect.
Round
2
Offsets and fillets curves with an arc of radius equal to the offset distance.
Smooth
3
Offsets and connects curves with a smooth (G1 continuity) curve.
Chamfer
4
Offsets and connects curves with a straight line between their endpoints.
…
taTree.
2. Since GH is acyclic by design we can't pick individually (without code, that is) our "picks" for the iceberg ... thus we need a global policy applied to ALL grid points at once.
3. This is what the next part does: it picks randomly some iceberg stuff and modifies their Z by a random value. If the Z is always "above" the grid or not it depends upon the domain of values to operate. Seed means "roll the bones again" (meaning another collection).
4. So we have the modified points Data Tree (that are steady - acting as the tips of the iceberg). Let's call them Anchors.
5. If we subtract set 4 from 1 we have the points prone to vary according some manipulation. Kangaroo does that manipulation (this is the best add-on that GH has to offer by 1M miles made by a very clever fella).
6. But if we instruct Kangaroo to do the job... he makes chaos since the points in 4 are not sufficient: we need perimeter steady points that act as Anchors as well. So we manage some logic to pick a variable set of perimeter points and we "merge" 4 and 6 and we have the final set of Anchors on hand - whilst all the rest are points willing to change.
7. Kangaroo is a physics engine meaning that the only thing that understands is ... er ... points and their relation (the "line" connecting them, that is). Kinda like a CPU that understands 0 and 1 and nothing else.
8. So we provide Kangaroo info about all the lines involved: how "stiff" they are and what is the expected/desired final length.
9. By double clicking the Kangaroo component ... the "simulation" starts running (in some kind of "loops") and goes towards an "equilibrium" where all our desires are satisfied - or the solution's entropy is the minimum possible (well up to some level, he he). Kangaroo displays a small control dialog that allows you to halt the process or reset it (meaning: start again).
10. If the instructions are "good"/"proper" the "loops" (iterations) are relatively few: if K does 1M "loops" ... this means that your instructions are silly or not well thought.
After stopping Kangaroo ... we have (hopefully) a "well" distorted collection of points (and their equivalent mesh) to proceed further via components usually found in the WB add-on
PS: If all the above sound Greek to you ... it's because I'm Greek, he he.
Moral: Get the gist of Kangaroo ASAP - worth spending some time I recon. If you do that and you need examples (other than the ones available at download time) ... well I have more than 300 (from simple to ultra paranoid).…
serveral questions:the first thing is in c++ i have to implement more methods than in my c# test project.
they are:
int MyGhComponent::MasterParameterIndex::get(){ return 0;}void MyGhComponent::MasterParameterIndex::set(int index){ }bool MyGhComponent::IsValidMasterParameterIndex::get(){ return 1;}
i found no hint for the implementation of that interfaces. could someone tell me that is correct ?OK, it works, but is it well writen ? What is the MasterParameterIndex?
the second "bigger" problem is, i want to have an output of an pointlist.X y Z 1.2 1.3 1.12.1 5.2 9.2...
my first approch was to use a
void MyGhComponent::RegisterOutputParams(GH_Component::GH_OutputParamManager^ pManager){pManager->Register_PointParam("Coordinate", "XYZ", "Node-Coordinate");}
and
void MyGhComponent::SolveInstance(IGH_DataAccess^ DA){Collections::Generic::List<GH_IO::Types::GH_Point3D>^ pnt = gcnew Collections::Generic::List<GH_IO::Types::GH_Point3D>(); for (int i = 0; i < 10; i++) { GH_IO::Types::GH_Point3D^ point = gcnew GH_IO::Types::GH_Point3D(i, i, i); pnt->Add(i); } DA->SetDataList(3, pnt);}
but this exampel doesn't work...i wirte a small workaround and use the following
pManager->Register_DoubleParam("X-Koordinate", "X", "X"); pManager->Register_DoubleParam("Y-Koordinate", "Y", "Y"); pManager->Register_DoubleParam("Z-Koordinate", "Z", "Z"); Collections::Generic::List<double>^ pntx= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pnty= gcnew Collections::Generic::List<double>(); Collections::Generic::List<double>^ pntz= gcnew Collections::Generic::List<double>(); ... add .. ect.
this workaround do the job, but i want a better soulution. and i know somewhere out there sould be a better solution. i want to use 3D Points directly in GH without list conversation.
so somebody a familiar with c++ / cli ? and could give me some tipps or a soulution ?
the first thing is: what is the right RegisterOutputParams ?
and witch data type is the right ? Point3d doesn't work. so i try GH_IO::Types::GH_Point3D and Rhino::Geometry::Point3d ...
br Friedrich…
ing ways to leverage simulation results from ladybug and inform design of building envelops with benefits that can be modeled. Given 20 percent of the cost of a project typically goes to the facades, and maybe a half of that goes to the openings, there is a good enough reason to question how to materialize that 10 percent, which can result in 10-30 percent difference in total energy comsumption.
I think ideally radiation analysis, natural ventilation and daylight analysis on floors should all inform opening sizes and placements, as well as the building sections at large. However natural ventilation seems to be the most complicated one because it couples airflow and thermo dynamics. I have a definition setup so that I can batch simulations for radiation analysis and daylight analysis, but natural ventilation is the missing link. So for what I am doing now I will select a handful of design that seem to work the best based on the two available analysis and convert all the geometry into CAD files so that I can run them in an evaluation copy of autodesk simulation CFD. So for now I can do this in 2 stages.
But for the future, given the possibility of actually have that as a part of grasshopper feature, which would be lovely, I want to understand the science behind it and share some links.
(http://www.wbdg.org/resources/naturalventilation.php) In this link the author outlines quite a few general principles and variables to consider for natural ventilated buildings.
For example, how stack effect works.
Qstack = Cd*A*[2gh(Ti-To)/Ti]^1/2, where
Qstack = volume of ventilation rate (m³/s)Cd = 0.65, a discharge coefficient.A = free area of inlet opening (m²), which equals area of outlet opening.g =9.8 (m/s²). the acceleration due to gravityh = vertical distance between inlet and outlet midpoints (m)Ti = average temperature of indoor air (K), note that 27°C = 300 K.To = average temperature of outdoor air (K)
The thing about natural ventilation is that not only the sizes and positioning of openings of the facade facing predominant wind matter, but also the openings on the other side matter. The vertical distance between the inlets and outlets also need to be taken into account. The author suggests that naturally ventilated buildings should be no wider than 45 feet.
and in this pdf presentation it discusses CFD for natural ventilation and illustrates why it is not easy
http://isites.harvard.edu/fs/docs/icb.topic882838.files/L17.6205Airflow-Modeling_Ibarra.pdf
and in this pdf briefly outlines the approach taken by designbuilder
http://isites.harvard.edu/fs/docs/icb.topic472869.files/DesignBuilder%20Simulation%20Training_HSD.pdf
Lastly a wide spectrum of environmental analysis works by e3lab
http://www.e3lab.org/research
http://www.e3lab.org/green-buildings
If I make progress on a way to tie the three analysis together (radiation, daylight and natural ventilation), I wont forget to post it on this thread.
Thanks.…
,with OpenfoamV1612+ in Windows 10 64bit.The blockmesh worked good.And the snappyhexmesh crashed in the process.My computer memory is not enough? Or some settings wrong?Could you help me solve this question?/---------------------------------------------------------------------------| ========= | || \ / F ield | OpenFOAM: The Open Source CFD Toolbox || \ / O peration | Version: v1612+ || \ / A nd | Web: www.OpenFOAM.com || \/ M anipulation | |*---------------------------------------------------------------------------*/Build : v1612+Exec : snappyHexMeshDate : Aug 27 2017Time : 09:39:54Host : "default"PID : 13443Case : /home/ofuser/workingDir/butterfly/outdoor_airflownProcs : 1sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //Create time
Create mesh for time = 0
Read mesh in = 2.14 s
Overall mesh bounding box : (-241.5472 -241.4418 0) (496.4376 536.2438 144.8633)Relative tolerance : 1e-06Absolute matching distance : 0.001081851
Reading refinement surfaces.Read refinement surfaces in = 0.01 s
Reading refinement shells.Refinement level 3 for all cells inside around_buildings_area.stlRead refinement shells in = 0 s
Setting refinement level of surface to be consistent with shells.For geometry outdoor_airflow.stl detected 0 uncached triangles out of 120Checked shell refinement in = 0 s
Reading features.Read features in = 0 s
Determining initial surface intersections
Edge intersection testing:Number of edges : 1684728Number of edges to retest : 1684728Number of intersected edges : 5583Calculated surface intersections in = 1.68 s
Initial mesh : cells:554112 faces:1684728 points:576779Cells per refinement level:0 554112
Adding patches for surface regions
Patch Type Region
outdoor_airflow:
6 wall buildings
Added patches in = 0.03 s
Edge intersection testing:Number of edges : 1684728Number of edges to retest : 0Number of intersected edges : 5583Selecting decompositionMethod none
Refinement phase
Found point (127.4452 147.401 72.43167) in cell 402042 on processor 0
Surface refinement iteration 0
Marked for refinement due to surface intersection : 8820 cells.Determined cells to refine in = 3.87 sSelected for refinement : 8820 cells (out of 554112)Edge intersection testing:Number of edges : 1883850Number of edges to retest : 250376Number of intersected edges : 21198Refined mesh in = 1.77 sAfter refinement surface refinement iteration 0 : cells:615852 faces:1883850 points:652499Cells per refinement level:0 5452921 70560
Surface refinement iteration 1
Marked for refinement due to surface intersection : 38502 cells.Determined cells to refine in = 0.04 sSelected for refinement : 40392 cells (out of 615852)Edge intersection testing:Number of edges : 2787132Number of edges to retest : 1118049Number of intersected edges : 85655Refined mesh in = 3.17 sAfter refinement surface refinement iteration 1 : cells:898596 faces:2787132 points:990317Cells per refinement level:0 5432351 486812 306680
Surface refinement iteration 2
Marked for refinement due to surface intersection : 159213 cells.Determined cells to refine in = 0.1 sSelected for refinement : 168471 cells (out of 898596)Edge intersection testing:Number of edges : 6576117Number of edges to retest : 4737635Rhino Model and GH files is in t'he zip file.Please help me solve this question!~~…
diseño paramétrico con Grasshopper: días 16, 17 y 18 de noviembre. Curso de iniciación a Grasshopper. Para seguirlo no se requieren conocimientos previos específicos. El objetivo de este curso es tomar contacto con Grasshopper, entender cómo funciona y empezar a fabricar y editar geometría con él. Más información y programa detallado del curso. - MÓDULO II: curso de diseño discriminativo con Grasshopper y análisis ambiental con Ecotect: días 23, 24 y 25 de noviembre. Se tratarán componentes avanzados de geometría y gestión de datos, así como soluciones evolutivas de optimización del diseño con Galapagos, y conexión con Ecotect. Más información y programa detallado del curso. - MÓDULO III: curso de diseño iterativo: scripting con Grasshopper en C#: días 30 de noviembre, 1 y 2 de diciembre. Curso de "scripting" con Grasshopper y Processing, donde se tratará de modelado recursivo con C# y RhinoCommon en Grasshopper. Formadores Los cursos están conducidos por Authorized Rhino Trainers: puedes comprobar nuestros tres años de experiencia, más de 30 cursos de Grasshopper y 300 alumnos en nuestra página web. Material El material de los cursos ha sido elaborado íntegra y exclusivamente por nosotros para estos cursos: - Manual de ejercicios de Grasshopper nivel I - Manual de ejercicios de Grasshopper nivel II - Manual de ejercicios de scripting en Grasshopper con C# Formato Cursos intensivos con duración de 18 horas con el siguiente horario: - Viernes: 17-21h - Sábado:10-14h, 16-20h - Domingo: 11-14 h, 16-19h Grupos El número de asistentes está limitado a un máximo de 10 personas para garantizar la calidad de la enseñanza y a un mínimo de 4 personas.…
Added by Miguel Vidal at 8:40am on August 30, 2012
la corretta comprensione del software che di livello specialistico per un confronto diretto con alcuni aspetti fondamentali dell’ architettura e del design.
Attraverso l'utilizzo di Grasshopper rivoluzionaria plug-in di Rhinoceros, si insegneranno nuove tecniche di modellazione parametrica.
Grasshopper, permette di esprimere al massimo le qualità e le potenzialità della modellazione Nurbs abbandonando in parte l'interfaccia classica di Rhinoceros. Quest'ultimo infatti viene sostituito da un menù a tendine dove vengono collezionati nodi utili alla composizione di algoritmi risolutivi.
La plug-in Grasshopper, dimostra come il linguaggio del computer stia diventando un reale strumento progettuale.
Il corso si svolgerà nei seguenti giorni: Sabato 26 Ottobre dalle ore 10.00 alle ore 19.00 Domenica 27 Ottobre dalle ore 10.00 alle ore 19.00 Scadenza preiscrizione per Grasshopper: 23/10
Contenuti
Nella prima parte del corso attraverso degli esercizi base si insegneranno i metodi di esplicitazione degli algoritmi generativi. In queste ore di lezione si illustreranno, attraverso fasi operative, i seguenti argomenti:
Suddivisione degli algoritmi in parametri e componenti;
Tipologie di dati comptiili con Grasshopper e loro combinazione creando definizioni minime;
Funzioni matematiche e logiche;
Data flow, liste e filtri di esclusione;
Costruzione di curve e superfici e loro trasformazione;
Nella seconda parte del corso lo strumento viene specializzato affrontando editing e trasformazioni complesse sulle superfici:
Elaborazione delle superfici di suddivisione;
Tassellazione spaziale di superfici a doppia curvatura;
Gestione di parametri variabili per la progettazione di definizioni finalizzate al controllo del movimento;
Ideazione di algoritmi per il passaggio dal modello digitale al modello reale attraverso la tecnica dello sliceing;
Alla fine del corso, verrà rilasciato l’attestato di partecipazione ad un corso di Rhinoceros qualificato certificato dalla casa sviluppatrice McNeel, valido anche per la richiesta di crediti formativi universitari.
Tutor del corso
Il corso sarà tenuto da un docente qualificato, esperto in disegno e rappresentazione dell' architettura e del design:
Michele Calvano| _architetto, dottore di ricerca in rappresentazione architettonica specializzato nella modellazione matematica (Nurbs) e modellazione parametrica.
Docente ART (Autorized Rhino Trainer)
Info
Responsabile didattico e docente del corso: arch. Michele Calvano cell: 340 3476330
Info mail: parametricart@gmail.com
…
ndrea Graziano (Co-de-iT) Arch. Salvo Pappalardo (AION architecture) Arch. Giovanni Basile (Officina Ermocrate)
[.] Descrizione:
Modulo 1 Il workshop è finalizzato a fornire ai partecipanti i fondamenti della modellazione parametrica e generativa attraverso Grasshopper, plug-in di programmazione visuale per Rhinoceros 3D (uno dei più diffusi modellatori NURBS per l‘architettura e il design). Il workshop mira a gestire e sviluppare il rapporto tra informazione e geometria lavorando sui sistemi di involucro in condizioni specifiche. La discretizzazione di superfici (pannellizazione sia Nurbs che Mesh), la modellazione delle geometrie attraverso informazioni (siano esse provenienti da dati di analisi ambientali, da mappe di colore o da database), l’estrazione e la gestione di informazioni richiedono la comprensione delle strutture dei dati al fine di definire un processo che va dalla progettazione alla costruzione. I partecipanti impareranno come costruire e sviluppare strutture di dati parametrici per informare geometrie ‘data-driven’ e come estrarre le informazioni rilevanti da tali modelli per il processo di costruzione.
Modulo 2 Il workshop, volto a promuovere le nuove tecnologie digitali di supporto alla progettazione e alla fabbricazione, fornirà ai partecipanti, utilizzando Grasshopper, gli strumenti per la preparazione dei modelli 3D di elementi modulari decorativi "bricks & tiles" in argilla la cui successiva prototipazione avverrà tramite fresatura dello stampo con pantografo CNC a 3 assi. Il workshop darà quindi ai partecipanti i fondamenti per l’utilizzo di tale strumento di fabbricazione digitale e si concluderà con la fabbricazione di un proprio modello realizzato durante il corso.
[more info]
[Press Kit]…
ight be able to provide more insight). Whenever you run a new simulation in Radiance, it is not always necessary to re-write all of the initial simulation files from scratch. These initial simulation files include both a .rad geometry file as well as a separate .pts file that contains the test point locations. If all that you are changing in a given parametric run is the locations of the test points (like your case), it is not necessary to re-write (or reinterpret) the entire .rad geometry file. My guess is that there is some type of check for this built into either code Mostapha wrote or radiance functions that Mostapha is calling. As such, it seems that the rad geometry file is not being re-written (or re-interpreted by radiance) completely when all that you change is the test points and this actually seems to be saving you an extra 10 seconds each time that you run the component without changing the materials or the building geometry. Other times (like when you plug in custom radParameters), it seems that it re-writes (or re-interprets) the .rad geometry file from scratch since this file is probably affected by customized rad parameters.
So far, if this explanation is holding, it seems like there would be no concern on your end but I also recognize that the difference between these long and short simulations is giving you radiation results that are ever so slightly different from each other (by my estimates, they differ by about 0.2%). Compared to the other types of assumptions that the radiance model is making, though, these are mere rounding errors that probably originate from the number of decimal places in the vertices of the rad geometry file. Rather than worrying about whether your simulations are giving you the right rounding errors to give you matching results, I would encourage you to instead contemplate how much your radiance results are matching reality given all of the assumptions that you are making about the climate (with the epw file for a "typical" year) and with the number of light bounces in the radiance simulation. To give you an example, I ran your model with a higher quality of simulation type (3 ambient bounces) and this gives you results that differ by 1.1% from the original simulation that you were running with only 2 ambient bounces (this is practically an order of magnitude larger than 0.2%).
To address your unease I will say that, for a long time, I also felt uneasy any time that I encountered something that seemed unpredictable in software that I was using. Once I started coding my own stuff, though, I realized quickly that unpredictable behavior is an unavoidable aspect of all software. There is always a tradeoff between accurate results and the time it takes to get them, which produces a multitude of possible ways to arrive at a solution. Add into this complex situation the fact that you might have an almost infinite number of possible inputs to a given set of code.
Because of the unpredictable multitude of cases, there is no application that is completely free from limitations and assumptions. In this light, what ends up being more important than the actual calculation method used is the social infrastructure that is in place to help understand what is being run under the hood, hence why both Radiance and Honeybee are open source and why we try to build a robust community of support through forums like this one!
-Chris…
n due at the end of march. i am hoping to see if i can do this as a sort of "HIVE MIND" experiment with one or two or more posters to the forum. i have uploaded two files to http://www.formpig.com/nine_bar-FAR and I have the following goals:
1. To "kinematically iterate" various formal building envelopes based upon a 50' x 100' lot that "conform" to the nine bar linkage geometry.
2. This lot would have "setbacks" consisting of two 5' side setbacks, a 10' rear yard setback and a 25' front yard setback. max height on the structure is 32' and the allowable overhangs into the setbacks are 2'. I would like to find a way to use the "nine bar geometry" to construct a series of iterations for "floors", "walls" and "ceilings", which would then be tied to a volumetric (cubic volume), or a total square footage (perhaps based upon two horizontal section cuts) which was based upon a given number that I will provide per local building code.
3. Laid on top of this we would also have "mcmansion ordinance" requirements based upon the pdf enclosed. i expect to have this "tent restriction" data in digital form to upload to ftp shortly.
It would be up to you individually or collectively to determine how best to position this "in the real world" based upon the lot, setbacks, zoning requirements etc. For instance, perhaps the nine bar configuration has its vertices coplanar with the 50' x 100' x 32' envelope restrictions and then the chosen volume is "trimmed' by the setback requirements. Or perhaps the nine-bar configuration is generated completely within the setbacks, or perhaps it is generated 2' outside of the setbacks so as to take advantage of the 2' overhang allowance on the setbacks, etc.
*
Given an opportunity to develop the work in a second phase we would have an opportunity to tie this into various efficiencies such as Bill of Materials (wall floor and ceiling square foot calculations), envelope to volume calculations, solar panel efficiencies (solar orientation and envelope geometry) etc, etc (love to get suggestions for this).
*
I've become /really/ convinced that this would be a /really/ interesting entry based upon my just finishing up Kas Oosterhuis' Towards a New Kind of Building: A Designer's Guide for Non-Standard Architecture". In an ideal world I was hoping that it would be possible to hash this out discussion-wise and then literally passing it around on the list after someone eventually made the first move by tossing out a rough ghx script. My expectation would be to finalize it rapidly in the next two weeks. Something of a contemporary version of a design charette.
However, I realize this may not be workable so if you have experience in this arena and particularly if you think this is a brief that is straighforward enough to be almost literally implemented in Grasshopper, please contact me for any wage and/or contract fee requirements.
I'm getting a bit of a late jump on this but my hope is that with the right participant(s) that I can thrash it together quick enough for the first round.
info@formpig.com…