glass panel).
2. This actually means that the parts on duty they don't differ that much. Meaning that we can use an "average" size (and "local" topology) acting as the Jack for all trades.
3. Meaning that we can effectively solve the abstract topology with an abstract app the likes of GH and then place in properly defined coordinate systems all the real-life bits and nuts ... closely "emulating" a pro solution (that could "adjust" the parts as well).
4. This means that one particular C# needs more lines of code since as it is it defines cable axis on a per nod to node basis ... but in fact these are defined as the min segment between curves (circles to be exact).
5. Additionally the end part of each strut differs depending on how many pairs of stabilizing cables are used (either 2 or 1). Meaning some lines of code more for defining the proper coordinate systems for the instance definitions.
6. This is the reason that I've postponed mailing to you the 4 horsemen (because PRIOR finishing the whole you MUST define what parts to use: the classic bottom-top design approach).
But in order to receive the Salvation (aka: Apocalypse) you MUST answer correctly to a simple puzzle:
Provided that money is no object, pick your car:
1. Ferrari 245 (Less is more)
2. Lancia Stratos (Lethal).
3. Cobra 427 (Men only)
4. Ford GT40 (Mama mia)
5. Ariel Atom (Mental)
6. Aston Zagato GTB4 (Sweet Jesus)
7. Fulvia HF Fanalone (THE racer)
8. Lambo Miura (Enough said)
9. Lotus Elise (Just add lightness)
10. Alfa Romeo 8C Competizione (In red)…
13;2} ... 20.{13;12}
21. {21;0}22. {21;1}23. {21;2} ... 41. {21;20}
42. {34;0}43. {34;1}44. {34;2} ... 75. {34;33}
76. {55;0}77. {55;1} ... ....
I want to grab the first 8 [0-7], the next 13[8-20], the next 21[21-42] etc
so i have the (known fibonacci seq) list of numbers on the left here:
C S
8 0
13 8
21 21
34 42
55 76
89 131
144 220
233 364
and i need the list on the right, so that i can select items using a Series (N=1 and S and C from the list above) and a List Item component.
the simple question is:
is there a component that can take a list and accumulate it in this way that I need?
if not, is there anyone that can point me to a simple relevant VB example so i could easily adapt it?
many thanks,
gotjosh…
he start point.
Generation (2) i have 4 points + (3*3points) = 13 points.
Generation (3) i have 13 points + (9*3points) = 50 points.
But when i bake the python component i have 157 points ? Why ?
What's the logic behind this ?
Also how can i have in a, lists of points according to generations and for exemple in b lines according to generations too ??
Here's the code:
import rhinoscriptsyntax as rsimport random as rr.seed(seed)
def Main():....allGenerations = []....allGenerations.append(startPt)....curGeneration = []....curGeneration.append(startPt)....for i in range(gens):........newGeneration = []........for pt in curGeneration:............ang1 = r.randint(-30,30) ............ang2 = r.randint(90,150) ............ang3 = r.randint(210,270) ............dist1 = r.randint(10,40) ............dist2 = r.randint(10,40) ............dist3 = r.randint(10,40) ............zV = -1 ............newPoints = branch(pt, ang1, ang2, ang3, dist1/(i+1), dist2/(i+1), dist3/(i+1), zV) ............newGeneration.extend(newPoints) ............curGeneration = newGeneration ............allGenerations.extend(newGeneration)....return allGenerations
def branch(pt, ang1, ang2, ang3, dist1, dist2, dist3, zV):....ptP1 = rs.Polar(pt, ang1, dist1)....ptP2 = rs.Polar(pt, ang2, dist2) ....ptP3 = rs.Polar(pt, ang3, dist3) ....ptA1 = rs.AddPoint(ptP1)....ptA2 = rs.AddPoint(ptP2)....ptA3 = rs.AddPoint(ptP3) ....pt1 = rs.MoveObject(ptA1, [0,0,zV])....pt2 = rs.MoveObject(ptA2, [0,0,zV])....pt3 = rs.MoveObject(ptA3, [0,0,zV]) ....ln1 = rs.AddLine(pt, pt1)....ln2 = rs.AddLine(pt, pt2)....ln3 = rs.AddLine(pt, pt3) ....return [pt1, pt2, pt3]
a = Main()
Thanks for you replies and sorry for my noob questions...
…
o sensor Shield V5.0 - 2 standard servos (plugged into pins 9 and 10 in the sensor shield) - 7.5V wall power supply - USB cable to computer
I'm running Rhino SR 8 on a 32 bit Windows Vista machine I have Version 0.9.0014 of grasshopper (the latest) and Firefly_Build_1.0067 I have flashed my Arduino board with the latest firefly firmata (updated September 10th, 2012)
I have checked that I am using the "MEGA write" box I have got the right bits going to the right pins and I have checked that they all have "servo" ticked instead of "digital" or "pwm"
My servos and board work perfectly well with the normal Arduino software, but just not any longer with firefly since my computer was switched off.
The port shows correctly as COM 4 and opens fine.
When I move the slider to control the servos, the TX light is on and the RX light flashes, but no servos move... (everything works with the sweep example in arduino though, so I have eliminated power and wiring issues)...
Any ideas what might be the problem?
I've tried re-installing, switching off and on many times, changing cables, trying a different board (also doesn't work any more with the duemilanove), trying all pins on the shield, trying one servo without the shield, trying one servo with the shield, lots of googling, lots of searching forums, unblocking the firefly installation files in explorer, lots of things... I'm all out of ideas... And very confused as it was working just a few days ago... Am I just missing something really obvious or could there be an issue with the software at my end?…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
s is the "circularity" of the sections of the ellipsoid by the planes. I measure that by sampling points on the sections, finding their centroid, getting max and min distance to centroid, and trying to minimize the difference between max and min. (As sections are ellipses, I think its accurate enough).
In this example, optimal section (one of the circles in the screenshot below) has a difference between min and max radii of about 9 e-5 , radii are about 10 units, so its not a perfect circle, but not so far.
Then I saw something on the net about families of circular cross sections, so I thought I could try to get some planes parallel to the optimal cut plane found by Galapagos, and cut the ellipsoid to see the results, screenshot shows that .
The radii delta is 1.47 e-4 on average, so it looks like its an infinite family of "circular" cross sections.
Of course there is (are?) another family, as the ellipsoid is symetric.
Important notice: I am not an expert at all in this stuff, just experimenting, so don't trust this at all.…
hat software I use: Microsation, AECOSIm (BIM), Catia/SiemensNX, Generative Components (slow, faulty, almost dead), Quest3d (boy! this is from planet Zorg) and GH (good fun but NOT for "strict" AEC matters). I use numerous other stuff for fun as well.
4. Do I use Modo for other than fun? No ... because I hate subdivision modeling (but this doesn't stop me from admiring a stunning product made by the best out there).
5. Am I a Bentley man? Yes (and no).
6. Does Rhino need a "top" rendering thing and/or Nexus? No.
7. Does Rhino need Quest3D? Yes.
8. Can Rhino do AEC things? No (but can act in a third violin role).
9. Should Rhino target AEC? Yes (requires a lot of money, mind).
10. Should GH target AEC? Yes (see n9).
PS: still renderings are previous century stuff: there's the next century going on now (from what I'm told, he he). Do people know that? No (as usual).
best, Peter…
" overlapping conical Breps (maybe I should fire him and hire Me). His excuse: an awful case boss, I'm so sorry.
3. Viruses are too small and/or terrain too big. Consider putting giant sardines (of the finest quality) or mega-goats (cool) or Ducati melted pistons (the norm).
But even if The Lord takes care of the C# and this, this, this and that happen (yielding a "fine" mesh with 1Z faces) > what could be the anchoring policy on that mess in order to achieve the vault goal?
Moral: ResetNowForEver…