algorithmic modeling for Rhino

Hi all and especially hi David/GDT, since this mainly goes to you.
It's the first time i'm suggesting features, and believe me, it is only after thinking a lot about the ease of implementing/usefulness of them. If they were already suggested and deemed impossible, i apologize.

First, it would be really cool to have a right-click menu item for any geometry retaining module, that does the following: bakes the geometry, then disconnects all inherited data from the module, and assigns the baked version as locally defined. This is a one-time only thing, of course - it would be cool because if you have a "step-definition", that is, you have clear bottlenecks in your dataflow, and at some point you become satisfied with what you have so far, and only need to manually tweak some stuff to move on, you can discard the "already solved part of your definition. It's just a sort of "casting in stone" of partial results, that helps especially with simple work-defs or helper-defs. You could also call it something kickass like "manual override" or "emergency/hand b(r)ake".

Second, if you have a component that outputs to a lot of others, and you want to change it with something else, you usually have to painstakingly reconnect all those wires, and if it doesn't work out, you do it right back or undo until you fingers bleed. Just as there is an extract parameter upstream for locally defined values, a downstream "extend parameter" with one rightclick menu item would make switching between various components easier.

Third, maybe a hot-key that you press and then click on a wire, which creates a "data" component at that point, splitting the wire and effectively allowing you to hijack it.

Lastly, maybe this is a stupid question, but what happened to the "clusters"? I mean i know they ended abruptly because of technical difficulties, but collapsing a group to a single component like that was totally awesome.

Oh, and a minor bug repor from the v7.053 - it's not important, but mildly annoying: when you have an embedded graft, flatten, reparam or expression into a plug, the component extends to the left with the nifty little icons, and that looks very nice, but the wires still go in the old place, so at first glance i always think the wires are plugged in wrong. Is it possible to move the plug along with the component icon edge, or at least make those little indicators smaller, so that the error is minimized?

Thanks for your time,
Hope i was pertinent
Andrei I.

ps: the lolcat component is adorable, but i do believe that overall worldwide grasshopper productivity has dropped by various increments of those 20 sec it takes for it to refresh. Sadly accustomed with the feeling of guilt associated to watching around 50 lolpics refresh, I suggest that every 5 refreshes or so, you get a "stop looking at this and get back to work" message. It is at least a good way to derogate responsibility for tempting people to watch kitty-pics all day. :D

Views: 238

Reply to This

Replies to This Discussion

Hi Andrei,

good ideas all.

The wire connecting bug has been fixed in 0.7.0054. You can double-click on the LolCat component to force an immediate update.

HandB(r)ake would be indeed quite easy to implement, but I'll need to write a mechanism for detecting wires at mouse clicks before I can go into that. I'd also like the ability to disable a specific wire at some point, or change the display properties of it.

Clusters were nothing but a display trick, and a nasty one at that. When I rewrote the core it would have taken a lot of time to re-implement that horrible hack. It needs to be done properly this time. I know it's an important feature which is sorely missed at the moment...


David Rutten
Poprad, Slovakia
:D oh you shouldn't have told me that about the LolCat's like giving a chimp a lol-machinegun. :D See, the really tempting part about it is that from a reasonable distance it looks like you're working, and no browser is open, so one can abuse it like the perfect crime.

Also, forgot to mention another idea which is pretty simple and straightforward: is there a way to hide the edges in the grasshopper preview? Like if you have a bunch of joined breps or something, and you only want to see the borders, not the internal edges of the whole thing. Right now, even if you use custom preview, the internal edges always show up. I'm talking about a sort of a "rendered view" preview mode, in addition to wf and shaded which doesn't necessarily need to render anything, just hide the automatic edges of surfaces/breps, while still drawing curves. (that way i can use brep-edges/En to still get a feel of the final geometry without baking it)

So, thanks for the excellent feedback, and I'll see you in a couple of days at the conference in Vienna! :D
another idea: would be super useful, instead of the markov widget, to have a custom toolbar kind of how the Corel Painter 11 has them, where you can drag your most used components, be they custom or standard and use as an "all-purpose-pallette".
Another interesting interface feature, which can, in itself solve the first issue, is to have a quick and easy way to split the GH window in 2, and run 2 defs in parallel, (or 2 viewports of the same def). Coupled with the possibility to configure GH to start with a template instead of "new", this would give a great "personalised workspace" feeling to any user. You would have you own little set up tools, bits of algorithm, whatever. I mean, a pallette would be cooler, by i'm guessing this is easier to implement and can be useful for other stuff.
Your second and third suggestions (especially "extend parameter") would be very very useful!
thanks. i actually thought about them ever since the 5.00.x versions, but i didn't have the courage to speak up :D
i'll do that more often from now on.





© 2018   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service