Search Results - 📍 trx兑换比例👉【TG：@trxHomeBot】，硬件冷钱包价格.v

Blog Post: My shared tools.

Transparent canvas, wormhole to Rhino…

Added by Daniel González Abalde at 4:59am on June 25, 2015

Blog Post: Brick Wall: Added by Tigran Kostandyan at 6:08am on October 23, 2013

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

Event: New Paradigm and Graphics Technology in Design Industry: elivering their latest workstation and graphics technology. Intensive computing and exceptional graphics technology will deliver generative modeling and computing to its next level. Participants will learn the ease of use of Grasshopper within Rhinoceros, so they could start creating their own generative design. Who should attend: 1. Professionals in design and engineering industry who would like to gain more knowledge and productivity 2. Students who would like to extend their knowledge to the next level 3. Supporting IT who would like to provide even more efficient tools for engineers and designers 4. Engineering and Design Enthusiasts Participants should send an email to fani@m3kom.co.id, to receive an invitation and its detail. For further technical information about the event, feel free to ask Rendy (tihe.tihe@gmail.com). This event will consist of the sneak preview of most anticipated real-time rendering for Rhinoceros: V-Ray RT for Rhino. Hopefully, this will also initiate the establishment of Indonesia's generative modeling designers community in Indonesia.…; Added by Bimo Adi Prakoso at 11:25pm on January 1, 2012

Event: Shapes of logic: Behavioural Networks workshop: propose new models of infrastructural self-organisation, urban automation and mobility systems. Adaptive networks based on multi-agent principles and crowd simulation are used to solve complex architectural and programmatic conditions in a three-dimensional urban environment. We will explore towards an intelligent architecture, defined by flows of information and its materialization in speculative infrastructure and architectural scenarios. A responsive infrastructure that is deployable in multiple regions. Our design process will be driven by a direct feedback loop of different simulation software, each informing another as input for emerging connectivity networks and interrelated urban systems, driven by site specific urban and topographical parameters. The workshop aims to develop ideas of adaptive and evolutionary space-making beyond deterministic and finite solutions. In a series of algorithmic design exercises, different network principles and speeds, users behavior and needs are tested and evaluated, both by observation and parameter based criteria. Students will propose an architectural intervention in dense urban scenarios, that is both tested for optimised efficiency and stimulating in its embodiment. METHODOLOGY Students will be introduced to expertise in generative, algorithmic and parametric design approaches. Tutors and students will engage experimentally with computational simulation, analysis, design and production to query the design repercussions of these information-based technological methods for urbanism. During the workshop, students will develop design proposals responding to studio briefs using Processing with Rhino and Grasshopper. The final results of the workshop will be visualized using V-Ray for Rhino and the Adobe Suite. Basic knowledge of Rhino and Adobe Suite is required. Advanced knowledge of Grasshopper and Processing is not mandatory. …; Added by Matthijs la Roi at 1:36am on April 6, 2017

Comment on: Topic 'That $#$#%$ sweep*2 thing': in a "bigger" scale, he he). Divisions are proposed to suit variable area schedules (small airport with 3 divisions bigger wow stuff with more). My initial intension was to design this via insulated tensile membranes (THE engineering purity) bit client thinks that these are only suitable for some gypsy campus. 2. Goal is to outline a collection of "boundary" surfaces (so far the definition deals only with the exterior skin and an indicative WIP "base") that could define "in-between" them space trusses. See a primitive "generic" outside boundary in the Rhino file (second not shown). Of course ideally this type of forms is actually T-Spline territory, but never mind. Back to GH thing: 3. See results with C# Surf rebuild and odd results with closed stuff as well. 4. It's obvious that mess relaxation (Geo Gym stuff) methods are required here - working solely with nurbs is a clear dead end (unless applying "weaving" in dense U/V areas) . Stupid questions section: (a) how we can trim surfaces in GH? - help in components...er...hmm...is this help? (b) by what means can we fillet, variable fillet and/or blend surfaces in GH? Of course given an infinitive amount of time one could do that by defining a myriad of suitable curves - but this is CAT not CAD (T=torture). Best, Peter (one step before Plan A, no actually there's no Plan A since Microstation/Gen Comp can't blend/fillet correctly a thing (or two), he he)…; Added by peter fotiadis at 2:31pm on December 20, 2011

