basis" problem ... all of a sudden - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:
http://www.grasshopper3d.com/forum/topics/array-1
4. Why this MITESIGF is MITESIGF? For 2 reasons:
4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :
4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively: you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.
Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).
Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).
more soon.
best, The Troll
…
strictly with code (BTW: did you crossed Rubicon?).
1. See this: Imagine a curve (say a "rail") that is divided N times and then circles are created with random radii. Circle control points (9, that is) are sampled (obviously) into a DataTree where branches are the rail divisions. Let's call the control points: "start" seed points.
2. Imagine a capability ... that stores all these (the original "seed" control points) into a "parameter" and then each time that a change occurs to them (varying the x/y, on a per point on a per branch on a per plane basis[that provides the Z]) stores the "modified point" into the parameter (at the same index with the old: meaning "deleting" the old) ... and then some other code gets that data and makes curves and lofts them. Reset means: sample again the original "seed" points into that "parameter". Closing are reopening the definition has no effect: the lofted stuff is derived from the (internalized, so to speak) modified points (from the "parameter").
3. A variety of "automation" is available: for instance if you jump from branch to branch and from item to item the value of the selected point is inquired and the sliders that control the new x/y are "set" to 0,0 (meaning no change - yet) values. There's mo "store" mode: it works automatically as far as you modify points or you hit the reset button
4. This does that (only achievable with code):
5. Obviously points can been replaced with anything ... and thus ... we can individually modify items in collections ... and forget for ever attractor points and all that (OK where appropriate, he he).
I'll post 30 similar examples soon in the forthcoming mother of all threads: "GH goes (at last) interactive". Watch this space.
BTW: study the "animation" where points with index 6 are "sequentially" modified. I've added some delay in order to give you time to get the gist of the whole thingy.
best, Lord of Darkness
…
you post a screenshot of what the message coming from its readMe! output looks like?2) Close your Grasshopper and Rhino.3) Download "Revo Uninstaller Pro" from here. It is free for first 30 days, which is what we need.4) Right click on the RevoUninProSetup.exe and check if the file is blocked. If it is, unblock it.5) Run the RevoUninProSetup.exe file and install "Revo Uninstaller Pro".6) Uninstall "MapWinGIS" with "Revo Uninstaller Pro". It is important that "Revo Uninstaller Pro" deletes not only files from MapWinGIS installation folder, but also all other leftovers (as registry inputs). Here is a small tutorial on how to do that. Watch it from 6:10 till the end.7) Restart your PC8) When your Windows boots up, make sure that you are logged in as Administrator!9) In your Start menu's search box type: "UAC", which will find your User Account Control Settings. Click on it, and a new window will open. Set the bar on the left to "Never notify".10) Turn off your Windows Firewall.11) Then turn off your custom Firewall (in case you have another one, besides standard Windows Firewall).12) Completely turn off your Antivirus.13) Download again the MapWinGIS-only-v4.9.4.2-x64.exe.exe file from here.14) Right click on the MapWinGIS-only-v4.9.4.2-x64.exe file and see if it is blocked. If it is, unblock it.15) Right click on MapWinGIS-only-v4.9.4.2-x64.exe file and choose: "Run as"... Administrator.16) One the installation preparation steps start, choose "Full installation". Wait for the MapWinGIS installation to finish.17) Right-click on "Rhino 5" icon and then choose: "Run as administrator".18) Open the the ironpython_admin.gh file again, and again post a screenshot of the message coming from its readMe! output.19) Drop the "Gismo Gismo" component to Grasshopper canvas. Post a screenshot of the message coming out from its readMe! output.
So we will need in total three screenshots of the readMe! output messages.
Thank you once again for being patient, and sorry for the large number of steps.…
Added by djordje to Gismo at 1:52am on April 9, 2017
nderstand each other quite well.
I will pick one piece of the PVsurface at the bottom row:
So the label "1" represents the PVsurface for which the shading diagram will be created.
Label "2" is the back facade (made of glass or opaque elements, does not matter).Label "3" represents the row of PVsurfaces above.
Now take a look at how the shading diagram would look like for the mentioned PVsurface. I made some of its parts a bit incorrect on purpose, so that I could clearly the differences a bit easier:
Label "1" would be first type of self-shading. It's the shading which prevents the PVsurface to "see" anything behind its back.Label "2" would be shading from the facade wall to which the PV surfaces are attached to. I deliberately colored it blue, to distinguish it from other two types of the shading. Otherwise it would look black.Label "3" is the second type of self-shading: the shading from the above row of PV surfaces.In literature, you won't find the terms: first and second type of self-shading. I invented them.To my knowledge, when self-shading is mention, this will probably be related with label "3" (second type of self-shading). It's the shading from the adjacent rows of PV modules in front, or like in this case above.So when I said:
You do not have to supply the surfaces additionally to the context_ input. The component will "under the hood" add them to the context_ input to account for self shading. Last year this hasn't been the case, but after the suggestion by Chris Mackey, I changed this feature.
This was related to the first type of self shading (label "1").
And when I said:
However, as we are using the PV SWH System size component, there will be no self-shading. The PV SWH System size component positions the PV rows in such a way, that no self shading will appear for the given minimalSpacingPeriod_ criteria.
This was related to the second type of self shading (label "3").
I should also mention that I made the upper photo a bit incorrect. If you would do the shading analysis, the label "3" would be almost non-existent. Here is how the shading diagram would actually look like:
As mentioned this is because PV SWH System size component will position each PVsurface row in such a way, so that there would be no second type of self shading for the chosen minimalSpacingPeriod_ criteria. In our case, as the minimalSpacingPeriod_ criteria we chose the summer solstice in the Northern Hemisphere from 10 to 14 hours. We should have taken from 9 to 15, but we took from 10 to 14 to as on option of lowering the distance between the PV rows.This means that there will be no second type self-shading all year round from 10 to 14 hours.
Let me know if all of this helps in any way.…
Loop'. The fun part of the slower version is that you can see what it's doing while it's running. 'Fast Loop' gives no indication that it's working, so you want to test it with small numbers and be sure it's coded properly before bumping the iteration count up.
The GH profiler running the slow version showed between 1 and 1.5 seconds per loop, but the reality was more like ~10 seconds per loop toward the end of an 11 X 11 grid, or ~20 minutes total. It's easier to be patient because you know it's working.
The 'Fast Loop' finished the same grid in 1.6 minutes! An impressive improvement. I've been running it on a 30 X 30 grid (900 points) for ~23 minutes so far and see nothing yet. Not the ~12 minutes I had hoped for... Now 36 minutes on this loop for 900 points... hope it's not stuck. Not fast! Later - DONE!! Profiler says 59 minutes for 900 points but it was more like an hour and twenty minutes total. It succeeded, I have a single 'Closed Brep' from 900 extruded rings, baked to Rhino.
Another strategy to explore would be doing 'SUnion' on a smaller grid using the Anemone loop, then replicate it by moving it as needed to form a larger grid; then run the copies through another 'SUnion' loop. I went ahead and implemented that while waiting. It works and is fast! Started with 3 X 3 and ran the result again as 5 X 5 (9 X 25 = 225 total) in barely ~70 seconds!? Trying 36 X 36 now... 1,296 points appears to have succeeded in less than ten minutes! Though it seems to take quite awhile after the loop ends before control is restored to GH/Rhino. I'll let you do your own experiments and benchmarks.
I encapsulated the loop in a cluster called 'suLoop' (blue groups).
Internal of 'suLoop' cluster:
…
Added by Joseph Oster at 11:14pm on March 22, 2017
ion date p: file path r: revision count v: Grasshopper version l: list of add-ons used"""
def Main(): global f, d, a, c, p, r, v f = ghenv.LocalScope.ghdoc.Name d = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Description a = gh.CentralSettings.AuthorName c = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Date p = ghenv.LocalScope.ghdoc.Path r = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Revisions.Count v = gh.Versioning.Version l = 1
Main()
The first question is that I'm bouncing between gh. and ghenv. for different things - can I/should I be more consistent? Are there consequences?
The second question is that I'm trying to pull the list of add-ons (variable "l") used in a definition. This data exists in the ghXML in the Library chunk:
<chunk name="Library" index="0"> <items count="4"> <item name="Author" type_name="gh_string" type_code="10"></item> <item name="Id" type_name="gh_guid" type_code="9">9d96da9c-9354-ef32-7983-0acb11a3d493</item> <item name="Name" type_name="gh_string" type_code="10">LunchBox</item> <item name="Version" type_name="gh_string" type_code="10">2014.4.27.0</item> </items> </chunk>
Any ideas on how to get that bad boy?
Thanks!
B…
e actual method.
Below, I descibe how they work:
1) drag "scheduleDay" onto the canvas
2) drag some Gene Pool lists onto the canvas and connect a number slider - from 0 to 3.
3) connect the Gene Pool list to _genePool input. The component change some important features of the Gene Pool list automatically. Now you have LB_GenePool!!
4) choose the template that it's suitable for you.
5) disconnect LB_GenePool and if templates are not good, you can change them manually
6) drag "Ladybug annual schedule" onto the canvas
7) Connect LB_GenePools to inputs for the days of the week, Epw file and if you want to "_holiday" (in this way you consider holidays). Now you have your simple schedule.
8) a small workflow to visualize it into Rhino..
9) Connect "Ladybug annual schedule" to "Honeybee_Create CSV Schedule" to make your csv Schedule
You could make a schedule more complex than the one in the example above.
You can do that with _analysisPeriod input.
Bests
Antonello…
imes. Your loop should go to y.Count - 1. Or, you could use a For...Each loop, circumventing the problem altogether:
Dim shortLines As New List(Of Line)
For Each segment As Line in y
If (segment.Length < x) Then
shortLines.Add(segment)
End If
Next
A = shortLines
--------------------------------
Another problem is this line of code:
New_Lines.Add(New_Line)
It is located inside the loop but outside the If statement, meaning it gets run every single iteration. This fills up the short line list with duplicates.
-------------------------------
Here's something else which is redundant:
Dim Input_Line As New Line
Apart from the fact that you don't need a special variable for this at all, you also don't need to add a New keyword. The type Line in RhinoCommon (just like Point3d, Vector3d, Plane, BoundingBox etc. etc.) are Structures, not Classes. Structures always exist when they are defined, whereas Classes can be null ("Nothing" in VB).
-------------------------------
Some more advice:
Dim i As Integer
For i = 0 To y.Count()
You can merge these two lines into one. VB.NET allows you to declare your iteration variable inside the loop:
For i As Integer = 0 To y.Count - 1
--------------------------------
If you don't like the For...Each approach at the top of this answer, here's how to write this using a For...To loop:
Dim shortLines As New List(Of Line)
For i As Integer = 0 To y.Count - 1
If (y(i).Length < x) Then
shortLines.Add(y(i))
End If
Next
A = shortLines
ps. A personal preference of mine is that I always encase the expressions inside If...Then statements in brackets. You technically don't need to do this, but I find it makes the code more readable.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…