he time to work with it.
the project is about facade strips which turns along height. the top angle is
parallel to the facade and the bottom is max. 90 degrees twisted, but the strips
should turn diffrently to achieve more dinamic look.
first i have tried to achieve this by calculating distance between the rotation angle from points of the grid and a single point.
then i have tried to ad some more effecting points and used the distance to the divided surface (the circles are just to control the area of effection):
i manually lofted it.
the result is a bit annoying becouse the points that effect the angle are always visible:
i have triend to solve this by drawing a line and divided it to recieve points along the bottom of the geometry. the result is not working properly:
Anyway,
there must be a better/smoother way to achieve this. i would like to effect the twist of the surfaces by distance to a spline, but im just lost. can you help me please?
the problems im encountering:
0- distance spline to grid to effect the angle
1- list of x/y coordinates and angle of rotation for each point of the grid
2- export points to excel
3- lofting lines in one direction only (x1, x2, x3...)
4- reduce the list data to 2 decimal (0,00)
5- maybe angle from radian to degrees
thx…
e some questions.
I want to loop with a foreach loop trough a list of points do i have to make a list before or is it possible to use them coming in from a noed i set the access to list?
Also i dont understand why no plane is created. How do i need to feed the points in?
And why is c# expecting open parens in line 88 and 86?
Hope its not to much at once, probably i should try a few less steps to get the problems solved one by one, just hoped it would be easier and sometimes just a parentesis is missing or some format stuff, so maybe it is not so much i really cant say.
If anybody has the time and feels he wants to help it would be nice on the other hand i understand cause of the amount of chaotic questions.
Regards!…
t BBox will then be mapped relative to the UVW space of that box to the new target boxes.
Where your definition is slipping up is the data matching aspect of GH. You have two lists (that count). One list contains 100 items of target boxes and the other contains 2 items of geometry. GH defaults to the Longest List data matching
List A --> List B
Target Box A0 --> Cuboid
Target Box A1 --> Cylinder
Target Box A2 --> (Oops List B has run out of items. Now GH will repeat the last item = Cylinder)
Target Box A3 --> Cylinder
.....
Target Box J9 --> Cylinder
Solution
There are two approaches to rectify this the most logical would be to group the geometries into one object (What you had in mind with the bounding box) to do this use the Group Component on the Transform Tab > Utility Panel.
The other approach is far more common in GH mentality. Use the Graft, right click the G input of Morph and select Graft from the Context Menu. This places all of the items in the List on to separate branches. Creating a list of lists (although these new list only have one item). When GH now tries to data match them it will apply the whole of the first geometry list (Only the Cuboid) to all of the target boxes and all of the second list (Cylinder) to the target boxes again.
I hope this helps…
finite element line with
start point
end point
id
cross-section (optional)
local coordinate system (optional)
some property (optional)
some other property (optional)
additional settings (optional)
etc
Now in 99% of the cases, users will only specify the first 4 parameters and leave the others blank. I'm not a huge fan of to many inputs so to clean up the canvas/components, I thought about exposing the optional parameters only upon zooming in on the component.
So far I've sometimes added a secondary component with more inputs to specify a list of additional settings (similar to the "settings" panel that exists/existed in Kangaroo), but this I find rather messy.
Alternatively I guess I could quite happily live with exposing the additional parameters at the click of a button. This I can do with the ZUI as it is written? I still need to get my head round what's what in this happy world of the canvas' third dimension...
…
e the meaning or posting "ready" (kinda) solutions in response to something asked in the code related forum? (that could be rather ridiculous: Greetings code freaks: a user - that you've never heard of - asked this and I did that ... utterly ridiculous).
Now .. if a request comes from a novice either a component based solution or a freaky one ... well ... they have a very limited usage (if any usage at all) on a per se basis: because only time combined with a certain experience could yield the required ability to deal with issues before happening.
On the other hand ...to tell you the truth I believe that's far easier for a novice to get some "basic" programming skills and deal with his/her issues (who are in 99% of cases data management related ones) than to attack them via components.
On the other hand I believe that in the future (not the distant one) ... anyone involved in this ugly business AND not speaking some freaky language he could be rated as class D citizen (brave new world: here we are).
But that's a highly personal opinion (extreme to the max, as usual, he he).
PS: I don't think that the majority of posts here come from novices (yesterday a fellow user asked a very challenging thing: the one with the max rectangle).
take care …
u are posting in the wrong place.
99% of the posted questions in the general discussion forum are from novice grasshopper users who have lack of very basic knowledge.
In my opinion, the best response to these posts is providing the simplest (easiest to understand) solution to the problem, plus an explanation of why the definition wasn't working, plus some suggested fields of study.
On the other hand, you provide a very fancy solution, which gets the job done (and usually a bunch of other jobs as well), but there is 0% chance it will be comprehended or further developed by the OP...
This is the typical giving_fish_VS_teaching_how_to_fish debate.
As for the "please ignore me if you enjoy being primitive" argument, I am afraid it is not as simple as that. A post with 3-4 replies (which, in this case, would be 3 subsequent versions of your solution, plus an awkward "ehm, tyvm" from the OP) has a great chance of going unnoticed by anyone who could provide a gh solution...
And finally I have to point out that the right place for coding discussion is just a doorstep away.
cheers,
a not-pissed-off co-member of this forum …
Added by nikos tzar at 8:29am on February 15, 2015
ostly via C# because ... er ... the remaining 99% (how to do some real-life canopy and/or a real-life truss out of the relaxed line graph) is only doable via code - no ExoW/IL (so ... the 1% is indeed doable).
At first ... just double click the Kangaroo1 engine, halt the simulation AND ONLY THEN redirect the resulting line list to the ExoW/IL. As delivered neither is active.
Note: ExoW and/or IntraLattice MAY or MAY NOT work (each one has his own issues, but ExoW despite the glitches yields way better looking liquid stuff). So the liquid root may or may not be the holly grail that you expect (life sucks).
Note: As is delivered this only does a liquid node load bearing structure (ideal for Planet Utopia). Paint the thing black, do some proper pavement, populate with birds of pray, wait for the envelope def (that's freaky), put humans inside, lock the doors > massacre.
…
narity constrains as well. Let's over-simplify the case. Using that planar test data set shown we create a classic Adjacency Matrix that tells us what node is connected with what (you can use Sandbox for making the connectivity required in order to make the Matrix) :
Some other freaky thingy gets the Matrix, does freaky things (using recursion) and finally yields node indices that belong to a closed loop/cycle (see the forefront and the back). The other indices shown (describing "bigger" loops) are used for other type of stuff/checks:
More soon…
to perform the kind of merge I want. Basically:
I have a series of three integers, each representing a radius measure:
Radii[0-2]
I have a three sets of series of 3Dpoints, each set with ~100-400 vals:
PListOne[0-333]
PListTwo[0-333]
PListThree[0-333]
I want to link the data paths up so that the Radii form the first dimension of the array, and that the second dimension is the corresponding points set. So
Radii[0] = 500 (the radius)
Radii[0][0] = 50,75,0 (the first point in PListOne)
...
Radii[2][99] = 44,66,0 (the 100th point in PListThree)
This should be really simple, but I cant seem tog et my head around the right components to do it. I've attached a file with number series in place of the radii/points lists. If someone could show me how to merge the components in the manner above, it would be extremely appreciated.…
all the other rules.
2. No Flattening! use path shift / trim tree instead of flattening.
3. No Path Mapper! I have never met a data operation with the path mapper that could not be achieved through relative means.
4. No Simplify! It makes things *look* nicer but believe it or not those zeros are meaningful and shouldn't just be eliminated. If you are OCD about the way your paths look, then Path shift after every operation that introduces a new branch level (a new "0" at the end) IF AND ONLY IF you are sure that in the case of your definition the component will always function "1 to 1" - that is, for every single input there is only one output.
5. If you absolutely must flatten (to take a global bounds, or generate random values for every item, or whatever) be sure to Unflatten before continuing.
6. Design for the worst case - start with primary inputs in the most complex data structure your definition is likely to need to be able to handle (a tree for instance) rather than a single item.
If you follow the above rules, 99% of the time your definitions will respond appropriately to any change in upstream data structure. If you want an example of how this works in practice, post your definition and I can help find "relative" approaches to the "absolute" things you are currently doing. …