I confess) here's comes the pain (the actual reason about why we must handle this solely with code):
1. Imaging a collection of actions (i.e. do this, do that etc etc) that yield something. That something is some plots defined in the pizza space (plane in fact). OK big deal.
2. Why is not a big deal? Because we are talking about an instance among a vast combination of things that yield a collection of possible solutions (that ideally feed other stuff for validation of some sort).
3. So what sits above all? A decision my dear Watson: should all that (the design evolution "process" so to speak) being controlled by a scenario management thingy? Or we do business based on a fire-and-forget policy?
…
ich was used as an input for those arcs. I've changed it to a 3-points-defined plane, making sure the X-axis is perpendicular to the curve tangent and I think it works for any curve.
After fixing the arcs at the ends, the substraction of the circles works OK
I've changed the definition of the struts to be a surface, instead of a psurf. By doing so, I can join the rib and the struts to bake the together, making the rhino model simpler and easier to manage
So, the only problem remaining is this one: I can only set one curve at the time as initial curve. If I choose "set multiple curves", the geometry collapses. I could still do my project setting one curve, baking the geometry and then choosing the next, but if anyone has any idea on how to allow for multiple curves to be set, I'd be very glad to hear about it.
You'll find the modified file attached. IMG 3 shows what happens when multiple curves are set.
Thanks!…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
rcks. Some of these are inherent to the language syntax, others are mistakes in the respective development platforms. Here are my pet-hates for both languages:
C#
1) Case sensitive. Yes. C# is bloody case sensitive. That just makes it so much harder to use the intellisense properly, not to mention it is a bug factory. The only thing a case sensitive language allows you to do is declare functions and variables with the same name, but with different cases. I cannot imagine this is ever a useful thing.
2) Event syntax. Handling events is ok (though I still prefer the AddHandler, RemoveHandler approach of VB), but raising events is an f-ing nightmare in C#.
3) Curly brackets instead of keywords. Every source code file I have ends with a cascade of curly closing brackets. I much prefer the VB approach of End If, End Class, End Namespace. It's just so much clearer when I can see which end constructs means what.
4) It doesn't compile while I type, so any errors in syntax/logic only surface when I explicitly compile. This is annoying as it drastically increases the time I have to spend when fixing dozens/hundreds of compiler errors.
5) No optional parameters in function signatures.
6) Weird keywords like sealed, virtual, pure etc. I much prefer self-describing words like MustInherit NotInheritable, MustOverride etc.
VB
1) Parenthesis for both functions and arrays. Stupid stupid stupid stupid stupid.
2) The editor replaces my carefully crafter scientific notation to decimal notation. I type
Dim tol As Double = 1e-12
and it is replaced with
Dim tol as Double = 0.0000000000001
Someone please fire whoever thought this was a good idea.
3) Array indexing, declaration and looping. VB is consistent in that it always uses base-zero for array indexing. C# (and C and C++) mix zero-based and one-based syntax. So plus two points for consistency but minus 13 for making me write "-1" whenever I need to do something with arrays.
4) Can't remember what #4 was supposed to be, but there definitely was a #4... Anyway, when I think of it I'll append another post.
At this point in time I hardly prefer either language. I think on the whole they are both beautiful and the DotNET framework is a work of art (and pure genius). I use both languages extensively in my daily routine and I'm very happy with them.
--
David Rutten
david@mcneel.com
London, UK…
command in Rhino 4 to have the default editor (and F1 in there to open the help). It is setup as a large number of functions, all available in the form of Rhino.DoSomething(). Mostly, DoSomething is either Add or Delete an entity from the current document.
Grasshopper is a plug-in for Rhino developed and distributed for free by McNeel. It is based on RhinoCommon, which is the new .Net SDK - which is being written for the upcoming Rhino 5. Grasshopper provides all Rhino users with a powerful yet understandable interface for automating their tasks and exploring geometry though a visual interface. This might be called the Grasshopper visual programming language. The first step to learn Gh would be getting acquainted to this model. None of the Grasshopper components modifies the current document, only the Bake button does so. This and another reason mean that RhinoScript cannot be directly used inside Grasshopper.
RhinoCommon as a library is written in C# and Grasshopper itself is written in Vb.Net and C#.
Grasshopper offers scripting components that are compiled in debug mode, on the fly, just when you click "Ok", for both C# and Vb. Also, at McNeel we are testing ways to provide a Python interpreter via IronPython to Grasshopper. A nice advantage would be that variable input would also be acceptable in this model. Rhino 5 already has a Python interpreter for automating Rhino.
Finally, Grasshopper has a public yet (warning here) quite rapidly changing SDK. You can download it via the _GrasshopperGetSDKDocumentation command (comment: you need to load Grasshopper in order to see this Rhino command). The help file also explains how to setup your own components and make Grasshopper load them. This is useful for fairly non-conventional usages.
I hope this intro is helpful.
- Giulio
_____________________
giulio@mcneel.com
McNeel Europe, Barcelona…
using this weekend... I noticed that the last saved file I have from Rhino was in July where I had been using GH. I opened it and it opened in Rhino 64 bit. (I still don't understand why I have a 32 and 64 bit on my computer. I don't think I installed it twice. Do I need both?).. But, Grasshopper is not even a command in 64 bit when I open it now. So I checked the SR release on it and it is SR6. I vaguely remember updating the SR release when I opened Rhino a few days ago... But, again something seemed weird because I checked the SR release earlier when you asked me which one I had. So I checked the 32 bit Rhino and it says SR3... How is this possible? I thought that when I update the SR that it would update for both.Why would Grasshopper disappear when I updated to SR6 (On the 64 bit)? and would there be something affecting GH to make it run so slow? I had a very simple script that needed to sit for 5 min to go through. I was trying to get the area of 20 planar rectangles...…
Added by Jason Wheeler at 8:46am on October 27, 2013
e working okay however you may find there are bits that may not work. Trial and error I'm afraid.
The easiest way if you're familiar with Python is to use pip to install it via the cmd shell. However if you're not comfortable doing that you can simply download the source package from their website and extract the folder named 'bs4'. You can save this where ever you like but I'd suggest using the location below: C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\IronPython\Lib\site-packages
You then need to add that same path so Rhino will know where to find beautiful soup when you ask it to. In Rhino (not grasshopper yet) open the python editor with '_EditPythonScript' go to the tools menu>options and then add the path to the module search paths.
Press ok. Sometimes Rhino will need to be closed and opened again to effect this change. Next open your grasshopper component and you should be able to use:
import bs4
print dir(bs4)
Good luck.…
then I join the points making lines.
With the catenary component, I get a new bunch of curves that are gonna be lofted to create a funnel.The problem comes when I loft every branch. The data seems ok because every operation is made separately, but everyone of this lofts has 2 lines with the inverse starting point and ending point.
Why is it happening? all the lines are created same time and same way...In the image below you can see the flip during the loft.
Thanks for your time!
Ricardo …
could be finally fixed, he he).
focus to the saved view: 5 "ways" to skin a cat (all failed).
case1: the Python does nothing.
case2: Python turns red : what's the 6th element?
case3: the standard GH sweep2 component (does an open poly - no close sweep option available). In fact and since the sweep2 is the most critical component of them all (at least for AEC purposes) I wonder ... er....the obvious (i.e. "some" critical options are MIA, that is).
case4: forget this
case5: does nothing
BTW: yellow is made by baking the data and using the Rhino sweep2 (close = true). Turquoise is baked via the case3 GH component no close option available anyway (spot the "gap").
any ideas welcome
best, Peter
…