Search Results - 广东11选5体育彩票开奖结累查询-『8TBH·COM』下载青蛙彩票网--2023年3月19日6时33分12秒.H5c2a3.rynzzgon4-cc

Topic: Mode shape animation in GH: actually can perform using a dedicated software: in 3D: https://www.facebook.com/francescopiasentini/videos/523532707845171/ in 2D: https://vimeo.com/189618609 The output of Modal Analysis (at a given frequency) is a list of point (x,y,z), each of them has the three coordinates and the maximum displacement in the direction normal to the surface (that's not flat) Point number x y zmax1 24,007565 337,876028 -0,6545572 -28,0404705 337,947773 0,7760153 57,141457 316,757768 -0,8413914 18,667466 314,814543 -0,235288 My idea is: -import stl surfaces of the object (violin) -import Modal Analysis data -deform stl (or Nurbs) surfaces using something like a customized CageEdit -animate this deformation from zero to maximum displacement -give a color to deformation (or first-second derivative of the interpoled deformation curves) My wish is to have closed surfaces at any steps, and to create "natural" deformation shapes. I just tried to import MA data. I was trying to create an array of circles with given x,y,z and radius, I could not figure how to separate information of position and radius when importing the file: file content: 0,1,0; 5;2,1,3; 2;5,2,6; 4; thanks for yout attention. Looking forward to hear you soon! Francesco …; Added by piase at 2:10am on May 31, 2017

Topic: Nested arrays/lists to datatrees: to convert nested arrays ? For intance if I have 5 times nested array, do I need to another method, or there is a short quick version that combines all three methods below into 1? public static DataTree<T> IEOfIEToTree<T>(IEnumerable<IEnumerable<T>> list, int iteration = 0) { DataTree<T> tree = new DataTree<T>(); int i = 0; foreach (IEnumerable<T> innerList in list) { tree.AddRange(innerList, new GH_Path(new int[] { iteration, i })); i++; } return tree; } public static DataTree<T> IE3<T>(IEnumerable<IEnumerable<IEnumerable<T>>> list, int iteration = 0) { DataTree<T> tree = new DataTree<T>(); int i = 0; foreach (IEnumerable<IEnumerable<T>> innerList in list) { int j = 0; foreach (IEnumerable<T> innerList2 in innerList) { tree.AddRange(innerList2, new GH_Path(new int[] { iteration, i, j })); j++; } i++; } return tree; } public static DataTree<T> IE4<T>(IEnumerable<IEnumerable<IEnumerable<IEnumerable<T>>>> list, int iteration = 0) { DataTree<T> tree = new DataTree<T>(); int i = 0; foreach (IEnumerable<IEnumerable<IEnumerable<T>>> innerList in list) { int j = 0; foreach (IEnumerable<IEnumerable<T>> innerList2 in innerList) { int k = 0; foreach (IEnumerable<T> innerList3 in innerList2) { tree.AddRange(innerList3, new GH_Path(new int[] { iteration, i, j ,k})); k++; } j++; } i++; } return tree; }…; Added by Petras Vestartas at 11:24am on October 17, 2017

Topic: split building mass component error: rce=activity Basically, I want to create a workflow to automatically subdivide a building mass envelope geometry into different floors which will be further subdivided as perimeter zones and core zones. But I encountered an error for a particular building mass geometry (a quite regular form) which doesn't work with the split building mass component (see item 4&5 below): The workflow is: 1. import building mass geometry: 2. divide the building mass into floors (one zone per floor) using one of the two different methods depending on whether the floor surface has holes or not: 3. use the split building mass component to further divide the zone for each floor into perimeter zones and core zone: 4. I tested several building forms which work for this workflow as shown below, except for one form C05 which is a courtyard block with small tower blocks on top of it: 5. in the last step, there is an error from the split building mass component saying that "solution exception: index out of range: 0" ... So, I wonder if this is error is related to the split building mass component or related to the way the building mass geometry is created. Appreciate your kind advice! Thank you!…; Added by Grasshope to Ladybug Tools at 2:24am on March 28, 2016

