Grasshopper

algorithmic modeling for Rhino

Well, friends

I'm trying to control some slider values via scripts. But I'm having some issues with the cast matter (see script).

Any help could be greatly appreciated

best, Peter

Views: 1238

Attachments:

Replies to This Discussion

OK, that was stupid

some (more stupid) questions soon

Hi peter,

Attached is how I modify sliders, for a project where I needed to check 150 vertices for correct joints - modifying a slider correctly becomes a bit of a difficult task.

Attachments:

Hi Arend

Thanks. In fact, maybe, I have a "similar" issue:

What I'm looking for is an approach to set a slider's value to 0 ("reset" it , so to speak) and then allow the ModifyPoints function shown to accept any value provided from that slider from that "reset" point and on .

It doesn't work at all (GH loops infinitely, see def attached and the slider - obviously - is locked in the sense that doesn't provide any value to the function).

This is a test from something far more complicated - the slider stuff/puzzle is in the main section of that script captured below.

In sort: the script creates some data (mode = create) and then interactively modifies/deletes that data (mode = modify and/or delete). Points are used for simplicity. Each time that a point is to be modified (in this simple test: the Z value) the slider that controls the Z input must start from a "neutral" 0.0 value (in order to respect the previously created values).

I'm in a jelly fish mind state right now (GH SDK is ... er ...hmm...)

Attachments:

And this is why the interactive tree/list manipulation is the most critical thing for engineering purposes: see the version prior fully(*) implementing ways for individually modifying anything that belongs to a list/datatree (mast heights, cable anchor points, membrane cone definitions, cone modes, cables, dogs, cats etc etc etc).

(*) assuming that I can get the gist of the slider "reset" and wait for me little thing, he he

forgot the definition

Attachments:

I've encountered similar problems. Sometimes there's a need to take a closer look at what going on, and configure individual elements.

Here's my solution. I call it the SphereMaker (c)(tm)(r)(wtf).

It works like this: given a random set of points (1), we want to control the radius of each sphere individually.

[Note: this could be done with a Gene pool, of equal the size of the list, but it's an incredibly crappy way to control your design. In the design case it was about choosing corner solutions for a design that's about 10mx10m, where the corners - may or may not have an error in the corner of it's offset. Given +/- 300 corners, a gene pool becomes a 'suboptimal' solution]

So: we want to keep a list, that's just a big as that random set of data. So we start out with a 'good guess'. this is our initial data, and we can check it one by one. (2a, 2b)

We can walk through the items using the slider manipulators (3) (forward and backward), and set the value of the currently selected item using save. There's a niftly little viewport manipulator that makes sure the viewport zooms into the item we're currently looking it (may, or may not be useful for your case). (4)

Attachments:

OK, let's narrow my issue:

Goal is to set a value of a given slider (of type NumberSlider) triggered by the event(s) of value change occurring in other sliders.

But I confess that I can't figure out how to do it. Should this work?

GH_Component.SolveInstance(IGH_DataAccess.GetData<double>(nickName, ref val));

Any help could be greatly appreciated.

Attachments:

Something like this? You can set the tickvalue of the slider to 0, it will reset it to the minimum value.

Attachments:

...Something like this? You can set the tickvalue of the slider to 0...

Well...

it doesn't work (see definition and simple instructions about how it"works" - added a bool toggle that enables/disables the "reset" slider thing).

Did some minor mods as regards finding the sliders (based on their NickNames, grouping is out of question in a def with 123,45 sliders, he he).

So ... we have a function ...

... that "monitors" the "master sliders" and if they change ... supposedly resets the "slave" slider, yes?

No, I'm afraid: it doesn't work at all (the loop???)

Attachments:

Hi peter, can you take me along a step back, for which problem is this the solution? There seems to be quite a lot of creative use going on for use of datatrees and points to define actually what seem to be some kind of other shaped datastructures, right?

Hi Arend,

Appears that the tickvalue can cut the mustard (thanks, I own you a big one) - I'll perform some mods as regards the "influenced" slider (easy: filtering should be based on some kind of name - nickname is rather the best approach - and not on active group, but that's irrelevant anyway).

Step back (assuming that you are talking about the "Tens_from_random_blah_blah" definition):

1. Engineering is the art of demystifying (or we are promising that anyway, he he). This means that you start defining (better: outlining) some topology for things based on some "generic" rules (like the ones applied for the masts,cables,cones etc etc). These things are kept in some kind of structure (Lists, DataTrees etc). Things are few in 99.99999% of cases (i.e. : even the biggest membrane "module" has, say, 20-50 masts per "module").

2. Then ... handling things "individually" (mostly modifying) becomes the most critical part. See this (an x "possible" solution by combining a myriad of "options" : a no cones membrane solution, in plain English):

3. But the above is impossible (for more than obvious reasons). You should deploy masts in some high/low sequence in order to achieve some meaningful convex/concave formation that could work.

4. This "works" :  5. This doesn't:

6. This works partially (the formation at the back is "flat" == undo able):

7. This is utterly kitsch (and faulty as the case6 - the back portion):

So it's quite obvious that without a (quite complex) capability to individually control things (in this occasion : mast heights) the whole definition is a waste of computer time. Additionally the more the solution is "demystified" (some curve is defined, some random points are created, some masts are in place, some cables appear etc etc) the more additional constrains are required in order to "narrow" the possibilities (In plain English : sliders should control other sliders as regards their min/max values, true/false, you/me etc etc).

Remember that we are talking about ONE (mast height) out of a myriad things that you should control "manually" (it's utterly pointless to mastermind some kind of "generic" rules - or use naive attractors etc etc) .You'll see the difference when I'll completely reform the definition by adding individual control upon anything.

PS: what about the blocks? (the real life stuff that actually make any solution possible). Can you imagine a 2nd set of "restrictions" imposed by "a  child to his parent"? (Assembly/Component modeling , that is).

more soon

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service