diseño, construcción y entendimiento de nuestro entorno.
BIM está poniendo a disposición de los diseñadores y gestores auténticas bases de datos que pueden generarse, conectarse y editarse de forma paramétrica, proporcionando una sólida capa de realidad a los ejercicios de diseño generativo y computación que son objeto de estudio en Algomad, el seminario que busca popularizar la programación y la parametrización en el diseño y en la experiencia de nuestro entorno construido.
Tras un paréntesis en 2015, Algomad vuelve con el objetivo de demostrar cómo una visión computacional del BIM es una oportunidad para mejorar la forma de trabajar de ingenieros, arquitectos, constructoras y operadores de edificios e infraestructuras, tendiendo un puente entre las técnicas de diseño digital más avanzadas y la realidad de la construcción.
Algomad 2016 tendrá lugar en el centro de Madrid, en IE School of Architecture and Design, IE University, los días 3, 4 y 5 de Noviembre de 2016 y comprenderá 4 talleres así como ponencias a cargo de expertos de primer nivel.
Estructura de Algomad 2016
Algomad 2016 se estructura en torno a tres áreas temáticas principales:
BIM, como la metodología total específica para el sector de la construcción.
Computación, englobando las aplicaciones de programación y parametrización al diseño de edificios e infraestructuras.
Realidad, como marco de trabajo, buscando siempre resolver problemas reales a través de los dos puntos anteriores.
Público objetivo
Arquitectos, arquitectos técnicos, ingenieros y en general académicos, estudiantes de últimos cursos y profesionales del mundo inmobiliario y de la construcción que compartan un interés por la digitalización de nuestro sector. Se espera un nivel mínimo en el uso de herramientas BIM y de parametrización. Algomad proporcionará formación adicional y gratuita en las herramientas básicas a emplear en los talleres para asegurar un correcto desempeño.…
reaky thing consisting from triangulated "modules" (i.e an assembly out of this, this and that) where the exterior edges ARE always under tension (= SS 304/316 cables OR nylon) and the interior ones MAY be under compression ( = steel, aluminum, wood, carbon) OR ... some of them ...may be under tension. Bastardized T trusses deviate a bit from theory ... but who cares? (not me anyway). T trusses have many variants (but as the greatest ever said: Less is More).
2. Large scale T for AEC is the art of pointless since it costs around the GNP of Nigeria. Here's some indicative components from a module of a multi adjustable TX system costing (the module) ~ the price of my Panigale (Google that):
The above is mailed to a friend who has MIT (yes, that MIT: the top dog) on sight ... therefor he needs some appropriate "credentials", he he.
3. The distance that separates the above with the demo TDT node provided is around 666.666 miles - but we don't care: we are after Art not some testimony to vanity.
4. On purpose I've used a smallish ring to give you a clear indication upon the constrain numero uno in truss design: CLASH matters.
5. You'll need:
(a) A decision related with the tensioners (classic Norseman + SS cables or nylon machined thingies?).
(b) A machinist who can do elementary stuff (like the adapters) and can weld this to that (the "ring" for instance). His abilities must be 1 in a scale of 100. If the fella has a computer (not a CRAY) and he knows what 3dPDF is (hmm) ... well ... use that way to communicate with him PRIOR designing anything: He must agree on the parts BEFORE the whole is attempted (as a design in GH or in some other app).
(c) A carpenter with a wood lathe for the obvious. BTW: BEFORE doing any TDT attempt > ask the carpenter about the available wood strut sizes. Against popular belief DO NOT varnish the wood (use exterior alkyd/oil stains from some top maker like the notorious US company PPG).
http://www.ppgpaints.com/products/paints-stains-data-sheets
(d) Good quality cigars (and espresso) plus some classic music (ZZTop, PFloyd, Cure, Stones, U2 etc etc) during the assembly.
(e) Faith to the Dark Side (see my avatar).
May the Force (the dark option) be with you.…
hacia donde crecerán las venas, y tenemos otro conjunto de puntos 'N' que son los que forman el patrón de venas.
1. Por cada 's' perteneciente a S, buscamos el 'n' perteneciente a N más cercano. Ese 'n' va a "moverse".
2. Por cada 'n' que se mueve, hacemos un vector dirigido a todos los 's' hacia los que se mueve.
3. Calculamos el vector medio de todos los vectores del paso 2, movemos 'n' con ese vector y lo añadimos a V.
4. Si algún 's' está muy cerca de algún 'n', ese 's' se elimina.
5. Se repite el proceso.
Esto es para formar venaciones abiertas sin autocrecimiento (como la siguiente imagen, hecho con Visual Basic).
Para las cerradas (las reticuladas que forman algo como células, como en la imagen tuya), el paso 1 y 4 son distintos y no sabría decirte cómo hacerlo. En ese pdf explica un método usando delaunay pero es muy lento, además gh no tiene ese algoritmo en 3d (entonces solo se podría hacer este patrón en 2d), por lo que estoy buscando otras vías, solo he logrado llegar a esto:
Es más complicado de lo que parece.
No obstante, si te conformas con menos, hay muchas formas de crear raíces y patrones similares, con SortestWalk, Anemone, etc... Hay ejemplos en este foro.
Si realmente quieres conseguir ese patrón, deberías aprender a programar porque para añadir distintos radios a las venas es necesario que las venas tengan topología y eso se complica demasiado desde gh. Nervous System para su "Hyphae" usó C++ con la librería CGAL, que es una muy poderosa librería de algoritmos de 3d.
…
d work exactly as the physical model. In the model, we have a curved surface which can be analysed into squares. These squares are filled with two kind of units which are connected with each other and create a grid that follows this curved surface.
We have managed to analyse this curved surface into a planar surface consisted of squares and we painted the squares with colours to represent the kind of unit that "fills" each square. So, now in rhino I have managed to build the curved surface that I want it to be filled with the two types of units.
I also have the planar surface built in Gh with the squares split into two lists, each one for each kind of unit. Because these units are mambranes, I used kangaroo to make them act like mambranes.
I hope I described the problem clearly. The point is to keep the dimensions of the units
the same and make it work in Kangaroo. Do you have anything in mind that I should look up or any advice ? Thank you in advance and i m sorry for the extended description.
*Pic 1: the curved surfaces that has to be filled with the units
*Pic 2: The binary system that shows which square is occupied by which unit
Blue=2 , Red=1, White= Blank
*Pic 3: unit 1
*Pic 4: unit 2
*Pic 5: a point of view of the physical model (not the final curve at the surface)
…
e.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
Thank you very much in advance!
1. why the underground zone representing the ground is defined as a plenum zone? By default, an office zone program is assigned. Will this affect the outside surface temperature of the ground plenum zone and affect, in turn, the outdoor microclimate map calculation?
2. I assume the construction GroundMaterial composed of five layers of 200mm concrete materials as assigned to the ground plenum zone is to assimilate a ground surface composed of thick concrete. But why this construction is assigned to this zone using both the Set EP Zone Construction and Set EP Zone Underground Construction components? Will the surfaces of this zone automatically recognized as underground surfaces based on their positions in relation to the default xy plane?
3. why a brep is connected to the input node distFromFloorOrSrf on the Indoor View Factor Calculator component which is expecting a number according to its annotation?
4. why the outdoor comfort analysis recipe is used for the indoor comfort analysis component?
5. why the OutdoorComfResult and DegFromNeutralResult are 2 csv files with PPD and PMV values if PMV/PPD thermal comfort model is only applicable to indoor air-conditioned space?
…
the following image of a hut.
I do not have experience using kangaroo to simulate forces, but I have made a test using multiple random components on a flat surface to fake the effect I'm going for. See image below.
The main issue I'm having is that the original file used for my test surface used box morph and the variable pipe command. Box morph is a bit touchy on a curved surface and it is not as elegant as I would like it to be (ie. I want all the hair diameters to be perfectly circular and uniform in size). Variable pipe also does not align the base of the hair with the existing surface, which means I have to offset the surface and then trim the excess of my pipe.....leading to heavy code and the file crashing.
So I'm trying to rebuild the "hairs" using a new method:
1) Subdivide the surface
2) Find the midpoint of each surface and then create a straight line that is perpendicular
3) Move a point along the on the straight line (between the start and end points) in the z direction, and then create a nurbs curve using this point and the start and end points
4) create a circle at the base of each crv, and then two more circles: one at the point in the middle point (I think I set it to .9) and the end of the curve
5) The problem: Now I am trying to sweep along these three circles and the nurbs curve to create a bent hair/pipe that is flush with the conic surface, but it does not work.
If someone can help that would be amazing. I've included my original surface test file and my new file where I am rebuilding using the sweep command. Below is a drawing of what I'm trying to achieve.
…
oftware connections built from the initial seed of the project. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
This release is also special since today it is just about 3 years (3 years and 2 weeks) from the first release of Ladybug. As with any release, there have been a number of bug fixes and improvements but we also have some major news this time. In no specific order and to ensure that the biggest developments do not get lost in the extensive list of updates, here are the major ones:
Mostapha is re-writing Ladybug!
Ladybug for DynamoBIM is finally available.
Chris made bakeIt really useful by incorporating an export pathway to PDFs and vector-based programs.
Honeybee is now connected to THERM and the LBNL suite thanks to Chris Mackey.
Sarith has addressed a much-desired wish for Honeybee (Hi Theodore!) by adding components to model electric lighting with Radiance.
Djordje is on his way to making renewable energy deeply integrated with Ladybug by releasing components for modeling solar hot water.
There is new bug. Check the bottom of the post for Dragonfly!
Last but definitely not least (in case you’re not still convinced that this release is a major one) Miguel has started a new project that brings some of Ladybug’s features directly to Rhino. We mean Rhino Rhino - A Rhino plugin! Say hi to Icarus! #surprise
Before we forget! Ladybug and Honeybee now have official stickers. Yes! We know about T-Shirts and mugs and they will be next. For now, you can deck-out your laptops and powerhouse simulation machines with the symbology of our collaborative software ecosystem.
Now go grab a cup of tea/coffee and read the details below:
Rewriting Ladybug!
Perhaps the most far-reaching development of the last 4 months is an effort on the part of Mostapha to initiate a well structured, well documented, flexible, and extendable version of the Ladybug libraries. While such code is something that few community members will interact with directly, a well-documented library is critical for maintaining the project, adding new features, and for porting Ladybug to other software platforms.
The new Ladybug libraries are still under development across a number of new repositories and they separate a ladybug-core, which includes epw parsing and all non-geometric functions, from interface-specific geometry libraries. This allows us to easily extend Ladybug to other platforms with a different geometry library for each platform (ie. ladybug-grasshopper, ladybug-dynamo, ladybug-web, etc) all of which are developed on top of the ladybug-core.
Without getting too technical, here is an example of a useful outcome of this development. If you want to know the number of hours that relative humidity is more than 90% for a given epw, all that you have to code (in any python interface) is the following:
import ladybug as lb
_epwFile = r"C:\EnergyPlusV7-2-0\WeatherData\USA_CO_Golden-NREL.724666_TMY3.epw"
epwfile = lb.epw.EPW(_epwFile)
filteredData = epwfile.relativeHumidity.filterByConditionalStatement('x>90')
print "Number of hours with Humidity more than 90 is %d "%len(filteredData.timeStamps)
Compare that to the 500 + lines that you would have had to write previously for this operation, which were usually tied to a single interface! Now let’s see what will happen if you want to use the geometry-specific libraries. Let’s draw a sunpath in Grasshopper:
import ladybuggrasshopper.epw as epw
import ladybuggrasshopper.sunpath as sunpath
# get location data form epw file
location = epw.EPW(_epwFile).location
# initiate sunpath based on location
sp = sunpath.Sunpath.fromLocation(location, northAngle = 0, daylightSavingPeriod = None, basePoint =cenPt, scale = scale, sunScale = sunScale)
# draw sunpath geometry
sp.drawAnnualSunpath()
# assign geometries to outputs
...
Finally we ask, how would this code will look if we wanted to make a sunpath for dynamo? Well, it will be exactly the same! Just change ladybuggrasshopper in the second line to ladybugdynamo! Here is the code which is creating the sunpath below.
With this ease of scripting, we hope to involve more of our community members in our development and make it easy for others to use ladybug in their various preferred applications. By the next release, we will produce an API documentation (documentation of all the ladybug classes, methods and properties that you can script with) and begin making tutorials for those interested in getting deeper into Ladybug development.
LADYBUG
1 - Initial Release of Ladybug for Dynamo:
As is evident from the post above, we are happy to announce the first release of Ladybug for Dynamo! You can download the ladybug package from Dynamo package manager. Make sure to download version 0.0.6 which is actually 0.0.1! It took a number of trial and errors to get it up there. Once you have the file downloaded you can watch these videos to get started:
The source code can be find under ladybug-dynamo repository and (as you can already guess) it is using the new code base. It includes a very small toolkit of essential Ladybug components/nodes but it has enough to get you started. You can import weather files, draw sunpaths and run sunlighthours or radiation analyses.
There are two known issues in this release but neither of them is critical. You need to have Dynamo 0.9.1 or higher installed which you can download from here (http://dynamobuilds.com/). It is recommended that you run the scripts with ‘Manual’ run (as opposed to ‘Automatic’) since the more intense calculations can make Dynamo crash in automatic mode.
To put things in perspective, here is how we would map Ladybug for Dynamo vs Ladybug and Honeybee for Grasshopper on the classic ‘Hype graph’. The good news is that what we learned a lot from the last three years, making development of the Dynamo version easier and getting us to the plateau of productivity faster.
We should also note that the current development of the Dynamo interface is behind that of the Ladybug-Core, which means there are a number of features that are developed in the code but haven’t made their way to the nodes yet. They will be added gradually over the next month or two.
If you’re interested to get involved in the development process or have ideas for the development, follow ladybug on Facebook, Twitter and Github. We will only post major release news here. Facebook, github and twitter will be the main channels for posting the development process. There will also be a release of a new ladybug for Grasshopper soon that will use the came Ladybug-Core libraries as the Dynamo interface [Trying hard not to name it as Ladybug 2].
2 - New Project “Icarus” Provides Ladybug Capabilities Directly in Rhino
Speaking of expanded cross-platform capabilities, the talented Miguel Rus has produced a standalone Rhino Plugin off of the original Ladybug code that has been included in this release. After writing his own core C# libraries, Miguel’s plugin enables users to produce sunpath and run sunlight hours analyses in the Rhino scene without need of opening Grasshopper or engaging the (sometimes daunting) act of visual scripting.
This release includes his initial RHP plugin file. It is hoped that Miguel’s efforts will extend some of the capabilities of environmental design to individuals who are unfamiliar with visual scripting, casting the network of our community into new territory. We need your help spreading the word about Icarus since the people who will benefit the most from it have probably not read this far into the release notes. Also, as the project is in the early stages, your feedback can make a great difference. You can download the current release from this link.
Once you download the zip file. Right click and unblock it. Then extract the files under C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\ folder. Drag and drop the RHP file into Rhino and you should be ready to go. You can either type Icarus in the command line or open it via the panels. Here is a short video that shows how to run a sunlighhours analysis study in Rhino.
3 - BakeIt Input Now Supports a Pathway to PDF +Vector Programs
As promised in the previous release, the BakeIt_ option available on Ladybug’s visual components has been enhanced to provide a full pathway to vector-based programs (like Illustrator and Inkscape) and eases the export to vector formats like PDFs.
This means that the BakeIt_ operation now places all text in the Rhino scene as actual editable text (not meshes) and any colored meshes are output as groups of colored hatches (so that they appear as color-filled polygons in vector-based programs). There is still an option to bake the colored geometries as light meshes (which requires smaller amounts of memory and computation time) but the new hatched capability should make it easier to incorporate Ladybug graphics in architectural drawings and documents like this vector psychrometric chart.
4 - Physiological Equivalent Temperature (PET) Now Available
Thanks to the efforts of Djordje Spasic, it is now possible to compute the common outdoor comfort metric ‘Physiological Equivalent Temperature’ (PET) with Ladybug. The capability has been included with this release of “Thermal Comfort Indices” component and is supported by a “Body Characteristics” component in the Extra tab. PET is particularly helpful for evaluating outdoor comfort at a high spatial resolution and so the next Honeybee release will include an option for PET with the microclimate map workflow.
5 - Solar Hot Water Components Available in WIP
Chengchu Yan and Djordje Spasic have built a set of components that perform detailed estimates of solar hot water. The components are currently undergoing final stages of testing and are available in the WIP tab of this release. You can read the full release notes for the components here.
6 - New Ladybug Graphic Standards
With the parallel efforts or so many developers, we have made an effort in this release to standardize the means by which you interact with the components. This includes warnings for missing inputs and the ability to make either icons or text appear on the components as you wish (Hi Andres!). A full list of all graphic standards can be found here. If you have any thoughts or comments on the new standards, feel free to voice them here.
7 - Wet Bulb Temperature Now Available
Thanks to Antonello Di Nunzio - the newest member of the Ladybug development team, it is now possible to calculate wet bulb temperature with Ladybug. Antonello’s component can be found under the WIP tab and takes inputs of dry bulb temperature, relative humidity, and barometric pressure.
8 - New View Analysis Types
The view analysis component now allows for several different view studies in addition to the previous ‘view to test points.’ These include, skyview (which is helpful for studies of outdoor micro-climate), as well as spherical view and ‘cone of vision’ view, which are helpful for indoor studies evaluating the overall visual connection to the outdoors.
HONEYBEE
1 - Connection to THERM and LBNL Programs
With this release, many of you will notice that a new tab has been added to Honeybee. The tab “11 | THERM” includes 7 new components that enable you to export ready-to-simulate Lawrence Berkeley National Lab (LBNL) THERM files from Rhino/Grasshopper. THERM is a 2D finite element heat flow engine that is used to evaluate the performance of wall/window construction details by simulating thermal bridging behavior. The new Honeybee tab represents the first ever CAD plugin interface for THERM, which has been in demand since the first release of LBNL THERM several years ago. The export workflow involves the drawing of window/wall construction details in Rhino and the assigning of materials and boundary conditions in Grasshopper to produce ready-to-simulate THERM files that allow you to bypass the limited drawing interface of THERM completely. Additional components in the “11 | THERM” tab allow you to import the results of THERM simulations back into Grasshopper and assist with incorporating THERM results into Honeybee EnergyPlus simulations. Finally, two components assist with a connection to LBNL WINDOW for advanced modeling of Glazing constructions. Example files illustrating many of the capabilities of the new components can be found in there links.
THERM_Export_Workflow, THERM_Comparison_of_Stud_Wall_Constructions
Analyze_THERM_Results, Thermal_Bridging_with_THERM_and_EnergyPlus
Import_Glazing_System_from_LBNL_WINDOW, Import_LBNL_WINDOW_Glazing_Assembly_for_EnergyPlus
It is recommended that those who are using these THERM components for the first time begin by exploring this example file.
Tutorial videos on how to use the components will be posted soon. A great deal of thanks is due to the LBNL team that was responsive to questions at the start of the development and special thanks goes to Payette Architects, which allowed Chris Mackey (the author of the components) a significant amount of paid time to develop them.
2 - Electrical Lighting Components with Enhanced Capabilities for Importing and Manipulating IES Files
Thanks to the efforts of Sarith Subramaniam, it is now much easier and more flexible to include electric lighting in Honeybee Radiance simulations. A series of very exciting images and videos can be found in his release post.
You can find the components under WIP tab. Sarith is looking for feedback and wishes. Please give them a try and let him know your thoughts. Several example files showing how to use the components can be found here. 1, 2, 3.
3- Expanded Dynamic Shade Capabilities
After great demand, it is now possible to assign several different types of control strategies for interior blinds and shades for EnergyPlus simulations. Control thresholds range from zone temperature, to zone cooling load, to radiation on windows, to many combinations of these variables. The new component also features the ability to run EnergyPlus simulations with electrochromic glazing. An example file showing many of the new capabilities can be found here.
Dragonfly Beta
In order to link the capabilities of Ladybug + Honeybee to a wider range of climatic data sets and analytical tools, a new insect has been initiated under the name of Dragonfly. While the Dragonfly components are not included with the download of this release, the most recent version can be downloaded here. An example file showing how to use Dragonfly to warp EPW data to account for urban heat island effect can also be found here. By the next release, the capabilities of Dragonfly should be robust enough for it to fly on its own. Additional features that will be implemented in the next few months include importing thermal satellite image data to Rhino/GH as well as the ability to warp EPW files to account for climate change projections. Anyone interested in testing out the new insect should feel free to contact Chris Mackey.
And finally, it is with great pleasure that we welcome Sarith and Antonello to the team. As mentioned in the above release notes, Sarith has added a robust implementation for electric light modeling with Honeybee and Antonello has added a component to calculate wet bulb temperature while providing stellar support to a number of people here on the GH forum.
As always let us know your comments and suggestions.
Enjoy!
Ladybug+Honeybee development team
PS: Special thanks to Chris for writing most of the release notes!…
inner As Curve() = section.ToNurbsCurve().Offset(normal, pc, -plate, 1e-3, 1e-4, Rhino.Geometry.CurveOffsetCornerStyle.Sharp)
the error message is:
"
{0}0. Error: Het oplossen van de overbelasting is mislukt omdat dit aantal argumenten door geen enkele toegankelijke Offset wordt geaccepteerd. (line 104)
"
this is the VBA script:
"Option Strict OffOption Explicit On'Import SDK and Framework namespacesImports RhinoImports Rhino.GeometryImports Rhino.CollectionsImports GrasshopperImports Grasshopper.KernelImports Grasshopper.Kernel.DataImports Grasshopper.Kernel.TypesImports GH_IOImports GH_IO.SerializationImports SystemImports System.IOImports System.XmlImports System.DataImports System.DrawingImports System.ReflectionImports System.CollectionsImports System.Windows.FormsImports Microsoft.VisualBasicImports System.Collections.GenericImports System.Runtime.InteropServices'Code generated by Grasshopper(R) (except for RunScript() content and Additional content)'Copyright (C) 2011 - Robert McNeel & Associates<System.Runtime.CompilerServices.CompilerGenerated()> _Public Class Script_Instance Implements IGH_ScriptInstance#Region "Members" ''' <summary>List of error messages. Do not modify this list directly.</summary> Private __err As New List(Of String) ''' <summary>List of print messages. Do not modify this list directly, use the Print() and Reflect() functions instead.</summary> Private __out As New List(Of String) ''' <summary>Represents the current Rhino document.</summary> Private doc As RhinoDoc = RhinoDoc.ActiveDoc ''' <summary>Represents the Script component which maintains this script.</summary> Public owner As Grasshopper.Kernel.IGH_ActiveObject#End Region#Region "Utility functions" ''' <summary>Print a String to the [Out] Parameter of the Script component.</summary> ''' <param name="text">String to print.</param> Private Sub Print(ByVal text As String) __out.Add(text) End Sub ''' <summary>Print a formatted String to the [Out] Parameter of the Script component.</summary> ''' <param name="format">String format.</param> ''' <param name="args">Formatting parameters.</param> Private Sub Print(ByVal format As String, ByVal ParamArray args As Object()) __out.Add(String.Format(format, args)) End Sub ''' <summary>Print useful information about an object instance to the [Out] Parameter of the Script component. </summary> ''' <param name="obj">Object instance to parse.</param> Private Sub Reflect(ByVal obj As Object) __out.Add(GH_ScriptComponentUtilities.ReflectType_VB(obj)) End Sub ''' <summary>Print the signatures of all the overloads of a specific method to the [Out] Parameter of the Script component. </summary> ''' <param name="obj">Object instance to parse.</param> Private Sub Reflect(ByVal obj As Object, ByVal method_name As String) __out.Add(GH_ScriptComponentUtilities.ReflectType_VB(obj, method_name)) End Sub#End Region ''' <summary> ''' This procedure contains the user code. Input parameters are provided as ByVal arguments, ''' Output parameter are ByRef arguments. You don't have to assign output parameters, ''' they will be null by default. ''' </summary> Private Sub RunScript(ByVal p0 As Point3d, ByVal p1 As Point3d, ByVal p2 As Point3d, ByVal pc As Point3d, ByVal plate As Double, ByVal itt As Integer, ByVal dev As Double, ByRef crvout As Object, ByRef crvin As Object, ByRef sec As Object, ByRef opp As Object, ByRef div As Object, ByRef pt4 As Object) 'your code goes here… opp = "test01" Dim section As New Polyline(5) section.Add(p0) section.Add(p1) section.Add(p2) section.Add(pc) section.Add(p0) Dim normal As Vector3d = vector3d.CrossProduct((p1 - p0), (p2 - p0)) Dim area As Double Dim chicken_int As Int32 = 0 Dim XX As Double Dim YY As Double Do chicken_int += 1 If (chicken_int > itt) Then Exit Do 'Compute the section offset Dim inner As Curve() = section.ToNurbsCurve().Offset(normal, pc, -plate, 1e-3, 1e-4, Rhino.Geometry.CurveOffsetCornerStyle.Sharp) Dim edges As New CurveList(inner) edges.Add(section.ToNurbsCurve()) crvin = edges Dim sections As Brep() = Brep.CreatePlanarBreps(edges) If (sections Is Nothing) Then Exit Do opp = "test02" 'Compute the centroid of the current section Dim am As AreaMassProperties = AreaMassProperties.Compute(sections(0)) Dim ct As Point3d = am.Centroid XX = am.CentroidCoordinatesMomentsOfInertia.X YY = am.CentroidCoordinatesMomentsOfInertia.Y area = am.Area Dim dx As Vector3d = pc - ct 'Compute the error of the current centroid Dim dl As Double = dx.Length div = dl 'Update output values crvout = section crvin = inner sec = sections(0) opp = area If (dl < dev) Then Exit Do 'Adjust outline with a boosting factor. section(3) += dx * 4 Loop pt4 = section(3) crvout = section End Sub '<Custom additional code> '</Custom additional code> End Class
"…