Comment on: Topic 'Blog post: Worrisome Trends in Architecture Education': is also takes place in own system. However, this action can be also carried out successfully by a foreign reference, if this considers the focused system as own. Hence, these two criteria are considered in my reflexions, to make your criticism handier for me. First the question must be put up, how is it in your case? Of friendly manner you answer this question perpetually with the statement that you are not a partial of the system of the architecture. Furthermore the question would be appropriate, whether an external reference (eg CAD) determined architecture. This can be answered with no, because determining and influencing are different things. Because you stress now your criticism as a foreign criticism, within the architecture the assuption must be put up, that this criticism is not unusual new on the one hand (because this condition were also in other times like that, and presumably also always so remain) and further more a lack of goodwill in your criticism comes to light, which perhaps distinguishes an external reference. Based on your critique, it would be also desirable in the system of the architecture if the academic rules become satisfyingly followed, even if this is no guarantor for good academic works. Nevertheless, there is an aspect which at least tolerates the evident lack in the Interdiziplinarität of the architecture. This is the classical and still valid determination of the architecture, presumably regulates not only the actions of the architects, but also those who want to become it. Many who stand in your criticism (the students, as well as the teachers, ... ), live in the awareness that architecture is a profession that combines as many areas around the topic of Building, and the architect is even only one dilettante among the external specialists. In this determination dilettantism is revalued rather positively, because this state the architects enables to assess the facets of a complicated building project better and to form thereby the whole result positively. To be a good architect, you should have circumspect specialists around yourself. And exactly this knows the system of the architecture, because "THE ARCHITECT" helps himself with the logic of other systems (to repair on the one hand his own deficits), and to create an artificial complexity, which ultimately aims to be the complexity of human beeing. Here "THE ARCHITECTS" becomes a quality-spoken, which currently seems the external reference (CAD, BIM) would like to take claim for themselves. ........ If would not thought about it, this might be helpful:http://www.amazon.com/The-Alphabet-Algorithm-Writing-Architecture/dp/0262515806/ref=sr_1_1?ie=UTF8&qid=1376920450&sr=8-1&keywords=mario+carpo"Finally, I’d like to restate my criticisms in general terms. If we are serious about moving architecture and urbanism away from purely artistic considerations and into a more rational arena, there has never been a better time than now. All of us have access to immense computational power which can be applied to problems that have been —until quite recently— intractable. But of course the garbage-in-garbage-out adage holds true; computation can be used to generate large amounts of complexity, but complexity does not equal worth. The only time when it makes sense to invoke computation in the design process is when there is some relevant data that needs to be computed" (David Rutton)I want to make it short, and just ask a few questions, and hope that the following questions are relevant also for you, and not be considered outside your system. i think that the weighting to such questions seem to be more valuable, not for the architects.1. What is wrong from a pure artistic intention?2. What is any sense in purely architectural discourse?3. strictly looked, can be determined sense generally in a purely architectural discourse?4. What is purely architectural discourse?5. What is Funktionalismus or Rationalismus without philosophical support? 6. Would not be the pure functional fulfilment empty ? 7. Would be not a critical position on the promise of purely rational algorithms applied?…; Added by RWNB at 9:56am on August 19, 2013

