eroberfläche des Grasshopper Programms
Funktionsprinzip eines grafischen Algorithmus-Editors (Datenfluss)
Unterscheidung von Parametern (Datentypen) und Komponenten (Datenverarbeitung)
Erzeugung, Bearbeitung und Analyse von Geometrie-Typen: Punkte, Vektoren, Linien, Kurven, Flächen (surfaces, brep) und Netze (meshes)
Strukturierung der Daten anhand von Listen und Bäumen
unterschiedliche Verknüpfungsmöglichkeiten von Parametern (data matching)
praxisnahe Grundlagen der Geometrie und Vektorrechnung für generatives Design
effizienter Aufbau von parametrischen Modellen anhand Übungsaufgaben
Auszug von Daten aus Modellen für die Fertigung; Daten aus Tabellen (Excel, CSV) importieren, exportieren
Einsatz von benutzerdefinierten Komponenten (custom components)
Vorkenntnisse: Rhinoceros3d Benutzeroberfläche der Software: Englisch Unterrichtssprache: Deutsch
Details und Anmeldung:
www.vhs-sha.de
click: SUCHE
Kurstitel: GRASSHOPPER
(auch: Kurstitel: RHINO)
Trainer: Peter Mehrtens
Kursdauer: 3 Tage / 8 Stunden pro Tag
Donnerstag, 19.07.2012, 08:00-17:00 Uhr Freitag, 20.07.2012, 08:00-17:00 Uhr Samstag, 21.07.2012, 08:00-17:00 Uhr Ort: Volkshochschule Schwäbisch Hall, im Haus der Bildung
Teilnahmegebühr: 299,00 € Teilnehmerzahl: 5-10 Personen
…
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.
2. AEC Projects are made by teams. Period.
3. Teams are organized with some sort of hierarchy. Period.
4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)
5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).
6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).
7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ... etc etc).
8. Efficiency is above all (even above tax-free cash).
9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.
10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).
If you combine all the above you'll have the answer (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.
PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).
best, Peter (Prince of Cynics)
…
you still have left, what matters is how much memory Rhino is using compared to how much Windows is prepared to give it. On 32-bit systems this is usually 2, sometimes 3 Gigs. On 64-bit systems it's such a high limit that it's unlikely you've reached the limit.
You're low on or out of specially allocated memory/handles. Certain processes such as GDI drawing or winforms UI elements require a handle per instance. Every window, every label, every button, every slider, every bitmap... each one has a unique handle associated with it. Depending on the windows version, you either get a few, some, a bunch or lots of these handles to play with. When you start running out, usually the first sign is that the UI goes all wonky. Text disappears, fonts suddenly look terrible, parts of windows go missing. When all the GDI handles that are allowed have been claimed, the application will crash. The same may be true for OpenGL or DirectX handles, I'm not an expert on those.
There's an arithmetic error causing an overflow error. Sometimes these are handled gracefully and you get a proper crash or error message, sometimes they cause software to start accessing the wrong memory.
It's just some random crash that decides to manifest as an out-of-memory crash. This happens a lot and it makes these crashes very difficult to track down.
Since your images start going black before the crash, I'm tempted to think we're dealing with a #2 crash here. Maybe all these images we're saving out are hogging GDI handles and choking the system. If the handles or GDI objects assigned to Rhino keep going up and up as you write out these images, that'll be good supporting evidence. You can use the Windows 8 Task Manager to keep an eye on these values, or if you're running an older version of Windows I recommend installing Sysinternal Process Explorer in lieu of the Task Manager.
…
Added by David Rutten at 1:20pm on February 28, 2015
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…
file. A TSpline made thing in fact.
2. This atroci ... er ... hmm ... I mean unspeakable beauty uses an exo-skeletal load bearing structure hence is THAT big (BTW: Apparently nobody knows what thermal bridge is nor thermal expansion nor vapor condensation ... but these are "minor" details these holly blob days, he he).
3. 2 means that some nodes of that "grid" MUST "meet" floors in order to support them and (hopefully) withstand some seismic forces. BTW: A Richter scale 9 (for an hour) is all what this building actually needs (that's acid "humor").
4. The "smarter" way to do this is to spread "some" (i.e a lot) random points (Note: David's algo yields "evenly-spaced-points" within the limits of the possible) on the guide blob (a polysurface in fact).
5. Then ... you need some algo that tests proximity AND "adjusts" the Z in order to have some node points "co-planar" (Z) with the floors.
6. Then you triangulate all that stuff (the points, that is) using some decent Ball Pivot Algorithm (NOT Delauney) and you get a triangulated mesh that "engulfs" the guide blob. If you want some quads (as shown) this is also possible.
7. So you have edges ... i.e poly lines (per mesh face) and if you offset them ... you have "drilling" profiles that you must use against a second guide "thickened" blob for creating a continuously smooth exo-skeletal LBS (as shown). Of course Rhino (being a surface modeller) could require years to do this solid difference opp (or an eternity).
8. Rounding the "lips" of that LBS Brep is out of question with Rhino or GH (but it can been done very easily using other apps). Then you must "split" the Brep (in modules? in nodes + "rodes"? you tell me) in order to make it in real-life (what about forgetting all that?, he he).
9. Then, there's the glazing thingy that is made via quads meaning planarity. This is achievable with Kangaroo2 but is a bit tricky.
Moral: WHAT a gigantic pile of worms is this thread of yours...
more soon.
…
ruses could follow. Then cones are made and some other things.You can move the cones around via the equivalent slider. If the cones "touch" then ... well .. test it and see what's happening,
2. Interactive capability is not present: assume that you have 666 paths/cones > by what means you think that you could control what's happening? By adding 666 sliders? (not in a million years).
3. Rhino is amusing with regard the solid union Method. Depending on Karma you can get this:
or that :
4. Leaving aside N3 .. if the real-time response goes AWOL with just 8 cones what would be the situation if you add 666 cones? This is the reason for using K to solve this ... obviously with "some" compromises yielding "vault" stuff like this:
or like that (an Alien billiard (C)(Tm)(US patent pending) for planet Zorg):
Moral: stick to the Soap_opera approach.…
achieving some preliminarily/conceptual Academic solution that "may" qualify as "realistic". I have several defs that do similar stuff ... but this is an Academic forum and as you can understand a real-life solution would never appear here.
But let's forget the W task (truss out of relaxed mesh with depth, known as W in our trade). See for instance a step prior the "thickness".
General guideline:
1. Create a boundary (a BrepFace) and attempt to do some "reasonable" Mesh via Mesh Machine.
2. Mastermind a policy to manage anchors (naked and/or clothed vertices). This appears easy but is impossible without code IF you want to do it interactively.
3. Separate naked edges from clothed ones (as we do in real-life in tensile membranes etc etc) in order to apply different goal parameters.
4. Relax the mesh (K231 engine).
5. Either work with a "geodesic" structure (W = 0) or make a truss out of the mesh in 4. In either case decide the real-life system in use (say a Mero KK or some other).
6. Check clash truss members issues and interactively vary vertices in order to resolve them.
7. Create all the required connectivity Trees (VV, VE, EV).
8. Mastermind the skin solution (only for experienced pros: avoid at any cost that one).
My advice? Unless you are very determined ... well ... what about choosing an easier design task?
…
ge curves. The source code is available as usual on GitHub, https://github.com/mcneeleurope/ShortestWalk.
Here some examples of walks on predefined and custom grids.
With equilateral grids (1, 2, 3), the shortest walk on the network is the same both counting the edge length and the number of links. With these types of grids, there are often several solutions, one of which is selected by the ShortestWalk component. If the automatic search is used (no lengths are specified), then the A* algorithm is used and this will result in a path that departs "not much" (there are more rigorous definitions) from the straight path.
With the square grid (2), the geometry is called taxicab or Manhattan, and results in the total distance being the sum between the number of vertical steps and the number of horizontal steps.
The circular grid (4, 6) shows a case in which curve distance and "link distance" (number of edges that are walked, uses Dijkstra's algorithm) results is completely different paths. This example here selects the tangential road (4) or the "city center" (6).
Finally, Voronoi diagrams (5), Delauney triangulations (7) and random mazes or labyrinths (8) can be walked, searched and solved quickly, if a solution is possible, now even if there are multiple overlapping curves.
These examples show two-dimensional grids, but it is possible to also compute (weighted) walks on three-dimensional networks.
The compiled Grasshopper assembly (.gha) and the examples can be downloaded from Food4Rhino. Join the group if you want to get updates for new releases.
- Giulio________________
giulio@mcneel.comMcNeel Europe, Barcelona…
al other things:1. the minimum and maximum spacing between points (a certain 'x' and 'y');2. the jump between two next points - let's say it is always 2. So if a minimum possible spacing is 'x' (pt.1) then the next one would be x+2, then x+4, x+6 etc. until it gets to x+n=y (the maximum);3. how many maximum/minimum points there are in a row - when a division reaches the minimum 'x' or maximum 'y distance I want it to stay there for a while (e.g. [...] x+(n-2), x+n=y, y, y, y, y, x+(n-2), x+(n-4)...) Therefore, what I want to get after dividing the base curve are curve pieces of following lenghts/points on the curve with following distances between them (for example):x, x, x, x+2, x+4, x+8 . . . x+n, y, y, y, y, y, x+n . . . x+4, x+2, x, x, x, x, x, x, x, x+2, x+4 . . . x+n, y, y, y, x+n . . . x-2, x, x, x, x, x-2 . . . and so on and on.As you can see the amounts of x's and y's in a row changes (Rule no.3).I've tried this with graphs and attractor points and got nowhere in almost 2 weeks (though I'm a beginner).. Perhaps someone here will have an idea :)I'm attaching a picture of what I have in mind (may be easier to understand than what I wrote for some people :))Cheers…