algorithmic modeling for Rhino
Hello,
perhaps would there be someone willing to publish an advanced tutorial for data matching? After a couple of weeks with GH I've grown to love it, but creating specific types of tree structures in order to have components interact with one another in desired patterns is still mostly puzzling to me, and I cannot achieve what I want even after hours of trying different ways.
I usually have to resort to splitting up all my data into several individual components, so that I have full control over who does what. You'll be able to tell that this is a waste of time though, or usually even impossible in the first place if you require a variable count of paths depending on sliders you change at the beginning of your definition.
So thank you to whoever might fancy putting up a video tutorial here.
Tags:
Amen.
Your problems are precisely the type which - now quite prophetically - I commented on recently. I suggested improvements to data management in GH that would benefit new users in particular by creating a more consistent and predictable logic. Essentially it would entail a dynamic GH address system.
If you're interested:
http://www.grasshopper3d.com/forum/topics/gh-addresses-just-me-or-u...
However, my take on it is that unless you've grown-up with GH and have 'evolved' with its peculiar ways of data management/control, you're going to be forever fighting a lost cause in A. Trying to understand it to your benefit, B. Convince the fanbois there are areas in urgent need of improvement. Just wait for the backlash when instead of agreeing that data management could be improved, you get accusations of 'trashing' GH. Clearly there's a problem here as you - like me - are not the first to highlight the shortfalls in respect to this matter, and you most certainly wont be the last.
You might be surprised to find that many of us here that you'd like to categorize as uncritical fanboys are equally comfortable working in purely script-based environments. Indeed, data structure in gh has evolved over the years, and often as a result of informed suggestions and criticisms that come from the user community. In your last discussion, it was simply apparent that you either didn't understand why it works as it does, were trolling, or had just made up your mind before you posted that data structure as managed in gh represents a failure. If I remember correctly - and please tell me if I have mistaken you for someone else - it's been a past practice of yours to engage rather confrontationally with the forum, whether it has been to extol the general limitations of visual programming or to describe your belief in its data structure's intractability. In these discussions, you resort at the last to name-calling, and it's rather clear that, your mind made up before you came, your opinion isn't likely to change. You miss a great deal as a result.
newy011 forgot your login and password ?
There's no getting around the fact that data structure in gh is challenging. That said, if you understand how it works, it gives grasshopper an extremely high degree of flexibility, in terms of being able to manage objects and perform extremely complex operations across multiple and diverse instances. There's also no getting around the current fact that grasshopper has appalling documentation, in general, and in particular, in terms of how data structures work and how you can use them.
Some resources as they stand now:
http://lab.modecollective.nu/lab/working-with-data-trees/ This one costs some money to access all of the videos, but at least there are a few available for free, and they can get you started.
http://www.grasshopper3d.com/forum/topics/path-mapper-help-1 A general overview of how to use the path mapper...this is useful for getting some understanding as well.
If you go to the tutorials section, you can find other videos that engage in data structures as well (here, for example: https://vimeo.com/album/2282897/page:2/sort:preset/format:thumbnail)
I do think that better documentation about how and why data structures do what they do is critical for McNeel to get a handle on. There is clearly a great deal of misunderstanding out there about them, and unfortunately, at this point, the only real way to figure it out is to forge through on your own. Definitely post your definitions, and people are likely to help you out as well.
Thanks David, that helped, especially the advanced Path Mapper illustrations.
Having used GH a lot since my post, I found that most of the time your job is to restructure data so they will match a certain tree pattern which then renders them eligible to become your desired component's inputs. This can often take a lot of time for me though.
GH would need more flexible "look inside, understand your data" functionality to put an end to the continuous panel opening, param viewer checking or list-item selecting (to verify list order). All these, combined with the added "show/hide preview" switching, multiply to a great amount of time, which I find unfortunate, even cumbersome and tiring once you dive into a longer GH session. Thankfully GH offers a minimum of mouse-hovering information already at this stage of development, yet I find this is far from enough.
Some tree transformations I am still unable to do. For example: how would you reverse a tree's branch order without reversing individual item indices? For trees that have only one item per path, I found "Flip Matrix" with reverse, simplify (if necessary) and then graft (to establish initial structure) works. However this won't work once you have more than one item in each path obviously.
I also find insertion of individual items into specific branches of already existing trees to be quite difficult. The most useful component I found has been "Partition", because it is the only I can think of allowing a flexible list length within branches.
Anyhow, I'm getting there. It's just frustrating sometimes how most of my time with GH is spent on data matching, rather than using actual geometry generating components.
Hey Chris, those two look great. I'm always confused though when people don't use the component names and instead icons only. What's the name of that last component? Don't think I've used it before.
Could you attach the *.GHs?
Sets>Tree>Replace Branches
In defence of the criticism i seem to be getting off the fanboi 'zombie horde', note that the above set of posts post has actually come from another GH user and echo's my words. Also, I never resort to petty name calling in my posts. While I will openly admit my tone can, at times, be provocative, I believe everything I post is based on fact or fair assessment and is unbiased sensible debate. Its obvious; GH needs to improve its data system, new users simply don't get such surreptitious data management and control mechanisms.
newy011, ayg011, ayg011(bis), AnewGHy, similar names, similar trolling arrogant behaviour, similar self superiority complex, similar way of writing.
Oh yeah they are obviously not the same guy. Sorry. And calling people "fanboi sombie horde" is not petty name calling at all. But calling people paranoid schizophrenics would be.
Anyway, a forum would it be a forum without a troll ?
So thanks for being here.
Now you are right, data management needs to be improved. But if one has to deal with data , one has to know (at least a bit) about programming. No software can guess automagically what the user wants if there is some complex data operations involved.
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson.
Powered by