Comment on: Topic 'Pain Points in Grasshopper': hat aren’t completely there. BIM will have to continue to evolve some more if their supporters want to get to realize the promise that still is. I can’t say much about PLM, but I would say that both BIM and PLM should be considered in future developments of GH and Rhino. David has said several times that some GH limitations regarding geometry and data structures (central to interoperability) are actually Rhino limitations. So, I wouldn’t put so much pressure on David for this, or at least I would distribute the pressure also on the core Rhino development team. Talking about Rhino vs. GH geometry, there is one (1) wish I have: support for extrusion geometry. GH already inputs extrusion elements from Rhino, but they are converted to breps. Is not a bad thing per se. The problem is when you need to bake several breps that make the Rhino file to weight several hundred MB. When these breps are actually prismatic, extrusion-like solids, is a shame that they aren’t stored as Rhino V5’s extrusion geometry in a file of just a couple of MB (I overcame this once with an inelegant RhinoScript that wasn’t good for other people). This was one of RhinoBIM’s main arguments. We can develop a structural model made of I-beams in GH using the Extrude components. We should be able to bake them as extrusions. That would also work for urban models with thousands of prismatic massing buildings (e.g. extruded footprints). Even GH’s boxes are baked as breps! Baking boxes as extrusions could be practical for voxelated or Minecraft-like models. (2) Collaborative network support. Maybe with worksession handling, or something that aloud project team members to work on a single definition or in external references or something alike. I know there is another Rhino limitation on this, but maybe clusters are already going in that direction? And maybe on the plug-ins domain: (3) Remote control panel that could be really “remote”, like from other computer or device. There is an old Android App for that, but is not only a matter of updating. I mean, it would be great to control a slider with the accelerometer of an Android phone, but to have that on an iPhone will require another development team. If GH could support networks, a remote counterpart of a RCP plug-in could be developed as a cross-platform web app. I don’t know if you can access accelerometer functionality through HTML5 already, but for now, asking a client (or an spectator or any stakeholder for that matter) to control your sliders from gestures of his/her own phone would be awesome (maybe Firefly will fill that hole?). (4) GIS support. GH already imports .shp files. Meerkat can even access the database, but what about writing to shapefiles or generating our own with databases processed/generated in GH? (5) SketchUp support. Not only starchitects and corporations are using GH in the AEC. There are a lot of small firms, freelancers and students interested. Most of them use SketchUp for 3D modeling (not CATIA, neither Revit). Yes, you can import/export .skp from Rhino, but if GH could support nested block at bake time (also mentioned by others), it could write .skp files with complex relations of blocks (that are called components in SketchUp) and nested groups, going beyond what Rhino can export. (6) Read/Write other formats. There are some challenges with proprietary formats that are not completely supported by Rhino, but they’re still a lot of open formats that are relevant to the fields of GH users, like stl and ply for 3D-printing. It could be nice to write mesh colors to a ply for 3D-printing a colored prototype based on GH colors. There are others, like IGES, STEP, COLLADA, etc. and 2D, like svg, odg and pdf. Some of them could offer special formatting options like custom data that the format supports but nobody uses just because is impractical to access this from direct modeling environments (but not from visual programming). --Ernesto…; Added by Ernesto Bueno at 3:00am on July 31, 2014

Topic: Grasshopper interface freezes and it uses large amount of memory during start: mment%3A1637953 First of all, the invalid Rhino license as seen previously has been removed, and the correct educational license we have is re-installed for this test. The re-appearing issue is that RAM usage spikes once GH is open in Rhino. It seems that this happens when a series of large GH project files incrementally saved are stored in the same folder. Moving those previously saved large project files to a new folder seems to be able to solve this issue. The images below explains the issue and the hypothetical solution: 1. A series of GH files were incrementally saved in the same folder previously, and the last few GH files are the ones opened most recently: 2. The total RAM usage is at the normal 5GB level once Rhino is open: 3. Once GH is open, the RAM usage spikes, and the it becomes very slow to maneuver the GH window before even opening any one of those GH files: 4. Once GH and Rhino are closed, the RAM usage drop to the previous level before the GH interface was open: 5. Now, all the incrementally saved GH files are moved to a new folder "wip" except the last one, i.e. for the last GH file, there is no other previous GH files in the same location: 6. Now, if we open GH, there is no sudden increase of RAM usage, and the 3x3 thumbnails on the GH canvas shows "missing" as those previously opened GH files are no longer in the same location as they were before: I understand that David mentioned that the thumbnails for previously opened GH files on GH canvas will not take much RAM. Nevertheless, I'm still not sure what is causing the increase of RAM usage and slowdown of GH interface. Relocating the large project files previously saved in the same folder as the current GH file seems to be able to make this issue go away, for unknown reason ... Appreciate if anybody experiencing similar issue can help to check if this solution works. Thank you. …; Added by Grasshope at 12:49am on January 26, 2017