Comment on: Topic 'Grasshopper for Rhino5 available for download.': ess more memory on 64 bits. So you can load larger files and generate more data. Every time you store something in memory it has to be stored at a specific location. We call this location an address. The first thing you store can be stored at address 0*. If that thing requires a total of 18 bytes, then addresses 0 through 17 are used up. The next thing you store can then be stored at address 18. And so on and so forth. At some point you run out of addresses and when that happens there is no more room to store any new data and there is thus nothing more that your app can do and that's usually when Windows shoots the application in the head and buries the remains behind the chemical sheds. The total number of unique addresses that can be represented by a 32-bit integer is 4,294,967,295 (4 GigaByte). However Windows only allows a 32-bit app to access 2GB, or potentially 3GB if a special switch is set. A 64-bit application is allowed to use 64-bit integers to identify memory addresses, which means the highest possible address is now 18,446,744,073,709,551,616 (or 18.45 ExaBytes). Basically, as long as you have RAM to back you up, a 64-bit application will not run out of memory. Of course it may still become prohibitively slow as a lot of data requires a lot of computation and 64-bitness does absolutely nothing to make things go faster. -- David Rutten david@mcneel.com Vienna, Austria * Not true in reality, Windows will already use up some of the available memory just to load the application.…; Added by David Rutten at 1:39pm on November 2, 2012

Comment on: Topic 'Springs': there too for example this nice elementary intro from Khan academy on Hooke's law or the chapter on Forces in Daniel Shiffman's Nature of Code Getting the most basic springs working can be surprisingly simple and fun, and I'd certainly encourage anyone to have a go at it to gain a better understanding of the principles. I learned about Newton's laws of motion and Hooke's law in school but it wasn't until I actually wrote them into some code and had that magic moment of seeing physically plausible behaviour emerge from those few equations that I felt I really appreciated their elegance and power. However, going further with physics simulation and dealing with issues of numerical stability, material properties, system topology etc can get much more involved and time consuming. For this reason I'm working on making Kangaroo physics a more accessible library (working along similar lines as TraerPhysics, Box2D, or ToxicLibs), because I think there are many people interested in scripting physical behaviours who have a general understanding of the ideas involved, but don't necessarily want to have to rewrite all of this stuff from scratch. (especially if they are more interested in doing something with the physics, such as combining it with a GA) It would be interesting to hear if you think such a library would be useful, and how you'd want to use it...…; Added by Daniel Piker to Kangaroo at 5:42pm on March 29, 2013

Comment on: Topic 'Outputting Nodal Connectivities in Text': grouped differently: On one hand (input P) we have 204 lists with 2 points each (the 2 endpoints of each line). So it looks like this: {point A, point B}, {point B, point C}, {point C, point D}, ....etc On the other hand (input S) we have a single list with all the points, cleared from duplicates(108 points). So it looks like this: {point A, point B, point C,...., point n} What [CP] does is: it takes every single point from P and searches all of S to find the closest point. Of course it will find the same point that it searched from. That's why the distance (D output) is always 0. BUT [CP] also has an output i. This is the index(an integer from 0 to 107) of the point in S that was closest to the point from P. So the output i has the data structure of input P but looks like this: {i of point A, i of point B}, {i of point B, i of point C}, {i of point C, i of point D}, ....etc ...and this, when joined into text is the output you want! I hope this all makes some sense, it is a bit late here :) cheers, nikos…; Added by nikos tzar at 3:57pm on April 5, 2015

Comment on: Topic 'Problem with Seam line overlap in Bump Tiling Nurb': switch to the other cases until you get the gist of the available options (push/pull, reverse, 2 surface creation modes, distance values remap etc etc). Push/Pull: The main point here: In plain English: a capability is added to exclude "peripheral" control points from the sample of modified points > toggle this bool in pink (shown: the false option) to get the gist of it and think: a sphere (or any closed in U/V surface) is in fact a "rolled"/"wrapped" variation of that flat thingy. Imagine what happens if you attempt to modify the sphere "star" points ... I hear you: but ... you start (gradually) replacing components with these C# freaky things of yours > is this help? Well ... er... can I have the next question please? he, he. Next update (V4): 10+ "tiling" options (patterns) for that poor surface. Plus random/chaotic stuff. Plus 12,34 divisions by zero have fun, best, Peter…; Added by peter fotiadis at 11:33am on April 20, 2015