Grasshopper

algorithmic modeling for Rhino

Hi guys,

I have this mathematical function f=(2z+1)y+2(y-1)(x-z)

x is constant (eg. x=4)

∈ [1,4] for example

∈ [0,ymax-1]

So for y=1

z=0, f=1

z=1, f=3

z=2, f=5

z=3, f=7

for y=2

z=0, f=10

z=1, f=12

z=2, f=14

z=3, f=16

for y=3

z=0, f=..... etc etc etc

I have created the GH algorithm (attached), but I have trouble to run all the values of z range for y, before going to y+1 (loop in a loop). Do I have to set it up in VB?

Thanks in advance

Views: 1861

Attachments:

Replies to This Discussion

Very easy:

1. You have to write out multiplications, so it would be "(2*z+1)*y+2*(y-1)*(x-z)"

2. You just have to graft Y. Then it will use ALL z values for each Y value.

I have attached the working file. Also used the expression component rather than function, because you can then always see your formula.

Hope that helps :)

Attachments:

In your function you need to use " * " for multiplications.

And graft Y values to "multiply" one list with the other.

Damn Graft! Thanks both of you! As for multiplications, sorry, I missed them at the uploaded sample file :P

Er...hmm...this is a task for (extremely simple) code and not components.

he he

Attachments:

Thank you too!

errata

Hmm, I think I would also call that an extremely simple patch (using 5 components). Judging by the question he asked he is obviously fairly new to Grasshopper and its good to show him how to do it in Grasshopper, especially when it essentially took 2 clicks to fix his problem.

I dont really see the benefit of using a node based programming environment, when I then have components with code in it, which is not comprehensible unless you open it and look at the code. It breaks the logical readability of a patch.

There is also <NULL> benefit in terms of computing time, which is the only justification I can see for using code components other than for actually doing something that CAN'T be done in GH.

I think you are right Armin...

but also Peter.

As someone said in another discussion (maybe Peter), as time pass, with tools like GH, the "art" of coding (with if, for, stuff, etc) is being losen!

Like cars: today are more and more only electronics, instead, some years ago you could repair your car by yourself, with just an hammer and iron wire, today this is no more possible! (stupid example :P )

GH is very useful, but it's important to not forgot coding.

If John is new to GH, maybe he would like to learn also c#.

And with a simple specific example like the one Peter attached, it is the easiest and more direct way.

Yeah I see that point. And dont get me wrong I am not against written code. I also code in different languages and I like the art of coding.

But I dont see the point to introduce another language into GH when its absolutely not necessary and something can be solved with the tools available in less time than writing that code, while at the same time making the GH code harder to read or impossible to follow the logic (one of the main benefits of node based code is the easy comprehension) without going into the code, seeing whats happening, etc.

I dont want to sound harsh, because its a valid solution, but I really just don't see the point in this case. For me the art of coding is using a language to solve a problem and only introduce another when absolutely necessary. Using a different language just "because you can" is nonsense.

ps: John, unless you want to become a serious programmer, dont learn C#.

so which programming language would you propose?

Well, that really depends on which way you are going.

If you want to stay node-based go for vvvv. Its very similar to GH but much more universal.

For actual written code I guess Python would be the way to go for most things. Its even usable in a lot of 3D software (Maya, C4D, etc), but also other completely unrelated areas.

But yeah in the end it depends what you want/need to do or if its just for yourself, how much of a masochist you are ;)

Well ...

... given the opportunity:

1. I'm an engineer (Architect to be exact). I'm not a big fan of Academics. I hate theories (and big ideas). I also own a practice (I'm the major shareholder to be precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.

2. AEC Projects are made by teams. Period.

3. Teams are organized with some sort of hierarchy. Period.

4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)

5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).

6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).

7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ...  etc etc). 

8. Efficiency is above all (even above tax-free cash).

9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.

10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).

If you combine all the above you'll have the answer  (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.

PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).

best, Peter (Prince of Cynics)

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service