rectly except for the first material in a series. See attached image... Here is my code:
Private Sub RunScript(ByVal M As Object, ByVal C As Color, ByRef AddName As Object, ByRef AddMat As Object, ByRef AddBool As Object, ByRef baseName As Object, ByRef newMatName As Object)
Dim z As String = "newMatName" Dim y As String = "BaseName" Dim x As Integer = 0 Dim nRestore As String Dim mTemp As Rhino.DocObjects.Material
mTemp = CType(M, Rhino.DocObjects.Material) y = mTemp.Name Dim nTemp As String
If mTemp.Name.Contains("_MOD_R") = False Then
nRestore = mTemp.Name nTemp = mTemp.Name & "_MOD_R" & C.R & "_G" & C.G & "_B" & C.B mTemp.Name = nTemp z = nTemp mTemp.DiffuseColor = C
If Doc.Materials.Find(nTemp, True) < 0 Then
Doc.Materials.Add(mTemp) x = x + 1 AddName = nTemp AddMat = mTemp
End If
mTemp.Name = nRestore
End If
newMatName = z
AddBool = x BaseName = y
End Sub
1) I have checked that all of the materials I am calling by name exist in the document and that data matching is correct. There doesn't seem to be anything special about the offending material except that it is always the first material that was added to the document by my script.
2) The main thing I was missing in the previous script was the "doc.Materials.Add()" -- how on earth should I have known that existed? Even a search for "doc.Materials" in the Rhinocommon SDK doesn't turn that up. I'm having a very hard time using the SDK to my advantage, it seems not to correlate to the actual code I need to write.
2b) Perfect example... now I am trying to rewrite my other component (which exposes all of the document materials) to set a few objects manually in Rhino with the Materials I want to use as templates. Now I am trying to find out how to access the material assigned to an object. Seems easy, but it's clearly not a Property, and I can't find an appropriate Method in either the Objects or Materials classes.
3) One of my problems originally, when feeding the component one material and multiple colors, was that the nTemp variable was not resetting properly for the second color. Same thing if I duplicated the material to match the list of colors. It would create a material on the first pass but concatenate "_MOD_R_G_B" in each subsequent pass and be caught by my String checker. Why is that? I thought that the nTemp Name variable would be reset in each pass by the line "mTemp = CType(M, Rhino.DocObjects.Material)" and "nTemp = mTemp.Name" combination.
Does the mTemp material somehow carry over its properties in each successive pass? That's why I added the nRestore to be sure each pass reset the name back to the original.
Still, I wonder if there is some problem with the way I am conceptualizing this that is causing the first material to be the same as the input material.
Thanks for your help on this...
Cheers,
Marc…
Python and install it and it should work fine.
2. You still see the image above in case 1 however you have GHPython already installed. What about that?
In this case probably the GHA component is blocked. Find GHPython.GHA on your system (usually at: C:\Users\%username%\AppData\Roaming\Grasshopper\Libraries) . Right click, go to properties and select unblock.
To make sure that GHPython is working fine on your system open the attachment file (testGHPython.gh). You should see something similar to the image below on your screen when you open the file:
If you see the something similar you should be fine to go! Try to open one of the example files.
3. You have Ladybug running but in some of the case the output is missing. You see something similar to this:
or this
This one is because you are using old version of GHPython. Close the file without saving. Download the new version and install it and re-open the file. It should work fine now.
Hope it helps,
Mostapha
…
ated in all editions of Architektura Parametryczna Workshops!Architektura Parametryczna Workshops Optimization Warsaw 2016 FAQWHEN?21-22nd May 2016 (Saturday-Sunday)HOW LONG DO THE WORKHSOPS LAST?The workshops last in total 16 hours.Saturday 10AM -7PM (with lunch break), Sunday 10AM -7PM (with lunch break)WHAT WILL I LEARN?On Saturday the optimization processes with solar, views and structural analysis will be explored. We will be discovering optimal solutions with the help of plug-ins such as Galapagos, Silvereye, Octopus, Karamba and Ladybug. In the Sunday morning we will learn how to present the results of the optimization: creating catalogues of solutions and printing the optimization graphs. In the afternoon participants will have time for the development of the personal project. HOW MUCH DOES IT COST?The workshops cost 600 PLN (or 160€) for Early Bird payments and 700 PLN (or 190€) for the regular payments. The 3-person group - 1500 PLN (or 440€ )EARLY BIRD?For those who are certain that they will attend the workshops, we have a special Early Bird offer till 30th of April 2016.HOW CAN I SIGN UP?Send an email to info@architekturaparametryczna.pl with the title: “OPTI WAW 16”.HOW MANY PLACES ARE AVAILABLE?We have only 11 places!WORKSHOPS: Level: intermediate – advancePerquisites: the basic knowledge of Rhino and Grasshopper3D. Plug-ins: Silvereye, Octopus, Ladybug, Karamba. Weaverbird. Python GHThe main aim of the 16-hour workshops is to give the participants the understanding of how the optimization process can be used in practice and how it can help in solving everyday design problems. The practical exercise will be supported with the short lectures explaining the theoretical background of the optimization algorithms. The general program of the Optimization Warsaw 2016 Workshops*:1. Optimization of the facade geometry with solar analysis.2. Optimization of the roof structures with Karamba.3. Finding the optimal configuration of the space frame structures with Karamba.4. Discovering the best location or/and geometry of the building in accordance to the best views from the plot.5. Presentation of the discovered solutions. *Some of the exercises might be changed.…
tion for dividing the surface evenly in both directions:
Again, the definition is quite simple:
"A" shows standard uv-isocurves division, the result indicates that we're dealing with quite a nasty surface - the domain is very unevenly distributed.
"B" shows my solution for the same surface (copy), which consist of these steps:
1. retreive one set of iso-curves (u or v, you can toggle which)
2. divide each of them into equal segments
3. use the resulting division points to form new pseudo-iso-curves
4. divide those curves into equal segments
The result is quite nice, but there's one downside to it:
It varies depending on the starting set of curves you choose (u or v) - use the toggle button to see the difference, especially for really unevenly distributed parameter spaces.
The reason why this happens is that steps 2-4 listed above are just the first iteration of the formula. If we repeat the process several times, we should get basicaly the same result starting with "u" and "v".
With the use of receivers copying the iterating part of the definition is really simple:
Of course making iterating definitions in Grasshopper is a total nonsense, it was just a quick way to check my idea.
One thing you've got to bear in mind is that I'm no math expert and this solution is based just on a hinch and intuition... so It's possible that it would jump into a stable state (if scripted) or something...
If you like my solution and you don't come up with one which doesn't requiere iterations, you can always post a message on the VB and C corner, maybe someone could code it for you.
Ok, I think that's enough for today, I've pretty much exhausted the subject on my end :)
Let me know how the definition works for you.
Cheers,
JJ
--
as for the akward curves when using different step size and count: it's no big deal, those are just the curves which fall outside the surface domain. remember that the input parameter N in the series component is inverted (expression is: 1/N)…
se to not expose the boundary condition as a curve parameter. You have to supply a Box instead. You can set the box simply by clicking the right mouse button over the "B" parameter and choose the "Set one Box" menu item. The intersection between the Box and the Plane will become the outline condition.
Extruding the shapes is a bit trickier, it involves manipulating Data tree structures. This is not trivial, but it is important. Your best friend here is the ParamViewer object (Params -> Special). It allows you to inspect the layout of a data structure in memory.
First of all, lets perform the Voronoi + Offset operation and see what we get:
The ParamViewer object that is plugged into the Voronoi output states that the data is structured in a single list of 17 items. The path of this list is {0:0}, but we'll deal with that later. The output of the Offset component is not the same at all. That output is stored as 17 different lists with one item each. The reason for this is that it is technically possible to offset a single curve and get more than 1 result. This is why Offset complicates the data structure.
Before we can turn the curves into surfaces, we need to make sure that the layout of the two data structures (the voronoi curves and the offset curves) is identical. We can achieve this with 3 additional components:
The Graft component complicates the voronoi curves in the same way as the Offset component did. The Simplify component removes all redundant branching information from a data structure, so we are left with the simplest representation that still maintains all the information.
Now we have both curve sets stored in identical lists, which means that when we feed them both into a Planar Srf component, it will treat each voronoi curve and the associated offset curve together:
I'm not surprised this is confusing you. It is a very complicated topic. We'll probably need to come up with better matching algorithms for data structures, better ways to display the data in a human-friendly form, better ways to manipulate the structures. If you have any suggestions, I'd be happy to hear them.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 2:32pm on October 4, 2009
ike using something like the Z vector, but technically you can use any vector you want. This vector will actually determine the static rotatation of all the planes, so you can control that here if you like. One important thing that I've noticed is that the closer the vector is to the plane of the curve or if its too similar to one of the tangent vectors, the more likely you'll have "flipping"
2) Take the cross product between the tangent and the static vector. This will be your first perpendicular vector, which you can use for the X component of the plane.
3) Take the cross product between the tangent and the result of the previous cross product. Use this result as the Y component of the plane. All three components (X, Y, and Z (which is the tangent vector)) are all perpendicular to each other now.
After you've done that you should have planes that decrease twisting. If your curve is not planar, then there will always be some twisting in the frames, but it will be minimal enough to use them effectively.
There also may be "flipping" within the frames, which means one (or both) of two things. First, you could have planes that have reversed their vectors, so the X vector is properly oriented, but pointing down when it should be pointing up. Second, the X and Y vectors could have potentially swapped, so that Y "should" be X and X "should" be Y. In order to check these things, you'll need to do a few tests. The first one is find out whether the vector (X or Y) of the plane your testing is pointing in the opposite direction of previous vector. The second test is to find out whether the vector (X or Y) of the plane your testing is perpendicular to the previous vector. In both cases, an angle test between the two vectors will be able to tell you what you need to know, but you will likely NEVER get exactly 180 for an opposite test or 90 for a perpendicular test. That means that you have to choose a range with which to determine that a given vector is opposite or perpendicular.
You should start testing the X vector to see if anything is wrong. If you find that the X vector is fine, then just move on because Rhino will only allow you to create right handed planes, and the Z vector (the tangent) will always be the same.
I don't believe that there's a native function within the old dotNET SDK for calculating angles, so use the example at the link below. It basically takes the arcCosine of the Dot Product of the two vectors your testing to return the angle in Radians. I'm not sure if this function is included in RhinoCommon or not....
http://wiki.mcneel.com/developer/sdksamples/anglebetweenvectors…
filled out with data only once the cluster is put to use.
It's very much like writing a subroutine in a programming language, if that analogy means anything to you. Let's say you write a function that converts a piece of text to UPPER CaSE, except for all the "a" characters. It might look something like this (in a made up language):
subroutine SpecialUpperCase(text)
upperCaseText = ""
for each character in text
if (character = "a")
upperCaseText = upperCaseText + "a"
else
upperCaseText = upperCaseText + ToUpperCase(character)
end if
next character
return upperCaseText
end subroutine
This subroutine defines a behaviour, but it requires input to actually do something. Which means you can never get this thing to do something on its own. Only after you insert it into an existing program will it run.
Now I can definitely see the point of being able to edit a cluster while it's operational and I can probably figure out a way to supply the data from 'beyond the veil' so to speak, but there are some things to keep in mind:
1) Clusters are not meant to be like layers, where you can choose to hide portions of a document without disabling them. Clusters are meant to be like blocks. You change one instance, you change them all, even perhaps instances of that cluster in other files.
2) If you open up a cluster that is used multiple times in the document, which data should I provide by default? And should I supply all 10,000 curves you've got in your 'real' document or only a single one so you can see if the cluster works?
3) Clusters are still very much unfinished. The editing part is not working. You can create them and explode them, but it needs a much better interface for changing the contents of a cluster. Also it is currently impossible to 'instantiate' clusters and have them all be the same platonic object. These features however are planned.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
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
…
d 5000 stiffness it usually works quite well but some overlap. If you put it much higher than 5000, it freaks out and explodes.
2. In order to make the spring network, it must create a spring between every circle and every other circle. This is a lot of springs. With 121 initial points, you have 7260 springs! On my old laptop, anything more than 200 points runs very slow.
3. You can swap between random and gradient radii with the toggle. See the note about swapping between large radii in center vs small radii at center.
Random Radii Start
Random Radii End
Large Radii at Center Start
Large Radii at Center End
Small Radii at Center Start
Small Radii at Center End
…
ot of other things to happen).
It begins a threaded version check to see if a newer version is available for download.
1 and 3 are clearly not needed for you to get it to work, so all the important stuff must happen in step #2. When showing the Grasshopper main window, the following things happen:
Grasshopper.Instances.ComponentServer method is called and if it returns null then the whole thing aborts. This is typically when you see the Grasshopper banner and the loading progress bar.
If the Instances.DocumentEditor field is empty, it will create a new instance of the window and assign it to Instances.DocumentEditor.
It will then make sure that if the window is visible, it is also within the bounds of the screen. This is useful for when a second monitor becomes unplugged.
If the window was hidden, it will show it.
To answer your earlier question: "Is there a way to know whether Grasshopper is done initializing?" the answer is yes. Grasshopper initialized on the main UI thread so unless your code is running in a thread you created, you will not be able to do anything while I initialize. You call Instances.ComponentServer and by the time the function returns initialization is over and done with.
"waiting for IscomponenetServer to become true" This is not useful. Either IsComponentServer is false, in which case you need to call Instances.ComponentServer to make it true, or it is already true in which case calling Instances.ComponentServer just returns the already existing server. So you might as well call Instances.ComponentServer directly and cut out the middle man.
However, if you plan to open files, you will also need the main editor window up and running or there will be no place to put these files.
So I think ultimately you're right in calling the _Grasshopper command, as it does both things that need to be done in order for you to open files and run solutions. However, you should be able to use LoadEditor() or ShowEditor() from the RhinoScriptInterface object as well, they do the same thing.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:56pm on October 22, 2012