Search Results - 分分快3最准高手助赢计划-『8TBH·COM』福利彩票开奖结果012期查询--2023年3月19日6时48分50秒.H5c2a3.5jexii16x-gov-hk

Event: rese arch LIVE Workshop: and 3d rapid prototyping using state of the art material simulation and optimisation. Participants will be guided through methods of advanced structural analysis and evolutionary algorithms implemented in Grasshopper, Karamba and Octopus in a 5 day workshop taught by Robert Vierlinger and Matthew Tam within the premises of the Academy of Fine Arts & Design in Bratislava, Slovakia. The workshop will cover the basics of setting up a karamba definition and more advanced form finding techniques with beams and shells through to preparing files for 3d printing and 2d documentation. For the Grasshopper newcomers there is a preparatory crash course on 20 July 2015 taught by Ján Pernecký. The workshop will be held entirely in English. VENUE Academy of Fine Arts and Design in Bratislava: VŠVU / AFAD, Hviezdoslavovo námestie 18, Bratislava, Slovakia ROOM 135 PRICING Early bird Student (until Jun 30, 2015) €320 Early bird Professional (until Jun 30, 2015) €380 Regular Student (from Jun 30, 2015) €400 Regular Professional (from Jun 30, 2015) €475 The fee covers only the tuition. Travel expenses, accommodation and food is to be covered by the participants. SCHEDULE Day 1 Lecture - Karamba in Projects from Competition to Construction Introduction to karamba - Setting up a basic karamba model Shells & Beams - Understanding the impact of load on geometries. Beams - Cross Section Optimization, Load Path Emergence Day 2 Extraction and Visualization of data from Karamba Complex Geometry - Processing of Free Forms for Karamba Force Flow - Understanding and Visualizing results on shells 3d Printing - Preparing geometries for rapid prototyping Day 3 Lecture - Form Finding in Karamba Isler Shells - Hanging Forms with karamba Shells - Shape Optimisation with Galapagos Trusses - Topology Optimization with Galapagos Columns - Positioning with Galapagos Multiobjective optimisation strategies with Octopus Day 4 Frequency Analysis & Non-Linear Analysis with Karamba Extraction and Visualization Part 2 BIS - Building Information Systems with karamba Day 5 Participant’s Examples and Topics Reviewing 3d Print Studies Large Complex Models Reviewing learn techniques and strategies Concluding lecture - public PARTNERS rese arch Academy of fine arts and design…; Added by rese arch at 4:00pm on June 15, 2015

Event: PARAMETRIC FIELDS 4.0. WORKSHOP GRASSHOPPER3D +FABRICATION - SICILY: ndrea Graziano (Co-de-iT) Arch. Salvo Pappalardo (AION architecture) Arch. Giovanni Basile (Officina Ermocrate) [.] Descrizione: Modulo 1 Il workshop è finalizzato a fornire ai partecipanti i fondamenti della modellazione parametrica e generativa attraverso Grasshopper, plug-in di programmazione visuale per Rhinoceros 3D (uno dei più diffusi modellatori NURBS per l‘architettura e il design). Il workshop mira a gestire e sviluppare il rapporto tra informazione e geometria lavorando sui sistemi di involucro in condizioni specifiche. La discretizzazione di superfici (pannellizazione sia Nurbs che Mesh), la modellazione delle geometrie attraverso informazioni (siano esse provenienti da dati di analisi ambientali, da mappe di colore o da database), l’estrazione e la gestione di informazioni richiedono la comprensione delle strutture dei dati al fine di definire un processo che va dalla progettazione alla costruzione. I partecipanti impareranno come costruire e sviluppare strutture di dati parametrici per informare geometrie ‘data-driven’ e come estrarre le informazioni rilevanti da tali modelli per il processo di costruzione. Modulo 2 Il workshop, volto a promuovere le nuove tecnologie digitali di supporto alla progettazione e alla fabbricazione, fornirà ai partecipanti, utilizzando Grasshopper, gli strumenti per la preparazione dei modelli 3D di elementi modulari decorativi "bricks & tiles" in argilla la cui successiva prototipazione avverrà tramite fresatura dello stampo con pantografo CNC a 3 assi. Il workshop darà quindi ai partecipanti i fondamenti per l’utilizzo di tale strumento di fabbricazione digitale e si concluderà con la fabbricazione di un proprio modello realizzato durante il corso. [more info] [Press Kit]…; Added by Salvo Pappalardo at 2:50pm on July 7, 2016

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