Comment on: Topic 'Baking Breps w/ Color - RHINOCOMMON': es only have one raison d'être, which is to group types into logical chunks. A Type is the definition of a class or a structure. Classes and structures are very similar entities (they can both contain any number of methods, properties and other types), but because they behave differently, you need to know which is which. An Instance of a type is a single object that actually exists. For example, the class Human is the definition of what it means to be human. You are an instance of this class. I am a different instance of this class. Damien is yet another instance of this class. Every instance can assign unique values to all its properties and fields. If for example the type Human had a property for height, then in my case it would say 1.97m. In Damien's case it would be set to something much less, as Damien isn't anywhere near as handsome and tall as I am. A Reference is a piece of information that tells you where a certain instance is. Think of a reference as an address. When you mail a letter (or e-mail), you must specify a valid and unambiguous address or the letter won't arrive. Similarly, every piece of data stored in the memory of your computer also has a unique address, but instead of "3670, Woodland Park Avenue, Seattle", it looks like this 0x12345678. Trying to access an instance through an invalid reference is like sending a letter without an address. References are sometimes also called "variables", though sometimes the word variable is only used to indicate primitive types, such as Booleans, Integers and such. A reference is not the instance itself. Take the following code: 1. Dim crv As Rhino.Geometry.Curve 2. Dim dup As Rhino.Geometry.Curve 3. crv = GetACurveFromSomewhere() 4. dup = crv 5. If (dup IsNot Nothing) Then dup = dup.DuplicateCurve() One lines (1) and (2) I declare two references, one is called "crv", the other "dup". Because Visual Basic is a strongly typed language, I can assign limitations to what sort of data crv and dup are allowed to reference. In this case they can only point to instances of the Rhino.Geometry.Curve class or any class which derives from Rhino.Geometry.Curve (such as Rhino.Geometry.NurbsCurve, or Rhino.Geometry.LineCurve). On line (3) I assign an actual curve instance to the crv reference/variable. At least, assuming the GetACurveFromSomewhere() function actually returns a proper instance. If it doesn't, crv will remain a "null reference". Line (4) is interesting, because both crv and dup will now point to the same curve instance. So even though there is only 1 curve in memory, both crv and dup provide access to it. This means that when we change the curve via crv, then dup will notice that change. On line (5) two things happen. I want to duplicate my curve data so I can change the data via dup, without affecting the data available via crv. The best way to duplicate a curve (i.e. create a second curve in memory, that has the same shape as the first curve) is to use the DuplicateCurve() method on the Rhino.Geometry.Curve class. However I cannot call a method on an instance that doesn't exist, so before I do that, I need to check whether or not dup actually points to a real curve object, or whether it is a null reference. Finally, it is also possible to have an instance of a class in memory, without any references to it. In this case nobody can reach that curve any more and it is essentially dead weight, taking up pointless memory. In C++ this is called a Memory Leak and it's considered a serious bug. In VB.NET and C# this memory will automatically be cleaned up by the .NET Garbage Collector. In my opinion the Garbage Collector is the single most important feature in .NET. It's what turns VB and C# from frustration central into a friendly and flexible coding platform. -- David Rutten david@mcneel.com Poprad, Slovakia…; Added by David Rutten at 4:10pm on August 9, 2011

Blog Post: Silkworm Source Code Release and Development

Hello Silkworm users,

Due to recent interest in this plugin again we are today making the source code public. This source code can be downloaded at…

Added by Silkworm at 11:14am on June 1, 2014

Topic: The Why and How of Data Trees: ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points. In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes. The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.* Data storage in Grasshopper In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time. A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point. Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count. The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface. Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless. A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined. The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'. Data storage as the outcome of a process If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points. This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network. It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others. The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family. A flexible mechanism for variable history records. The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view. A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10]. Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}. The messy reality of data trees. Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths: {0;0;0;0;0} {0;0;0;0;1} {0;0;0;0;2} {0;0;0;0;3} {0;0;1;0;0} {0;0;1;0;1} {0;0;1;0;2} {0;0;1;0;3} instead of the far more economical: {0;0} {0;1} {0;2} {0;3} {1;0} {1;1} {1;2} {1;3} The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible. Conclusion Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future. * This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms. ** I'm skipping a lot of taxonometric classifications here to keep it simple.…; Added by David Rutten at 2:22pm on January 20, 2015

Page: ND_Examples: A repository of generic or complex examples. Example 01: Attractor Values ND_001_AttractorValues.gh Example 02: Curve Values ND_002_CurveValues.gh Example 03: Point Attractor ND_003_PointAttract; Added by Marios Tsiliakos to Nudibranch at 5:34am on January 29, 2013