our students could taste first hand the Apocalypse (and/or the brave new world and/or the animal farm - depending on your point of view, he he).
2. First ... make a break and spend some time to play with the def attached. Of course comes straight from the Dark Side (no components of any kind). But you know what? ... sooner or later your students they must obey to the Dark Side ... or they'll extinct (future galloping you know ... I mean in a few years from now anyone not speaking some programming language > Homo heidelbergensis ).
3. This thingy attached works in 2 modes: (a) design a(ny) pattern (in a "flat" Plane.WorldXY) or (b) apply a(ny) pattern (in any given surface List).
Start from here (diamond pattern, like the one used by you):
Apply random Z noise (other pattern used):
Or use surfaces (to make frames or their content among other things):
Note: Although this def attached MAY appear off-topic ... there's a reason (other than using any pattern you like) that I provide this to you : because that way we can totally control nodes, edges and "facets" and therefor extract any plane imaginable and therefor place/manage any imaginable profile.
Note: Of course using the make frames capability (and extruding these BrepFaces AT ONCE both sides) we could obtain "autonomous" [monocoque, so to speak] modular load bearing "panels" ready for assembly (instead of beams + nodes + plates + cats + dogs + why??) ... but this is not exactly what you've asked ... he he.
more soon…
ints. Anyway this is made for AEC purposes (wavy roofs/envelopes and the likes) and is classified as internal (but I could provide a "light" version).
To give you a very rough idea: C# rebuilds first any input list of nurbs > then samples the control points in a tree > then excludes (or not) the "peripheral" points (case: closed in U/V surfaces) > then "picks" some of them according a rather vast variety of options (~30) > then modifies these either individually (that's only possible with code and it's a bit tricky) or via any collection of push/pull attractors or randomly or ... > then "joins" the 2 sets together (modified + unmodified) > and finally does the new nurbs. Only 456 lines of code that one.
With regard the Dark Side: C# would be my recommendation (P is ala mode, mind) for a vast variety of reasons (less than 10% of them are GH related).
If you decide to cross the Rubicon:
How to go to hell (and stay there) in just 123 easy steps:
Step 1: get the cookies
The bible PlanA: C# In depth (Jon Skeet).
The bible PlanB: C# Step by step (John Sharp).
The bible PlanC: C# 5.0 (J/B Albahari) > my favorite
The reference: C# Language specs ECMA-334
The candidates:
C# Fundamentals (Nakov/Kolev & Co)
C# Head First (Stellman/Greene)
C# Language (Jones)
Step 2: read the cookies (computer OFF)
Step 3: re-read the cookies (computer OFF)
...
Step 121: open computer
Step 122: get the 30 steps to heaven (i.e. hell)
Step 123: shut down computer > change occupation/planet
May The Force (the Dark Option) be with you.
…
onents to the latest version and, as you can see, everything works fine:
Over the next week, I am going to be adding in several new capabilities to the Adaptive model in LB+HB that are not an official part of ASHRAE or ISO standards but they are endorsed by the experts and researchers who have helped build the standards. Mostapha, I will be sure to have the component give a comment any time that these un-standardized methods are used and I will be clear that I have made them a part of LB because I have found these insights from new research to be particularly helpful to design processes for passive architecture. Also, I think many of us recognize that both ASHRAE and ISO were initially founded to produce standards for conditioned or refrigerated spaces and that, understandably, they . Among the features that I will be adding in:
1) You will have the option of using either the American ASHRAE adaptive model or the ISO EN-15251 model (see the CBE's comfort tool for a visual of the differences - http://comfort.cbe.berkeley.edu/).
2) In addition to a different comfort polygon, the European standard also uses a "running mean" outdoor temperature instead of the average monthly outdoor temperature. This "running mean" is computed by looking at the average temperatures over the last week and weights each of the daily average temperatures by how recent it is. This makes more sense to me than the ASHRAE method and addresses the issue that you bring up, Alejandro. Needless to say, the updated adaptive model will allow you to use either a running mean or average monthly temperature with either the American or European polygon.
3) The WIP adaptive chart currently has an option for a "levelOfConditioning". This input allows you to make use of research the was conducted along-side the initial development of the adaptive model, which showed that the findings did not contradict the PMV model when people were surveyed in fully conditioned buildings. This parallel research ended up producing a different correlation between the outdoor and desired indoor temperatures and this correlation had a much shallower slope than the official adaptive model for fully naturally-ventilated buildings. The levelOfConditioning allows you to make a custom correlation for full natural ventilation, full conditioning or (presumably) somewhere in between for a mixed-mode building. This levelOfConditioning will become an official input for all LB components using the adaptive model (not just the chart at the moment).
At the end of all of this, I will put together a new video series on Adaptive comfort so that we are all on the same page about how to use the model.
-Chris…
e display pipeline @ xx:xx:xx(xxxms)
iThe DrawViewportWires only when loaded!
The DrawViewportMeshes always when the viewport is refreshed!
Any Idea?
Public Overrides Sub DrawViewportWires(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportWires(args)-> Disabled because nothing to Display If (Hidden) Then Return
For Each item As Rhino.Geometry.Circle In Circle args.Display.DrawCircle(item, GC, 3) Next
For Each item As Rhino.Display.Text3d In txt
args.Display.Draw3dText(item, GC) Next
End Sub
Public Overrides Sub DrawViewportMeshes(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportMeshes(args) -> Disabled because nothing to Display If (Hidden) Then Return
Dim Brep As Rhino.Geometry.Brep Dim M As Rhino.Display.DisplayMaterial
For i As Integer = 0 To Circle.Count Brep = Rhino.Geometry.Brep.CreatePlanarBreps(Circle.Item(i).ToNurbsCurve())(0) M = New Rhino.Display.DisplayMaterial(VC.Item(Math.Min(i, VC.Count - 1))) args.Display.DrawBrepShaded(Brep, M) Next
End Sub
…
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…
plug-ins can be found at this website:
http://www.food4rhino.com/?ufh
Th plug-in we were going to focus on yesterday was Kangaroo - a form finding mesh editing software. The instructions for downloading it can be found here, although all computers in the lab should already have it loaded.
http://www.food4rhino.com/project/kangaroo?ufh
Your assignment for next week is found below.
Assignment #6
1. You are to model a membrane shading structure for the WAAC outdoor courtyard adjacent to 1001 Prince Street (seen below).
This is an abstract model - no measurements are required. A basic model would be the walls of the the various building and the ground. Spend a few minutes in the space and get a feeling for what a shading membrane would look like in the space.
2. Use the Kangaroo plug-in to make the mesh. I would look at the tutorials below (do part 2 of the design Analyze as a minimum).
http://www.designalyze.com/tutorial/columbia-meshing-spring-2013-class-04
https://www.youtube.com/watch?v=9i8dGtcQxMk
https://www.youtube.com/watch?v=yY5WU_8L4S8
There is also a manual that comes with the download. It should be on the share file at the WAAC; if not just download it for free at the Food 4Rhino website.
3. It does not matter what your membrane structure looks like, but try to use your eye as a designer. Think about things such as sun angle, experience from both in the courtyard and also from the windows above, support location in the wall etc...
Take a screenshot of the completed image. Do not save to dropbox, but bring to class next week - March 23rd.
Post here if you have any questions. See you all next week!
…
20%3ATopic%3A1241658&page=2#comments), I have some questions regarding the work mechanism of the lighting control in HB/Daysim.
1) Which specific sensor point (out of many) in the "lightingControlGroup" should fulfill the requirement of "lightingSetpoint" (300lux)?
in other words:
Does it mean that the average illuminance calculated from all the "sensorPoints" in the "lightingControlGroup" (insteady of any single sensorPoint) should fulfill the "lightingSetpoint" requirement?
if this is the case:
Why the lighting schedule obtained from DSElectricalLightingUse is different from the lighting schedule obtained by post-processing/checking all the hourly illuminance results at all the sensorPoints? (please see the attach gh file edited from Mostapha's version)
2) What's the difference, if I hook up "lightingControlGroups_" or not, as shown in the RED arrowhead in the attached file? (Because the results are different as well)
3) If I have a large space (like a 40m*70m sports hall) and want to know its annual lightingControlProfiles, do I need a "lightingControl" component to be hooked on to the "readAnnualResultsI" (in order to calculate its annual lightingControlProfiles)?
If needed, how many "testPoints" I should choose to be used as "sensorPoints_" in the "lightingControl" component?
Thank you in advance for your kind help!
Best,
Ding…
uld help me to optimize the script, so it works reliable.
At the end the script should work only by the input of the following informations:
- Top-Curve
- Bottom-Curve
- accuracy ( like poly-count)
- is the bowl an open or closed structure?
This is an example of a good result:
From here its probably the best if you open both attached files, so you understand the problems.
1. Bug:
Offset direction of the bottomcurve needs to be set up by hand sometimes.
The script uses "loft" on a bunch of 3pt Arcs to create transitions. Arc 3pts" needs a "Point B" on the offset of the bottom line. Sometimes the offset is inverted, so i need to change it by hand.
The rule to make it work correct is: "The offset of the bottom line goes into the same direction as the top line, but on the same hight as the bottom line."
How can i implement this in GH?
2. Bug:
The floor generation needs a lot of guessing the right index numbers of lists.
The script uses 2x "Deconstruct Brep" to find the actual bottom curve of the created transition Brep. "Patch" is used to create a floor from this curve.
If the bowl is an open structure, the script creates a line between the endpoints of the bottom curve to close it, in order to create a trimmed "Patch". But again, you have to set up the right Index Numbers by hand...
3. Bug:
If the bowl is an open structure and the endpoints of the top-line and the bottom-line are the same the lofting is not working. At the moment I use a script that finds double points in the list and deletes it.
But the the result is, that the loft is not starting at the beginning or the end. Here is an Image.
I have only a little experience in gh, but i really want to learn more.
Thank you all for your help!…
g by a given diameter and some shapes.
What I've done: 1. diameter definition: to find the final object diameter
2. rails definitions: from a initial rails and diameter definition I've find a scaling factor in order to create the final rails with the same form of initial rails but with the wanted distance from the center.
I find the scaling factor using the ray and the distance of a projected point of initial rail to the plane XZ
3. shapes definitions: like the rails definition. I used more than one shape because sometimes I need particular forms along the path.
The sweep 2 rail component gives me a no good result
I tried the options inside the components in order to manipolate the data, but I don't found the solution.
If I bake the final rails and shapes, the sweep 2 rail in RH (selected object) works well, but in GH no (red object).
I attach the RH and GH files for all who can help me Thanks
Filippo…
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.…