algorithmic modeling for Rhino

Search Results - 福彩3天齐网首页正版保真『0TBH·COM』福彩三d试机号码开机号码2023年3月19日7时42分22秒.H5c2a3.kcssaaksa.com

Comment on: Photo 'Forest Pavilion_Covering': ails. Some word about the mesh... (see Image_01) I took a flat 4 points NURBS surface as imput (very easy, it defines the total area of my pavilion) and some points (that defines the contact with the ground). Then I extracted a grid of points from the NURBS (Surface_Util_Divide surface) and compared 'em with the contol points, in order to associate to each grid's point its own attractor (Vector_Point_Closest Point). Than I moved the points down. I used the distance from each point to its attractor (inverted) as amplitude for the vector of the movement, in order to say: the nearer you are to the control point, the more intense your movement will be. During this operation I've passed the distances' data list into a graph mapper (Params_Special_Graph Mapper), in order to regulate in a very intuitive and interactive way the shaping of my canopy. At the end of the process I asked GH for a simple Delaunay mesh (Mesh_Triangulation_Delaunay Mesh). It's a very cool command, I believe!!! Ok, now some word about the component, it's design and it's repetition/adaptation to the mesh... (see Image_02) I took the mesh and extracted components on first and faces's information on second. Then I selected and separated the vertexes (1°, 2°, 3°) of each triangular face into threee well defined list. Then I re-created the triangles' edges. Please pay attention because it's not the same if you use output information from Delaunay components, because here we need a justapposition of edges where triangles touches each others. After this work I joined the edges and found their centroid. At the same time I found the mid point of each edge. Now the component... (see Image_03) It' a little bit longer to describe: I'll try to be synthetic. Substantially it is a loft from a curve to a point, repeated three times for each triangle (Surface_Freeform_Extrude Point). The point is an elevation of the centroid of the triangle (you can choose if the exstrusion has a single height or it's related to an attractor. In my case it was fixed). The curve is combination of things. There's an arch, which starts on the edge (there's an offset from the corner) end terminates on the same edge (on the other side, obviously). While it's generation the arch passes through a third point which belong to another segment. This last connects the mid point of the original edge (base triangle) with the centroid. The result is a kind of polyline, with two segments and an arch. If you go back to the image of the component that I posted probably you'll understand what I'm saying better than with the definition. The posit…; Added by Matteo Lo Prete at 4:38pm on November 6, 2009

Comment on: Topic 'Possible to add background thread to a custom component': ding is not for the faint of heart and is quite a significant understanding. However, I don't know what your dealing with, so that may be the way to go about it. Your component if its "finished" has to supply some sort of results that are then used downstream. AFAIK there isn't a way to "prevent" down stream components from calculating until your finished. They have to get some sort of information or else they'll just be waiting. Considering how the results of those components are likely to be invalid until the information gets calculated, it may be better off supplying them with nulls until you have some actual information to give them. Anyway, I think that you should think very closely about the structure of your routine, and specifically how it will interact and update itself. The way I'm thinking about it now is that there really isn't anything that's done in the "solve instance" function if you will. Essentially the "solve instance" function would either A) start the reading of the file if no data is found, or B) output some data if it is found. This is an extreme undersimplification, but the simpler you keep this the more likely this will work. Here are a few more "details", i guess, of how I could see this potentially working... Thread A - Initial call to Solve Instance function + Check and see if there are any results that exist from reading your file - at this point there shouldn't be. These results should be stored in some sort of class variable that is accessible to both threads. It might also be a good idea to have some boolean flag that will also be accessible that represents whether your reading/writing those variables. + Fire a function in another thread that begins the read process. Note that you'll likely have to do this through a delegate and an invoke call, but I'm not 100% sure + Fill in some null values for the variables you must supply + Output the nulls, thus finishing the Solve Instance function Thread B - File Read Function running in separate thread + Open up the file. Note that its probably a good idea just to pass the file path (as a string) between the different threads. Leave the creation of the file/text stream to the one thread that's using it. + Perform all the necessary reading from the file + Copy all your data to the variables that are accessible to both threads. + Expire either the solution on either the component in question or (at last resort) the whole canvas. I know expiring the whole canvas is defenitely possible, but it should be possible to just expire the one component that's doing the reading. Thread A - "Second" call to Solve Instance after being manually expired + Check and see if there are any results that exist from reading your file, which there now should be. + Output those shared results + Clear the last results (or cache them in some way) so that the next time the Solve Instance function is fired, you don't find any results and reread the file. I think there are a few variations to this that could happen too, including having a separate function for reading and writing through the data that's called using its own delegate/invoke call to make sure that its extra safe. If you haven't already, you should really look into event driven programming, delegates, and asyncronous messaging. These are going to be the 3 things that you'll need to have a decent hold on to make sure this things works. Just to let you know, debugging these things can be a bitch.…; Added by Damien Alomar at 12:30pm on May 5, 2010

