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!…
utput. A typical parametric analysis involves either toggling input parameters while observing an output response in a cyclic trial and error feedback loop, or by adopting an optimisation approach to search for the 'best' output value based on some target of interest (e.g. in parametric simulation analysis studies).
Either-way, it remains cognitively difficult to keep track of input-output relationships, especially in multi-input parameter scenarios. Furthermore, optimisation outcomes are one-off outcomes that do not provide insight into the underlying input-output causality that is responsible for generating the output in the first place. As a result, it becomes challenging to control the computational workflow intuitively.
Inference Lab is a plug-in that overcomes such challenges by introducing bi-directionality between inputs and outputs, within Grasshopper. In other words, Inference Lab facilitates both forward and inverse computations. An inverse computation implies the ability to set a target output value of interest and instantly reveal the input distributions that are likely to cause the set target. This facilitates an instant cross-section of the input-output mapping. Inference Lab enables interaction with the input and output distributions to explore the cause and effect bi-directionally.
The following demo video illustrates the potential of Inference Lab for a structural design scenario. Given a typical parametric FEA simulation set up, Inference Lab was used to identify 1) how the design parameters influence the maximum deflection and the weight of the cantilever truss structure, and 2) identify the parameter ranges that satisfy specified targets on max deflection and weight.
Under the hood, Inference Lab builds a statistical representation of the input-output workflow from data that is generated automatically from the parametric definition within Grasshopper. The statistical representation takes advantage of a marriage between machine learning and Bayesian inference (a classic technique from probability theory).
More literature about the research underlying Inference Lab can be found here.
Inference Lab is presently composed of four main components: 1) PSlider, 2)POutput, 3)DataGenerator, 4)Model Builder.
Notes:
Inference Lab is a by-product of my very recent PhD work so please forgive me for the lack of information. I intend to update this page with structured tutorials explaining the potential of Inference Lab in various scenarios.
The Inference Lab plug-in is not yet available for download as I am in the process of ironing out a few minor issues. I hope to share an alpha version very soon. …
nter the programming world and tinker more complex, interactive solutions. We will also explore advanced programming paradigms. There is no class official programming language, as both C# and Vb.Net are possible on the participant’s side, and all examples will be provided in both C# and Vb.Net. Additionally, we will see how to get started writing full .Net plug-ins. Finally, we will have time to explore user’s own proposals on the third day.
Day 1 Morning: programming introduction in .Net
• The Grasshopper scripting components. Choosing a .Net language. Language developments
• Variables declaration, assignment and utilization. Operators. Methods [functions]. Calls
• Classes: declaration and instancing. Constructors. Importing a namespace. On3dPoints, OnLines
• Arrays declaration and usage. Lists. Adding to arrays and lists, advantages and opportunities.
Afternoon: patterns
• About OOP (object oriented programming) as opposed to procedural programming. Discussion
• Example of OOP good code reuse: sorting points by coordinates using the .Net SDK classes
• Lists as input parameters. Trees as input parameters. Usage and limitations
• Finding resources: on the net with website that can help getting started and troubleshoot. And books
Day 2 Morning: extending Grasshopper functionality with our definitions
• Store data between updates. The use of fields [globals, or static locals]
• Examples on how to use stored data between updates: a simple agents simulation
• Baking geometry with scripting directly into the Rhino document. Baking with names
• Passing custom types from a scripted component to another one. Our own code reusability
• Rendering an animation from Grasshopper. How to get started and final results
Afternoon: customizing our tools
• Our Rhino plug-in with Visual Studio C# [Vb.Net] Express Edition & wizard. Parametric mesher
• Writing a custom Grasshopper component: hacking an exporter for our data to Excel
Day 3 All day: personal project
• Rehearsal on any example from the first two days. A project that you want to start on your own, being it a Rhinoceros plug-in, a Grasshopper assembly or a script. Example might be to send data through network with UDP to Processing
MINIMUM REQUIREMENTS
A good foundation of Grasshopper visual programming is mandatory. You will need a level which corresponds to the Grasshopper 101 course outline. Examples of things that will not be covered in this course are: sorting document spheres by diameter, paneling of a surface with grasshopper components. You are expected to already know these from the Grasshopper course.…
to enter the programming world and tinker more complex, interactive solutions. We will also explore advanced programming paradigms. There is no class official programming language, as both C# and Vb.Net are possible on the participant’s side, and all examples will be provided in both C# and Vb.Net. Additionally, we will see how to get started writing full .Net plug-ins. Finally, we will have time to explore user’s own proposals on the third day.
Day 1 Morning: programming introduction in .Net • The Grasshopper scripting components. Choosing a .Net language. Language developments • Variables declaration, assignment and utilization. Operators. Methods [functions]. Calls • Classes: declaration and instancing. Constructors. Importing a namespace. Point3d, Lines • Arrays declaration and usage. Lists. Adding to arrays and lists, advantages and opportunities. Afternoon: patterns • About OOP (object oriented programming) as opposed to procedural programming. Discussion • Example of OOP good code reuse: sorting points by coordinates using the .Net SDK classes • Lists as input parameters. Trees as input parameters. Usage and limitations • Finding resources: on the net with website that can help getting started and troubleshoot. And books Day 2 Morning: extending Grasshopper functionality with our definitions • Store data between updates. The use of fields [globals, or static locals] • Examples on how to use stored data between updates: a simple agents simulation • Baking geometry with scripting directly into the Rhino document. Baking with names • Passing custom types from a scripted component to another one. Our own code reusability • Rendering an animation from Grasshopper. How to get started and final results Afternoon: customizing our tools • Our Rhino plug-in with Visual Studio C# [Vb.Net] Express Edition & wizard. Parametric mesher • Writing a custom Grasshopper component: hacking an exporter for our data to Excel Day 3 All day: personal project • Rehearsal on any example from the first two days. A project that you want to start on your own, being it a Rhinoceros plug-in, a Grasshopper assembly or a script. Example might be to send data through network with UDP to Processing MINIMUM REQUIREMENTS A good foundation of Grasshopper visual programming is mandatory. You will need a level which corresponds to the Grasshopper 101 course outline. Examples of things that will not be covered in this course are: sorting document spheres by diameter, paneling of a surface with grasshopper components. You are expected to already know these from the Grasshopper course.…
y (movement, protection, temperature regulation) but also the evolution of cultural expression precisely by exceeding the purely indexical performative relations. Designing not only for the needs but for the desires.
Computational couture looks at the creation of exclusive custom-fitted clothing (typical of haute couture) through the lens of a systemic approach, extending the sartorial techniques with 3D modeling and computation-based approaches developed in Rhinoceros and the visual programming environment Grasshopper.
Aim of the workshop is to exert, infuse and expand the sartorial sensibilities to body proportions and dress making into an algorithmic approach that loops through design and fabrication by means of laser cutting and 3d printing for the design and production of a garment. Participants will be divided in teams focusing on specific aspects of the garment related to the production technique (laser cutting or 3D printing).
////////////////////////////////////
WORKSHOP | calendar
Day 1
Introduction to algorithms and computational design for creative disciplines Basics of 3D modeling in Rhinoceros Basics of Grasshopper Introduction to basic sartorial techniques
Day 2 Testing design options for the dress in Grasshopper (tutored work)
Day 3 Fabrication session . file preparation . parts testing and pre-assembly
Day 4 dress fabrication and assembly
Day 05 finalization of dress final presentation
////////////////////////////////////
WORKSHOP | registration
FEE FOR PARTICIPANTS
Early bird (until 4/5): 250 € Full fee (from 5/5 until 15/5): 350 €
The fee includes materials and fabrication. Plane tickets and accommodation are not included in the fee.
////////////////////////////////////
REGISTRATION (until 15/5/2015)
For registration please write at :
beyond@iaac.net
for more info visit:
http://beyond.iaac.net/?page_id=1620
…
large scale prototyping techniques. The programme continues to build on its expertise on complex architectural design and fabrication processes, relying heavily on materiality and performance. Autumn DLAB brings together a range of experts – tutors and lecturers – from internationally acclaimed academic institutions and practices, Architectural Association, Zaha Hadid Architects, among others.
The research generated at Autumn DLAB has been published in international media – ArchDaily, Archinect, Bustler – and peer-reviewed conference papers, including SimAUD (Simulation in Architecture and Urban Design), eCAADe (Education and research in Computer Aided Architectural Design in Europe).
Autumn DLAB investigates on the correlations between form, material, and structure through the rigorous implementation of computational methods for design, analysis, and fabrication, coupled with analog modes of physical experimentation and prototype making. Each cycle of the programme devises custom-made architectural processes through the creation of novel associations between conventional and contemporary design and fabrication techniques. The research culminates in the design and fabrication of a one-to-one scale prototype realized by the use of robotic fabrication techniques, with the aim of integrating of form-finding, material computation, and structural performance.
The programme is structured in two stages:
PART 1 – participants are introduced to core concepts of material processes, computational methods and digital fabrication techniques. Basic and advanced tutorials on computational design and analysis tools are provided. The programme performs as a team-based workshop promoting collaboration, research and ‘learning-by-experimentation’.
PART 2 – participants propose design interventions based on the skills and knowledge gained during phase 1 and supported by scaled study models and prototypes. The fabrication and assembly of a full-scale architectural intervention with the use of robotic fabrication techniques will then unify the design goals of the programme.
Applications
1) A limited number of 10 places are available. To apply, please send a small portfolio (5MB) to the Visiting School Office.2) PARTIAL SCHOLARSHIPS ARE AVAILABLE. Please send a letter of intent and a small portfolio (5MB) to the Visiting School Office.3) As this programme has a limited number of places it requires a selection process, if you are offered a place on programme, the Visiting School Office will inform you of how you can complete the registration process.
The deadline for applications is 13 AUGUST 2021.
Eligibility
The workshop is open to current architecture and design students, PhD candidates and young professionals. Software Requirements: Adobe Creative Suite, Rhino 6. No prior knowledge of software tools is required for eligibility.
Fees
The AA Visiting School requires a fee of £975 per participant, which includes a £60 Digital Membership fee.Students need to bring their own laptops, digital equipment and model making tools.
…
pproach that will hopefully work. There's still the last part of putting it all together, but I figured I'd post my progress so you could play around with it if you wanted. This is kind of a lucky situation since its only single face breps and simple trims that are being worked with.
I've attached 3 definitions to this post. The first is my reorganization of your original definition, which creates the surfaces from the point grid and culls out any surfaces that are not "on" the surface so that we don't have to deal with them later down the line. This is done through a small VB component which determines whether any of the corner points lie on the surface. If it does it keeps the surface, if not, then it doesn't. The only issue with this is that in your example file, there are some surfaces which the corner points do not lie on the surface, yet the surface that they create spans the underlying surface. At this point I'm not worrying about those. You mentioned that you only want the surfaces that lie at the edge...this can be done by testing whether all 4 corner points lie on the trimmed surface or not.
The second definition is a coded version of the project function. In the example it will project to all the breps supplied, yet in the final version this probably won't be desired. Also, the direction (z axis) is hard code...this could be swapped out if desired.
The third definition is an shot at trimming a surface with an input curve (that curve happens to be projected). I tried this many ways, but found that the function RhinoCutUpSurface seamed to work alright. The other attempts at doing this directly with through functions available for OnBrep were unsuccessful and very complex. Luckily because the underlying brep is an single, untrimmed surface this function works well for us, but in situations where we have a trimmed or multiface brep we'd be up a creek with out a paddle. The function creates an array of breps, but in our case it will create essentially the same surface split by our curve and joined together as a single brep with two (possibly more) faces. All we have to do is find out which face we want to keep and duplicate that into a separate brep and pass it out of the component. In the example file I'm determining which on to keep based off of the distance from a test point to the centroid of each face.
The other option here, which would trump the need for projection or trimming, would be to extrude the edge curves through the surface in question, and use the BrepSplit function which requires two breps. There would still be the need to sort out what to keep, but if this approach were used, all the split pieces would be separate breps.
So, all the pieces are pretty much working separately, all that I have left to do is put them all together in the base definition. The only thing that is really the hump with that is determining exactly which face to keep. My idea at the moment is to find out which corner of the surface does not like on the base surface and use that to determine which face will be thrown out. This might be one of the easier ways, but will not be rock solid. The other option is to pull a test point that's on one of the faces to the base surface and the other face, then use the distance from test point to the point on the base surface and the distance to the pulled point on the other face to the base surface to figure out which one to keep.
As to sectioning off parts of the solution, you could do this in a number of ways, but here's two simple ones. In a scripting component just add a boolean value to the inputs and put the whole script inside of an if statement that looks at that boolean value. With components just add a boolean gate or a null pattern componet anywhere you want in the stream. Again, hook in a boolean toggle value, and that will stop the info from going to components that are downstream.…
rectly except for the first material in a series. See attached image... Here is my code:
Private Sub RunScript(ByVal M As Object, ByVal C As Color, ByRef AddName As Object, ByRef AddMat As Object, ByRef AddBool As Object, ByRef baseName As Object, ByRef newMatName As Object)
Dim z As String = "newMatName" Dim y As String = "BaseName" Dim x As Integer = 0 Dim nRestore As String Dim mTemp As Rhino.DocObjects.Material
mTemp = CType(M, Rhino.DocObjects.Material) y = mTemp.Name Dim nTemp As String
If mTemp.Name.Contains("_MOD_R") = False Then
nRestore = mTemp.Name nTemp = mTemp.Name & "_MOD_R" & C.R & "_G" & C.G & "_B" & C.B mTemp.Name = nTemp z = nTemp mTemp.DiffuseColor = C
If Doc.Materials.Find(nTemp, True) < 0 Then
Doc.Materials.Add(mTemp) x = x + 1 AddName = nTemp AddMat = mTemp
End If
mTemp.Name = nRestore
End If
newMatName = z
AddBool = x BaseName = y
End Sub
1) I have checked that all of the materials I am calling by name exist in the document and that data matching is correct. There doesn't seem to be anything special about the offending material except that it is always the first material that was added to the document by my script.
2) The main thing I was missing in the previous script was the "doc.Materials.Add()" -- how on earth should I have known that existed? Even a search for "doc.Materials" in the Rhinocommon SDK doesn't turn that up. I'm having a very hard time using the SDK to my advantage, it seems not to correlate to the actual code I need to write.
2b) Perfect example... now I am trying to rewrite my other component (which exposes all of the document materials) to set a few objects manually in Rhino with the Materials I want to use as templates. Now I am trying to find out how to access the material assigned to an object. Seems easy, but it's clearly not a Property, and I can't find an appropriate Method in either the Objects or Materials classes.
3) One of my problems originally, when feeding the component one material and multiple colors, was that the nTemp variable was not resetting properly for the second color. Same thing if I duplicated the material to match the list of colors. It would create a material on the first pass but concatenate "_MOD_R_G_B" in each subsequent pass and be caught by my String checker. Why is that? I thought that the nTemp Name variable would be reset in each pass by the line "mTemp = CType(M, Rhino.DocObjects.Material)" and "nTemp = mTemp.Name" combination.
Does the mTemp material somehow carry over its properties in each successive pass? That's why I added the nRestore to be sure each pass reset the name back to the original.
Still, I wonder if there is some problem with the way I am conceptualizing this that is causing the first material to be the same as the input material.
Thanks for your help on this...
Cheers,
Marc…
s: [Mesh Brep] which used the Rhino mesher, [Mesh Surface] which create a rectangular grid of mesh faces on a single surface and [Simple Mesh] which attempts to represent each face in a Brep using a single Tri or Quad and accuracy be damned. Let's focus on the easy ones first...
[Simple Mesh] is a first attempt at providing a completely reductionist meshing engine. It was born out of a skype discussion I had with Brian James one night during the weekly Seattle RMA developer meeting. It only handles very simple cases at the moment so it's probably not all that useful, but it's there anyway just in case. If this mesher cannot handle a certain Brep face because it's too complicated it will use the native Rhino mesher for that face.
The purpose of [Mesh Surface] is to provide a single surface mesh that isn't distorted by the underlying parameterization of a surface. My approach for this actually turned out to be really slow, which is why the [Q] input is set to false by default. This mesher was never designed to take trims into account, however you get a single option [H] to control how trims interact with the mesh.
[Mesh Brep] merely channels the native Rhino mesher. You can supply meshing settings that look a little bit like the meshing settings that Rhino itself exposes. With these settings you can control how seams in breps are handled, how much the mesh is allowed to deviate from the underlying geometry, how many quads you want etc. This is the most customizable option, but even here it's totally possible you can't get what you want. For example, there is no way to enforce a mesh that contains only quads. As soon as seams are stitched or whenever trims are present, you're going to get triangles along the edges of meshes.
--
David Rutten
david@mcneel.com…