io, alle ore 19:30 presso la Mediateca MARTE di Cava de’ Tirreni (Sa), la lecture magistralis dell’arch. Walter Nicolino dal titolo “Augmented visions / Responsive spaces”, un viaggio culturale che, attraversando gli studi progettuali a diverse scale condotti tra la sede torinese e il centro ricerca di Boston, mette in luce una attitudine nell’indagare e nel dar forma alle interazioni tra le persone, gli oggetti e gli spazi, al fine di fornire possibili risposte alle nuove istanze poste dalla rivoluzione digitale.
In apertura i saluti istituzionali del sindaco Marco Galdi, mentre a introdurre la lecture l’arch. Amleto Picerno, promotore del Mediterranean FabLab di Cava de’ Tirreni e tutor della Summer School digitalMed, il laboratorio progettuale che da quattro anni a questa parte, indaga temi, pratiche e tecniche dell’attuale panorama architettonico internazionale. È la smart city al centro della IV edizione di Summer School Digitalmed 2013, che si svolge a Salerno dal 22 al 28 luglio con l’obiettivo di creare un sistema di relazioni e di interazioni continue tra la città, le persone e l’ambiente in cui queste si rapportano in un continuo scambio di informazioni.
Ad esprimere la critic ai prototipi di progetto che emergeranno dal workshop digitalMed, sarà proprio Walter Nicolino, architetto di spicco del panorama italiano, coinvolto in numerosi progetti di ricerca al Senseable City Lab del MIT di Boston, insieme all’arch. Carlo Ratti con cui è fondatore e socio dello studio torinese CARLORATTIASSOCIATI.
Il 26 luglio lo space 1.0 della Mediateca MARTE di Cava de’ Tirreni si fa, dunque, arena d’avanguardia per un interessante dibattito durante il quale, a proposito della Summer School digitalMed, si ragionerà anche sul modo in cui le tecnologie digitali influenzano l’architettura.
«Da qualche tempo a questa parte possiamo scegliere se orientarci alla perfezione tramite navigatori GPS o perderci come sognanti flâneur metropolitani; possiamo associare in un batter d'occhio infiniti layers di dati a un luogo, oppure contemplarne in silenzio il paesaggio; possiamo anticipare la realtà con sofisticate rappresentazioni virtuali, oppure esercitarci in giocose autocostruzioni partecipate.
Possiamo avere l'una e l'altra cosa: non si tratta di una scelta tra il mondo reale e quello virtuale, come predetto da parte della letteratura agli albori dell’era digitale, ma si tratta di capire come il nostro ambiente costruito e gli spazi in cui viviamo stiano imparando a parlare un nuovo linguaggio e ad interagire in modo sempre maggiore con le persone - afferma Walter Nicolino che parafrasando Le Corbusier “La civilisation digitale cherche et trouvera son expression architecturale”, sottolinea l’importanza di integrare le nuove tecnologie e radici locali senza perdere la visione e la dimensione umana della città: All’architettura è richiesta una revisione dei propri strumenti per creare spazi flessibili, inclusivi, in grado di adattarsi ai nuovi modi di vivere e lavorare e di rispondere in modo interattivo alle nostre esigenze».
…
ives that have been shared so far.
Intersect Shouldn't Punt When Encountering Areas of Intersection
Several posts talk about how Booleans are really just shortcut implementations of the Intersect/Trim/Split/Join (ITSJ) design pattern. Agreed. I realized this when trying to understand and resolve my first Boolean related problem. So when I broken down my characterization to the 4 component steps, I found is that it was the Intersect operation that was generating an erroneous (read: incomplete) set of intersection curves. I posted my findings along with a possible solution in an email to McNeel tech support and in this Rhino discussion an edited version of which I’ve quoted again below. But the only response I received from McNeel was that I shouldn't expect any changes in the product that improves Booleans.
The unexpected behavior I've been having with Rhino, and by extension Grasshopper, is that the current implementation of the Rhino Intersect command is generating an incomplete network of curves when given 2 surfaces having regions that are (almost) coincident. When Intersect determines that there's no single curve able to represent the intersection in those areas, but rather an area of intersection, Intersect erroneously doesn't generate any curve to represent that portion of the intersection — which is mathematically incorrect. This decision to "punt" in these situations renders the generated results to not be useful for subsequent steps of the ITSJ design pattern. Rather than not including these areas of intersection in the network of curves, Intersect should generate any non-kinky, non-looping curve(s) through a region of intersection that connects with all other intersection curves adjacent to the region. Any valid curve is far more useful — and mathematically correct — than no curve through these regions.
Informative and Detailed Error Reporting Will Save Users’ Time
A number of users feel as I do that the error information available when an operation fails is insufficient.
The Rhino Learning Curve Is Fractally Steep
While some responses have suggested that I’m just too new to Rhino, a number of long-time Rhino users have said that they are continually “learning” the product's idiosyncrasies, and expect that they will never really know what the product will do every time. What they’ve learned from their years of experience is how to hack their designs to work around Rhino’s quirks.
I conclude from these stories that, sure, I’m green, but that I, all of us, are destine to be forever “green” because the current development methodology results in a product that can never really be understood.
Wow.
In his reply above @Paul N Jeffies said…
One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between. That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.
As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.
The Solution Begins With Changing The Conversation
With all this said, I don’t believe that Rhino is fatally flawed or impossible to fix. I also don't believe that the resulting loss of productivity is the users' fault. I do believe though that the first step is for all, McNeel and users, to name the condition, raise this as a high priority, work collaboratively to define a corrected abstraction stack, and add appropriate rigor to the implementation of the next major release.
About a month ago I spent about 1/2 hour searching through the Rhino discussions for topics related to The Boolean Problem. I found literally 100's of posting, with many noops like I am now saying they were giving up and going to another tool because Rhino’s learning curve was too steep. Yes, filleting and trimming are two other big Rhino problems that I believe have similar roots. Yet I wonder whether these deep-seated challenges could, in fact, be overcome — by first changing the conversation.
I’d again ask what other, more experienced users think.
- Bob…
Added by neobobkrause at 2:49pm on October 4, 2016
will work slightly different from before. Sorry about breaking this, but it proved impossible to improve the selection logic with the fairly ambiguous notation that was implemented already.
Not every change is breaking though and I hope that most simple matching rules will work as before. There will be a McNeel webinar on Wednesday the 6th of November where I discuss the new selection rules (as well as path mapping syntax and relative offsets within one or more data trees). This will be a pretty hard-core webinar aimed at expert users. The event will be recorded so you can always go and watch it later. I figured I'd briefly explain the new selection rules on Ning before I release the update though.
-------------------------------------------------------------------------------
Imagine we have the following data tree, containing a bunch of textual characters:
{0;0} = [a,e,i,o,u,y] {0;1} = [ä,ë,ê,ï,î,ö,ô,õ,ü,û,ÿ,ý] {1;0} = [b,c,d,f,g,h,j,k,l,m,n,p,q,r,s,t,v,w,x,z] {1;1} = [ç,ĉ,č,ĝ,ř,š,ş,ž]
There are a total of four branches {0;0}, {0;1}, {1;0} and {1;1}. The first branch contains all the vowels that are part of the standard English alphabet. The second branch contains all non-standard vowels and branches three and four contain the standard and non-standard consonants respectively.
So what if we want to select from this tree only the standard vowels? Basically include everything in the first branch and disregard everything else. We can use the [Tree Split] component with a selection rule to achieve this:
{0;0}
This selection rule hard-codes the number zero in both tree path locations. It doesn't define an item index rule, so all items in {0;0} will be selected.
If we want all the vowels (both standard and non-standard), then we have several options:
{0;?} = select all branches that start with 0
{0;(0,1)} = select all branches that start with 0 and end in either 0 or 1
{0;(0 to 1)} = ......................................... and end in the range 0 to 1.
Conversely, selecting all standard vowels and consonants while disregarding all non-standard character can be achieved with rules as follows:
{?;0}
{(0,1);0}
{(0 to 1);0}
It is also possible to select items from each branch in addition to limiting the selection to specific branches. In this case another rule stated in square brackets needs to be appended:
{0;?}[0 to 2]
The above rule will select the first three vowels from the standard and the non-standard lists.
Basically, rules work in a very consistent way, but there are some syntax conventions you need to know. The first thing to realize is that every individual piece of data in a data-tree can be uniquely and unambiguously identified by a collection of integers. One integer describes its index within the branch and the others are used to identify the branch within the tree. As a result a rule for selection items always looks the same:
{A;B;C;...;Z}[i] where A, B, C, Z and i represent rules.
It's very similar to the Path Mapper syntax except it uses square brackets instead of parenthesis for the index (the Path Mapper will follow suit soon, but that won't be a breaking change). You always have to define the path selector rule in between curly brackets. You can supply any number of rules as long as you separate them with semi-colons.
The index rule is optional, but -when provided- it has to be encased in square brackets after the path selection rule(s).
The following rule notations are allowed:
* Any number of integers in a path
? Any single integer
6 Any specific integer
!6 Anything except a specific integer
(2,6,7) Any one of the specific integers in this group.
!(2,6,7) Anything except one of the integers in this group.
(2 to 20) Any integer in this range (including both 2 and 20).
!(2 to 20) Any integer outside this range.
(0,2,...) Any integer part of this infinite sequence. Sequences have to be at least two integers long, and every subsequent integer has to be bigger than the previous one (sorry, that may be a temporary limitation, don't know yet).
(0,2,...,48) Any integer part of this finite sequence. You can optionally provide a single sequence limit after the three dots.
!(3,5,...) Any integer not part of this infinite sequence. The sequence doesn't extend to the left, only towards the right. So this rule would select the numbers 0, 1, 2, 4, 6, 8, 10, 12 and all remaining even numbers.
!(7,10,21,...,425) Any integer not part of this finite sequence.
Furthermore, it is possible to combine two or more rules using the boolean and/or operators. If you want to select the first five items in every list of a datatree and also the items 7, 12 and 42, then the selection rule would look as follows:
{*}[(0 to 4) or (6,11,41)]
The asterisk allows you to include all branches, no matter what their paths looks like.
It is at present not possible to use the parenthesis to define rule precedence, rules are always evaluated from left to right. It is at present also not possible to use negative integers to identify items from the end of a list.
If you want to know more, join the Webinar on Wednesday!
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 8:57pm on November 3, 2013
t in a number of curves, offset them and then make a union of those. This should give me the curve on which the center of the next particle that collides with the cluster lays.
[See attached picture]
Here's my problem. At first I got an awfull lot of error messages due to my inexperience with coding in VB and/or GH. After alle those were taken care of I have two scripts that do the job. I want to be able to do it in one script but I can't get the array of curves into the Curve.CreateBooleanUnion(x). If I set thoses curves as output and as input [hint: curves] in the next VB script, then Curve.CreateBooleanUnion(x) does work.
I guess I'm doing something terribly wrong in stating my variables, but I have no clue how to solve this.
Thanks for taking the time to look at my problem.
Reinier
Script 'offset'
Private Sub RunScript(ByVal x As Curve, ByRef A As Object) Dim z As array z = x.Offset(plane.WorldXY, 0.5, 1, 2) A = z(0)End Sub
Script 'union'
Private Sub RunScript(ByVal x As List(Of Curve), ByRef A As Object)A = Curve.CreateBooleanUnion(x)End Sub…
tween groups of the points - to form a triangular grid, i.e. using paneling tools : Panel Connections (PTMPanel). Which provides a data tree I am happy with, especially for use further down the line.
Making a list for some of the panels to be measuresd and compared externally (to export data to an excel document from them). I have exploded a number of the polylines to get a perimeter around an area of panels for further analysis; Meaning I have bored down into the tree structure further to single items within the panels and groups, and want to get back out... with the branch and tree structure still intact? Or re attach it so I can label and sort items in line with parent tree structure.
Question:
Can I map the exploded items back into the parent structure without writing a script? and by using the Path Mapper - or could it be that I need to use Replace Branches..? (If so what are the scripts to use with these to get the results I am after?)
I thought this might be a useful post - As I might get a neat solution and in searching for solutions to this. I brought up some pretty ambiguous discussions, that seem to me, to skirt round the subject.
If I am approaching this in the right way : I am looking to get the result {B;i} from {A;B;C;D} (i). To use the result as both a Tag for the drawings and as the data structure for export to excel - that is in data that links the two columns.
The paths are where 'B' = panel number and 'i' its exploded component line - which will result in an item number of either, 0,1 or 2 attached to the parent panel number.
NB/ The tree structure i have used from Dispatching, leaves groups of four items, (I see this coming from the paneling tools component) which might need to be in a straight integer series list, instead - as with flattened parent panels.
This is where I have got stuck this time but have attempted many various other methods to no avail.
Hope this unveils a tricky area for those, like me that are more visual than scripting programmers in GH.
…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
hole. Currently I control it through PREVIEW, in component Solid Geometry or Solid DiferencedIn practice, the procedure of generating this whole is not needed, if the number of wholes = 0, or Yes/No (appeared or no) Question: How to use Boolean Toggle (optionaly):
1 to control the component PREVIEW state (On/Off)2 better for me- to start or stop the procedure to create whole (whole = 0,false - no whole needed)Hope you will hlep.
regardsSlawek…
C# only).
We've switched UI toolkits from winforms to Eto (which has much better cross platform support) so GH2 will run on both Mac and Windows. The developer of Eto now works part-time at McNeel so I'm pretty confident any problems that come up can be solved the proper way.
We're working on complete documentation. Glossaries, explanations of core-concepts, example files for all components, etc. etc. All fully editable and extensible by third party content providers, be they plugin developers, teachers, translators, or whatever.
This time around I'm designing the SDK with multi-threading in mind, so a lot of types have become immutable. I'm also adding multi-threading wherever it makes sense in the core classes.
This time around I'm adhering to .NET guidelines for the SDK.
There will also be much deeper and better support for data trees (they were introduced only halfway through GH1 development). The same goes for data conversion.
There is support for user data on each and every data type. So you can assign custom data to curves, numbers, breps, whatever and it will piggy back along as that data flows through the network. This user data will also serve as the basis for custom settings. For example you could assign the user data "BakeLayer = Building A" to some geometry and when that geometry gets baked, GH will figure out in what layer it is supposed to end up. Or you can assign "DisplayColor = Orange" and that geometry will appear orange in the viewports.
Expressions have been extended to be any chunk of VB or C# code (support for python will probably be added at some point). They can be far more intricate (but they don't have to be) and they will be run as compiled code, rather than interpreted code. Expressions also have ways to access data that is defined elsewhere in the document. So if there's a slider somewhere called "Thickness" then an expression in a number input parameter could look like "Min(x * 2, Thickness)".
--------------------------------------------------------------------------------------------
I am doing or have done the above. I'm hoping to get around to the items below.
--------------------------------------------------------------------------------------------
The interface will be simplified. I'm planning to remove a lot of options and settings and replace them with smarter code. If that ultimately fails options and settings can always be brought back.
There will be a lot more zoom aware UI, so if you want details about some component or parameter, you'll no longer have to dig through a gazillion menu items, you just zoom in on that object.
There will be better tools to document, debug and manage large files. This is a huge area of R&D but it is one of the major weaknesses of GH1 in my opinion.
Solutions will be multi-threaded, and hopefully also run in the background.
As part of a general effort within McNeel, I'm hopeful there will be a reliable way to explore, install, and uninstall plugins for Grasshopper directly from the Grasshopper interface. No need to go to some webpage, no need to register, no need to log in, no need to enter captchas or having a new password emailed to you because you can't remember the old one. It's ridiculous how difficult this appears to be in 2015, but we now have someone at McNeel who's really good at this stuff and I'm pretty confident they'll make it awesome.
There'll be a lot more types of data to work with (sub-d geometry, extrusions, polylines, spheres, graphs, bitmaps, better support for fields, ...). The aim here is both to reduce memory overhead by providing light-weight types and to provide more functionality.
There will be more ways to organise and display data, both on the canvas and in the viewports. Better bar graphs, better pie charts, better and more everything.
The default preview materials will be grey and yellow, not red and green.
--------------------------------------------------------------------------------------------
As you can see there's a lot of work to be done, for sure the first alpha release will be as soon as possible, but I've been focusing on core classes only so far. There's no working prototype, there's no working UI, there's no document class yet that actually runs solutions. We're a long way from the first alpha.
Right now I'm mostly acquainting myself with Eto (YouTube video if you want to know what that means) and I'm working on data type conversions and preview materials.
--------------------------------------------------------------------------------------------…
to explain the ultimate goal in case it helps to clarify. I have all the elements i need now to pull this together thanks to your help, as you say most critical things are already implemented or not relevant to this particular thread. With your fret generator and equal spacing generator and my primitive convoluted solution for compound radius fretboard i have everything i need but need some time to cleanly implement and pull it together now.
as to your questions/coments:
1/ I don't care about Excel files in this context. The SIMPLE solution is to just copy/paste sets of string gauges into as many panels as you need and switch between them.
this was just to explain that ultimately there are a lot of different input patterns but all the data for them does already exist. for sure it is not necessary but in the end it's a feature i would like to implement since it will make the patch much more practical.
2/ What are "scale length low E string" and "scale length high e string"? Are they the actual string lengths of the bass and treble strings?
This is the initial decision taken by the luthier: which scale lengths to use for the multiscale build. While anything that makes sense goes here luthiers will probably want to choose some common values, say 24.75" (like most Gibson guitars) or 25.5" (like a Fender Stratocaster)
P.S. I did the rotations at the points where the treble string intersects the virtual bridge and nut (blue lines), so rotation has no effect on its length.
P.P.S. In case it isn't obvious, rotation has no effect on string spacing either.
This is the kind of things i don't know cause i'm zero in maths and i usually have to try out and measure to know for sure :-) as i said my initial instinct would have been to rotate around the 'zero frets' center point simply because everything is built aroun d the X axis. If you rotate around the treble string (the high e string) would the distance of the upper fretboard edge to the x-axis be the same than from the lower fretboard edge to the x-axis ?
for running data through panels, thanks for the tip, i do this mainly to visualize the values without having to hover over the outputs, good to know i shouldn't patch them onward from the panel.
PS: For the height of the strings above the fretboard (the 'action'), it's not as complicated as it sounds and most of the time an experienced luthier or guitar tech will have no problem achieving whatever low action desired if the neck is straight and built properly and the frets level and dressed properly. there's a german company who's built a machine to do the 'perfect setup': the PLEK machine
i'm sorry it takes me much longer to digest and implement all this, i will post back when i've merged everything together but i think i have evrything so far
…
or a couple of thingies.
Pattern.gh
I defined parametrically a triangle which I then smoothed out to become more like a blob shape. After that I created a pretty simple pattern that I had in my mind (costed me a lot of time to make this in GH) and finally wanted to rotate each element as it goes higher . The dispatching part seems to be working pretty slow, so it might need an optimization, but I’m still happy with the result as it shows exactly what I wanted, so this is a minor issue in my case.
I then decided to try tessellating my extrusions. You’ll see the voronoi script which is a blob-group in the same Pattern.gh:
I had an idea of something and started the code from scratch, then decided to watch tutorials and implement the code shown there. I somehow coped to combine my code with this in the tutorials, but since my knowledge of Grasshopper is zero to basic my code seems to be very unoptimized and lagging.. When dragging the sliders, it takes a lot of time to compute the changes, although, I’m working on a 24gigs 6th gen i7 machine. It might also need optimization.
Here comes the first tricky part that I couldn’t sort out in an elegant way neither in Grasshopper nor in Rhino. I want a smooth transition between the wall and the ceiling, so that the voronoi tessellation doesn’t get interrupted. If I was to do it in Rhino I’d make a curve with a filleted edge which I’d then revolve/sweep along a rail.
Pattern.gh:
Second thing is – I’ve defined a shape which I want to rotate at a certain degree as it goes higher, however, I don’t have the knowledge to make this happen automatically and just copy the script over and over again. Is there a chance to somehow “loop” the code and parametrically define the degree of rotation and amount of units in the loop?
Next thing is I want to somehow be able to rotate each “6-storey-building” dependently on its surrounding buildings, so that their “terraces” never overlap. I’m using quotes, since they’re still some silly shapes that have nothing to do with buildings and terraces. The principle has to be something like gear wheels or the so-called rack wheels . There has to be some pace which I could set parametrically, but I’m still unsure how to do that in Grasshopper.
The pre-last thing is that I want to control the height of each “building” based on let’s say a topography. I presume this could be done somehow with height maps or some gradient mapper connected to curvature analysis. Not really sure how something like this would work, but I’ve seen such codes that control height depending on a variable.
The last one is more or less similar to the previous. I want to be able to “dissolve” the pattern that I initially created and make it irregular. I suppose this could be done with attractor curve, but again this is just a guess. Please note that this is a top view and the shapes on the upper-left corner have got more "wings" which means there is more floors in the according building. Let's say the buildings in the upper-left corner are 6-7 floors high, in the middle are 4-5 and to the right they're only 3 floors high.
Sorry for that many questions in a single thread. Please let me know if I have to split them in separate threads. All this information is needed for learning purposes. I’m now preparing myself for my bachelor thesis and try as much things as I could, so that I’ll be ready for the final stage of my bachelor’s degree.
Many thanks in advance! Cheers!…