es of the mesh faces as points. Is the component HingePoints reordering the points in any particular manner, i.e. point 1 and point 2 being the opposite corners of the quad faces?
1. Solution exception:Cannot marshal 'parameter #5': Invalid managed/unmanaged type combination (Arrays can only be marshaled as LPArray, ByValArray, or SafeArray).
I have attached the script and a couple of snapshots showing the red component inside the origami cluster.
Aside from this error, I had also noticed that the two last addition components which provide the RestAngle and Strength Values to the Kangaroo Physics component were loosing the '0' value entered as 'A' (they were getting Null instead). I have replaced the manual entry with a panel entry. However, I still cannot get the Kangaroo Physics component to run the simulation (or the forces might be somehow equal to the initial ones, and hence not getting the system to move in any way).
I am out of ideas as to why this might be happening. I had worked with Kangaroo before and really liked it. This origami component is really promising and I would really like to get it to work on my machine.
The grasshopper version I am using is: 0.9.064. Kangaroo is 00.096.
I would be very grateful if you could have a look into it and let me know your thoughts.
Thanks for your help!
Best
Maria
…
.
If the above are correct then I am afraid there is no solid answer, data matching (how to modify 2 groups of data so that they work together) can be done in many ways and no one is suitable for every case.
For example in the [move] component in your definition you have the G input receiving 27 lists with 54 lines each (1458 lines) and you want to move these lines in Z direction. Depending on how you want to move them it could make sense to have T input receiving:
a. One vector (this would move all the lines by this vector)
b. 54 vectors (this would move the first line of each list by the first vector, the second line of each list by the second vector, ...... , the last line of each list by the last vector)
c. 27 vectors grafted so that the paths match (this would move the first list of lines by the first vector, the second list of lines by the second vector, ...... , the last list of lines by the last vector)
d. 27 lists with 54 vectors each (1458 vectors). This way each line will move by the corresponding vector.
So, as you can see there is not a global solution.
In order to be able to decide how to format your data you must always be aware of what your existing data structure means. For example, in the above case, you have your lines in the format {A;B;}N. Now A has 6 values (0 to 5) which is the number of your original surfaces. B has various values because it is the number of edges that each surface had(deconstruct Brep component). Finally N (the number of items in each list) is 54 because you offseted each edge 54 times (offset component).
So in order to decide which of the above cases suits you best you must have these things in mind.
In general some useful components for data matching are: [tree statistics] [list length] [repeat data] [graft] [simplify] and [flatten] and of course many more, depending on the case...
But in order to use these properly you must first study about data trees and how they work.....
Hope this helped a bit and please post back if you need some help into a specific part of your definition.…
try to get the output. In this case the output needs to be set before requesting for it. I am doing it with this call:
ret = gsaobj.Output_Init_Arr(1,"Global","A1",14003001,3)
In API help the call is documented like this:
short Output_Init_Arr (long iFlags, string sAxis, string sCase, enum ResHeader header, long num1dpos)
so this call has 5 arguments (long, string, string, long, long) (the enums are defined as longs)
This call works, because when I print the ret, i get 0 that is "succeded" so everything works so far.
Then I request the output with the following:
results = []
ret = gsaobj.Output_Extract_Arr(10,results,numcomponents)
In API help the call is documented like this:
short Output_Extract_Arr(long iRef, SAFEARRAY(struct GsaResults)*arrayResults, long* numComponents)
I am getting the error "
Runtime error (ArgumentException): Could not convert argument 1 for call to Output_Extract_Arr."
So it seems that is not accepting 10 as a long in the beginning (assuming that argument 1 is the first). I already tried passing a variable as long, using long(10) there, nothing works.
Furthermore I don't know if the other two variables are correct like that. I come from VBA where I need to declare everything but AFAIK python is more permissive in this sense. "results" should be a dynamic array of objects and "numcomponents" a long.
Any help would be appreciated!
Thanks! :)
…
y interesting and smart way to construct surface. I tried some experiments out using a similar idea - take a developable surface which has a series of holes cut through it now offset that surface and unroll both of them, once both have been cut out insert a dowel into the holes (the dowel represents the offset distance). In the end the shape is recreated via tension and in that way there are some similarities. With your concept the thing I have trouble figuring out is how do you cut the variable angle kerfs. Are you using a 5-axis swarf cut, a cnc panel saw - how do you control this? It would be great to have a set of constraints which limit the number of possible angled cuts - these limits would equal the number of v-groove bits you have in the cnc - and then you could just cut the lines with the programmed tool which matches the given angle. Or maybe I am completely wrong, now I think I am wrong, about the execution and you are only changing the gap between each kerf and the angle of the side wall stays constant.
Anyway to answer your question catia can analyze the characteristics of a piece of formed material (this analysis is usually applied to sheet metal and to design forming tools)it's just a matter or defining the material to match that which you are using. Another possibility although not as numerically clear is using a simulation tool like Maya cloth or Virtools. I know this maybe less likely but you can define all sorts of materials in Maya and then simulate their behavior under numerous forces and constraints. I think it would work it's just how do you extrapolate the values Maya needs and then correlate them back into the cloth parameters. Once it yields the final formed mesh then further analysis could be performed in cosmos, ansys, or catia.
I have one other suggestion. In solidworks if you perform a lofted bend on a sheet metal part and then generate a flat pattern it creates a large set of bend lines representing how to perform the bending of an unusual shape using a metal brake. It seems like those bend lines could be machined with you technique to create lofted forms instead of extrusions.
What materials seem to work best so far, have you only been using wood (the purple stuff is probably not wood)?
If you are ever in Los Angeles I have a shop with a 3 axis and 5 axis router, a large vacuum bag, and all the other things to experiment on this and would be open to this.…
Amuse yourself by trying to figure what kind of series logic could deploy (or not) these room unit combos across the blue space grid shown.
2. Let's assume that surgery etc etc departments are sited in some ground floor and their requirement for rooms is variable ... meaning that some kind of heuristic GH approach must be applied here (for instance : fill the first level with rooms required by all departments with min distance from a given core and if more are required go to next floor etc etc).
The real room unit cluster looks like that (all units are prefab)
3. Voids in the whole cluster deployment (avoid Soviet type of bloc aesthetics) mean that culling could be challenge here (we need ...er..."visual" culling , so to speak)
4. After finishing some solution create custom preview(s) in order to visualize what dept owns what rooms.
5. If in trouble with Architectural things > relax > be cool > open 3d PDF > be a great Architect in just 10 easy steps.
PS: of course I know GH clusters...but as they are they violate my rule N1: never walk the walk if no return is possible, he he. But assuming that David could resolve the return issue (sure he can) this is NOT the answer for my "proposal" for multiple Canvas - again like multiple Views in any CAD stuff these days. Just imagine clusters with some serious hierarchy depth > where am I ? what input comes from what output?
I'll be back with a chaotic case (Series in complete anarchy) in order to demonstrate the critical necessity for a visual Tree Manager/Viewer (a visual thing within the GH visual thing). For manager read : decomposer, composer, visual identifier (per data item/branch) tree re-mapper, anything actually.
more soon (and a in depth analysis about what a Tree Manager/Viewer should do - in an ideal world, that is)
Cheers, Peter
…
which needs to go in the first line only.
Each value K is one element of the knot vector
XYZ is an individual control point. Each point gets its own line/string in the output list
R is the weight of the XYZ point defined in the same line
I can get all these data into separate lists easily enough using the buttons etc. But getting them into the proper order and moving stepwise down the data to generate the desired output string list is eluding me so far.
My thought is to make an array of columns.
Column one is a list of knot values.
Column two is a list of X values.
Column 3 = list of Y values
Column 4=z values
Column 5 is weight values
etc
The idea would be to read the first value in each list into a list of five elements, then make a string out of it. The second value of each column into a separate string on the next line, then the third value from each column into the third string in the output list and so on.The last few values in the output list will contain knot vector elements only, as there are more of these than there are control points. Some of these curves are very long, with many control points, like hundreds and hundreds.
It seems I should be able to pull the lists of interest and combine them into a tree somehow; so far all I have been able to manage is to get them into a single list by starting with control points, then weaving each list of interest successively into the growing list. I'm thinking I need to get the list for each parameter into an individual branch, then read a path across the branches at each index value. But I am missing something about the terminology. I have watched a few videos and it makes sense when people are pulling nested geometry out of models, but this is a little different. More of a data management issue. I'm sure if I wrestle with it I will get it, but it may not be pretty. Any pointers appreciated. A couple of approaches are attached. Not sure whether to loop a list subset through the data or do something else. Thanks,
Karl in LA…
e in Euclidean space then the distance metric can be discontinuous:
Discontinuous means that a tiny change in input may result in a large change in output. Observe the image above, we start measuring euclidean distances from point A. At first the process appears to be continuous. We measure at distance b and we get point B. We increase the distance slightly to c and we get point C, which is very close to point B. We increase the distance slightly again to d, but now suddenly we're in a completely different location. This jumping behaviour can mean that certain questions (such as: "how do I divide this curve into 4 points, all equally far apart?") do not have an answer. It could be possible for 3 and 5, but not 4.
Another problem is that there may be multiple solutions. In the image above the point D isn't the only point that is d units away from A and coincident with the curve. There may be any number of those points depending on the shape of the curve, the location of A and the value of d. And of course once you have two (or more) solutions, you can have two (or more) answers. Then each of those solutions may yet again have more than one outcome for the next point in the chain and before you know it the question you asked has 35295 different answers and good luck trying to find one you like.
Now of course sometimes it is possible to answer your question unambiguously. I made a solution that uses Galapagos. It's pretty slow, and it'll get slower the more segments you want:
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:26am on September 9, 2013
rid that works on the left and/or right edge of the components, so that it's easier to align them (similarly to the align functions that show up when multiple objects are selected)
Overall, I think we'd just need a basic grid for alignment, so whatever is easy/quick to implement might be good enough.
4) great, I didn't know about aliases - that pretty much answers my question.
Related to this, when I press F4 and search for a component, if the mouse/pen pointer is above the list, when I press enter Grasshopper will insert the component under the pointer, and not the one I have found with the keyboard. Am I missing something? In case could it be fixed?
As a side note, at the moment the keyboard focus is always on the Rhino Command Line. Would it be possible to optionally change the focus when the Grasshopper window is active so that we can insert new components just by typing, without pressing F4 or doubleclicking? I just find myself constantly using the keyboard to insert components, so that'd be a very nice timesaving.
5) Your idea would be great to manage complex panels and I think would be very nice to have.
However I was thinking of a different workflow, that could be useful - for instance - when working with several objects in Rhino that are referenced in Grasshopper as basis to create more complex objects.
For example: I have three different surfaces that are used to create framed grille elements. It would make sense to select these surfaces in Rhino and access to a panel that shows the element properties (for example frame dimensions, type of grille, etc.) - similarly to the property panel in Rhino.
Additionally, If I need to create a new grille element from another Rhino surface, I could just duplicate the RPC component along with the definition without the need of manually publishing all the parameters to a new RPC group. I hope this makes sense.
I understand this may not be an "urgent" feature, however I find that working with RPCs is very pleasant so I'd really like to see this feature expanded in some way :-)
6) Just perfect :-)
Thanks again David!
Marco
…
r planet Utopia?
2. In what sort of animal these "shaders" are to be used? Meaning that designing a "Viz" control for 2345,67 mini-membranes is one thing and doing it for your house is a totally different challenge. In plain English: it's more than possible to hit the Wall if lot's and lot's of items are invited to the party (you bring the girls and I'll provide the Vodka).
3. Do you like the idea of completely separating (on a spatial basis) input/viz control (what is on display and on what level of "detail") from the core logic (i.e. components). Pros: obvious, Cons: obvious.
4. Is this def planned as a "constant" evolution thing? Meaning that using, say, the mapper isn't the best idea if your input goes from {a;b;c} to {a;b;c;d;g;...;z}.
5. Have you any - even academic - plans (see 1) to walk the walk up to the end?. Meaning talking to Birdair/Taiyo Kogyo etc etc ( http://www.birdair.br.com/ ). If yes be prepared because these fellas work a bit differently as regards potential collaboration and feedback at design phase.
BTW: the thing that would change the world as you know it:
http://www.birdair.br.com/tensileArchitecture/tensotherm.aspx
best, Peter
…
rder to deal with the contents of the MERO structure (like glass, panels, polycarbonate). That is what the C# does already.
3. Vectors (a la "Umbrella" sticks) in order to place correctly your MERO nodes (the "hexagon" brackets - so to speak). That is what the big C# (the one that I've send to you some time ago) does already.
4. Calculations (lengths, angles) for each node against the other related nodes and the points derived from dividing the MERO square "tubes". For a given node these points are variable (from 2 [when in the "bounds" of mesh] to 6 ["typical" middle point, so to speak].
5. Demo block instances in order to see first hand what GH can actually do (that's WOW stuff: you slide a slider and "several" real-life components are placed in 3d space in real-time, he he).
6. Node connectivity data for the obvious (assembling the MERO on site).
7. Some assembly "simulation" capability (we do this today and this tomorrow ...)
So forget the single carrot (plenty carrots for you soon) for a while and answer to the most critical question: Based on what you've displayed to me (Skype) what is your policy against the MERO node itself?
I mean: we don't deal with a classic MERO ball type here (meaning variable drilling axis per ball). Meaning that the "hexagon" bracket (if I may use the term) IS VARIABLE. Meaning: you need a "module" that can being adapted against "every" possible (logical) angle value? (and compose the bracket?) Or you gonna fabricate the "brackets" on a per node basis?
And what if we had a planar glazing system? (same principle, more expensive, 100 times more WOW).
BTW: The best man in the world to do "similar things" with "hinged" custom aluminum systems (like doing the blue facade that you've displayed to me with some semi structural/structural system) he's a very close friend of mine. He's based in Dubai UAE.…