ist gives a very good description of how the mesh isreconstructed, as shown below, from 0 subdivisions through to 3.
My question is, would anyone know how to create a script to sort these into loops of faces, so that, for instance, the sequence 0,1,4,5,16,17,20,21 could be sorted into an ascending item number of 0 through to 7, and so on and so forth for the rest of the rows or columns in the mesh?
…
eries of ramps with slopes =< 10%.
Here's my pseudo-code:
1. Populate brep with random points
2. Sort points by Z values
3. Draw line from point '0' of sorted points to all other sorted points
4. Project lines down to plane of first point and cull all lines =< 5.7 degrees (10% slope)
5. Sort remaining lines by length and return line with the largest length (what I want)
6. Cull all points used to create lines =< 5.7 (step 4)
7. ??? now, I want to somehow pass remaining points from step 6 back into the loop and return the next curve that is: the largest length curve from all curves =< 5.7 degrees
I've attached the script
Thanks ya'll!
…
of Space, 1984) and specified in (Turner A. , “Depthmap: A Program to Perform Visibility Graph Analysis, 2007), intuitively describe the difficulty of getting to other spaces from a certain space. In other words, the higher the entropy value, the more difficult it is to reach other spaces from that space and vice-versa. We compute the spatial entropy of the node as using the point depth set:
(11)
“The term is the maximum depth from vertex and is the frequency of point depth *d* from the vertex” (ibid). Technically, we compute it using the function below, which itself uses some outputs and by-products from previous calculations:
Algorithm 4: Entropy Computation
Given the graph (adjacency lists), Depths as List of List of integer, DepthMap as Dictionary of integer
Initialize Entropies as List(double)
For node as integer in range [0, |V|)
integer How_Many_of_D=0
double S_node=0
For depth as integer in range [1, Depths[node].Max()]
How_Many_of_D=DepthMap.Branch[(node,depth)].Count
double frequency= How_Many_of_D/|V|
S_node = S_node - frequency * Math.Log(frequency, 2)
Next
Entropies [node] = S_node
Next
…
tura significa confrontarsi con l’architettura ‘free-form’, in cui indagare liberamente la generazione di forme, a prescindere da ogni principio compositivo, statico o costruttivo.Il workshop di costruzione è un momento di sperimentazione didattica sulle strutture resistenti per forma, un'occasione per confrontarsi con problemi costruttivi reali, per superare la dicotomia tra progetto e realizzazione, forma e struttura.
Lecture >> 26/04 >> info qui
Dialogo tra architetture organiche nel segno della sostenibilità: il panorama italiano contemporaneo a confronto.
Laboratorio di progettazione >> 27-29 aprile >> + Laboratorio di costruzione >> 4-6 maggio >> info qui …
ing on a project that has been left alone for a few months, when I couldn't get it just right and I'm finding myself thoroughly stumped. It was originally manually built in Rhino (see steps below) but I was hoping I could use GH to create better surfaces.
So, what I'm basically asking is if I can build this well using GH, and what approach I should use. It's basically a "c" shape, with a twisted octagonal surface of a varying diameter, but the files are attached.
I built this in Rhino using the following steps:
Drew my two outline curves, used tween curves to create a central line
Arrayed points at equal distances along the central curve, and drew perpendicular lines from these points to the outline curves
Created polygons (8 sided) using the line end points and added curve fillets
Manually rotated each polygon, by +15 degrees each time
Drew 2 edit point curves using opposite points on each polygon, connecting them all in a similar was to lofting
Used Sweep2, with the two twisted curves as the rails, and polygons as the cross sections
Extract isocurves, tweak, rebuild, use end polygon, split by isocurves, to sweep between each set of two isocurves
Tweak, rebuild, tweak, rebuild etc
My issue is that the surfaces this have produced can be a little tight/warped/loose/twisted/generally bad... And I was hoping someone on here could give me a little insight on how you'd approach this problem in GH. I know this is long, and rambling, but it someone could just point me in the right direction I'd be so grateful. I don't need a step-by-step, as I think it'd actually be good for me to figure it out by myself.
Thanks for taking the time to read all this! And any help is so appreciated!…
st variety of papers (mostly related with LIDAR airborne sampled clouds) ... but ... hmm ... no code (other than some "abstract" algos that may (or may not) work). Reason? A very hot cake that one these days: from reverse engineering to DARPA founded future defense systems and up to cruse missiles pattern recognition algos.
The solution (obviously doable only via code) is the so called flat hard clustering ... were points are sampled into clusters based on the coPlanarity "rule". For large amounts recursive octTrees (an oriented box divided in 8 "partitions") subdivisions are used and then pts are processed in parallel (and then clusters are re-evaluated in order to "absorb" other clusters with same plane A,B,C,D vars etc etc).
See what's happening in a very carefully made test point collection:
3.7 ms and the "ideal" clustering (7 search loops VS the max 42M theoretical threshold):
Depending on the pts "preparation" ... a considerable more time/search loops is required ... and ... well ... also "valid" clusters (4 points and up) made:
So "ideally" speaking in your case:
1. Mesh faces center points (or alternatively: mesh vertices) are sampled into a pts collection .
2. Hard flat coPlanarity clustering is attempted yielding pts/planes in equivalent DataTrees.
3. Planar Breps are made with respect the planes (like the black things captured above) and sampled, say, into a breps List.
4. The method Brep[] solids = Brep.CreateSolid(breps); is used for attempting to create your desired "engulfing" brep. This method is very slow mind (other waaaay faster approaches also available).
…
l the changes you want and then close it again, you'll only have to recalculate once, whereas adding 3 inputs via the ZUI would recalculate 3 times right away and once more after you've changed the cluster to hook up the new inputs.
Does the cluster recalculate the entire solution, even though the new input hooks aren't connected to anything? Would it be possible to not recompute (not call ExpireSolution or its equivalent?) when an input parameter is added via the ZUI only? Could this be done by adding a flag on each input hook added by the ZUI, triggering the flag when the input hook is connected to a parameter, and recalculating the cluster only when the flag has been triggered?
Also, the current behavior, I think, is actually different. In order to work with the cluster, you need to see the geometry/data you're working with, so you have to enter the cluster, add the hooks, leave the cluster, connect the hooks to parameters, enter the cluster, play around in Grasshopper, exit the cluster:
Double click cluster.
Navigate to where you want to add new hooks.
Add hook (either from the toolbars, or by copy/pasting existing ones, or by double click search)
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)
Connect new inputs with relevant parameters in the parent document.
Double click cluster.
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete. (input * ICSOLUTION)
Repeat 7 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)
Which comes to: 2 extra-cluster solutions, and N intra-cluster solutions, where N is the number of new inputs. The cluster was opened and closed twice.
Zoom in on cluster.
Click on the (+) symbols to add inputs. Each input added via the ZUI doesn't recompute, since we know that the input hooks created this way aren't connected.
Connect new inputs with relevant parameters in the parent document. Also no new solutions.
Double click cluster.
Navigate to where the new input hooks were created (Perhaps aligned vertically, below the last-most input hook?)
Probably move the hook to a more meaningful location.
Connect hook to relevant parameter. This will cause a new intra-cluster solution which may take some time to complete. (input * ICSOLUTION)
Repeat 7 until satisfied.
Close and Save Cluster. This will cause a new extra-cluster solution which may take some time to complete. (1 ECSOLUTION)
Which comes to: 1 extra-cluster solutions, and N intra-cluster solutions, where N is the number of new inputs. PLUS, you only had to enter/exit the cluster once.
Thanks again, David!
Dan…
Added by Dan Taeyoung at 8:47am on January 11, 2014
a modélisation paramétrique avec Grasshopper pour Rhinoceros3D ainsi que démontrer plusieurs façons de l’appliquer à votre travail architectural.
Cette formation est conçue comme une expérience augmentée autour de l’architecture paramétrique et elle comprend aussi :
+ Une introduction au design paramétrique par Francesco Cingolani+ Une étude de cas d’un projet de l’agence de l’agence HDA Hugh Dutton Associés+ Acces gratuit 3 journées à l’espace de coworking SUPERBELLEVILLE
INSTRUCTEURS
FRANCESCO CINGOLANI . designer, enseignant en architecture paramétrique, co-fondateur deSUPERBELLEVILLE coworking, collaborateur de l’agence Hugh Dutton Associés. – voir le profil Linked-in
ŞULE ERTÜRK . Architecte diplômée de l’Université Yildiz Teknik à Istanbul, Master en architecture paramétrique, travaille actuellement aux Ateliers Jean Nouvel dans le département 3D. - voir le profil Linked-in
QUENTIN GAUCHER . Architecte DE-HMONP, diplômé de l’ENSA Paris La Villette, intervenant en architecture paramétrique sur divers projets - voir le profil Linked-in
DATES 25 mars 2013 . Annonce de la formation / Début des inscriptions5 avril 2013 . Fin des inscriptions13 – 14 avril 2013 . Formation
HORAIRES Samedi et Dimanche 13 et 14 avril . 10:00 > 13:00 – 14:00 > 19:00Total : 16 heures
TARIF700 € professionnels400 € étudiants
RÈGLEMENT50% est à régler lors de l’inscription (au plus tard le 5 avril)50% au début de la formation.Les règlements s’effectuent par carte bancaire via Paypal ou par virement bancaire.
NOMBRE DE PARTICIPANTSMinimum pour l’activation de la formation : 5Maximum : 7
CONTACTInscriptions et réglements : fr.cingolani@gmail.com . SUPERBELLEVILLE coworkingInformations : quentin.gaucher@gmail.comimmaginoteca.com/grasshopper
EN BONUSLe café italien et les plats faits maison de Claudia offerts aux participants :)…
o: http://github.com/HeinzBenjamin/FlexCLI/issues
Download
You can find FlexHopper here:
http://www.food4rhino.com/app/flexhopper
and here:
https://github.com/HeinzBenjamin/FlexCLI
Info
FlexHopper offers physics computation in Grasshopper. It is GPU-based and therefor very fast. Currently supported modes of simulation are: free particles, fluids, rigid bodies, soft bodies, tensile structures and cloth, custom constraints.
FlexHopper is a Grasshopper plugin built on top of FlexCLI - Flex Common Language Interface. FlexCLI is built against NVidia Flex release 1.1.0. NVidia Flex is patented property of NVidia. FlexCLI and FlexHopper are openly accessible under the GNU License through my Github account. (Link above)
For more information on NVidia Flex go here: https://developer.nvidia.com/flex and https://developer.nvidia.com/nvidia-flex-110-released
FlexCLI runs on x64 architectures only. It was built against .Net 4.5.2
FlexHopper was tested with Rhino5 64bit and Grasshopper 0.9.0076 WIP
Requirements
Windows 7, 8, 8.1 or 10 64bit
NVidia or AMD Graphics Card
NVIDIA: GeForce Game Ready Driver 372.90 or above
AMD: Radeon Software Version 16.9.1 or above…
ay how many valid permutations exist.
But allow me to guesstimate a number for 20 components (no more, no less). Here are my starting assumptions:
Let's say the average input and output parameter count of any component is 2. So we have 20 components, each with 2 inputs and 2 outputs.
There are roughly 35 types of parameter, so the odds of connecting two parameters at random that have the same type are roughly 3%. However there are many conversions defined and often you want a parameter of type A to seed a parameter of type B. So let's say that 10% of random connections are in fact valid. (This assumption ignores the obvious fact that certain parameters (number, point, vector) are far more common than others, so the odds of connecting identical types are actually much higher than 3%)
Now even when data can be shared between two parameters, that doesn't mean that hooking them up will result in a valid operation (let's ignore for the time being that the far majority of combinations that are valid are also bullshit). So let's say that even when we manage to pick two parameters that can communicate, the odds of us ending up with a valid component combo are still only 1 in 2.
We will limit ourselves to only single connections between parameters. At no point will a single parameter seed more than one recipient and at no point will any parameter have more than one source. We do allow for parameters which do not share or receive data.
So let's start by creating the total number of permutations that are possible simply by positioning all 20 components from left to right. This is important because we're not allowed to make wires go from right to left. The left most component can be any one of 20. So we have 20 possible permutations for the first one. Then for each of those we have 19 options to fill the second-left-most slot. 20×19×18×17×...×3×2×1 = 20! ~2.5×1018.
We can now start drawing wires from the output of component #1 to the inputs of any of the other components. We can choose to share no outputs, output #1, output #2 or both with any of the downstream components (19 of them, with two inputs each). That's 2×(19×2) + (19×2)×(19×2-1) ~ 1500 possible connections we can make for the outputs of the first component. The second component is very similar, but it only has 18 possible targets and some of the inputs will already have been used. So now we have 2×(18×2-1) + (18×2-1)×(18×2-1) ~1300. If we very roughly (not to mention very incorrectly, but I'm too tired to do the math properly) extrapolate to the other 18 components where the number of possible connections decreases in a similar fashion thoughout, we end up with a total number of 1500×1300×1140×1007×891×789×697×...×83×51×24×1 which is roughly 6.5×1050. However note that only 10% of these wires connect compatible parameters and only 50% of those will connect compatible components. So the number of valid connections we can make is roughly 3×1049.
All we have to do now is multiply the total number of valid connection per permutation with the total number of possible permutations; 20! × 3×1049 which comes to 7×1067 or 72 unvigintillion as Wolfram|Alpha tells me.
Impressive as these numbers sound, remember that by far the most of these permutations result in utter nonsense. Nonsense that produces a result, but not a meaningful one.
EDIT: This computation is way off, see this response for an improved estimate.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:06pm on March 15, 2013