Comment on: Topic 'Manual Interacting within Grasshopper: Caché geometry?': ou mean by 'Activate Direct Rhino Modifying'. Perhaps you could expand? I like the idea of mixing and matching script and 'direct' modeling. There seems to be a lot of potential platforms for this: 1. Implict History: Is there a way for GH to read the direct modifications (with History activated) and translate this as a component (or cluster of components?)? IH seems to record the UI events and the associated elements. GH would need to write as well as read the IH info, in order to preserve as much flexibility downstream as possible. You mentioned Houdini. H seems to record all 'implicit' or direct mods, done via the CAD mouse-based UI, in its network graph. Maybe, this should be captured in the IH cluster/component mentioned above. 2. RhinoParametrics: RP has done a lot of work to intercept and translate Rhino commands into its version of Implicit History. Seems to be centred on points, which makes sense as so much of the traditional 'dumb' way of inputing CAD info is based on mouse clicks on screen (points) predicated by commands, active locks, workplanes etc. 3. Gumball: Rubberduck's use of the new Gumball tool to capture 'direct' modeling inputs thru the Gumball points to a good source for capturing this kind or input, that is related to the 'macro recorder' approach taken by RP and IH. 4. The new Geom Cache component seems to be able to preserve a lot of info about the baked object. There may be even a way to read tagged info generated both GH baked with the "reference" object, and external to GH (by IH, the gumball or even third party apps like RP). Would be interesting to know what kind of info is 'preserved'. Houdini seems to have a pretty consistent approach to geometric data, that seems to allow parallel NURBS/subD/mesh versions of the geometry. It also seems to have a coherent heirarchical approach to vertices/edges/loops/faces etc that allows the subelements to be arbitarily grouped for 'direct' modeling, and still be part of a procedural script. I guess the polygon / mesh approach to geometry lends itself to this. If all the procedural commands/components all understand mesh geometry in either vertex, edge, face format, then combining direct and script modeling is doable in transparent way? In your example above, the Geo Cache node 'flattens' the object to dumb geometry which is manipulated using Rhino, then used as a Reference object, in the next section of the graph. I guess there is nothing to stop the follow on components reading the precedenting graph for parameters, for additional intelligence? Does GH 'get' or 'put' parameter data? …; Added by dominic at 7:36am on October 4, 2011

Comment on: Blog Post 'Grasshopper To Revit': .box.com/s/1db994751279373d299d https://www.box.com/s/d6fc400e73e9bfc5da53 …; Added by CongChien at 3:01pm on May 8, 2012

Comment on: Topic 'Blog post: Worrisome Trends in Architecture Education': sophy though, I have a rudimentary grasp of the Ancient Greeks and modern schools of thought such as Existentialism and Pragmatism, but there is certainly no depth in my understanding. However here the same rule applies. You can quote philosophy all you want, but unless you understand that which you're channelling you can be -at best- accidentally correct. According to you, these are all vital characteristics: Aesthetic judgement Intuition about spatial effectiveness Knowledge of construction materials & assembly systems Consideration of performance-driven design properties Mad synthesizing skillz [1] and [2] are pretty much worthless, especially when we're dealing with students. Aesthetic judgement is not something that can be wrong or right. You can hone your aesthetic skills but you cannot cultivate better tastes. Intuition is also problematic. It's basically a stand-in for argumentation. Instead of saying "these buildings have to have 20 meters apart because of wind/sound/human perception/human psychology/light/shadow/etc. etc" is a far stronger statement than "these buildings have to have 20 meters apart because of my feelings". Who are you to be trusted? If you have a long and distinguished career backing you up, maybe your opinions carry some weight, but until that point you'd better be prepared to justify your decisions with cold hard logic and data. [3] is certainly important for certain jobs in construction, but it can be argued that implementation details are not necessarily central to a design. One can design a good computer interface without having to be able to program, and certainly without being familiar with all the idiosyncrasies of a particular programming language. Conversely, one can design an excellent space without knowing exactly how strong certain atomic bonds are. If what you design is physically impossible, then obviously something has to change, but it doesn't mean that the design as an abstract idea was bad. Of course on the other hand one can argue that designing impossible things is not doing anyone any favours. I'm not exactly certain where I stand on this issue, probably comfortably in the middle; YES, students need to learn about what can be build in the physical world, but NO that is not part of design training. I'm not quite sure what [4] means. [5] is true for a lot of professions, not just Architects. I would concede that architects probably have more to take into account than most designers and that it is indeed an important skill to have. I would say that -especially for students, who have little experience- an incredibly important skill to be able to ask yourself "why am I doing this?" about pretty much every decision you make. Basically you need to get very comfortable applying the Socratic method to everything you do. -- David Rutten david@mcneel.com Tirol, Austria…; Added by David Rutten at 11:03am on August 14, 2013

Comment on: Topic 'Disposing custom classes/parameters': ctor. I do not dispose of any IGH_Goo instances, mostly because I have no idea when an instance is truly no longer needed. If any of your fields need to be disposed, you may have to implement a destructor, but I have no experience with this. 2) should I pass those classes to other parameters by DA(0, MotherClass.Duplicate?) or it is already there by GH_Goo ? IGH_Goo is not duplicated by default. If you use DA.GetData() and ask for IGH_Goo types, you'll get a reference to the same instance as exists. Thus, if you take in an instance of your type, modify and output it, you should duplicate it yourself. But you only need to do this if you change the state of an instance. MyGooType data = null; if (!DA.GetData(0, ref data)) return; data = data.Duplicate() as MyGooType; data.Property = newValue; DA.SetData(0, data); 3) should I create ChildClass and MotherClass in SolveInstance, or create it once as a component's field and then change theirs properties and pass it to DA (as duplicate ?).... It's almost always better to use variables with the lowest possible scope. So method variables are preferred to class variables, class variables are preferred to static variables. 4) if I create those classes in SolveInstance, is it necessary to Dispose them there ? NO! Do not dispose of instances that are passed on to output parameters. Disposing objects typically makes them invalid, so if you share instances with anyone else, you should not dispose them or the other code may well crash. However I don't think your types need to be disposable so this is a moot point now. In general, if you're dealing with disposable types, and the instances aren't shared, then you dispose them as quickly as possible. But if they are shared it's a lot more complicated. 5) finally - maybe it would be better if MotherClass inherits the ChildClass ? Maybe. Not necessarily. Depends on the classes. …; Added by David Rutten at 12:08pm on December 31, 2014

Comment on: Topic 'Multiple breps with Meshmachine': ght on why this is, and some ideas I have for how to improve things going forward. MeshMachine grew out of some scripts I started developing over 3 years ago (described here), originally just with the aim of achieving approximately equal edge lengths on a smooth closed triangulated mesh. As time went on, I kept adding things, such as ways of keeping boundaries and sharp edges fixed, different ways of controlling edge lengths that vary across the surface, and different ways of pulling to surfaces. I was also still experimenting with different rules for the core remeshing operations, such as valence driven vs angle driven edge flips. All of these things meant many variables in the script. I wanted to share the work so others could play with it, but not really knowing exactly what people might use it for made it difficult to simplify the interface, so I just exposed most of these variables I was using (actually there were originally even more, but I felt a component with 20+ inputs was excessive, and combined some of them and fixed others to default values). I've never been happy with that component, but some people want a component that you can just feed a surface and get a mesh with 'nice' triangles, without too much fuss or needing to know anything about how it works, while other people want to be able to vary the density based on proximity to the border, and curvature, and attractor points and see the intermediate results, and model minimal surfaces without pulling to any underlying surface, and... Since then I did the rewrite from Kangaroo to Kangaroo2, and through that process, and associated conversations with Steve Baer, David Rutten and Will Pearson, my ideas about how to structure libraries and make cleaner more flexible Grasshopper components changed. Much of this centres around using interfaces (in the specific programming sense, not to be confused with UI), because they allow separating code into multiple components, while still allowing to edit parts of it within Grasshopper, and other parts in a proper IDE (because I find the GH code editor is not conducive to writing large amounts of well structured object oriented code). Towards the end of last year, Dave Stasiuk and Anders Deleuran invited me and Will Pearson over to CITA for a few days of mesh and physics coding and beer drinking. During this time I made the first steps to restructuring MeshMachine to be more modular and interface based like Kangaroo2, instead of one giant script. One of the main motivations for doing this was to make it easier to combine the K2 physics library with the remeshing. However, at the time I hadn't yet released K2, so it didn't make sense to post examples that used those libraries. After the launch of K2, this restructured MeshMachine development has been a bit on the back-burner, but this discussion and Dave Stasiuk's work with Cocoon is inspiring me to pick it up again. Seeing how you are combining the Cocoon and MeshMachine, and how Dave is also using interfaces in his recent work suggests to me it might be possible to integrate them more smoothly... …; Added by Daniel Piker at 7:47am on July 30, 2015

Comment on: Topic 'shades generated by Window Shades Generator are not shown by Decompose by Type': rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points: 1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating. 2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component). 3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo). Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon. -Chris …; Added by Chris Mackey to Ladybug Tools at 9:15am on August 1, 2015

Comment on: Topic 'unpredictable behaviour of LBHB components': 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…; Added by Chris Mackey to Ladybug Tools at 3:46pm on August 22, 2015

Comment on: Topic 'Finding an optimal size of PV panel in given array.': size component supported only ground PV panels and angled roof PV panels. Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one). Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…; Added by djordje to Ladybug Tools at 3:56am on March 31, 2016